DF24 and X1800

I was reading trough the X1x00 Programming Guide and i noted that the DF24 texture format is only available on Radeon X1600 and Radeon X1300, and not on the X1800.

Therefore it doesn't even support the new Fetch-4 feature, which permits to accelerate PCF implementations retrieving 4 neighboring texels from a single-channel texture map (not only depth textures) at once.

How come this decision?
 
Off topic but does it state in the guide whether the X1000 series offer hardware support for DST? If so, what formats?
 
Neeyik said:
Off topic but does it state in the guide whether the X1000 series offer hardware support for DST? If so, what formats?
r300/r4x0/x1800 16bit dst

x1300/x1600 16/24bit dst with fetch4

I assume r580 will then support 24bit dst with fetch4
 
Last edited:
tEd said:
r300/r4x0/x1800 16bit dst

x1300/x1600 16/24bit dst with fetch4
Well, that's...odd. Remember when Futuremark were stating that hardware DST and PCF was supported by more than one IHV? I presume that they were referring to the X1300/1600 (I assume so simply because I can't think of another IHV that offers hardware PCF support); that aside, I wonder why ATI aren't offering it for the X1800?
 
S3 were the vendor they were talking about at the time, for hardware PCF. But yeah, why does R520 not support 24-bit depth textures and why no PCF sampling either?
 
Neeyik said:
Well, that's...odd. Remember when Futuremark were stating that hardware DST and PCF was supported by more than one IHV? I presume that they were referring to the X1300/1600 (I assume so simply because I can't think of another IHV that offers hardware PCF support); that aside, I wonder why ATI aren't offering it for the X1800?
futuremark was referring to s3's deltachrome which supports dst/pcf
 
Last edited:
Oooh, now I see. I should really read more often! Any guesses as to why the DST support isn't there for the X1800? Surely it can't be an issue with the memory system?
 
Fetch4 should accelerate not only PCF, but also some other softening and anti-aliasing. It's unfortunate the R520 doesn't have it.

I wonder though, will devs need to code separate paths, or will fetch4 be handled for them?

(edit)
I can think of two explanations:
1 - Support is there in R520, but not working correctly
2 - The decision to add this stuff came too late to integrate into the R520 design (presumably the R520 was designed first)
 
Last edited by a moderator:
I asked Eric about this a little after tEd first mentioned it:

Dave Baumann said:
WRT DST, what does the D16 and D24 formats buy you? Presumably these are just handy formats for depth textures?

You mentioned that there are some things to improve DST performance – I see someone has mentioned a feature called “fetch4â€￾, which I assume is related – can you elaborate on that at all? (I know that SGI has patented the DST mechanism for texture sampling, I’m now wondering if you have a special texture / shader instruction that can perform the same action, but with different functionality).

sireric said:
We expose them as 4CC, since we don’t have PCF, which is what NV does with Z surfaces. But, DST surfaces are useful.

Nope, can’t elaborate. All in due time.

I'm sure you've already noticed that Eric isn't one for being coy about whats going on, but in this case he's specifically not being drawn on it.
 
Ati will have a presentation about shadow maps implementation on developer day. I'm sure you will hear more about their dst format and fetch4 there.
 
We expose them as 4CC, since we don’t have PCF, which is what NV does with Z surfaces. But, DST surfaces are useful.
Why another way to use DST? Why not make current software able to use it, without PCF? Or do they use the filtering mode to enable fetch4, so that would interfere with enabling PCF through the filtering mode?
 
Xmas said:
Why another way to use DST? Why not make current software able to use it, without PCF? Or do they use the filtering mode to enable fetch4, so that would interfere with enabling PCF through the filtering mode?

Without PCF you will get a deep value but current software expected a percent value. If the driver does not patch the shader it can not work.

You enable Fetch4 with a magic number set as LOD Bias.
 
In other words yet another case of something *obvious* that should have been done.. hell even S3 is doing it.. yet ATi inexplicably chose not to on their top of the line GPU.

Then of course we will now have to deal with a bunch of BS PR about how "its not needed now" "you can just do it this other obscure way and get almost the same results" "um i chose not to answer the question of why Nvidia does it and it makes their stuff better and faster but its still a waste of time today"..

ATi gets a pass on not supporting expected functions/features way to much. They need to take a hit at some point so they will stop doing this kind of crap.
 
Last edited by a moderator:
Hellbinder said:
ATi gets a pass on not supporting expected functions/features way to much. They need to take a hit at some point so they will stop doing this kind of crap.

Hellbinder everybody does that maybe to a different extend but still does it.
Like nVidia not suppporting 32 bit compressed textures for generations.
Or matrox not supporting VS 2.0 even if the parhelia chip supported it.
The list can be endless.

I think that ati choice is more about politics\patents then actual implementation.

Back on topic: I didn't really got Dave answer. Ati didn't actually stated yet why they don't support it on x1800, and Eric said that he cannot comment on it?
 
NocturnDragon said:
I was reading trough the X1x00 Programming Guide and i noted that the DF24 texture format is only available on Radeon X1600 and Radeon X1300, and not on the X1800.

Therefore it doesn't even support the new Fetch-4 feature, which permits to accelerate PCF implementations retrieving 4 neighboring texels from a single-channel texture map (not only depth textures) at once.

How come this decision?

I spoke with Callan briefly about it. The X1600 was designed a little bit later and they were able to added that Fetch4 into it. I didn't know it was available in X1300 also though.
 
AFAIK the method implemented by NVIDIA is patented by SGI, but a deal with SGI many years back give access to the technology (exactly how S3 are doing it I don't know - perhaps a "blind eye" approach). What NVIDIA does with D24 textures is non-standard in DX but has become commonplace because it was frequently utilised by the XBOX and did still work in DX even though the behaviour is not specified.
 
Hellbinder said:
In other words yet another case of something *obvious* that should have been done.. hell even S3 is doing it.. yet ATi inexplicably chose not to on their top of the line GPU.

Then of course we will now have to deal with a bunch of BS PR about how "its not needed now" "you can just do it this other obscure way and get almost the same results" "um i chose not to answer the question of why Nvidia does it and it makes their stuff better and faster but its still a waste of time today"..

ATi gets a pass on not supporting expected functions/features way to much. They need to take a hit at some point so they will stop doing this kind of crap.

Fetch4 is superior to PCF. It's a programmable solution vs a fixed function solution. Yes, the interface is different, so there's no direct backward compatibility, but Fetch4 can do everything nVidia's PCF filter can do, and more.
 
Demirug said:
Without PCF you will get a deep value but current software expected a percent value. If the driver does not patch the shader it can not work.
You're referring to the depth comparison, not PCF. You can have the depth compare without PCF.

Humus said:
Fetch4 is superior to PCF. It's a programmable solution vs a fixed function solution. Yes, the interface is different, so there's no direct backward compatibility, but Fetch4 can do everything nVidia's PCF filter can do, and more.
It's not superior, it's different. Yes, it might enable you to do something else with less cycles. But just like you can "emulate" PCF in a pixel shader, you can do fetch4 in a pixel shader. It's a performance enhancement like PCF is.

And if PCF is exactly what you want, there is nothing superior to PCF support in hardware.
 
So what exactly does this "fetch4" thing do again?

I gather it gets four texture samples from a single-channel texture, right? From where? Just the plain neighbours in the texture map (which level, which neighbours?), or are these proper filtered samples with "more widely" interpolated texcoords?
 
Back
Top