I’m using shadow maps in the fragment programs and it looks worse than having them done automatically on nVidia hardware which filters the comparison results.
How can I get the surrounding texels in my fragment program so I can filter the result to make it match nvidia’s quality?
Titan,
Are you seeing bad filtering on NVIDIA hardware with fragment programs?
As it turns out, ARB_fragment_program states:
Interactions with ARB_shadow
The texture comparison introduced by ARB_shadow can be expressed in
terms of a fragment program, and in fact use the same internal
resources on some implementations. Therefore, if fragment program
mode is enabled, the GL behaves as if TEXTURE_COMPARE_MODE_ARB is
NONE.
Which essentially states that shadow mapping (including any filtering) must be performed directly by the fragment program.
Frankly, NVIDIA somehow missed this clause during the working-group meetings. When we did finally see it (after the extension’s ARB approval), we tried to get the clause removed, but to no avail. We still honor ARB_shadow functionality and filtering when using fragment programs, because it’s vastly more efficient than forcing the programmer to implmement the same functionality inside the fragment program.
Thanks -
Cass
Originally posted by cass:
Are you seeing bad filtering on NVIDIA hardware with fragment programs?
Actually I’m seeing no filtering. But this is because I am directly computing the comparison result.
I’m not sure the way to read the results of the surrounding texels. I want to add ± 1/512 to the s,t position I am reading from and sample the texture in those four locations (if I am using a 512x512 shadow map) in order to emulate the standard nice filtering nVidia has when normally using shadow maps. Even if nVidia works around this I need to add something like this for ATI, S3, XGI, 3Dlabs, Matrox, Intel, MESA, and any other companies that may decide to support fragment programs and shadows.
We still honor ARB_shadow functionality and filtering when using fragment programs, because it’s vastly more efficient than forcing the programmer to implmement the same functionality inside the fragment program.
I haven’t tried this. I just read the OpenGL standard and didn’t realize nVidia has an intentional “bug” to do what I want. This is both good news and bad news. Good because this is vastly more effcient than having me do it in the fragment program 
But bad because I’m not sure if I should write code that depends on behavoir that is by most accounts a bug. It seems that at any day this “bug” could be fixed to work correctly and then it would be my fault my application doesn’t work.
I really wish you guys had been able to get the specification to work your way! I don’t suppose there is an extension to specify you want it to work your way in a cleaner way instead of just knowing that it exists?
This really is a huge goof up in the spec as it not only will make any use of Nvidias native PCF impossible but also that of any future hardware. Why on earth hasn’t this been changed already?
ARB_fragment_program should obviously have separate shadow tex instructions or at least just use the normal filtering settings. At elast glslang gets this right…
Originally posted by titan:
I really wish you guys had been able to get the specification to work your way! I don’t suppose there is an extension to specify you want it to work your way in a cleaner way instead of just knowing that it exists?
That may end up being the only reliable way of supporting the shadow mapping properly, but it would be a real annoyance.
I believe this wording appeared because the ARB_fragment_program spec really started life as ATI_fragment_program, and apparently there is no “fixed-function” texture support for shadow maps. It’s a perfectly legitimate restriction for a vendor extension, but it is very unfortunate for an ARB extension to carry this baggage. The same is true of the “maximum indirections” restrictions, but at least that restriction can transparently vanish on more capable hardware. The shadow issue would require an OPTION. Hopefully this issue will be resolved with ARB_fp2.
Thanks -
Cass
FWIW: I think adding the OPTION would be the right choice. It’s OK to not require it on base ARBfp1 hardware (seeing as half of the current hardware supporting the extension don’t have native support).
It might have been a little better overall if NVIDIA made the non-conformant behavior on NVIDIA hardware an NVIDIA extension until such time as the spec could be updated. As it is, the shadow map behavior is similar to the CLAMP_TO_EDGE issues that caused some titles to work on GeForce2 and nothing else… (including GeForce3)
But, whatever. It’s good that these things are known and documented, at least. That’s what really matters.
At elast glslang gets this right…
Which is probably why the ARB hasn’t gotten around to providing that functionality. ARB_fp was just a stop-gap measure on the road to glslang.
Originally posted by Korval:
Which is probably why the ARB hasn’t gotten around to providing that functionality. ARB_fp was just a stop-gap measure on the road to glslang.
I’m sure we will be reving the ARB_fp extension. There’s lots of software that already uses this path, and it will be the simplest way to get to incremental programmability improvements until GLSL is pervasive and well-supported.
Thanks -
Cass
If nVidia had based its NV_FP/NV_VP2 extensions on ARB_FP/VP interface & shader syntax, rather then on its old NV_VP1, the shadow problem would have practically not existed, regardless of what ARB_FP spec would say about it.
As a bonus, we would also have now handy ARB’s syntax everywhere (after using ARB_VP on GF3, going to NV_FP/NV_VP2 on GF FX felt like a downgrade) and less work with implementing GPU specific techniques… (Yes, i’m aware i can use ARB interface to load NV text)
If nVidia had based its NV_FP/NV_VP2 extensions on ARB_FP/VP interface & shader syntax, rather then on its old NV_VP1, the shadow problem would have practically not existed, regardless of what ARB_FP spec would say about it.
??? I don’t see how.
NV_fp was written before the existence of ARB_fp. NV_vp existed for a long time before ARB_vp.
Now that there are ARB extensions for this functionality, of course we’ll be implementing those. We will still have vendor extensions, but they will generally layer atop the ARB framework (grammar, framework, etc).
Thanks -
Cass
??? I don’t see how.
Let’s assume the OPTION you proposed is in shape similar to NV_VP_1_1. Consider this:
What’s the difference between B and C solutions ? For me, none significiant.
NV_FP allows shadow tests, so if you had designed it to be backward compatible with ARB_FP on syntax level, we would now be automatically in situation equivalent to what you could achieve with the OPTION (+ the bonus, of course)
NV_fp was written before the existence of ARB_fp. NV_vp existed for a long time before ARB_vp.
But NV_FP/VP2 were after ARB_VP, and as I imagine, you guys knew better then anyone else there would be similar movement in fragment pipeline area.
[This message has been edited by MZ (edited 10-15-2003).]
But NV_FP/VP2 were after ARB_VP, and as I imagine, you guys knew better then anyone else there would be similar movement in fragment pipeline area.
They were published after ARB_vp, but they were spec’d and implemented well before and usable (and being used) via NV30Emulate.
No hidden agenda here, no bad planning. That’s just the way things happened. Like I said, the focus of future ASM-level extensions will be the ARB grammar/syntax and framework.
Thanks -
Cass