On 14/10/2007, Chris Robinson chris.kcat@gmail.com wrote:
May need more work for this to be proper, but we currently allow R16F render targets under the same circumstances. It's also enough to make UT3 (which requires it) happy.
Unless the performance problems with R32F have been fixed, this will cause performance regressions in applications that actually try to use it. (C&C3 for example).
On Sunday 14 October 2007 02:57:35 am H. Verbeet wrote:
On 14/10/2007, Chris Robinson chris.kcat@gmail.com wrote:
May need more work for this to be proper, but we currently allow R16F render targets under the same circumstances. It's also enough to make UT3 (which requires it) happy.
Unless the performance problems with R32F have been fixed, this will cause performance regressions in applications that actually try to use it. (C&C3 for example).
With some other fixes, it may work better using pbuffers where there are possibly R32F formats available. Unfortunately, by oversight or design, GL has no renderable single-component formats* so we have to fall back to R32G32B32F, which could be a bit harder on the hardware. Most apps seem to only use it for shadow mapping though, so perhaps using a 32-bit depth texture would work? And maybe use depth textures for R16F as well.
* There is the NV extension which gives 16 and 32-bit Red-only renderable formats, but that has other issues, namely having to use GL_TEXTURE_RECTANGLE_NV which causes the texture's coords to behave differently. Plus it won't work on non-NV hardware.
Am Sonntag, 14. Oktober 2007 18:24:42 schrieb Chris Robinson:
With some other fixes, it may work better using pbuffers where there are possibly R32F formats available. Unfortunately, by oversight or design, GL has no renderable single-component formats* so we have to fall back to R32G32B32F, which could be a bit harder on the hardware. Most apps seem to only use it for shadow mapping though, so perhaps using a 32-bit depth texture would work? And maybe use depth textures for R16F as well.
What does a depth texture return for red, green, blue and alpha when sampled by a pixel shader, or a vertex shader via VTF? Does it work with fixed function fragment processing? It may be a workable solution if the returned channels match, since it doesn't have the texture rectangle restriction.
On Sunday 14 October 2007 11:34:41 am Stefan Dösinger wrote:
What does a depth texture return for red, green, blue and alpha when sampled by a pixel shader, or a vertex shader via VTF? Does it work with fixed function fragment processing? It may be a workable solution if the returned channels match, since it doesn't have the texture rectangle restriction.
According to the ARB spec, whenever a depth texture is used for color, it behaves like a luminance texture, so I'd assume r, g, and b would be the depth value, and alpha would be 1. I'm just not sure if you can attach a depth texture to a color attachment on fbos..
On Sunday 14 October 2007 02:57:35 am H. Verbeet wrote:
Unless the performance problems with R32F have been fixed, this will cause performance regressions in applications that actually try to use it. (C&C3 for example).
Thinking some more, it's also possible that wined3d's too lax in reporting 32-bit float formats. GL's float extension requires both 32-bit and 16-bit formats (the half-float extension is only for uploading 16-bit float data) with all the blending effects. By contrast, D3D drivers may have supported 16-bit floats first, and not reported 32-bit floats until the hardware was powerful enough.
Perhaps if 32-bit float formats aren't reported unless some other cap indicates newer hardware is present, it'll prevent apps from using 32-bit floats where it'd be a detriment to speed.
On 14/10/2007, Chris Robinson chris.kcat@gmail.com wrote:
On Sunday 14 October 2007 02:57:35 am H. Verbeet wrote:
Unless the performance problems with R32F have been fixed, this will cause performance regressions in applications that actually try to use it. (C&C3 for example).
Thinking some more, it's also possible that wined3d's too lax in reporting 32-bit float formats. GL's float extension requires both 32-bit and 16-bit formats (the half-float extension is only for uploading 16-bit float data) with all the blending effects. By contrast, D3D drivers may have supported 16-bit floats first, and not reported 32-bit floats until the hardware was powerful enough.
Perhaps if 32-bit float formats aren't reported unless some other cap indicates newer hardware is present, it'll prevent apps from using 32-bit floats where it'd be a detriment to speed.
IIRC it's specifically R32F that's slow, while A32B32G32R32F should work ok. Looking at the format table, perhaps that's just GL_RGB32F_ARB vs GL_RGBA32F_ARB, not sure. If nobody else does, I can try to look into that tomorrow.
-
Chris Robinson -
H. Verbeet -
Stefan Dösinger