I have a Radeon

DaveBaumann said:
It may be valid, its just not defined by DX documentation - as far as we've discussed with one developer, the what's applied to a D24S8 in these circumstances is very different from other hardware, and not documentmented within directx.

DirectX doesn't document applications of technology at all. DirectX also doesn't say anything about stencilshadows for example.
It strictly describes hardware features, not how you may or may not use them.
So if I choose to use R32F as a shadowbuffer and perform bilinear PCF on it in a pixelshader, that is perfectly valid DirectX code.

And here's something to think about... If MS wanted everyone to work completely inside the spec, why would they have offered the opportunity to expose extra texture formats through the DirectX interface?
 
london-boy said:
HEY! THIS IS THE GENERAL FORUM, IT'S ONLY MEANT FOR ME AND MY GAY JOKES, IF YOU WANT TO BITCH ABOUT ATI AND NVIDIA AND WHATEVER ELSE, YOU HAVE 829 OTHER FORUMS ON THIS VERY SITE!!!!!!!!

Yea, some idiot moved my thread here!!! :)
 
Scali said:
So if I choose to use R32F as a shadowbuffer and perform bilinear PCF on it in a pixelshader, that is perfectly valid DirectX code.

DirectX documents the behaviour of what to expect for certian operations / functions. In this instance, when you filter a D24S8 texture you are getting different behaviour to anything that DirectX specifies.
 
DaveBaumann said:
DirectX documents the behaviour of what to expect for certian operations / functions. In this instance, when you filter a D24S8 texture you are getting different behaviour to anything that DirectX specifies.

I'm not talking about that. I'm talking about implementing the same filter via a standard R32F format and some pixelshader instructions.
Then I get the exact same results as NVIDIA, and it's completely within DirectX specifications.
You seem to imply that this is somehow not valid to do, and that the DirectX specification has something to do with that:
the non-DST path is the way to do shadows according to the specifcations of DirectX.
 
Could anyone point me to this "DirectX spec" everyone is talking about? Last time I checked, there existed no spec (in the sense of the OpenGL specification), just SDK docs and MSDN docs, but that was some time ago. Besides, why would D3D not specify depth textures, they've been in OpenGL forever, and are (Shock! Horror!) sort of supported by ATI. Granted, they do not do filtering and they managed to botch the entire ARB_fragment_program spec with regards to depth texture/shadow map interaction just because their hardware didn't have dedicated hardware for it, but it's all solved in glsl.

Anyway, implementing lerped-PCF if it's available in hw is a no-brainer, you get slightly better quality for the SAME COST for chrissakes. It won't help with very bad shadow aliasing, but then single sample without lerped-PCF will look horrible in that situation as well, so you haven't really lost anything. The only thing that would be sort of bad would be if you couldn't compare lerped-PCF with no PCF at all. That would be around the same cost, but only differ in quality. Or you might wan't to compare lerped-PCF in hardware with the same filtering but done in the shader, which would be same quality, different cost.

And, honestly, Scali is no fan boy. An arrogant git, yes ;) but no fanboy.
 
I own and use a Radeon 9500 Pro, a Geforce FX 5700, a DeltaChrome S8, a Geforce 3Ti200 and a Wildcat VP560. Additionally, a Matrox m3D, a Kyro II, a Voodoo 2 and a Voodoo 3-3000 PCI are gathering dust on my shelf. I owned and later sold a Riva 128, a Riva TNT, a Savage 2000, a Geforce 2MX, a Radeon DDR ("7200" nowadays) and a Radeon 8500LE.

Duh. If enumerating toys indeed gives more relevance to my opinion, I'd like to take this chance and say that Scali, you make excellent banning material, regardless of what you think you're doing here.
 
I own a Radeon 9600 pro AIW, X800 pro (flashed 16/500/540), and an engineering sample 9700 pro that has gone a bit wonky...as well as an old Rage Fury (non-Pro) that I keep around for luck.

I also own a GF4 ti4400, FX 5900 (flashed 5950 ultra), and currently have in my possesion a 6800 GT.

Oh, and I got a V3 3000 pci and a V5 5500 AGP too. :)
 
Scali said:
london-boy said:
HEY! THIS IS THE GENERAL FORUM, IT'S ONLY MEANT FOR ME AND MY GAY JOKES, IF YOU WANT TO BITCH ABOUT ATI AND NVIDIA AND WHATEVER ELSE, YOU HAVE 829 OTHER FORUMS ON THIS VERY SITE!!!!!!!!

Yea, some idiot moved my thread here!!! :)
I'm that idiot. Your first post has nothing to do with "3D Graphics Cards and Drivers" -- all you wanted to do was say you wanted folks to know you're not a fan of any particular IHV. Basically a blog. In our forum. Should I be writing my Reverend at The Pulpit threads in, say, the 3D Technology & Hardware forum? No, because they are basically my blog.
 
DaveBaumann said:
It may be valid, its just not defined by DX documentation - as far as we've discussed with one developer, the what's applied to a D24S8 in these circumstances is very different from other hardware, and not documentmented within directx.

What Dave's getting at (I believe) is that the implicit comparision in the look up used in NVIDIA usage of DST is clearly outside of the 'normal' DX usage (its not out of spec as there is no specification in this case but its clearly against the grain).

To understand why, ask your self what wrong with this (apart from it being psuedo code)?

// pixel shader code
sampler DSTTexture : register(s0);
float4 CopyStencilToColour( ... )
{
// a DST texture contains the depth in x and stencil in y
float2 ds = tex2D( DSTTexture, uv );
return ds.yyyy;
}

float4 UseDepthToLookupSomething( ... )
{
// a DST texture contains the depth in x and stencil in y
float2 ds = tex2D( DSTTexture, uv );
// depth should be a smooth [0,1] based on distance
return tex2D( LookupTable, ds.xx );
}

The answer oddly is NOTHING, they are absolutely valid and should be the behaviour of a card that claims support for D3DFMT_D24S8.

Being a complete idiot and having never heard of NVIDIA why can't I assume that a D3DFMT_D24S8 texture returns a normalised depth and normalised stencil value as a texture as is indicated by the D3DFMT_D24S8 code?

Personally I'd much rather NVIDIA have exposed DST/PCF via a FOURCC code (which is what they are for) but I assume there was/is a problem in the SetDepthStencil API that stops them doing that (possible MS check the format before they get a chance to work with it...)
 
Back
Top