Announcement

Collapse
No announcement yet.

Why EGL...?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why EGL...?

    Context: I'm a complete noob when it comes to, well, a lot of things. This included.

    I was wondering why Wayland decided to go with EGL as it's interface. I looked it up and anything I can find on it says that it's an interface specifically for OpenVG/OpenGL ES. Isn't OpenGL ES for mobile/embedded systems? Why would we use that on a desktop?

    This is where my stupidity comes in, because this makes it sound like Linux desktops that use Wayland won't be using normal OpenGL, but rather OpenGL ES... and I was wondering what the effects on performance and everything would be with that...

    This is a serious question that I can't seem to find an answer to, and I figured this would be a good place to start

  • #2
    It's "just" a platform independent way to get gl contexts, buffers, ....
    You can still get a full blown OpenGL context using eglBindAPI(EGL_OPENGL_API) instead of any gles API if I'm not mistaken.

    Comment


    • #3
      Originally posted by droste View Post
      It's "just" a platform independent way to get gl contexts, buffers, ....
      You can still get a full blown OpenGL context using eglBindAPI(EGL_OPENGL_API) instead of any gles API if I'm not mistaken.
      Ah, that would be good
      Now if only the official documents stated that...

      Comment


      • #4
        Wayland doesn't _Have_ to use EGL rendering, it is backend-agnostic. If I recall correctly the Raspberry PI port of debian that uses Wayland, uses software rendering.

        Also, even when an EGL backend is used, it only means that the Wayland compositor uses EGL for composition, applications (Wayland clients) can still use whatever API they want for their rendering. The clients' job is just to get the graphics on a buffer and pass it on to the compositor, the clients can use whatever method they want for rendering those graphics - that's the whole point of Wayland, that it doesn't dictate any rendering API for the clients.

        Comment


        • #5
          Originally posted by dee. View Post
          Wayland doesn't _Have_ to use EGL rendering, it is backend-agnostic. If I recall correctly the Raspberry PI port of debian that uses Wayland, uses software rendering.

          Also, even when an EGL backend is used, it only means that the Wayland compositor uses EGL for composition, applications (Wayland clients) can still use whatever API they want for their rendering. The clients' job is just to get the graphics on a buffer and pass it on to the compositor, the clients can use whatever method they want for rendering those graphics - that's the whole point of Wayland, that it doesn't dictate any rendering API for the clients.
          Thanks for the info
          I should really start doing some deeper research on Wayland and graphic stacks in general :P

          Comment


          • #6
            Originally posted by dee. View Post
            Wayland doesn't _Have_ to use EGL rendering, it is backend-agnostic. If I recall correctly the Raspberry PI port of debian that uses Wayland, uses software rendering.
            The Raspberry Pi uses software rendering at the moment, but will be able to use hardware acceleration due to Wayland's backend agnosticism.

            X, the windowing software (or composition protocol) that we use, is not optimised to use the graphics core of the BCM2835, the chip at the heart of the Raspberry Pi. All the work is done by the ARM processor instead, which slows things down and leaves the graphics core twiddling its thumbs.
            from here

            Collabora has been working with the Raspberry Pi Foundation to deliver an improved Weston backend, making full use of the Raspberry Pi VideoCore to offload as much graphics processing work as possible, reducing CPU and memory usage.
            from here.

            Comment

            Working...
            X