[RFC] OpenGL packaging/staging policy

[RFC] OpenGL packaging/staging policy

[Burton, Ross]

Hi,

Now that we've almost got 1.3 out of the door we can go back to
breaking everything. Hooray!  Let's try to (un)break OpenGL again.

First, I should say that I'm not looking at this from an GenX/Intel
specific perspective where Mesa is all you need.  meta-intel ships two
different binary GL drivers (cdt-pvr for Cedar Trail, EMGD for
everything else Atom that doesn't have i945) so I'm perfectly aware of
the problems.

For example, Cedar Trail's (SGX545-based) GL stack comprises of GLESv1
GLESv2 and EGL library blobs, and a DRI driver blob.  This DRI driver
can be used by Mesa's libGL.  This is actually a more complex problem
than Beagle has where it just doesn't do GL.

This is my attempt at a simple solution that doesn't involve
complicated packaging tricks.

Rule 1.  Unambiguous package naming

Debian-style renaming and multiple providers of the same API doesn't
work as you'll end up with multiple packages in the same feed called
libgl1, so all GL packages should be named in the style of libgl-foo,
where foo is the source of the package.  I've got a branch where this
is implemented for Mesa as a proof of concept[1], and the Python
fragment could easily be moved into a class and re-used easily.

Rule 2. No dependencies on specific GL implementations

Packages currently depend on the exact GL that they were built with,
although the GL packages are swappable.  Not very interesting for
systems where there's only one provider, but still a valid problem for
systems with swappable hardware or alternative GL stacks.  All linkage
to the GL stack should be intercepted and replaced by something like
"virtual/libgl | libgl-mesa".

This means changing the shlib dependency detection code to support
per-library overrides, there's plenty of prior art in existing
distributions to help here.

Rule 3. Only Mesa stages, nothing else

Whilst there are multiple GL implementations that offer various
subsets of GL, they are all effectively interchangeable.  It's not a
massive concern what exact GL is present when building because they've
all got the same API.  We can take advantage of this and remove the
problems caused by multiple GL implementations staging by only putting
Mesa into the sysroot.  Any other GL implementation should explicitly
stop staging itself to avoid sysroot tainting.  This can be
implemented by making Mesa build all APIs on all platforms (which
isn't a problem when it comes to image building or feeds, thanks to
rule 1), and removing the virtual/libgl PROVIDES from the other GL
implementations.

For systems which don't use Mesa at all (for example, BeagleBoard)
then this potentially means that Mesa will be built when it shouldn't.
 GLX support in the X server may already be pulling it in (I made this
a packageconfig in 1.3 so distros can turn it off), but in any case I
think this is an acceptable compromise - Mesa isn't slow to build in
the scheme of things, and per Rule 2 this is purely in sysroot and not
in the images.


tl;dr: all packages built against a constant GL, all GL
implementations interchangable, no package conflicts in the feeds.

Any comments before I get my hands dirty with the next incomplete task
(shlib dependency generation)?

Ross

[1] http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mesa&id=784fa1372bb38dbc82e53a49b757c3c02593f2b8

Re: [RFC] OpenGL packaging/staging policy

[Tomas Frydrych]

Hi Ross,

On 22/10/12 17:35, Burton, Ross wrote:
> Rule 3. Only Mesa stages, nothing else

I think it is a big mistake to special case mesa as anything other than
*a* GL provider. GL stacks provide their own headers, these headers
might not be identical to the mesa headers, and people writing GL
software for the particular target have every right to expect to be
using the headers provided with their GL stack -- sooner or later this
rule will have to be broken because of customer software  not buildable
under Yocto. (Whether the headers should be identical is neither here
nor there; Yocto needs to work in the real world, and you well know that
in the real world this is not the case.)

I know some folk don't like to hear this, but whether you like it or
not, GL libs are tied to specific HW, i.e., are machine-specific. Our
current difficulties stem directly from trying to pretend this is not
the case, or that mesa is somehow more than just *a* GL provider. IMHO
the correct thing to do here is:

a) Make the mesa packages machine specific so we can control compatible
machines and preferred providers to match the HW realities,

