Radeon 9700 floating pointing point support

[alexsok]

I'd call that marketing BS against a competitor.

Possibly, but if u R300 indeed doesn't support arbitrary swizzling and NV30 does, then nVidia must have thought it was important to mention it in the paper.

Although I'd be glad if they would have written "arbitrary swizzling" there, instead of writing simply "Swizzling", since it seems R300 does support Swizzling...

 

[hax]

Possibly, but if u R300 indeed doesn't support arbitrary swizzling and NV30 does, then nVidia must have thought it was important to mention it in the paper.

From a purely competitor standpoint, the main focus is to harp on some things and blow it out of proportion. It's up to other folks to discern what is really true. Read between the lines, and determine whether or not what is being harped on is of any importance. It's just what competitors do.

I'm sure I can dig into the NV30 and pull some stuff out and harp on that, but it really serves no purpose other than propagating marketing fluff (or FUD...however you want to term it). Whether or not what is being harped on is of any significance is what should really matter.

When you say something like it doesn't support "arbitrary" swizzling, people come off with the impression that you can't swizzle. When you say it can swizzle, but in a single instruction you can't end up with only one format, the stance is not as strong. So, you see...it's all marketing fluff.

 

[DemoCoder]

No one said it can't swizzle. Even PS1.3/1.4 allowed limited swizzling. You could construct any arbitrary swizzle using mov ops with 4 write masks.

The point was, it doesn't support arbitrary swizzle, which vertex shaders do, so it is a non-orthogonality in the instruction set. No one is saying it's a card killer, it's just a little annoying. But then again, this whole thread is about something Humus finds annoying, but maybe other devs don't.

It's not marketing BS, it's just whatever featre devs fall in love with and get excited about.

 

[hax]

It's not marketing BS, it's just whatever featre devs fall in love with and get excited about.

It's an unqualified statement that does not get expounded upon. Just how limited is the limitation, if any? Is it even important, I'd say not. But like you said, at best it is a minor annoyance, or in practice, not even an issue. While some devs may be able to discern what the limitations are, not everyone here is a dev, and it is clear who just regurgitates information.

With the fanboyism on forums, I just wanted to make certain things crystal clear before some fanboys go apesh*t over it. More than half the time that I read these boards, I have to shake my head in disbelief. I'm not one to attack/criticize a competitor's methods/products (in public any way ), I just feel clarification is in order when it comes to a clear marketing twist to a minor thing.

 

[Basic]

Ah, I think i got it.

The source for RGB destination is completely independent from the source for A dest.
Any source component can be put into A.
RGB can come from any source components, but it must be 1 or 3 distinct source components, never 2.


It wouldn't be a complete waste to have the omitted swizzles, but I guess most interesting stuff can be done with the available swizzles. (And of course, if you realy want that unavailable way, it's always possible in more cycles.)


Btw, did you give the swizzles in argb format? Isn't it supposed to be rgba? That would make it more like VS, where the fourth component is the odd one.

 

[hax]

did you give the swizzles in argb format?

Technically it is RGBA, but since it really doesn't matter (because what feeds the shader could have swizzled the data too, like texture channels have arbitrary selection), so I just typed what came to mind. ARGB is just a habit of mine, practice on older hardware from various companies beat that into me.

 

[KimB]

Interesting, the way I see it, this means that any time you want to do a swizzle that the R300 won't do natively (obviously this is an optimization in instruction size...probably to reduce the size of on-die caches mostly), it appears that you would need to do two swizzles instead of just one.

Given that this is only one extra instruction, I doubt it will have much impact on performance.

However, in comparison to the CineFX architecture, which supports far more instructions in the PS, it seems that it may be more of a problem in program length (but not a severe one, of course), though not an overly-common one. Hopefully, for the sake of the R300, ATI chose the swizzles to support that are most-used...

 

[Althornin]

Hopefully, for the sake of the R300, ATI chose the swizzles to support that are most-used...

pffft.

 

[WaltC]

You don't know whether this limitation is hardware or driver level, but in any case, it's splitting hairs. You're probably talking about this section of NVidia's OpenGL docs

Why must the NV_texture_rectangle extension be used in order to use
floating-point texture maps?

RESOLVED: On many graphics hardware platforms, texture maps are
stored using a special memory encodings designed to optimize rendering
performance. In current hardware, conventional texture maps usually
top out at 32 bits per texel. The logic required to encode and decode
128-bit texels (and frame buffer pixels) optimally is substantially
more complex.

Translated: the circuitry required is too complex, so we didn't build in this functionality.

Why do you need cube maps anyway?

GOOD question! It's the same thing I asked back in 3dfx days when nVidia introduced it... The only answer I ever got was "Because nVidia says we do." Now that nVidia's dropping support, I guess we don't, right?

NVidia's statement is that they optimized for 2D (which I would argue is the MOST useful).

Interesting that they (nVidia) didn't hesitate to introduce cube mapping as a 3D feature years ago. Ditto Fast Write support. I agree with you, though, that cubemapping was never much of a 3D feature that anyone has supported to any degree.

How slow will the R300's floating point cube lookup be compared to a few fragment ops on the NV30? Is the R300's floating point cubemap decode optimized?

