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. > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