b) Split the ginormous mesa recipe, so that it is, for example, possible
to stage mesa gl without mesa egl, so that we can accommodate HW that
wants to use bits of mesa.

Tomas

Re: [oe] [RFC] OpenGL packaging/staging policy

[Phil Blundell]

On Mon, 2012-10-22 at 17:35 +0100, Burton, Ross wrote:
> Rule 3. Only Mesa stages, nothing else
> 
> Whilst there are multiple GL implementations that offer various
> subsets of GL, they are all effectively interchangeable.  It's not a
> massive concern what exact GL is present when building because they've
> all got the same API.

This is an attractive idea but I'm not sure that the underlying
assumption is entirely correct.

Different GL libraries will have different vendor extensions and Mesa's
headers won't necessarily know about them.  If the vendor ships the
extension bits in a custom header (rather than jamming them into a
modified glext.h) then this could be worked around by staging the
headers separately, but you're still left with the problem that Mesa's
libGL.so might now be missing symbols that are required during
linking.  

Also, even if the APIs were the same, I am slightly nervous about
relying on all vendor GLs having an identical ABI to Mesa.  I can't
immediately think of any reason why they shouldn't but, equally, vendors
have been known to do peculiar things in the past and I wouldn't be
totally shocked to find that there is some binary libGL out there which
manages to be ABI-incompatible with Mesa in some or other creative
fashion.

p.

Re: [RFC] OpenGL packaging/staging policy

[Otavio Salvador]

On Mon, Oct 22, 2012 at 2:35 PM, Burton, Ross <ross.burton@intel.com> wrote:
...
> Rule 1.  Unambiguous package naming
>
> Debian-style renaming and multiple providers of the same API doesn't
> work as you'll end up with multiple packages in the same feed called
> libgl1, so all GL packages should be named in the style of libgl-foo,
> where foo is the source of the package.  I've got a branch where this
> is implemented for Mesa as a proof of concept[1], and the Python
> fragment could easily be moved into a class and re-used easily.

It would be nice to also have a common SoC arch so the binaries are
clear not allarch but not rebuild for every board.

For example in iMX53 and iMX51 case they share same GL package set and
we could have a armv7-imx5 or so common to all them so we'd not
rebuild it for every board.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [OE-core] [RFC] OpenGL packaging/staging policy

[Otavio Salvador]

On Mon, Oct 22, 2012 at 2:35 PM, Burton, Ross <ross.burton@intel.com> wrote:
...
> Rule 1.  Unambiguous package naming
>
> Debian-style renaming and multiple providers of the same API doesn't
> work as you'll end up with multiple packages in the same feed called
> libgl1, so all GL packages should be named in the style of libgl-foo,
> where foo is the source of the package.  I've got a branch where this
> is implemented for Mesa as a proof of concept[1], and the Python
> fragment could easily be moved into a class and re-used easily.

It would be nice to also have a common SoC arch so the binaries are
clear not allarch but not rebuild for every board.

For example in iMX53 and iMX51 case they share same GL package set and
we could have a armv7-imx5 or so common to all them so we'd not
rebuild it for every board.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [RFC] OpenGL packaging/staging policy

[Mark Hatle]

