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

[Emil Velikov]

On 13/02/14 08:58, Maarten Lankhorst wrote:
> Hey,
> 
> On 11-02-14 05:26, Emil Velikov wrote:
>> 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
>>   - 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.
> Thanks, I've been meaning to do his myself but didn't find the time yet.
> Up until 7/13 look good at least. and 11 looks like it could be
> committed too.
> 
Thanks to having a look :)

Patch 11 causes all radeons to reuse the existing screen between api's,
which I'm not sure is the right thing for opencl.

> The rest would need some more testing than simply reviewing the code and
> looking for obvious bugs. :-)
> 
> Would it help to change the vdpau abi? I have a patch in my vdpau loader
> to look for an entry point similar to the one used in megadrivers, but
> it could be changed to add the name of the library too as argument.
Not entirely sure that such a change is needed but I would not mind
taking a look. Does this patch live somewhere public ?

>> 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.
> swrast never worked right with vdpau, good riddance. :-)
>> 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.
> If pipe-loader is used for dri, then that problem will fix itself
> without needing exports. ;-)
Quite possible, never tested it thus I presumed it is 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.
> Hooray, removing all duplication is a good thing!
You're welcome

Overall:
There is Jakob's IRC R-b for the first ten patches, and the comments
I've heard so far were for the last 2-3. I'm planning to commit 1-10
next week, as they squash some annoying bugs.

Then take a look at creating megapipe, and integrate that with the rest
of this series.

-Emil
>> 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.
>