Why the obsession with OpenGL?

[Brian Beuken]

maybe a bit controversial...but.

I'm kinda worried about the mad rush everyone is heading towards to use the new OpenGL drivers, its a nice idea, but the chip itself does not support full OpenGL, so that will mean some of it is going to be software rendered and we don't have that much CPU power.

Isn't it simply a better idea to focus on using OpenGL ES2.0 properly? Used well its more than capable of producing some amazing graphic work. (though I do keep finding faults in the Pi version)

[Fidelius]

For us here Blender is a "killer app", and according to some first short tests, it works great with the new alpha OpenGL driver on our Pi².

Not to mention my wife's "killer app" Tetzle... ;-)

And the desktop's windows are moved, resized etc faster now. Because this new driver provides HW accelerated X11 2D support (AFAIK this is called Glamor on Linux?) and HW accelerated 3D via OpenGL. So the Pi²'s user experience is visibly better now, with the plain desktop and with 3D apps like Blender.

And this is highly welcomed. Because there's so many applications in Debian's huge software repository relying on OpenGL which now can be installed out of the box with late Ian Murdock's apt-get. Why wait for them [edit: them = the many OpenGL applications in the repository] to get OpenGL-ES ready, if they ever do?

Until before this new driver, the nice Videocore4's potential has mostly been sleeping when we used the Pi² in a desktop session. Now the good Pi² gets an important 2D and 3D helper and this additional potential is made available with this new duo driver.

Well done, Pi-Foundation, Broadcom and Eric Anholt!

[PeterO]

Why wait for them to get OpenGL-ES ready, if they do ever?!

Minor correction: OpenGL ES 2.0 has been available on the PI since they start (or soon after). Some of us have even written applications using it !
PeterO

[Fidelius]

OpenGL ES 2.0 has been available on the PI since they start (or soon after). Some of us have even written applications using it !

Peter, thanks for that addition, and indeed I too use OpenGL-ES on the Pi since I got one (mostly via Java's FX which on ARM devices uses OpenGL-ES to do hardware acceleration).

What I meant was those many (majority?) of applications in Debian's software repository which need OpenGL in order to run "out of the box", like Blender, Neverball, etc.

[PeterO]

Too many "them"s I see what you mean now
I don't think they will ever get them ready. Application sets for Desktop GL and ES are different. The Pi is "odd" because you have a chip designed for mobile applications (hence supporting ES) being used in a desktop environment (which really wants "full" GL).
PeterO

[jamesh]

I reckon for a first version, this OGL driver is pretty good. As the OP said, it does resort to SW rendering when there isn't a HW block to do the work but I think Eric has also written code to run on the VPU/Quads to offload that from the main ARM CPU's, which is how a lot of the original OGLES stack worked anyway.

The advantages of OGL have been well explained in previous posts.

However, I am intrigued to know what areas of OGLES2.0 are breaking, since the library passes the Khronos conformance tests. I presume they have been reported on github? The library has been used extensively 'in the field' in millions on mobile devices so is pretty well tested. (Nokia, Samsung, Roku, Amazon + others)

[Fidelius]

I don't think they will ever get them ready. Application sets for Desktop GL and ES are different. The Pi is "odd" because you have a chip designed for mobile applications (hence supporting ES) being used in a desktop environment (which really wants "full" GL).

How true. It's another reason why the OpenGL and OpenGL-ES successor Vulkan combines both worlds, I think?

[Fidelius]

I reckon for a first version, this OGL driver is pretty good.

Yes, indeed. Even the "acid test" aka Blender worked fine right out of the box. We only created a few smaller models but it worked very fine so far. For an alpha driver indeed!

As the OP said, it does resort to SW rendering when there isn't a HW block to do the work but I think Eric has also written code to run on the VPU/Quads to offload that from the main ARM CPU's, which is how a lot of the original OGLES stack worked anyway.

Is this what our desktop PC's Gallium driver does via llvmpipe, when certain OpenGL features are required by some 3d apps which our old ATI graphics card can't deliver in hardware? (Then the CPU cores' load increases heavily then, but at least the applications display what they should.)
Just here Eric moved these software rendering parts from the ARM CPU to the VC4's quads? Impressive.

[Brian Beuken]

However, I am intrigued to know what areas of OGLES2.0 are breaking, since the library passes the Khronos conformance tests. I presume they have been reported on github? The library has been used extensively 'in the field' in millions on mobile devices so is pretty well tested. (Nokia, Samsung, Roku, Amazon + others)

viewtopic.php?f=68&t=136093&p=905054#p905054

[Pablo Walters]

And the desktop's windows are moved, resized etc faster now. Because this new driver provides HW accelerated X11 2D support (AFAIK this is called Glamor on Linux?) and HW accelerated 3D via OpenGL. So the Pi²'s user experience is visibly better now, with the plain desktop and with 3D apps like Blender.

Where can we download this new driver? Does it support OpenGLES in X windows? This sounds wonderful.