On 10/22/12 11:35 AM, Burton, Ross wrote:
> Hi,
>
> Now that we've almost got 1.3 out of the door we can go back to
> breaking everything. Hooray!  Let's try to (un)break OpenGL again.
>
> First, I should say that I'm not looking at this from an GenX/Intel
> specific perspective where Mesa is all you need.  meta-intel ships two
> different binary GL drivers (cdt-pvr for Cedar Trail, EMGD for
> everything else Atom that doesn't have i945) so I'm perfectly aware of
> the problems.
>
> For example, Cedar Trail's (SGX545-based) GL stack comprises of GLESv1
> GLESv2 and EGL library blobs, and a DRI driver blob.  This DRI driver
> can be used by Mesa's libGL.  This is actually a more complex problem
> than Beagle has where it just doesn't do GL.
>
> This is my attempt at a simple solution that doesn't involve
> complicated packaging tricks.
>
> Rule 1.  Unambiguous package naming
>
> Debian-style renaming and multiple providers of the same API doesn't
> work as you'll end up with multiple packages in the same feed called
> libgl1, so all GL packages should be named in the style of libgl-foo,
> where foo is the source of the package.  I've got a branch where this
> is implemented for Mesa as a proof of concept[1], and the Python
> fragment could easily be moved into a class and re-used easily.

I can't say I'm a fan of the debian renamining, but in this case I think it's 
very important to do this.  Using the pkgv_<name> = 'libgl-foo' is a good idea.. 
  I'm guessing that is the easiest way to get consistent behavior.

> Rule 2. No dependencies on specific GL implementations
>
> Packages currently depend on the exact GL that they were built with,
> although the GL packages are swappable.  Not very interesting for
> systems where there's only one provider, but still a valid problem for
> systems with swappable hardware or alternative GL stacks.  All linkage
> to the GL stack should be intercepted and replaced by something like
> "virtual/libgl | libgl-mesa".

Moving everything to libgl1, or virtual/libgl or similar is what I would 
suggest.  This is consistent with the rest of the system behavior.

> This means changing the shlib dependency detection code to support
> per-library overrides, there's plenty of prior art in existing
> distributions to help here.

Each of the libgl's should have equivalent provides (i.e. libgl1)

> Rule 3. Only Mesa stages, nothing else
>
> Whilst there are multiple GL implementations that offer various
> subsets of GL, they are all effectively interchangeable.  It's not a
> massive concern what exact GL is present when building because they've
> all got the same API.  We can take advantage of this and remove the
> problems caused by multiple GL implementations staging by only putting
> Mesa into the sysroot.  Any other GL implementation should explicitly
> stop staging itself to avoid sysroot tainting.  This can be
> implemented by making Mesa build all APIs on all platforms (which
> isn't a problem when it comes to image building or feeds, thanks to
> rule 1), and removing the virtual/libgl PROVIDES from the other GL
> implementations.
>
> For systems which don't use Mesa at all (for example, BeagleBoard)
> then this potentially means that Mesa will be built when it shouldn't.
>   GLX support in the X server may already be pulling it in (I made this
> a packageconfig in 1.3 so distros can turn it off), but in any case I
> think this is an acceptable compromise - Mesa isn't slow to build in
> the scheme of things, and per Rule 2 this is purely in sysroot and not
> in the images.

For systems like BeagleBoard, do they use X11, if so what do they use for GL? 
Most of the ARM systems use raw direct PowerVR drivers in my experience, and 
generally don't use X11.

We definitely need a solution for X11 / Mesa based systems.. and a way to 
qualify the other systems with the way their graphics solutions are built.

--Mark

>
> tl;dr: all packages built against a constant GL, all GL
> implementations interchangable, no package conflicts in the feeds.
>
> Any comments before I get my hands dirty with the next incomplete task
> (shlib dependency generation)?
>
> Ross
>
> [1] http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mesa&id=784fa1372bb38dbc82e53a49b757c3c02593f2b8
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [oe] [RFC] OpenGL packaging/staging policy

[Otavio Salvador]

On Mon, Oct 22, 2012 at 3:32 PM, Phil Blundell <philb@gnu.org> wrote:
> On Mon, 2012-10-22 at 17:35 +0100, Burton, Ross wrote:
>> Rule 3. Only Mesa stages, nothing else
>>
>> Whilst there are multiple GL implementations that offer various
>> subsets of GL, they are all effectively interchangeable.  It's not a
>> massive concern what exact GL is present when building because they've
>> all got the same API.
>
> This is an attractive idea but I'm not sure that the underlying
> assumption is entirely correct.
>
> Different GL libraries will have different vendor extensions and Mesa's
> headers won't necessarily know about them.  If the vendor ships the
> extension bits in a custom header (rather than jamming them into a
> modified glext.h) then this could be worked around by staging the
> headers separately, but you're still left with the problem that Mesa's
> libGL.so might now be missing symbols that are required during
> linking.
>
> Also, even if the APIs were the same, I am slightly nervous about
> relying on all vendor GLs having an identical ABI to Mesa.  I can't
> immediately think of any reason why they shouldn't but, equally, vendors
> have been known to do peculiar things in the past and I wouldn't be
> totally shocked to find that there is some binary libGL out there which
> manages to be ABI-incompatible with Mesa in some or other creative
> fashion.

In this case every package depending on GL packages will be
PACKAGE_ARCH specific; this would be nice if we can share it amoung
boards at least.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [RFC] OpenGL packaging/staging policy

[Phil Blundell]

On Mon, 2012-10-22 at 15:33 -0200, Otavio Salvador wrote:
> On Mon, Oct 22, 2012 at 2:35 PM, Burton, Ross <ross.burton@intel.com> wrote:
> ...
> > Rule 1.  Unambiguous package naming
> >
> > Debian-style renaming and multiple providers of the same API doesn't
> > work as you'll end up with multiple packages in the same feed called
> > libgl1, so all GL packages should be named in the style of libgl-foo,
> > where foo is the source of the package.  I've got a branch where this
> > is implemented for Mesa as a proof of concept[1], and the Python
> > fragment could easily be moved into a class and re-used easily.
> 
> It would be nice to also have a common SoC arch so the binaries are
> clear not allarch but not rebuild for every board.
> 
> For example in iMX53 and iMX51 case they share same GL package set and
> we could have a armv7-imx5 or so common to all them so we'd not
> rebuild it for every board.

Surely in the case Ross describes, the "imx5" bit would be encoded into
the package name (i.e. they'd be libgl-imx5) and then PACKAGE_ARCH can
just be used as normal to represent the ISA and/or ABI.  I can't think
of any situation where encoding the GPU type into PACKAGE_ARCH would be
especially useful.

p.

Re: [OE-core] [RFC] OpenGL packaging/staging policy

[Phil Blundell]

On Mon, 2012-10-22 at 15:33 -0200, Otavio Salvador wrote:
> On Mon, Oct 22, 2012 at 2:35 PM, Burton, Ross <ross.burton@intel.com> wrote:
> ...
> > Rule 1.  Unambiguous package naming
> >
> > Debian-style renaming and multiple providers of the same API doesn't
> > work as you'll end up with multiple packages in the same feed called
> > libgl1, so all GL packages should be named in the style of libgl-foo,
> > where foo is the source of the package.  I've got a branch where this
> > is implemented for Mesa as a proof of concept[1], and the Python
> > fragment could easily be moved into a class and re-used easily.
> 
> It would be nice to also have a common SoC arch so the binaries are
> clear not allarch but not rebuild for every board.
> 
> For example in iMX53 and iMX51 case they share same GL package set and
> we could have a armv7-imx5 or so common to all them so we'd not
> rebuild it for every board.

Surely in the case Ross describes, the "imx5" bit would be encoded into
the package name (i.e. they'd be libgl-imx5) and then PACKAGE_ARCH can
just be used as normal to represent the ISA and/or ABI.  I can't think
of any situation where encoding the GPU type into PACKAGE_ARCH would be
especially useful.

p.

Re: [oe] [RFC] OpenGL packaging/staging policy

[Burton, Ross]

On 22 October 2012 18:32, Phil Blundell <philb@gnu.org> wrote:
> Different GL libraries will have different vendor extensions and Mesa's
> headers won't necessarily know about them.  If the vendor ships the
> extension bits in a custom header (rather than jamming them into a
> modified glext.h) then this could be worked around by staging the
> headers separately, but you're still left with the problem that Mesa's
> libGL.so might now be missing symbols that are required during
> linking.

This was a concern, and this is a RFC for a reason.

In my (admittedly limited) experience, it's fairly common for
applications to treat vendor's GL headers are references and
copy/paste the bits they want for this exact reason.  Imaging a game
engine that wants to use a nVidia extension *and* and ATI extension
(depending on the runtime environment) that isn't yet in the standard
GL headers - it can't be expected to compile against both GL
implementations.

If there's a clear popular example of an application that insists to
be built against a specific vendor's GL and that behaviour can't be
described as broken (and fixed with a few lines of patch), then this
is a solid counter-argument.

Ross

Re: [RFC] OpenGL packaging/staging policy

[Burton, Ross]

On 22 October 2012 18:19, Tomas Frydrych <tf+lists.yocto@r-finger.com> wrote:
> Our
> current difficulties stem directly from trying to pretend this is not
> the case, or that mesa is somehow more than just *a* GL provider. IMHO
> the correct thing to do here is:

Mesa is the only free GL provider, which does make it useful in an
open source build system.

> a) Make the mesa packages machine specific so we can control compatible
> machines and preferred providers to match the HW realities,
>
> b) Split the ginormous mesa recipe, so that it is, for example, possible
> to stage mesa gl without mesa egl, so that we can accommodate HW that
> wants to use bits of mesa.

This would be the "complication packaging tricks" that I alluded to in
the original mail.

Ross

Re: [RFC] OpenGL packaging/staging policy

[Burton, Ross]

On 22 October 2012 18:37, Mark Hatle <mark.hatle@windriver.com> wrote:
> For systems like BeagleBoard, do they use X11, if so what do they use for
> GL? Most of the ARM systems use raw direct PowerVR drivers in my experience,
> and generally don't use X11.

X works.  GLX doesn't work as it requires GL (unless you're evil), but
that's fine as GLX is effectively deprecated and EGL sort-of/should
work.

