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