On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen <cand@xxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