Ross

Re: [RFC] OpenGL packaging/staging policy

[Tomas Frydrych]

On 22/10/12 20:27, Burton, Ross wrote:
> On 22 October 2012 18:19, Tomas Frydrych <tf+lists.yocto@r-finger.com> wrote:
>> Our
>> current difficulties stem directly from trying to pretend this is not
>> the case, or that mesa is somehow more than just *a* GL provider. IMHO
>> the correct thing to do here is:
> 
> Mesa is the only free GL provider, which does make it useful in an
> open source build system.

Useful, yes, but not different. Having multiple providers is a normal
scenario that OE handles perfectly well; having a privileged provider
and bunch second class providers is a new scenario that serves no useful
purpose here -- you are creating the problem you are trying to solve.


> This would be the "complication packaging tricks" that I alluded to in
> the original mail.

There is nothing complicated about this; the fact that you cannot build
mesa GL without *staging* mesa EGL at the same time is broken which ever
way you look at it. Having only mesa to stage things is not a fix, it's
a work around, and one that punishes everyone else for the mesa mess. :-)

Tomas

Re: [RFC] OpenGL packaging/staging policy

[Daniel Stone]

Hi,

On 23 October 2012 04:19, Tomas Frydrych <tf+lists.yocto@r-finger.com> wrote:
> b) Split the ginormous mesa recipe, so that it is, for example, possible
> to stage mesa gl without mesa egl, so that we can accommodate HW that
> wants to use bits of mesa.

