OpenGL ES 2.0 Support For Compiz, KWin, Cairo

[phoronix]

Phoronix: OpenGL ES 2.0 Support For Compiz, KWin, Cairo

There's been a lot of references this week at UDS Budapest to OpenGL ES support since this version of OpenGL is what's predominantly supported on ARM/embedded devices. There's already been talk of OpenGL ES support in QEMU, among other projects. OpenGL ES 2.0 support is also coming to the Compiz and KWin compositing window managers. An OpenGL ES 2.0 back-end for Cairo was also brought up separately...

http://www.phoronix.com/vr.php?view=OTQ0MQ

[V!NCENT]

I'm guessing that OpenGL ES doesn't use expensive floating point? If so then this should definately be the de-facto floss OS standard IMHO.

[barbieri]

E17 supports GL-ES 2.0 for a while

Enlightenment DR17 is built on top of Evas and thus supports OpenGL-ES 2.0 for a year or so.

Although not as complete in effects as Compiz, it does a great job at the basics to improve desktop usability, reduce flicker effects and is being used in various embedded system with SGX/PowerVR gpus.

[plonoma]

Very interesting.

With the compatibility stuff introduced in OpenGL 4.1, OpenGL has become a superset of OpenGL ES which makes things rather uncomplicated.

(OpenGL ES in radeon FLOSS drivers please)

[bridgman]

(OpenGL ES in radeon FLOSS drivers please)

In principle I believe it is there today, since the GL vs GL ES paths are up in the common Mesa code. Don't think it has been tested much, however, although AFAIK Wayland is using GL ES and EGL on the radeon drivers today.

[pingufunkybeat]

How does it work anyway?

Right now, the drivers advertise OpenGL 2.1 and the additional extensions.

How would they advertise OpenGL ES 2.0? Isn't all of the functionality needed for it already present?

[bridgman]

Last year you had to build mesa to expose GL or GL ES. My understanding is that more recent changes allow you to choose to expose any combination of GL, GL ES 1.1, GL ES 2.0.

I haven't had time to figure out exactly what an application program would see if you enabled both GL and GL ES. I think you either build the app against GL or GL ES headers and that embeds enough information for the runtime to figure out the rest.

[bridgman]

Last year you had to build mesa to expose GL or GL ES. My understanding is that more recent changes allow you to choose to expose any combination of GL, GL ES 1.1, GL ES 2.0.

My guess is that default builds only expose GL, not GL ES.

[mgraesslin]

In principle I believe it is there today, since the GL vs GL ES paths are up in the common Mesa code. Don't think it has been tested much, however, although AFAIK Wayland is using GL ES and EGL on the radeon drivers today.

It is there. I am using here KWin + OpenGL ES + EGL + radeon. It is working very nicely and I'm quite happy with it as it seems that the code pathes are much more stable (in fact I did not have a single crash since the switch to radeon compared to desktop GL crashing immediately) and reliable. Also KWin's OpenGL ES support had been implemented on nouveau with OpenGL ES/EGL. And we have asked distros to build special KWin packages and will recommend the ES usage.

[runeks]

This is great. I'm looking forward to (hopefully) be able to play with compiz on a Genesi Efika MX Smartbook at some point. That is, when they get the 3D driver working... ARM is cool, but it's too bad there are no open 3D drivers.

Hey bridgman, does AMD have any plans on entering the ARM-market? We need you here . I know you sold off a portion of ATI that dealt with ARM (Adreno, right?), have you reconsidered your position on ARM since?
Now that you've started generating profits again, maybe it's time reinvesting that money in an ARM division?
I'd love it if you could elaborate on this situation a bit; if it's possible, and if it isn't, why not.