No it's a hack. It's actually no real improvement to stock gb.
It's actually worse. Have you tried a GPU intensive app (angry birds will do nicely) yet?
The "HW accel" is more like disable everything related to the real hw accel and so add backward support. Arcee sure can give more informations on this, because he wrote it (and is way more into android than I am). But this is my understanding.
It's a bit uglier than that. Reverting to a GB-compatible state is pretty much impossible, since the changes are big, and span a lot of subsystems (everything that deals with the display: surfaceflinger, stagefright, camera, and all their dependencies).
The 2 major (there are others) changes are:
1 - display buffer management now depends on the new unified "Android Native Window" buffers, managed by gralloc. (the old overlay system for video/camera was completely discontinued). Pre-HC grallocs do not support this in any way or fashion, and will fail in any attempt to do so.
2 - Most textures (think of them as bits of displayed stuff) are now of a specific type (external EGLimage), which are opaque to the GL implementation (i.e., it doesn't need to recognize the format to pass them along between layers). The renderers forward everything along as external images, and pre-HC GL implementations didn't support the image_external extension at all, so they reject any attempt to do this.
The simplest way I can explain this is... the hacks I placed in CM9 force everything to be plain old (and supported) 2D textures, and push them into gralloc as such for immediate render.
This is not how it's supposed to work, the GPU
hates it, so a number of other hacks were necessary (like retrying unlocks every 1msec whenever a buffer operation fails), and the end result is a highly innefficient implementation (and completely incompatible with the actual accelerated stuff ICS wants to use). There's no acceleration at all, just a best-effort approach at getting things to actually render; And since it doesn't create true ANative buffers, things that depend on them (OMX and Camera, for instance) won't work either.
Now... this was
never meant to go into distributable builds, and it's very unlikely you'll ever see "official" CM9 builds using this stuff. Its only purpose was to get the devices functional enough to work on more generic CM features outside an emulator.