Patchwork [3/3] cogl-1.0: add option to enable GLES1

login
register
mail settings
Submitter Andreas Oberritter
Date July 11, 2013, 12:56 a.m.
Message ID <1373504197-9550-3-git-send-email-obi@opendreambox.org>
Download mbox | patch
Permalink /patch/53475/
State Rejected
Headers show

Comments

Andreas Oberritter - July 11, 2013, 12:56 a.m.
Only PACKAGECONFIG options for GL and GLES2 were available before.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
---
 meta/recipes-graphics/cogl/cogl-1.0.inc | 3 +++
 1 file changed, 3 insertions(+)
Ross Burton - July 11, 2013, 8:52 a.m.
On 11 July 2013 01:56, Andreas Oberritter <obi@opendreambox.org> wrote:
> Only PACKAGECONFIG options for GL and GLES2 were available before.

The rationale behind this was that the GLES1 support isn't tested,
mainly as there's not a lot of hardware that can't also do GLESv2.
Was this enabled for completeness or are you actually restricted to
GLESv1?

Ross
Andreas Oberritter - July 11, 2013, 10:53 a.m.
On 11.07.2013 10:52, Burton, Ross wrote:
> On 11 July 2013 01:56, Andreas Oberritter <obi@opendreambox.org> wrote:
>> Only PACKAGECONFIG options for GL and GLES2 were available before.
> 
> The rationale behind this was that the GLES1 support isn't tested,
> mainly as there's not a lot of hardware that can't also do GLESv2.
> Was this enabled for completeness or are you actually restricted to
> GLESv1?

It's for completeness, so if you have libraries for both GLES1 and
GLES2, you can compare them easily and then choose the one that works
better for your application. If nothing else, then this may improve test
coverage. Because it's disabled by default, introducing this option
doesn't have any bad side effects. On the good side, it explicitly
disables GLES1, so if a later version of cogl switches to
auto-detection, the behaviour of the build won't change.

Regards,
Andreas
Ross Burton - July 11, 2013, 11:01 a.m.
On 11 July 2013 11:53, Andreas Oberritter <obi@opendreambox.org> wrote:
>> The rationale behind this was that the GLES1 support isn't tested,
>> mainly as there's not a lot of hardware that can't also do GLESv2.
>> Was this enabled for completeness or are you actually restricted to
>> GLESv1?
>
> It's for completeness, so if you have libraries for both GLES1 and
> GLES2, you can compare them easily and then choose the one that works
> better for your application. If nothing else, then this may improve test
> coverage. Because it's disabled by default, introducing this option
> doesn't have any bad side effects. On the good side, it explicitly
> disables GLES1, so if a later version of cogl switches to
> auto-detection, the behaviour of the build won't change.

The GLESv2 backend will work best, because the v1 backend is crippled
by v1's limitations and lack of testing.  And GLESv1 is already
disabled explicitly in EXTRA_OECONF (that this patch should remove).

I'm leaning towards rejecting this as it doesn't serve a purpose,
unless someone can say that they're actually using the GLESv1 backend
(that upstream admits isn't tested).

Ross
Phil Blundell - July 11, 2013, 11:51 a.m.
On Thu, 2013-07-11 at 12:53 +0200, Andreas Oberritter wrote:
> On 11.07.2013 10:52, Burton, Ross wrote:
> > On 11 July 2013 01:56, Andreas Oberritter <obi@opendreambox.org> wrote:
> >> Only PACKAGECONFIG options for GL and GLES2 were available before.
> > 
> > The rationale behind this was that the GLES1 support isn't tested,
> > mainly as there's not a lot of hardware that can't also do GLESv2.
> > Was this enabled for completeness or are you actually restricted to
> > GLESv1?
> 
> It's for completeness, so if you have libraries for both GLES1 and
> GLES2, you can compare them easily and then choose the one that works
> better for your application. 

If your hardware supports GLESv2 then it seems very unlikely that the
GLESv1 backend is going to work better for any application.  I suppose
it's just about conceivable that there might be some or other bug in the
GLESv2 driver which you could work around by using the GLESv1 API, but
I've never heard of this happening in practice and it doesn't sound very
likely.

I wouldn't be surprised if Cogl's GLESv1 backend went away altogether in
the not-too-distant future.  The gap in capabilities between GLESv1 and
either GLESv2 or big GL is quite significant.

All that said, if there is genuine (even if possibly misguided) interest
in experimenting with GLESv1 then I don't have any real objection to
adding a PACKAGECONFIG option for it.

p.

Patch

diff --git a/meta/recipes-graphics/cogl/cogl-1.0.inc b/meta/recipes-graphics/cogl/cogl-1.0.inc
index c0d410e..f2c1e26 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0.inc
+++ b/meta/recipes-graphics/cogl/cogl-1.0.inc
@@ -17,6 +17,7 @@  AUTOTOOLS_AUXDIR = "${S}/build"
 
 # Extra DEPENDS for PACKAGECONFIG
 EDEPENDS_GL = "virtual/libgl libdrm"
+EDEPENDS_GLES1 = "virtual/libgles1"
 EDEPENDS_GLES2 = "virtual/libgles2"
 EDEPENDS_KMS = "libdrm virtual/egl"
 EDEPENDS_EGL = "virtual/egl"
@@ -26,6 +27,7 @@  EDEPENDS_WAYLAND = "wayland"
 # Extra RDEPENDS for PACKAGECONFIG
 # This has to be explictly listed, because cogl dlopens the backends
 ERDEPENDS_GL    = "libgl"
+ERDEPENDS_GLES1 = "libgles1"
 ERDEPENDS_GLES2 = "libgles2"
 
 EXTRA_OECONF += "--disable-introspection	\
@@ -38,6 +40,7 @@  PACKAGECONFIG[cogl-pango] = "--enable-cogl-pango,--disable-cogl-pango,pango"
 
 # GL flavours
 PACKAGECONFIG[gl] = "--enable-gl,--disable-gl,${EDEPENDS_GL},${ERDEPENDS_GL}"
+PACKAGECONFIG[gles1] = "--enable-gles1,--disable-gles1,${EDEPENDS_GLES1}, ${ERDEPENDS_GLES1}"
 PACKAGECONFIG[gles2] = "--enable-gles2,--disable-gles2,${EDEPENDS_GLES2}, ${ERDEPENDS_GLES2}"
 
 # EGL backends