What? You can't do that.  Well, you kinda can if you're using GLX and
nothing else, maybe, sorta.  But the EGL and GL (ES) implementations
are very heavily tied together and can't be used as independent works.
 You can separate GLU, which we've already done.  I think you can
split out the core of libgbm, but not the DRI plugin.  And that's
about it.

I've got gles2/opengl/egl MACHINE_FEATURES in my tree at
git://git.collabora.com/~daniels/poky, which goes some way towards
improving the current GL (ES) situation.  But trying to split the
actual stacks into multiple parts helps no-one.

Cheers,
Daniel

Re: [RFC] OpenGL packaging/staging policy

[Tomas Frydrych]

On 23/10/12 03:06, Daniel Stone wrote:
> What? You can't do that.  Well, you kinda can if you're using GLX and
> nothing else, maybe, sorta.  But the EGL and GL (ES) implementations
> are very heavily tied together and can't be used as independent works.
>  You can separate GLU, which we've already done.  I think you can
> split out the core of libgbm, but not the DRI plugin.  And that's
> about it.

I am well aware that GL stacks are closely tied together, and personally
would not advise anyone to mix and match. But please reread the original
email Ross sent explaining the Cedar Trail 'complex' situation. If Intel
want to use mesa GL and their PVR GLES1/2 / EGL binary bits together ...

