OpenGL as a DISTRO_FEATURE

OpenGL as a DISTRO_FEATURE

[Ian Geiser]

Greetings, I maintain 3 different platforms with varying degrees of GL support.  Would it make more sense to migrate the "opengl" distro feature to MACHINE_FEATURES?  This way we could compensate for the platforms that use Mesa and the ones that use their custom implementations?  Thoughts?

Re: OpenGL as a DISTRO_FEATURE

[Ross Burton]

On Sunday, 3 February 2013 at 17:15, Ian Geiser wrote:
> Greetings, I maintain 3 different platforms with varying degrees of GL support. Would it make more sense to migrate the "opengl" distro feature to MACHINE_FEATURES? This way we could compensate for the platforms that use Mesa and the ones that use their custom implementations? Thoughts?

Even if there were machine features, a distro feature is still something you'd want.

There's been the idea of having fine-grained machine features for the aspects of OpenGL that the hardware supports (gl, gles, egl, etc).  It's not as simple as it appears and causes a rather large number of packages to become machine-specific.

What would you use the machine features for?  Conditionally compiling support for a particular variant of GL into packages that cannot be detected at runtime, or something else?

Ross

Re: OpenGL as a DISTRO_FEATURE

[Ian Geiser]

> -----Original Message-----
> From: Ross Burton [mailto:ross.burton@intel.com]
> Sent: Sunday, February 03, 2013 2:04 PM
> To: Ian Geiser
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] OpenGL as a DISTRO_FEATURE
> 
> On Sunday, 3 February 2013 at 17:15, Ian Geiser wrote:
> > Greetings, I maintain 3 different platforms with varying degrees of
> GL support. Would it make more sense to migrate the "opengl" distro
> feature to MACHINE_FEATURES? This way we could compensate for the
> platforms that use Mesa and the ones that use their custom
> implementations? Thoughts?
> 
> Even if there were machine features, a distro feature is still
> something you'd want.
> 
> There's been the idea of having fine-grained machine features for the
> aspects of OpenGL that the hardware supports (gl, gles, egl, etc).
> It's not as simple as it appears and causes a rather large number of
> packages to become machine-specific.
In the case of my product that is not a problem.  It may have implications on the community distributions though.

> 
> What would you use the machine features for?  Conditionally compiling
> support for a particular variant of GL into packages that cannot be
> detected at runtime, or something else?
> 
The case I have is 3 platforms:
1) Atom N450
2) WM 8950
3) VIA VX900

The Atom has the normal mesa-dri drivers and can use the OpenGL implementation from that.  The WM has only OpenGLES drivers and no OpenGL implementation.  So in that case I want to use only GLES support in the various packages that conditionally support it (in my case Qt4).  The last platform the VIA has its own OpenGL implementation that can completely replace mesa for packages that support OpenGL. In the case of my distro I support Qt4 but it can use OpenGLES or OpenGL.  The problem comes in when I start setting preferred providers in the machine conf files.  In the case of my WM, I have only gles and since the distro supports opengl, it needs a virtual/libgl and finds it with mesa.  Now I can remove opengl from my distro, but the Atom and VIA support opengl, and will not have it available to Qt because it turns off.  

So really on reflection the real problem is that when you support two platforms in the same distro that either have opengl or opengles you get into trouble.  Now one approach might be to make a distro based off of the common distro that supports either opengl or opengles but that to me sounds like I am fixing the problem in the wrong place.
 
Now I could be missing an obvious better way.

Re: OpenGL as a DISTRO_FEATURE

[Marcin Juszkiewicz]

W dniu 03.02.2013 20:45, Ian Geiser pisze:

> The case I have is 3 platforms: 1) Atom N450 2) WM 8950 3) VIA VX900
> 
> The Atom has the normal mesa-dri drivers and can use the OpenGL
> implementation from that.  The WM has only OpenGLES drivers and no
> OpenGL implementation.  So in that case I want to use only GLES
> support in the various packages that conditionally support it (in my
> case Qt4).  The last platform the VIA has its own OpenGL
> implementation that can completely replace mesa for packages that
> support OpenGL. In the case of my distro I support Qt4 but it can use
> OpenGLES or OpenGL.  The problem comes in when I start setting
> preferred providers in the machine conf files.  In the case of my WM,
> I have only gles and since the distro supports opengl, it needs a
> virtual/libgl and finds it with mesa.  Now I can remove opengl from
> my distro, but the Atom and VIA support opengl, and will not have it
> available to Qt because it turns off.