It's really surprising how much this echoes 3dfx's replies of a few years ago when so-called 3D Internet journalists were all over them with questions like "How come 3dfx doesn't support cubemapping?" If I recall correctly 3dfx's objection at the time had a lot to do with the bandwidth required for "real-time" cubemapping in a 3d game and how nVidia's current cube-mapping product didn't have close what it needed to actually cube map. The Internet journalists seemed impervious to the point: all they knew was that 3dfx was minus a "feature" that nVidia had and this seemed "bad" to them... (Whether said feature worked or was actually of any value seemed entirely beside the point to them.)

Is this the start of yet another NV30 vs R300 war where someone takes their pet favorite feature and blows it up to such a large magnitude that it supposedly kills the other card?

Maybe there's something basic here I've missed, but it seems as though for weeks now all I've been hearing is that the nv30 FP pipeline is "better" than the FP support in Radeon. Well, it looks like here is a clear instance of that not being the case--apparently ATI was able to build in the complexity that nVidia wasn't, and ATI is supporting cubemapping (whether it gets used much or not--just like nVidia did.) I think it stands on its own without any need to embellish it out of proportion.

 

[KimB]

GOOD question! It's the same thing I asked back in 3dfx days when nVidia introduced it... The only answer I ever got was "Because nVidia says we do." Now that nVidia's dropping support, I guess we don't, right?

Apparently you didn't read what most of the arguments have been about.

Specifically, the NV30 is flexible enough to support cube maps in the shaders for floating-point targets. The only possible issues we may have are performance/number of instructions used, though there is no guarantee that so-called hardware support for floating-point 3D textures or cubemaps will make them any faster.

 

[fresh]

Who cares anyway? By the time any REAL DX9 game comes out, we'll have moved on to DX10 hardware. Just like I feel that with the R300 I can finally play DX8 games properly with AA+AF. In the future I'll be playing DX9-class games on a DX10 card.

Just look at the VAST QUANTITY of DX8.1 games out, and you can guesstimate how many DX9-with-128bit-fp-cubemap-lookups-coded-in-PS we'll see around this time next year. The best new thing with R300/NV30 is that you can finally play with proper AA+AF+high res. The rest is just the icing on the developers' cakes 8)

 

[KimB]

Fresh, that argument is rife with fallacy.

In particular, we won't see games that use such things until we have hardware at the lowest-common-denominator that can do such things at decent speeds.

In other words, the sooner, the better, for any hardware feature.

Still, the NV30 has enough flexibility to do pretty much anything with floating-point textures, though there may be performance concerns.

 

[Xmas]

This whole discussion seems to be based on the false premise that anyone will need floating point textures anytime soon. This whole float thing is currently just a toy for programmers. Cube maps are not supported? Well, convert your texture coordinates with a few instructions. Can't do arbitrary swizzle? Mov to a temp register and swizzle again. No texture filtering? Do your own with tex, lerp and whatever you want!
The "real" performance will depend on other things than that.

With the flexibility of these new chips, there shouldn't be much left you can ask for, data dependent branching in the fragment pipeline being the big exception. I don't see a problem in writing my own filtering function. It's a few lines of HLSL code.

 

[DemoCoder]

Why do you need cube maps anyway?

GOOD question! It's the same thing I asked back in 3dfx days when nVidia introduced it... The only answer I ever got was "Because nVidia says we do." Now that nVidia's dropping support, I guess we don't, right?

No, cube maps WERE needed when hardware was fixed function. Now that hardware is flexible enough to completely control texture coordinates and how lookup is performed, it is no longer needed as a "builtin" feature, the same way EMBM isn't needed.

NVidia's statement is that they optimized for 2D (which I would argue is the MOST useful).

Interesting that they (nVidia) didn't hesitate to introduce cube mapping as a 3D feature years ago. Ditto Fast Write support. I agree with you, though, that cubemapping was never much of a 3D feature that anyone has supported to any degree.

Cube mapping is very useful for doing things like per-pixel normalization. It was definately a needed feature, which is why most vendors implemented it and why it is in use today.

Maybe there's something basic here I've missed, but it seems as though for weeks now all I've been hearing is that the nv30 FP pipeline is "better" than the FP support in Radeon. Well, it looks like here is a clear instance of that not being the case--apparently ATI was able to build in the complexity that nVidia wasn't, and ATI is supporting cubemapping (whether it gets used much or not--just like nVidia did.) I think it stands on its own without any need to embellish it out of proportion.

Who's been saying that the NV30 pipeline is "better"? I have been non-stop arguing since the debut of the R300 that both of these cards are killers and that the intersection of their common features is awesome. I have also argued in the past that arbitrary swizzle can be emulated easily, and that the 160 instruction limitation of the R300's pixel shaders is "effectively infinite" for games. 1024 instruction pixel shaders would run far far too slow, and I think you will find that most shaders will be underneath 30 instructions.

If you read my posts from over one year ago I consistently said "both ATI and NVidia's next gen cards will go beyond DX9 features, and both of them will have enhanced features that the other doesn't have"

I'm getting annoyed at all the nitpicking going on here. To me, DirectX9 is such a monumental advancement in the state of the art that I don't really care about pixel or vertex shaders 3.0 right now. IMHO, it will take devs another 2-3 years to figure out all the tricks and stuff they can do with VS/PS2.0 and DX9 features.

Arguing over swizzling, instruction length limits, FP formats supported, etc at this point seem to be splitting hairs on gorilla who has a million of them. DX9 has so many damn new cool possibilities, lack of any one of the "beyond dx9 features" is basically irrelevent for consumers.