Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I asked this on StackOverflow, but it might make more sense here:

Has anyone implemented deferred rendering/shading under OpenGL ES 2.0? It doesn't support MRTs, so with only one color buffer, it's not something that can be implemented in the "usual" manner.

Specifically, I'm exploring on iPad, iPhone4 (maaaybe iPhone 3gs), and Android. On the GLESView app on iPad/iPhone4/iPhone3gs, the GL_OES_RGB8_RGBA8 extension is present, and I haven't looked too deeply yet, but with 8bits/channel, this idea is interesting: http://www.gamedev.net/topic/562138-opengl-es-20-and-deferred-shading/

Any other ideas? Is it even worth doing, performance-wise?

share|improve this question
    
Yes, its possible. –  iamcreasy Jul 31 '11 at 0:28
5  
Via which technique(s)? –  Jim Buck Jul 31 '11 at 0:39
add comment

3 Answers 3

Really you have to consider what is the absolute minimum you need for a deferred renderer. If you fall back to deferred lighting it reduces the amount of data that needs to be stored in the GBuffer, and really it's a helluva lot cheaper than rendering half the scene 3 time or more to support a low amount of lights.

I would go for the following GBuffer format:

  • Reuse the depth buffer for the lighting pass, not sure how widely this is supported on mobile devices, but it's a free depth texture.
  • A single GBuffer texture, inside it I would store: Normal U, Normal V, Param 0, Param 1. Lambert-Azimuthal encoding looks really nice for normals and compresses them down into just two components, relatively cheap to encode and decode as well.
  • Two parameters for lighting variables is a lot, could use one as an enumeration for multiple lighting functions if the hardware does well with dynamic branching.

Deferred lighting is similar to deferred rendering, except you render the scene twice:

  1. Render Geometry Depth, Normals, and Lighting Parameters into the GBuffer.
  2. Render Lights into the accumulation buffer.
  3. Render Geometry with material shaders, composite your lighting here as well. If your good with working out reverse operators of lighting equations you can do a LOT of really cool things with this step.
  4. Do any post-processing you can afford, be sure to abuse the depth and normal textures to death here for efficiency sake.

About storing the lighting results. I've become fond of storing diffuse color and specular luminance so that the accumulation buffer only needs to be a standard 32-bit color texture. You can estimate the specular color by calculating chroma of diffuse color and combining that with specular luminance.

The most important part however is going to be using the depth-stencil buffer to it's fullest, ensure that your not rendering any of the lighting code where it's not needed. I'd even go so far as to add some discard statements into the fragment shaders on terms that will drop light visibility below the device's displayable range (1e-3 is usually a safe cutoff).

share|improve this answer
add comment

The main problem is Fillrate. On mobile GPUs, your fill rate is low that you can't do Deferred shading in realtime at native resolution.

On iPhone 4 & iPad 1, fillrate is just ridiculous. The only device IOS with good fillrate is iPad 2, but i doubt there is enough... On android, only Tegra devices have the GL_NV_draw_buffers to use MRT but fillrate is very low too. The Mali 400 seems to have the best fillrate. If you want cry, just try to fill a color rectangle at fullscreen resolution 4 times... Many devices can't do it 60 fps.

On desktop GPUs, you have 10 times (or more) fillrate as mobile gpus. Don't forget that mobile GPUs use the same memory as CPU and you don't have dedicated memory.

There are some examples in WebGL (same API) so that isn't a limitation of the API.

share|improve this answer
1  
+1 to fillrate weakness. I couldn't even get Gaussian blur to run on 1536x2048 resolution at 60fps (it immediately bumped the frame rate down to 30fps, even with only 4 samples) –  bobobobo Mar 24 '13 at 17:50
add comment

Yes, it is possible. However, it isn't particularly worthwhile.

First, unless you have access to the NV_draw_buffers extension (as the name implies, it is NVIDIA-only. So unless you're running on Tegra, you don't have it), framebuffer objects under ES 2.0 can only render to one image at a time. So to generate your G-buffers, you will need to render your scene multiple times, thus taking away one of the advantages of deferred rendering.

Second, bandwidth on mobile platforms is not the same as you would get even on mid-grade GPUs. And bandwidth is critical to making deferred rendering (for many lights) worthwhile. Without that bandwidth, the light passes are really going to hurt, performance-wise.

Third, PowerVR hardware is really not designed for this kind of thing. It optimizes rendering with its tile-based rendering hardware. So deferred rendering on top of that would be less helpful than in a traditional scan-conversion architecture.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.