[Intel-gfx] [PATCH] Add second DRI driver name (DRI2DriverVDPAU)

[Eric Anholt]

Rinat Ibragimov <ibragimovrinat at mail.ru> writes:

> Понедельник, 26 августа 2013, 16:22 -07:00 от Eric Anholt <eric at anholt.net>:
>> Rinat Ibragimov <ibragimovrinat at mail.ru> writes:
>> 
>> > Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt <eric at anholt.net>:
>> >> Ибрагимов Ринат <ibragimovrinat at mail.ru> writes:
>> >> 
>> >> > libvdpau uses second DRI driver name to determine which VDPAU driver
>> >> > to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
>> >> > with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
>> >> > I'm experimenting now with generic vdpau driver using OpenGL/VA-API,
>> >> > it would be convenient to have this driver selection working without manual
>> >> > driver selection.
>> >> 
>> >> If it's a generic driver, why would it need a "i965" string passed over
>> >> the DRI2 protocol to find it?
>> >
>> > It doesn't actually. It's just to simplify distribution package management.
>> > If one names driver libvdpau_nvidia.so.1, it will break VDPAU on
>> > nVidia equipped machines. With this patch one can name it
>> > libvdpau_i965.so.1 and driver will be loaded on intel equipped
>> > machines only.
>> >
>> >> 
>> >> One of the things I'm planning on doing is removing use of the
>> >> protocol-provided DRI2 driver name from Mesa -- Mesa knows what drivers
>> >> it has built, and it knows how to detect those devices (in the EGL
>> >> code), so why would we pay attention to what the X Server thinks our
>> >> driver's name is?  Seems like vdpau could probably do the same.
>> >> 
>> >
>> > VDPAU uses entry point library (libvdpau) which loads backend drivers.
>> > libvdpau uses second DRI2 driver name amongst other methods to determine
>> > which driver to load. It can not rely on Mesa's internal knowledge, because
>> > it must work with proprietary nVidia driver too.
>> 
>> Right, I meant "couldn't libvdpau have a method to determine which
>> driver to load based on looking at your hardware, like how Mesa's EGL
>> does?", since only libvdpau is likely to know how pieces of hardware map
>> to driver binaries.
>> 
>
> VDPAU drivers have separate code from libvdpau, while Mesa have drivers
> inside it (if I get it right). I can't figure out how libvdpau beeing separate
> can determine mapping between hardware and driver to load. The only way
> is to ask[1] DRI2.

Yet the Xorg 2D driver is even less related to the set of vdpau drivers
available than the vdpau driver loader (which could do things like look
at a symbol in the driver to find a probing mechanism, like the X Server
does to X drivers, or read some config directory containing mappings
installed by the external drivers).

The reason I'm making a point of this is that DRI3 is dropping the
driver name strings from the protocol.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20130828/4ca1ef95/attachment.sig>