Regardless what is done with the packaging, allowing only mesa to stage
dev files will break things. GL headers are not interchangeable, even if
all the implementers are well behaved (which is a big if), the
*platform.h files are allowed to be implementation specific and so have
to be staged by the actual platform GL stack.

Tomas

Re: [RFC] OpenGL packaging/staging policy

[Daniel Stone]

Hi,

On 23 October 2012 19:37, Tomas Frydrych <tf+lists.yocto@r-finger.com> wrote:
> On 23/10/12 03:06, Daniel Stone wrote:
>> You can separate GLU, which we've already done.  I think you can
>> split out the core of libgbm, but not the DRI plugin.  And that's
>> about it.
>
> I am well aware that GL stacks are closely tied together, and personally
> would not advise anyone to mix and match. But please reread the original
> email Ross sent explaining the Cedar Trail 'complex' situation. If Intel
> want to use mesa GL and their PVR GLES1/2 / EGL binary bits together ...

That'll break catastrophically for anyone using GL + EGL, but eh, if
they're insane enough to support it, and you're insane enough to
explicitly allow for it as a supported configuration ...

> Regardless what is done with the packaging, allowing only mesa to stage
> dev files will break things. GL headers are not interchangeable, even if
> all the implementers are well behaved (which is a big if), the
> *platform.h files are allowed to be implementation specific and so have
> to be staged by the actual platform GL stack.

Right, I do agree with you, but in the mixed-stack situation, which
headers are we building against? :)

Cheers,
Daniel

Re: [RFC] OpenGL packaging/staging policy

[Tomas Frydrych]

On 23/10/12 10:18, Daniel Stone wrote:
>> Regardless what is done with the packaging, allowing only mesa to stage
>> dev files will break things. GL headers are not interchangeable, even if
>> all the implementers are well behaved (which is a big if), the
>> *platform.h files are allowed to be implementation specific and so have
>> to be staged by the actual platform GL stack.
> 
> Right, I do agree with you, but in the mixed-stack situation, which
> headers are we building against? :)

The GL / GLES / GLES2 / EGL headers are separate from each other, so in
theory if you have separate libgl, libles, libgles2, and libegl
packages, you could even stage them from four different sources. But for
the Cedar Trail scenario a separate big GL and a combined GLES/GLES2/EGL
package, plus a package for common libs. This might be of some use for
others (IIRC, the whole discussion about this was sparked after enabling
EGL in the mesa package), though it means building mesa multiple times.

Tomas

Re: [RFC] OpenGL packaging/staging policy

[Burton, Ross]

Hi,

This was interesting discussion and certainly achieved the goal of
soliciting comments...  A less aggressive plan:

Rule 1.  Unambiguous package naming

I won't repeat this, everyone agreed this was sane.  I've a patch for
mesa that I'll submit shortly.

Rule 2.  No whitelisting for GL driver conflicts

The target GL shall be staged, and situations which result in multiple
GLs being installed should handle this case and resolve it.

For atom-pc this means building Mesa.  For Beagle this means staging
the Beagle binary drivers.  For Tegra as I've discovered this is
"interesting" as they don't appear to provide any headers in their
Tegra For Linux tarball...

For Cedar Trail and EMGD, the easiest solution is a dedicated Mesa
building just GL.  As Mesa's DRI driver API isn't stable this is
practically required anyway: the ABI of the libGL we build and the
libGL that the binary driver was built against need to match.  This
mesa-just-gl (mesa-solo?) can be in meta-intel unless other machines
turn out to have a similar (crazy) requirement.

Rule 3.  No dependencies on specific GL implementations

Useful so that GL implementations are swappable on systems where that
can happen, but not essential if there isn't a single blessed GL for
sysroot.  We'll do this later.

Some things that will also happen whilst I do this:
1) mesa-dri renamed to mesa.  Let's get this done nice and early!
2) mesa stops architecture-overriding enabling of EGL and GLES, so all
architectures that build Mesa get GL/EGL/GLESv1/GLESv2.  If you don't
want this don't build Mesa, and the namespaced packaging means there
won't be conflicts.

Any more comments?

Ross

Re: [OE-core] [RFC] OpenGL packaging/staging policy

[Burton, Ross]

Hi,

