On Thu, Sep 6, 2012 at 4:25 PM, Koen Kooi <[email protected]>wrote:
> > Op 6 sep. 2012, om 15:04 heeft "Burton, Ross" <[email protected]> het > volgende geschreven: > > > (CCing oe-core, discussion should happen there really) > > > > On 6 September 2012 11:00, Andrei Gherzan <[email protected]> wrote: > >> In DISTRO_FEATURES we have opengl. That is pretty vague and generally we > >> don't want to have mesa on machines where there is no libgl but only > gles + > >> egl. For example if we want to compile something that adds a DEPENDS > based > >> on DISTRO_FEATURE opengl, this dependency will be added even if there > is no > >> libgl implemented for that specific machine. > >> > >> First idea would be that opengl (gl / gles) are machine related. On the > >> other hand opengl can be a DISTRO_FEATURE as we have a software > >> implementation - mesa. > >> > >> How would you guys see a solution for this? The idea that came into my > mind > >> was to map opengl to libgl or libgles. Or to both if there is the case. > > > > (First I must apologise for the uneven flow of this mail - my mornings > > been pretty choppy but hopefully people can see what I'm thinking) > > > > I've been thinking about this quite a lot recently, as the current > > setup is broken in some way on most hardware. There is a bigger > > problem than just distro or machine features - the packaging isn't > > obvious or correct either. > > > > First, we need a concrete definition of the "opengl" distro feature. > > I propose just "some form of OpenGL functionality" without any > > implications about what specification is present. > > > > Then, machine features for the portions of OpenGL that the hardware > > supports - gl, gles1, gles2. I'd love to say "gles" means GLESv2 but > > I suspect we're not quite safe from the horrors of hardware that only > > supports GLESv1 yet. > > > > We then need more virtual providers for the GL libraries. Mesa is an > > obvious provider - it provides libgl, libglesv1, libglesv2 and libegl. > > On Raspberry Pi the binary drivers provide libglesv1, glesv2, and > > egl. As the performance of the software renderer will be terrible, > > unsetting the libgl provider makes a lot of sense. > > > > Because there are multiple providers of the GL libraries, and they are > > not all specific to a single machine, every package that provides GL > > packages need to be namespaced. The Debian-renaming makes this > > trickier but luckily it can be overridden in the recipe, so Mesa > > should be building libgl-mesa, libegl-mesa, and so on. Every other > > provider of the GL libraries should do this too. > > > > Library dependencies are also broken, of course. A package that links > > to libGL.so.1 shouldn't get a dependency on mesa-dri or whatever was > > installed to provide that library, but a dependency on a virtual > > "libgl" package. As far as I'm aware this isn't something that the > > automatic shlibs dependency generation handles, but there is plenty of > > prior art for this. > > It's not automatic, but you can do something like this: > > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=23b02134 > > That recipe ships multiple copies of the libraries to account for > different silicon revisions (the shader compiler will offload different > things to the CPU), but we don't want the shlibs code to pickup the copies. > So for mesa you can do: > > PRIVATE_LIBS_${PN}-dri = "libGL.so" > RPROVIDES_${PN}-dri = $magic_python_function(PACKAGE_CONFIG, > sometthing, something, libgl) > > And in the recipes that link to a GL lib you do: > > RDEPENDS_${PN} = "libGL" > > Which only leaves the DISTRO to sort out the runtime preferred provider, > which is likely a conf file with a bunch of PACKAGE_CONFIG entries for all > the machines the DISTRO wants to support. > > I'm not sure how this would work as there are recipes like libsdl with: ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', '', d)} ag
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
