Allow disabling depth prepass with r_depthShaders

[slipher]

This cvar can be used to demonstrate that #119 is caused by a faulty depth shader. Or to quantify the performance benefits of depth shaders.

AFAIK disabling them shouldn't affect the final result of rendering, so it does not need to be a cheat var. But I could be wrong. So in case the performance benefits turn out to be negative on some system, depth shaders could be turned off.

[slipher]

Another bug suspected to be caused by a faulty depth shader is #334. This could be tested by reverting the workaround 3c7061a. I don't know which map has this though.

[VReaperV]

But I could be wrong.

The benefit is performance, yes. Also, I think you can make it non-latch and instead do the check in R_AddDrawSurface().

[VReaperV]

AFAIK disabling them shouldn't affect the final result of rendering, so it does not need to be a cheat var. But I could be wrong.

Actually, there is. We have some shaders that use the current depth image: generic, global fog, motion blur, SSAO and dynamic light shaders (depthtile1/2 and lighttile). While global fog and SSAO would be rendered after all depth is written anyway, the other 5 won't.

[VReaperV]

Also, it would break portals.

[slipher]

Also, I think you can make it non-latch and instead do the check in R_AddDrawSurface().

Just tried this but it wasn't totally convenient since the depth mask bits of the main shader are modified depending on whether there is a depth shader. I'd have to make a backup copy of the depth bits.

We have some shaders that use the current depth image: generic, global fog, motion blur, SSAO and dynamic light shaders (depthtile1/2 and lighttile). While global fog and SSAO would be rendered after all depth is written anyway, the other 5 won't.

Hmm yeah the light tile is a deal breaker. I don't think any of the others are problems but lighting definitely is. I'll make this a cheat cvar for debugging then.