z-buffer, render targets & shaders
category: general [glöplog]
Is it possible to read the z-buffer from a shader or do I have to render the depth to a render target and use it as a texture on the shader?
You can with DX10 (you have to be careful with the multisampling)
You can't with DX9 on PC (althouth there is a hacky way with some ATI cards) but you can on XBOX 360.
You can't with DX9 on PC (althouth there is a hacky way with some ATI cards) but you can on XBOX 360.
How do I know that my shader code doesn't suck? Like being slow or something, is there something I shouldn't use?
experience
shouldn't you have said, experiments?
shouldn't you have said, plagurise?
xernobyl, use nvidia perfhud, pix for windows (actually it's getting quite good but still miles away from pix for xbox).
xernobyl: reading the zbuffer you're currently writing to - no. reading a previously rendered zbuffer as a texture - yes, possible on ati in dx9 (but not on nvidia because of their shadowmap hack), possible on dx10, possible in opengl. otherwise you have to render depth values to a (float) rendertarget.
performance-wise, there's a load of things that can make your performance slow to a crawl and it all depends on the situation. :) number of instructions in the shader, texture reads, loops and branches in shader, anything which breaks zcull (there's a whole bunch of ways to do that) or doesnt make best use of it.. :) a long list.
if youre using an nvidia card and directx get nvperfhud, it's a huge help in finding the cause of the problem.
performance-wise, there's a load of things that can make your performance slow to a crawl and it all depends on the situation. :) number of instructions in the shader, texture reads, loops and branches in shader, anything which breaks zcull (there's a whole bunch of ways to do that) or doesnt make best use of it.. :) a long list.
if youre using an nvidia card and directx get nvperfhud, it's a huge help in finding the cause of the problem.
GLSLDevil is also nice for finding OpenGL and GLSL bugs.
Quote:
number of instructions in the shader, texture reads, loops and branches in shader
That was not the answer I was looking for... if that doesn't stall a processor I don't know what would :D
I know it wasn't a good question. It was more a "don't bother trying to..." sort of question. :)
Anyway thanks for all the answers. I think ps won the thread.
just two words for ya. SOFTWARE RENDERING!
GLSLDevil is strange on my machine.. I basically haven't managed to get it to do anything interactive, even when I load up glsl files. Weird.
same for me, cant get GLSLdevil to work. the whole application hangs up when i start to launch a debugsession.
you still have to run some kind performance analyze tool for your software renderer aswell i guess. (if you want to optimize it).
Software rendering... home-made pixels & stuff...
if you make your own pixels, isn't that hardware-based rendering?
hmm, exact. But with less hardware facilitations/enhancements.
(^ in the case of sw rendering). Like: you have to write more code to obtain the same result, so the "home-made factor" increases (intended as the number of things you have to create/do by yourself).
Thinking better about that, I realize that the definition of "home-made" can be not so obvious ...at all o_O
Thinking better about that, I realize that the definition of "home-made" can be not so obvious ...at all o_O
anyway software rendering and hardware rendering, it's the same thing in the end: you need to be able to test the performance of your code, and to have indicators.
Software rendering make it easier, because the performance is easier to predict and measure: it's more linear.
It seems to me that performance prediction for hardware rendering is a great deal more complicated because you can have interdependencies and big cases of "fringe" effects when you start exceeding the hardware capabilities. (which are also multi dimensional rather than say, the easy "number of cycles" available per frame that can serve as a mental model for CPU based rendering)
Software rendering make it easier, because the performance is easier to predict and measure: it's more linear.
It seems to me that performance prediction for hardware rendering is a great deal more complicated because you can have interdependencies and big cases of "fringe" effects when you start exceeding the hardware capabilities. (which are also multi dimensional rather than say, the easy "number of cycles" available per frame that can serve as a mental model for CPU based rendering)
How can I avoid effects on the borders of the screen, like when doing blurs...? Scaling the quad?
yes
Quote:
reading a previously rendered zbuffer as a texture - yes, possible on ati in dx9 (but not on nvidia because of their shadowmap hack),
you can read depth buffers from both ati and nvidia hardware with dx9. both vendors expose FOURCC texture format codes for their raw depth buffer textures. on ati its DF16 and DF24 (DF16 supported on 9500 and up, DF24 on SM 3.0 and up) and on nVidia its RAWZ and INTZ (RAWZ for 6000 and 7000 series INTZ for 8000 series).
blackpawn : yes and no. From what I remember this will work on those cards only if you don't use multisampling.
If you do, it won't work on many ATI cards and some NV series I don't remember (might be 6xxx).
If you do, it won't work on many ATI cards and some NV series I don't remember (might be 6xxx).
Quote:
From what I remember this will work on those cards only if you don't use multisampling.
You can't access a multisampled depth target even in Direct3D 10, although you can in 10.1
QUICK HELP ME! I'VE STARTED A 4KB FOR NVISION AND I NEED YOUR HELP!
Just kidding.
In GLSL/OpenGL When rendering to a floating point framebuffer do the values get clamped to 0..1? For instance when rendering using a deferred shading technique do I have to scale the values (world space coordinates) so that they don't get clamped and rescale them when I reuse them? Using that example it makes sense that the values don't get clampled, but you never know those things.
I could try to see what happens but someone here must know the answer.
Just kidding.
In GLSL/OpenGL When rendering to a floating point framebuffer do the values get clamped to 0..1? For instance when rendering using a deferred shading technique do I have to scale the values (world space coordinates) so that they don't get clamped and rescale them when I reuse them? Using that example it makes sense that the values don't get clampled, but you never know those things.
I could try to see what happens but someone here must know the answer.