Jump to content
  • Advertisement
Sign in to follow this  
dv

OpenGL OpenGL ES 2.0 and deferred shading?

This topic is 3072 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, looking at the gl2.h header, I don't see any 8_8_8_8 formats, only 5_6_5 and 4_4_4_4. This gets me worried, since I was about to write a GLES2 renderer using light-index deferred shading. But if I cannot get 32bit rgba textures to render on using FBOs, deferred shading as a whole becomes unfeasible. Area there really only 16bit textures on GLES2 devices?

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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 :-)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!