[Mesa-dev] Convert vdpau and dri targets to the pipe-loader

[Christian König]

Am 11.02.2014 05:26, schrieb Emil Velikov:
> Hello list,
>
> The recent patches from Rob gave me a nice kick to give another stab at
> integrating the pipe-loader into the vdpau/dri targets.
>
> What:
>   - With these patches one library will be created for hardware and one for
> software driven backends - eg. libvdpau_gallium_dri, libvdpau_gallium_sw

Just drop, the software driven backends. I was about to remove them anyway.

>   - Each library can use every possible pipe driver, determined at runtime.
>   - To get the dri (galliumdrm_dri) or vdpau library working create hardlink
> (or symlink) to it (libvdpau_nouveau.so -> libvdpau_gallium_dri.so)
>
> Why:
>   - Smaller overall size while having no extra exported symbols. This is
> a nice method of us to share most of gallium (read mesagallium and
> aux/gallium) without exporting every symbol either one to those two contain.
>   - Drop the multiple duplicated
>   - With those done, some additional symbol cleanup can be made using the
> linker. The stripped size of pipe_nouveau and pipe_swrast decreased by
> ~0.6MiB, downto 2.2, 1.2MiB accordingly. With similar results on other
> libaries.

NAK, at least for the VDPAU drivers that doesn't sounds like such a good 
idea to me.

Reducing the number of exported symbols can be archived otherwise and 
giving up their self containing without any external dependencies just 
to save some extra space on disk doesn't sound like a valid reason to me.

Every extra installed library increases the likeliness of version 
clashing, so for APIs that doesn't distinct frontend from backend by 
themselves (like OpenCL, OMX etc..) pipe-loader indeed makes sense, but 
for APIs that can distinct that on their own it doesn't really make any 
sense to me.

Christian.

>
> What has been tested:
>   - (st/dri) nouveau and swrast were spinning glxgears and nouveau was
> glretrace-ing lol, dota2 and portal traces.
>   - (st/vdpau) nouveau - tested using mplayer in benchmark mode. no
> significant changes were noticed. swrast was broken while using vdpau,
> as to why it was dropped a while back.
>
> What has not been tested/known to be broken:
>   - (st/dri) currently the drm_configuration() and the driver options
> (__dri2ConfigOptions) are not wired up.
>   - (st/vdpau) the driver specific create_winsys are not exported by the
> vdpau library, thus gl-vdpau interop is not tested and possibly broken.
>   - Resolve all the linking between the library and all backends
> nouveau_dri.so -> galliumdrm_dri.so
>   - Scons and drivers having multiple winsys (i915)
>
> In the weeks ahead:
>   - Cleanup/resolve the above issues
>   - Tackle the remaining two st (omx and xvmc), which should be trivial.
>   - Compact the dri/drm and dri/sw state-trackers into a single library.
>
>
> Please let me know how you feel on the subject, and as ususal some
> testing including opencl, gbm, egl and gl-vdpau interop would be greatly
> appreciated.
>
>
> The complete patchset can be found in the pipe-loader-to-all branch over at
> https://github.com/evelikov/Mesa/
>
> Note: the first 10 patches should be fine as is as.
>
> Cheers,
> Emil
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev