Having newest drivers for my Radeon 9600 Pro I still can’t run many demos doing shadow mapping.
For example with Cg Browser I constantly get “Device/Dirver doesn’t support shadow maps!”, with several other I just get info that effect can’t be initialized, but this I think due to “wrong” graphic card - not nVidia one, am I right?
I’ll add that on my extensions list there is “GL_ARB_depth_texture”, which should be enough.
Is this an ATI error?
Having the ARB_shadow and ARB_depth_texture extensions is supposed to give you shadow maps.
ATI hardware does not have direct support for shadow maps, so you have to perform the filtered lookups and R-coordinate compare explicitly in your fragment programs, unless the ARB_fragment_program_shadow extension is available (which it isn’t on ATI hardware). An inexcusable error in judgement by ATI in my opinion.
NV hardware does have direct support for shadow maps with percentage closer filtering and it gets used in fragment programs whether you’ve specified the shadow option or not.
– Eric Lengyel
I guess most nvidia shadow demos will also use the nvidia-only extension NV_render_depth_texture for rendering the depth texture.
I am confused. The following site indicates that ATI supports ARB_SHADOW and ARB_DEPTH_TEXTURE
http://www.delphi3d.net/hardware/allexts.php
Please clarify - I have been using these extensions during development and I desire my application to run on ATI as well as NVidia…
Thanks Eric! 
ATi cards do. It is probably NV_render_depth_texture that’s causing the problem.
Hi –
ATI hardware does not support the percentage-closer texture lookup necessary for a robust implementation of the ARB_shadow extension. The drivers implement the ARB_shadow extension by adding instructions to a fragment program (or the ATI_fragment_shader settings on earlier hardware) to simulate a depth texture lookup and R-coordinate compare. If you look closely at the extension documentation for ATI_fragment_shader, you’ll see a paragraph stating that ARB_shadow is ignored when fragment shaders are used, meaning that you have to take care of it yourself. In an unfortunate oversight, this paragraph survived the transition to ARB_fragment_program, and ATI drivers also ignore the depth compare mode when fragment programs are enabled, leaving it to you to do the work. If you take a filtered sample of a depth map, you get averaged depths (not what you want) instead of averaged 1s or 0s resulting from the R-coordinate compare. Thus, you have to perform multiple unfiltered lookups yourself in a fragment program, compare them against the R-coordinates, and then average them together to get the same result that a single instruction gives you on NV hardware.
The recent ARB_fragment_program_shadow extension was created to help remedy this problem by adding shadow map texture sampling targets. When ATI supports this, they will internally translate a shadow map lookup instruction into the mess that I described above.
ARB_shadow certainly does work on ATI hardware (R3xx series), at least when fragment programs aren’t in use. I wrote a test app a while back using the extension and it worked perfectly. As I implied, though: I wasn’t using fragment programs.
Will the R420 based hardware have PCF texture lookups in hardware?
Sad that ATI doesn’t support authomatic shadow texture lookup.
Especially annoying is that it’s not possible to simply “add” shadow maps effect to your scene rendered using some fragment programs.
Now, with ATI card on board you have to either change each of your fragment programs, so that shadow test is being performed in them or add separate pass for shadowing and do it with extra shadow fragment program or through standard OpenGL pipeline.
You can always use glslang on ATI hardware. It doesn’t have these issues since shadow lookups were speced correctly from the start. I don’t have time to look at the spec right now, so I don’t know how filtering is specified, maybe it’s just a hint. I n that case, you’ll get ugly aliasing on ATI hardware. But that might be a good thing, showing ATi how great shadows would look if they supported PCF 
Korval, I don’t have first hand confirmation, but considering that the R420 pixel shader untis are practically identical to the R300 bar a facing register and more instructions, I highly doubt it. I know for a fact they don’t support partial derivatives in D3D for example. They are still worse feature wise than NV30.