glReadPixels + GL_DEPTH_COMPONENT? Why is this not possible?

I have decided to port some of my work to OpenGL|ES. Why reading the depth component should be so slow as you have mentioned somewhere in this forum? glReadPixels is normally not the fastest thing, too. But…there is some support for it. What about the depth buffer. We have accepted painfully the write only vertex buffers. The lack of glPolygonMode, too. What should we do now without access to the depth buffer? How are we supposed to do lens flares and occlusion tests of points generally? For the other missing features we have writen own “emulations”. As the pixels are accessible, the depth buffer must be accessible, too. Just make a survey among the developers to inform you which are the most used functions in OpenGL and then make your specs. Possibly, you ask the hardware manufacturers first what would be possible. Ofcourse, they offer you the cheapest possibility for them. I think if you have asked the developers first and then served the ready spec to the manufacturers they would accept this, as they would have no choice. It is just funny to have support for the physically useless matrix palette extension that nobody in the game industry has ever used, and not to have support for the key features of OpenGL. Anyway…I just want to know how you, people, decide what to be and what not to be? This is the question?

Hi bkamenov,

I think everyone has different requirements, and the OpenGL/ES will never reach the full potential of OpenGL (wasn’t that the idea to begin with?, have a rendering API that’s lean but simple and powerfull?).

I for example can perfectly live without zbuffer readback, but I’d love to see glTexGen, the GL_INTENSITY format for textures.

glPixelStorei (GL_UNPACK_ROW_LENGTH, …) is also missing. The lack of this one is a shame. Sure I can work around this with buffer copies, but I can’t see reason why it wasn’t implemented. It’s dead easy to add that into the glTexSubImage copy-loop.

After working with GL/ES for almost a year now I think it’s a nice and usable subset of OpenGL. All the features I really missed could be worked around.

If you want to do have lensflares that use occlusion just organize your data so you can raytrace in the CPU (for a single ray or two this will even work on slow CPU’s).

That is for sure that I should make workarounds for some fx. But ray tracing is unfortunatelly suitable only for geometry based objects and even in this case not so cheap (using CPU cycles). How about the ray intersection test with a dynamic geometry (skinning, morphing) or with planes with an apllied alpha channel (leaves of a tree)? Object approximation (sphere, box & ect.) produces poor results in this case. Working on mobile devices implies writing fast algorithms and the ray tracing in this situation is not the best solution. Actually, the collision detection is also an enormous problem for the current devices. Adding the sound processing would make a slide show of the already slow graphics - ARM processors without FPU. Anyway I should live without it - I want too much, I suppose, but I`d prefer to write some new features instead of thinking out tricky emulations of old standards.

I had a similar problem a couple of years ago when I moved a game project from a platform where I could do occlusion testing to a platform where it wasn’t possible.

I rendered additive glow-billboards around lightsources to make them look better (think streetlights in a racing game at night). As I didn’t had occlusion anymore I just moved them slightly to the viewpoint and rendered them with z-test enabled.

It took weeks for our graphical artists to find out that they where always a tiny bit off center (due to the projection) and didn’t had the “real” occlusion anymore.

And it was a lot cheaper to render them as well. I still have screenshots here. Notice how nice the lighting effects look like though everything was faked with billboards.

looks really nice. How about porting that to OpenGL ES? :slight_smile:

Reading the framebuffer is one of the most expensive operations, as it defeats parallelism between CPU and GPU. The CPU has to wait until the GPU has finished rendering the current frame. Then the GPU has to wait until the CPU has finished whatever it wants to do with that frame data and starts submitting GL commands again. Depending on the graphics architecture, driver and workload, you could lose 2/3 of the potential performance that way.

For the color buffer, it can be argued that the ability to take screenshots or to mix 3D rendering into 2D GUIs is an absolute necessity. I don’t think there is an equally strong argument for reading the depth buffer. In fact, reading the depth buffer can be even slower as some graphics architectures never store a depth buffer in memory during normal operation. OpenGL ES 2.0 will have visibility queries. But for the moment you will have to live with what’s there already. Just like you can’t use shaders yet though most developers want them. (Though I’m not convinced most developers want the ability to read the depth buffer)

As to how Khronos decides on API specifications, have a look at the promoter, contributor, and academic member lists on this page:
These are the companies and organizations that take part in defining Khronos APIs. There are hardware and software companies, but often the hardware companies are the main contributors, for several reasons. They are the ones who have to deal with the specification first. They have the resources for extensive research. And they know best the implementation costs as well as limits of feasibility.

A specification driven entirely by software developers is unlikely to work. Not just because it would probably ignore requirements for an efficient hardware implementation, but also because of the timescales. Hardware development often starts before the API specification process, and as time progresses, they influence each other. The goal is to have implementations available by the time the specification is ratified, so application developers can immediately use the API. Without this communication, hardware developers would have to start much later, creating a huge gap between when the API spec is finalized and the time implementations become available.

You say hardware manufacturers would have no choice. That is not true. They could choose to ignore a spec that is forced on them and form a group like Khronos where software AND hardware companies have a say in the spec.

Please don’t think hardware companies don’t take the opinions of software developers into account. They do, as everybody is aware that hardware without software would be pointless. But these requirements are filtered with the results of research, the experience on what can be efficiently done in hardware, and the demands of customers.

Now Im happy that I have a really professional answer. I was a little confused about the things going around OpenGL|ES and I really didn't want to insult anybody. Surely there must be some reasons to shorten OpenGL|ES in that way. I was going out from the normal old desktop OpenGL. It must do the same sync, mustn't it? That is why lots of question marks have arosen around my head - why these guys are doin' that. The shaders should come but in a few years. I thing they are a great tool but only with the dynamic branching freedom. The mobile devices aren't so fast yet. Ill test the power of PowerVR on a Nokia N93 on Monday, hopefully it will bring the so desired FPU power and framerates over 20fps. Nils, it is nice to hear more from collegues in Germany. The screens are very cool. We have also a surprise for the mobile 3D community, but this will be anounced in a few months. Have a nice weekend guys and lots of greetings from Bremen.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.