Results 1 to 10 of 14

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

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,378

    Default OpenGL ES 2.0 Support For Compiz, KWin, Cairo

    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

  2. #2
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    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.

  3. #3
    Join Date
    Jun 2009
    Posts
    11

    Default 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.

  4. #4
    Join Date
    Sep 2010
    Posts
    480

    Default

    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)

  5. #5
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,538

    Default

    Quote Originally Posted by plonoma View Post
    (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.

  6. #6
    Join Date
    Jun 2009
    Posts
    2,932

    Default

    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?

  7. #7
    Join Date
    Dec 2010
    Posts
    108

    Default

    Quote Originally Posted by bridgman View Post
    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.

  8. #8
    Join Date
    Oct 2008
    Posts
    3,208

    Default

    Quote Originally Posted by V!NCENT View Post
    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.
    I was curious about this myself, so i looked it up.

    The core OpenGL ES 2.0 spec does not require it.

    It does define an extension, though, which is similar to the one required in GL3 (apparently it's less flexible but I don't know the particulars). It's supposed to be covered by the same patents, though. OES_TEXTURE_FLOAT

    Although optional, it seems it is expected to be present and so it might cause issues with applications that expect it if they aren't coded very well.

    From Khronos regarding the OES extensions:
    OpenGL ES extensions that have been approved by the Khronos OpenGL ES
    Working Group are summarized in this section. These extensions are not required
    to be supported by a conformant OpenGL ES implementation, but are expected to
    be widely available; they define functionality that is likely to move into the required
    feature set in a future version of the Specification.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •