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
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
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
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
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
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.
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Lauri Kasanen -
Michel Dänzer -
Rob Clark