Required backwards support level?

Required backwards support level?

[Lauri Kasanen]

Hi,

Obviously old userspace + new kernel combo needs to be supported. But
I'm not so sure about a mixed case, does old userspace + new userspace
need to be supported to run at the same time?

For example, a new 64-bit mesa+libdrm and a 32-bit old set, both
running apps at the same time.

Or is it acceptable to assume that once a new userspace has been run,
an old one won't be run for this boot?

- Lauri

Re: Required backwards support level?

[Rob Clark]

On Sun, Apr 6, 2014 at 8:26 AM, Lauri Kasanen <cand@gmx.com> wrote:
> Hi,
>
> Obviously old userspace + new kernel combo needs to be supported. But
> I'm not so sure about a mixed case, does old userspace + new userspace
> need to be supported to run at the same time?
>
> For example, a new 64-bit mesa+libdrm and a 32-bit old set, both
> running apps at the same time.
>
> Or is it acceptable to assume that once a new userspace has been run,
> an old one won't be run for this boot?

old 32b userspace in a chroot, for example?

Maybe you can give a better description of what you are wanting to do?
 Could you decide on 32b vs 64b userspace on a per 'struct drm_file'
basis (ie. each time /dev/dri/cardN is opened)?

BR,
-R

> - Lauri
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Required backwards support level?

[Lauri Kasanen]

On Sun, 6 Apr 2014 10:53:58 -0400
Rob Clark <robdclark@gmail.com> wrote:

> On Sun, Apr 6, 2014 at 8:26 AM, Lauri Kasanen <cand@gmx.com> wrote:
> > Hi,
> >
> > Obviously old userspace + new kernel combo needs to be supported. But
> > I'm not so sure about a mixed case, does old userspace + new userspace
> > need to be supported to run at the same time?
> >
> > For example, a new 64-bit mesa+libdrm and a 32-bit old set, both
> > running apps at the same time.
> >
> > Or is it acceptable to assume that once a new userspace has been run,
> > an old one won't be run for this boot?
> 
> old 32b userspace in a chroot, for example?

Yes, for example.
 
> Maybe you can give a better description of what you are wanting to do?
>  Could you decide on 32b vs 64b userspace on a per 'struct drm_file'
> basis (ie. each time /dev/dri/cardN is opened)?

This is related to my memory management work. As the VRAM queue is
global, it cannot be determined on a per-app basis. If at least one
client is running old userspace, the new scoring cannot be used.

Switching live between the two would bring additional complexity. I'd
hope to be able to determine by the first 3d app if the userspace is
new enough. But that depends on if it's expected to be able to run
mixed loads.

- Lauri

Re: Required backwards support level?

[Daniel Vetter]

On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen <cand@gmx.com> wrote:
>> Maybe you can give a better description of what you are wanting to do?
>>  Could you decide on 32b vs 64b userspace on a per 'struct drm_file'
>> basis (ie. each time /dev/dri/cardN is opened)?
>
> This is related to my memory management work. As the VRAM queue is
> global, it cannot be determined on a per-app basis. If at least one
> client is running old userspace, the new scoring cannot be used.
>
> Switching live between the two would bring additional complexity. I'd
> hope to be able to determine by the first 3d app if the userspace is
> new enough. But that depends on if it's expected to be able to run
> mixed loads.

At least thus far we've worked under the example that any
explicitly-enabled new behaviour is only enabled per-fd. That's also
useful when you install all your developer versions into a prefix, so
still have 2 versions of X driver, libdrm, mesa, everything else lying
around and want to switch at runtime even.

Can't you fake a default score somehow for all legacy userspace and
always run with the new code? Reimplementing the old interfaces in
terms of the new ones also allows you to kick out duplicated code
(usually) compared to having both old and new code around.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: Required backwards support level?

[Michel Dänzer]

On Son, 2014-04-06 at 15:26 +0300, Lauri Kasanen wrote:
> Hi,
> 
> Obviously old userspace + new kernel combo needs to be supported. But
> I'm not so sure about a mixed case, does old userspace + new userspace
> need to be supported to run at the same time?
> 
> For example, a new 64-bit mesa+libdrm and a 32-bit old set, both
> running apps at the same time.
> 
> Or is it acceptable to assume that once a new userspace has been run,
> an old one won't be run for this boot?

I'm afraid not. Trivial counter-example: Build Git snapshot from after
your changes, hit regression (not necessarily related to your changes),
run git bisect involving snapshots from before your changes.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Required backwards support level?

[Lauri Kasanen]

On Sun, 6 Apr 2014 19:58:48 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen <cand@gmx.com> wrote:
> > This is related to my memory management work. As the VRAM queue is
> > global, it cannot be determined on a per-app basis. If at least one
> > client is running old userspace, the new scoring cannot be used.
> >
> > Switching live between the two would bring additional complexity. I'd
> > hope to be able to determine by the first 3d app if the userspace is
> > new enough. But that depends on if it's expected to be able to run
> > mixed loads.
> 
> At least thus far we've worked under the example that any
> explicitly-enabled new behaviour is only enabled per-fd. That's also
> useful when you install all your developer versions into a prefix, so
> still have 2 versions of X driver, libdrm, mesa, everything else lying
> around and want to switch at runtime even.
> 
> Can't you fake a default score somehow for all legacy userspace and
> always run with the new code? Reimplementing the old interfaces in
> terms of the new ones also allows you to kick out duplicated code
> (usually) compared to having both old and new code around.

Certainly, that can be done. 

- Lauri