GLES and the 2D Accelerator


pmprog

DNF (Did Not Finish)
Joined
Apr 25, 2011
Messages
4,150
So there's talk about the missing 3D drivers at the minute, and there's the 2D accelerator.

Will GLES require the 3D driver, even when trying to render 2D graphics? If so, how would the 2D accelerator be used?
 
"3D accelerator" is just a label put on the GLES hardware. The 2D accelerator is completely different, it has a featureset very simlar to DirectDraw. It can do right angle rotations, blits with blends or color keying, format conversion, scaling and a few simple things like that.

It's probably ideal for SDL 1.2 built-in blitting.
 
So I'm guessing SDL2 and Allegro (that both use GLES as a back end) will not work until the 3D drivers are sorted then? Am I understanding that right?
 
OpenGL is available even without 3D driver. That is, Mesa software rendering. Meaning stuff will still start, but rather crawl than run.
I had the honor to compile my game on the Pyra dev-board last Gamescom. 7 fps @ Pandora resolution. It was 2D rendered with OpenGL, running fullspeed on Pandora and generally not really demanding.
So uh, not really usable. There may be faster software OpenGL implementations, though.
 
OpenGL is available even without 3D driver. That is, Mesa software rendering. Meaning stuff will still start, but rather crawl than run.
I had the honor to compile my game on the Pyra dev-board last Gamescom. 7 fps @ Pandora resolution. It was 2D rendered with OpenGL, running fullspeed on Pandora and generally not really demanding.
So uh, not really usable. There may be faster software OpenGL implementations, though.
We need a glshim like wrapper lib which simulates 2D OpenGL ops using the 2D accelerator instead of 3D driver (or mesa replacement). :D

/joking :p
 
Neat, didn't know that existed.

But TinyGLES seems to be more akin to Mesa 3D, in that simulates OpenGLES in software.

My suggestion/joke was to do something like that, but using the 2D accelerator for the specific case of 2D rendered via OpenGL. Which is kinda silly because something like that would become redundant once proper 3D driver is working.
 
I'm not interested in the hardware acceleration blob, so as long as stuff compiled for the Pyra goes through Mesa or something else that can fall back to software mode this time, I'll be happy. :)

OpenGL support without hardware acceleration is not meaningless. I was able to run the Tiled map editor just fine in Pandian; it requires OpenGL, but having fast OpenGL is not so essential for it. I'm sure there are other such programs.
 
I'm not interested in the hardware acceleration blob, so as long as stuff compiled for the Pyra goes through Mesa or something else that can fall back to software mode this time, I'll be happy. :)

OpenGL support without hardware acceleration is not meaningless. I was able to run the Tiled map editor just fine in Pandian; it requires OpenGL, but having fast OpenGL is not so essential for it. I'm sure there are other such programs.

Well Mesa worked fairly well... World of Goo was semi playable and that was running X86 emulation via Exagear Desktop and Steam. Most of the 3D stuff I showed off was via Mesa.
 
  • Like
Reactions: rSl
Makes me wonder how horrible my code really was back then. I've improved the performance quite a bit by now since it wasn't impossible to drop some frames on the Pandora at certain times, but that bad?
Maybe I did something really suboptimal for Mesa every frame, not really sure at this point.

Let's say... it isn't the fastest, I guess.
 
Back
Top