Rinat Ibragimov <ibragimovrinat@xxxxxxx> writes: > Понедельник, 26 августа 2013, 16:22 -07:00 от Eric Anholt <eric@xxxxxxxxxx>: >> Rinat Ibragimov <ibragimovrinat@xxxxxxx> writes: >> >> > Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt <eric@xxxxxxxxxx>: >> >> Ибрагимов Ринат <ibragimovrinat@xxxxxxx> 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.
Attachment:
pgpncJ4FJO8Vr.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
