OpenGL ES 2.0 and deferred shading?

There is an extension that provides support for 8888 surfaces, GL_OES_rgb8_rgba8, the format types are then:

* GL_RGBA8_OES,
* GL_RGB8_OES

There are alot of extension formats, take a look at gl2ext.h http://www.khronos.org/registry/gles/api/2.0/gl2ext.h. I think these are widely supported

Regards,

Alex

You'd be surprised at how much the sgx and mbx [to some extent] can handle. I can't post picks, but my current project, uses some advanced [new gen] shaders like effects. The trick is, i leverage memory on gpu and ram (iphone that is). If you have a few passes, offset workload on ram, render to buffer and export for off-gpu calculations.

The SGX makes it easier, as i have access to almost all rendering buffers.

Good Luck

Quote:

Original post by namar777 You'd be surprised at how much the sgx and mbx [to some extent] can handle. I can't post picks, but my current project, uses some advanced [new gen] shaders like effects. The trick is, i leverage memory on gpu and ram (iphone that is). If you have a few passes, offset workload on ram, render to buffer and export for off-gpu calculations. The SGX makes it easier, as i have access to almost all rendering buffers. Good Luck

What do you mean with "almost all rendering buffers"? That you can access stencil, depth, color with the CPU?

Furthermore, is there some table of recommendations what to do and what to avoid for PowerVR SGX chips?

One other problem is: I want to use LIDR because I can use it without requiring floating point format buffers. Quick recap: LIDR renders light indices instead of material attributes in its G-buffer. A second pass then accesses light attributes by using said IDs. It is possible to get away with RGBA8 for the G-buffer (e.g. no floating point stuff, just one RGBA8 tuple per pixel). However, LIDR requires storing the lights in a texture or buffer (otherwise the index would be useless). With OpenGL3 (or GL2 with extensions), I would create a texture buffer object or uniform buffer object for this. I cannot require such a thing for GLES2.

I have four point light attributes (position, radius, attenuation, color), which means 8 floats per light. Given a maximum of 256 visible lights per scene, this would require 128 uniform matrices. Now, I could store the floats as RGBA8 tuples in a RGBA8 texture, color could be converted to logluv to allow for luminances >1 while occupying only one RGBA8. The result would be 5 RGBA8 tuples for each light. Note that this texture would probably be modified each frame. This, combined with additional unpacking (though unpacking a float is essentially just a dot product with a constant vector), makes me wonder if I am doing something that would diminish the PowerVR's performance.

I could just try it out, however my development platform with the SGX on it will arrive in a couple of weeks, and if somebody with PowerVR experience can spot a bottleneck just by reading the text above, it would save me a lot of time :-)

For SGX development advice, please take a look at the first 2 links in my sig.

Regards,

Alex