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

[Rinat Ibragimov]

Понедельник, 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.


[1] http://cgit.freedesktop.org/~aplattner/libvdpau/tree/src/vdpau_wrapper.c#n104
---
Rinat