Deferred Shading Performance Problems

[Dark Photon]

I have a lot of light overlap, so I will try the tile based method. I assume that the lights are supposed to be passed to the shaders using fixed size arrays or the built in forward rendering lighting stuff.

Uniform arrays, UBOs, textures, ...whatever works.

[cireneikual]

I am nearly done coding the tiling version, but I ran into a problem: I decide which lights are assigned to which tiles by rendering the light volumes to an FBO with the same resolution as the tile grid dimensions, but if a volume is completely encompassed by a tile, it will disappear (too low resolution). Is there some way I can render to the FBO such that it will render to fragments as long as geometry is touching them?

[Dark Photon]

Is there some way I can render to the FBO such that it will render to fragments as long as geometry is touching them?

Maybe in the vtx shader push the corners away from the center toward the next pixel boundary? Just tweak the clip-space position you'd output before you're done.

[cireneikual]

Alright, I got the tiled deferred shading to work, but it actually runs significantly slower than the normal deferred shading. Using timer queries, I found that the problem wasn't on the GPU side, but the CPU was taking a lot of time to set up the lights after the light grid has been generated. Is glLightfv particularly slow? I have to call it hundreds of times each frame in order to set up the lights for each grid cell.

[aqnuep]

Alright, I got the tiled deferred shading to work, but it actually runs significantly slower than the normal deferred shading. Using timer queries, I found that the problem wasn't on the GPU side, but the CPU was taking a lot of time to set up the lights after the light grid has been generated. Is glLightfv particularly slow? I have to call it hundreds of times each frame in order to set up the lights for each grid cell.

What? You use glLightfv? For deferred rendering?

[cireneikual]

Yes, since I am using tile-based deferred shading: http://visual-computing.intel-resear...red_rendering/
It groups lights together based on tiles in order to reduce g-buffer look-ups.

[aqnuep]

Yes, since I am using tile-based deferred shading: http://visual-computing.intel-resear...red_rendering/
It groups lights together based on tiles in order to reduce g-buffer look-ups.

But why do you use glLightfv? Why don't use use uniform buffers or at least uniforms?

[cireneikual]

It was the easiest to implement. Why not use it? Is it slow?

[aqnuep]

It was the easiest to implement.

I can barely believe that it is in any way easier to implement than using uniforms.

Why not use it?

Maybe because it's deprecated, or because it's not really general purpose, or because you are bound to 8 lights per draw call?

Is it slow?

I would bet it is, though I don't know, I didn't call that function since the advent of programmable shaders.

Though, after this, I have doubts whether you actually implemented deferred rendering as that requires shaders and I (fortunately) haven't met anybody yet who used glLightfv with shaders.

[Dark Photon]

...I (fortunately) haven't met anybody yet who used glLightfv with shaders.

I betcha you have and have just forgotten

Remember GLSL pre-1.2 and gl_LightSource[0].diffuse, etc. (and similar Cg syntax in the arb profiles?) -- training wheels that let you implement fixed function pipeline and variants in shaders?