On 22 January 2016 at 18:15, Christian König <deathsim...@vodafone.de> wrote: >> Form autofoo perspective things look great. > > Thanks, that exactly what I wanted to know. > >> Although I second Ilia's concern - we need a form of runtime detection >> here. Pretty much all distros ship the vdpau(+ other video driver >> backend) in a separate library. Thus this will likely get us nowhere >> we want - as I'm suspecting this is to assist the unsuspecting user, >> which hasn't installed package X or Y in the first place ? > > As I said, Mesa should NOT check what vdpau backend libraries are installed > or used before advertising NV_vdpau_interop. > > Take a look at how the interop works, NV_vdpau_interop should be advertised > if the OpenGL implementation provides the necessary functions. What and if a > VDPAU backend gets loaded to work with that is completely independent of > this. > I never said that one should check for vdpau ;-) I was thinking more of "does the backend driver provides a way for vdpau to work" - i.e. radeon/amdgpus and nouveau export the extra entrypoint that allows you to share the winsys but others do not. There is also the, as you know better than me, version (miss)-match of dri and vdapu modules, which also should be checked at runtime ?
> We want to switch over to a DMABuf based interop implementation so that we > can get away from using the Mesa internal structures. > > This not only has the advantage of fixing this ugly hack, but also would > allow an application to decode on one driver (radeonsi) and display with > another one (r600). > Moving towards dmabuf is a great thing. I was suggesting that we add a comment/reference about the current state of things. Seems like my example set your blood boiling - sorry about that. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