As they are different architectures you can try this:

DISTRO_FEATURES_wm8950 = "here copy your default DISTRO_FEATURES but
skip opengl"

Replace wm8950 with MACHINE name. Ugly solution but should work.

Re: OpenGL as a DISTRO_FEATURE

[Ross Burton]

On Sunday, 3 February 2013 at 21:33, Marcin Juszkiewicz wrote:
> As they are different architectures you can try this:
> 
> DISTRO_FEATURES_wm8950 = "here copy your default DISTRO_FEATURES but
> skip opengl"
> 
> Replace wm8950 with MACHINE name. Ugly solution but should work.
That means that Qt won't be built with GLES support.

The best approach is to probe the hardware/libraries at runtime and adapt - i.e. if only GLES libraries are available use those, but a lot of software doesn't support that or simple probing isn't sufficient (Intel Pine Trail supports both but GL is best, Cedar Trail supports both but GL is terrible).

Ross 

Re: OpenGL as a DISTRO_FEATURE

[Ian Geiser]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Ross Burton
> Sent: Sunday, February 03, 2013 6:35 PM
> To: Marcin Juszkiewicz
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] OpenGL as a DISTRO_FEATURE
> 
> On Sunday, 3 February 2013 at 21:33, Marcin Juszkiewicz wrote:
> > As they are different architectures you can try this:
> >
> > DISTRO_FEATURES_wm8950 = "here copy your default DISTRO_FEATURES but
> > skip opengl"
> >
> > Replace wm8950 with MACHINE name. Ugly solution but should work.
> That means that Qt won't be built with GLES support.
> 
> The best approach is to probe the hardware/libraries at runtime and
> adapt - i.e. if only GLES libraries are available use those, but a lot
> of software doesn't support that or simple probing isn't sufficient
> (Intel Pine Trail supports both but GL is best, Cedar Trail supports
> both but GL is terrible).
In my instance I know what hardware I am targeting at build time so I can make the choice there.  That is why I think MACHINE_FEATURES might be more appropriate.

That being said a grep through a few layers shows that this might not be a low impact change so Marcin's solution while not ideal might be the least amount the churn.

Re: OpenGL as a DISTRO_FEATURE

[Ian Geiser]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Marcin Juszkiewicz
> Sent: Sunday, February 03, 2013 4:34 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] OpenGL as a DISTRO_FEATURE
> 
> W dniu 03.02.2013 20:45, Ian Geiser pisze:
> 
> > The case I have is 3 platforms: 1) Atom N450 2) WM 8950 3) VIA VX900
> >
> > The Atom has the normal mesa-dri drivers and can use the OpenGL
> > implementation from that.  The WM has only OpenGLES drivers and no
> > OpenGL implementation.  So in that case I want to use only GLES
> > support in the various packages that conditionally support it (in my
> > case Qt4).  The last platform the VIA has its own OpenGL
> > implementation that can completely replace mesa for packages that
> > support OpenGL. In the case of my distro I support Qt4 but it can use
> > OpenGLES or OpenGL.  The problem comes in when I start setting
> > preferred providers in the machine conf files.  In the case of my WM,
> > I have only gles and since the distro supports opengl, it needs a
> > virtual/libgl and finds it with mesa.  Now I can remove opengl from
> > my distro, but the Atom and VIA support opengl, and will not have it
> > available to Qt because it turns off.
> 
> As they are different architectures you can try this:
> 
> DISTRO_FEATURES_wm8950 = "here copy your default DISTRO_FEATURES but
> skip opengl"
> 
> Replace wm8950 with MACHINE name. Ugly solution but should work.
Then I have 3 DISTRO_FEATURES lines in my distro.conf, or I have DISTRO_FEATURES spread out inside of my machine.conf files.  Ugly solutions ship, but elegant solutions get maintained ;)