This was interesting discussion and certainly achieved the goal of
soliciting comments...  A less aggressive plan:

Rule 1.  Unambiguous package naming

I won't repeat this, everyone agreed this was sane.  I've a patch for
mesa that I'll submit shortly.

Rule 2.  No whitelisting for GL driver conflicts

The target GL shall be staged, and situations which result in multiple
GLs being installed should handle this case and resolve it.

For atom-pc this means building Mesa.  For Beagle this means staging
the Beagle binary drivers.  For Tegra as I've discovered this is
"interesting" as they don't appear to provide any headers in their
Tegra For Linux tarball...

For Cedar Trail and EMGD, the easiest solution is a dedicated Mesa
building just GL.  As Mesa's DRI driver API isn't stable this is
practically required anyway: the ABI of the libGL we build and the
libGL that the binary driver was built against need to match.  This
mesa-just-gl (mesa-solo?) can be in meta-intel unless other machines
turn out to have a similar (crazy) requirement.

Rule 3.  No dependencies on specific GL implementations

Useful so that GL implementations are swappable on systems where that
can happen, but not essential if there isn't a single blessed GL for
sysroot.  We'll do this later.

Some things that will also happen whilst I do this:
1) mesa-dri renamed to mesa.  Let's get this done nice and early!
2) mesa stops architecture-overriding enabling of EGL and GLES, so all
architectures that build Mesa get GL/EGL/GLESv1/GLESv2.  If you don't
want this don't build Mesa, and the namespaced packaging means there
won't be conflicts.

Any more comments?

Ross

Re: [RFC] OpenGL packaging/staging policy

[Tomas Frydrych]

On 29/10/12 17:26, Burton, Ross wrote:
> Rule 1.  Unambiguous package naming
> 
> I won't repeat this, everyone agreed this was sane.  I've a patch for
> mesa that I'll submit shortly.
> 
> Rule 2.  No whitelisting for GL driver conflicts
> 
> The target GL shall be staged, and situations which result in multiple
> GLs being installed should handle this case and resolve it.
> 
> For atom-pc this means building Mesa.  For Beagle this means staging
> the Beagle binary drivers.  For Tegra as I've discovered this is
> "interesting" as they don't appear to provide any headers in their
> Tegra For Linux tarball...
> 
> For Cedar Trail and EMGD, the easiest solution is a dedicated Mesa
> building just GL.  As Mesa's DRI driver API isn't stable this is
> practically required anyway: the ABI of the libGL we build and the
> libGL that the binary driver was built against need to match.  This
> mesa-just-gl (mesa-solo?) can be in meta-intel unless other machines
> turn out to have a similar (crazy) requirement.
> 
> Rule 3.  No dependencies on specific GL implementations
> 
> Useful so that GL implementations are swappable on systems where that
> can happen, but not essential if there isn't a single blessed GL for
> sysroot.  We'll do this later.
> 
> Some things that will also happen whilst I do this:
> 1) mesa-dri renamed to mesa.  Let's get this done nice and early!
> 2) mesa stops architecture-overriding enabling of EGL and GLES, so all
> architectures that build Mesa get GL/EGL/GLESv1/GLESv2.  If you don't
> want this don't build Mesa, and the namespaced packaging means there
> won't be conflicts.
> 
> Any more comments?

FWIW, I am happy with this proposal :)

Tomas

Re: [RFC] OpenGL packaging/staging policy

[Burton, Ross]

Hi,

In case anyone didn't notice, Mesa in oe-core just renamed the binary
packages to libgl-mesa etc, and enabled EGL/GLES on all platforms.
Hopefully there isn't any fallout (there are
replaces/conflicts/provides in place) but if you maintain a GL recipe,
please consider adopting a similar naming scheme.

Ross

Re: [OE-core] [RFC] OpenGL packaging/staging policy

[Burton, Ross]

Hi,

In case anyone didn't notice, Mesa in oe-core just renamed the binary
packages to libgl-mesa etc, and enabled EGL/GLES on all platforms.
Hopefully there isn't any fallout (there are
replaces/conflicts/provides in place) but if you maintain a GL recipe,
please consider adopting a similar naming scheme.

Ross