Announcement

Collapse
No announcement yet.

Raspberry Pi 4's V3D Driver Adds OpenGL ES 3.2 Geometry Shader Support

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

  • Raspberry Pi 4's V3D Driver Adds OpenGL ES 3.2 Geometry Shader Support

    Phoronix: Raspberry Pi 4's V3D Driver Adds OpenGL ES 3.2 Geometry Shader Support

    The Broadcom V3D Gallium3D driver within Mesa 20.0 now has initial support for geometry shaders as needed by OpenGL ES 3.2...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by 144Hz View Post
    Merge request, not pull request.
    Meh, same thing, different versioning system.

    Having just made the change in my company from mercurial on rhodecode to git on gitlab, I have some sympathy for mixups like that.

    Comment


    • #3
      Will we ever see the Broadcom driver in Mesamatrix? It seems like Eric Anholt didn't like that and preferred the (less up to date) overview here https://people.freedesktop.org/~imirkin/glxinfo/

      Also how useful is GL ES on the desktop? I would have thought Core GL (and Vulkan) is what we really want?

      Comment


      • #4
        Originally posted by Veto View Post
        Will we ever see the Broadcom driver in Mesamatrix? It seems like Eric Anholt didn't like that and preferred the (less up to date) overview here https://people.freedesktop.org/~imirkin/glxinfo/

        Also how useful is GL ES on the desktop? I would have thought Core GL (and Vulkan) is what we really want?
        Probably depends upon the camp you sleep in but yeah Vulkan see to be the long term play here.

        Comment


        • #5
          What's the limits the hardware supports in Vulkan, GL and GLES?

          Comment


          • #6
            Originally posted by Veto View Post
            Also how useful is GL ES on the desktop? I would have thought Core GL (and Vulkan) is what we really want?
            Qt5 can be compiled to use GL ES2, so if your favourite desktop environment is KDE/Plasma, this make it possible to run OpenGL accelerated desktop on SBC-class hardware such as the Raspberry Pi in this article. Or in my case on the Rockchip 3399 / panfrost supported Pinebook Pro. Manjaro ARM is an example of a distro that has such es2 variant of qt5, enabling accelerated Plasma desktop.

            Such boards already have OpenGL ES support, but might not have full blown OpenGL yet. (That's the case with panfrost). If you go check mesamatrix, you'll notice that OpenGL and OpenGL ES don't exactly require the same extension - thhus sometime a driver can have enough reverse engineered stuff to be able to work for ES but not OpenGL.
            Qt5 ES2 is one solution in this case.
            The alternative solution using something like gl4es which is a OpenGL to OpenGL ES translation level, which enables full blown OpenGL desktop acceleration on hardware that only has OpenGL ES support.


            TL;DR: GL ES on the desktop is useful as a temporary solution until full blown Open GL is availabble.

            Comment


            • #7
              Michael - are you planning to interview the Igalia developers at any point to get into the detail of what they are planning to do with the project going forward? I'd be interested to know if they have any plans to implement some sort of S3TC - > Ericcson Texture Compression wrapper to get texture compression running with existing applications. Or simply force it on with an application.

              Comment

              Working...
              X