[OE-core] [yocto] opengl / libgl / libgles

[Andrei Gherzan]

On Thu, Sep 6, 2012 at 4:25 PM, Koen Kooi <koen at dominion.thruhere.net>wrote:

>
> Op 6 sep. 2012, om 15:04 heeft "Burton, Ross" <ross.burton at intel.com> het
> volgende geschreven:
>
> > (CCing oe-core, discussion should happen there really)
> >
> > On 6 September 2012 11:00, Andrei Gherzan <andrei at gherzan.ro> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120919/0baead70/attachment-0002.html>