Re: OpenGL as a DISTRO_FEATURE

[Tomas Frydrych]

Hi Ross,

On 03/02/13 23:35, Ross Burton wrote:
> On Sunday, 3 February 2013 at 21:33, Marcin Juszkiewicz wrote:
>> As they are different architectures you can try this:
>> 
>> DISTRO_FEATURES_wm8950 = "here copy your default DISTRO_FEATURES 
>> but skip opengl"
>> 
>> Replace wm8950 with MACHINE name. Ugly solution but should work.
> That means that Qt won't be built with GLES support.
> 
> The best approach is to probe the hardware/libraries at runtime and 
> adapt - i.e. if only GLES libraries are available use those, but a 
> lot of software doesn't support that or simple probing isn't 
> sufficient (Intel Pine Trail supports both but GL is best, Cedar 
> Trail supports both but GL is terrible).

Run-time probing is not a solution at all, because (a) we are not
talking about how to write portable GL applications, but primarily how
to package software already written by other people, and (b) with the
current OE set up run-time probing cannot work anyway (and does not,
e.g. cogl), because with two 'GL' providers there is no guarantee that
the optimal one (i.e., not the mesa software GL rasterizer), gets used.

The above scenario where someone wants to maintain a distro with
multiple target architectures is the normal thing to ask for with OE.
The fact that current OE cannot support it cleanly, and it has to be
worked around on distro level (whether by bbappends that make the GL
components machine-specific as they should be, or hacks like
DISTRO_FEATURES_my-random-machine), demonstrates that we are not doing
it right at the moment.


> It's not as simple as it appears and causes a rather large number of 
> packages to become machine-specific.

From actual experience I think this is well overstated; I dare you to
support this by real numbers :-)

Tomas

--
http://sleepfive.com

Re: OpenGL as a DISTRO_FEATURE

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

O conclusion on this topic would be great. There are a lot of people
waiting for a fix on this topic.


On Tue, Feb 5, 2013 at 10:58 PM, Tomas Frydrych <tf+lists.yocto@r-finger.com
> wrote:

> Hi Ross,
>
> On 03/02/13 23:35, Ross Burton wrote:
> > On Sunday, 3 February 2013 at 21:33, Marcin Juszkiewicz wrote:
> >> As they are different architectures you can try this:
> >>
> >> DISTRO_FEATURES_wm8950 = "here copy your default DISTRO_FEATURES
> >> but skip opengl"
> >>
> >> Replace wm8950 with MACHINE name. Ugly solution but should work.
> > That means that Qt won't be built with GLES support.
> >
> > The best approach is to probe the hardware/libraries at runtime and
> > adapt - i.e. if only GLES libraries are available use those, but a
> > lot of software doesn't support that or simple probing isn't
> > sufficient (Intel Pine Trail supports both but GL is best, Cedar
> > Trail supports both but GL is terrible).
>
> Run-time probing is not a solution at all, because (a) we are not
> talking about how to write portable GL applications, but primarily how
> to package software already written by other people, and (b) with the
> current OE set up run-time probing cannot work anyway (and does not,
> e.g. cogl), because with two 'GL' providers there is no guarantee that
> the optimal one (i.e., not the mesa software GL rasterizer), gets used.
>
> The above scenario where someone wants to maintain a distro with
> multiple target architectures is the normal thing to ask for with OE.
> The fact that current OE cannot support it cleanly, and it has to be
> worked around on distro level (whether by bbappends that make the GL
> components machine-specific as they should be, or hacks like
> DISTRO_FEATURES_my-random-machine), demonstrates that we are not doing
> it right at the moment.
>
>
> > It's not as simple as it appears and causes a rather large number of
> > packages to become machine-specific.
>
> From actual experience I think this is well overstated; I dare you to
> support this by real numbers :-)
>
> Tomas
>
> --
> http://sleepfive.com
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
*Andrei Gherzan*
m: +40.744.478.414 |  f: +40.31.816.28.12

[-- Attachment #2: Type: text/html, Size: 3623 bytes --]