Deferred Shading article+ Demo
- Thread starter ben6
- Start date
Cg won't magically make an application run on a card that doesn't support the necessary extensions. Especially extensions that have nothing to do with Cg such as NV_float_buffer, which is for high precision floating point pbuffers.
Also, AFAIK there is no equivalent ATI extension that exposes floating point pbuffers under OpenGL.
Also, AFAIK there is no equivalent ATI extension that exposes floating point pbuffers under OpenGL.
About the algorithm I have a doubt.
Why does it have to do one extra pass for each light? From what I know about the Phong Lighting Equation and pixel shaders you just have to calculate n lights in the same shader program (limited by the maximum number of instructions in the pixel shader). Only if you are going to use more lights than the number of lights that can be sopported in single pixel shader program you should do multiple passes.
The algorithm seems efficient in the sense that multiple passes (>2) are iimplemented with just two pasess and the second one generates only as many fragments in the rasterizer as the screen resolution (because you are just sending the quad). Also the vertex shader only has to process 4 (6) vertexs. This seems even better than just a first pass with only generate Z and then only process the fragments that has the same Z in next passes. In the later all the geometry is processed again with each new pass, and the same amount of original fragments are generated by the rasterizer (even if they are killed before shading).
Rendering to multiple textures (if their data size is larger than the framebuffer data size) would be better because more information per pixel could be stored. The limit seems to be in how much data can you store at the end of the first pass for the next passess per pixel.
Why does it have to do one extra pass for each light? From what I know about the Phong Lighting Equation and pixel shaders you just have to calculate n lights in the same shader program (limited by the maximum number of instructions in the pixel shader). Only if you are going to use more lights than the number of lights that can be sopported in single pixel shader program you should do multiple passes.
The algorithm seems efficient in the sense that multiple passes (>2) are iimplemented with just two pasess and the second one generates only as many fragments in the rasterizer as the screen resolution (because you are just sending the quad). Also the vertex shader only has to process 4 (6) vertexs. This seems even better than just a first pass with only generate Z and then only process the fragments that has the same Z in next passes. In the later all the geometry is processed again with each new pass, and the same amount of original fragments are generated by the rasterizer (even if they are killed before shading).
Rendering to multiple textures (if their data size is larger than the framebuffer data size) would be better because more information per pixel could be stored. The limit seems to be in how much data can you store at the end of the first pass for the next passess per pixel.
Hyp-X said:Humus said:
Do you think it can be implemented on the R9700?
(Just if you have no idea for your next demo)
Well, if ATi ever decides to ship the 9700 I have ordered to me so I can try ...
It should be possible to do on the 9700 though, and I might try it someday. However,
sound like an incredible fillrate eater. Can't see how this can be any faster unless you're extremely transform-limited. Using loops in the fragment program and do all lights at once might solve that. You'll still need another pass per light anyway if you want shadows.
I don't think so. I just know of it's existance because I saw it in a glATi.h file some time ago.
Edit: It turns out it's called GL_ATI_texture_float. I guess it might not be related to pBuffers after all.
#define GL_RGBA_FLOAT32_ATI 0x8814
#define GL_RGB_FLOAT32_ATI 0x8815
#define GL_ALPHA_FLOAT32_ATI 0x8816
#define GL_INTENSITY_FLOAT32_ATI 0x8817
#define GL_LUMINANCE_FLOAT32_ATI 0x8818
#define GL_LUMINANCE_ALPHA_FLOAT32_ATI 0x8819
#define GL_RGBA_FLOAT16_ATI 0x881A
#define GL_RGB_FLOAT16_ATI 0x881B
#define GL_ALPHA_FLOAT16_ATI 0x881C
#define GL_INTENSITY_FLOAT16_ATI 0x881D
#define GL_LUMINANCE_FLOAT16_ATI 0x881E
#define GL_LUMINANCE_ALPHA_FLOAT16_ATI 0x881F
Edit: It turns out it's called GL_ATI_texture_float. I guess it might not be related to pBuffers after all.
#define GL_RGBA_FLOAT32_ATI 0x8814
#define GL_RGB_FLOAT32_ATI 0x8815
#define GL_ALPHA_FLOAT32_ATI 0x8816
#define GL_INTENSITY_FLOAT32_ATI 0x8817
#define GL_LUMINANCE_FLOAT32_ATI 0x8818
#define GL_LUMINANCE_ALPHA_FLOAT32_ATI 0x8819
#define GL_RGBA_FLOAT16_ATI 0x881A
#define GL_RGB_FLOAT16_ATI 0x881B
#define GL_ALPHA_FLOAT16_ATI 0x881C
#define GL_INTENSITY_FLOAT16_ATI 0x881D
#define GL_LUMINANCE_FLOAT16_ATI 0x881E
#define GL_LUMINANCE_ALPHA_FLOAT16_ATI 0x881F
Has anybody tried running this yet? I get 6.5 frames per minute
Similar threads
