Has FP24 been a limitation yet?

[Ostsol]

I thought we agreed FP24 was a strange (though valid) number where _PP is concerned, but, hey thats the precision ATi has chosen for their chips - what do you want me to do about it?

I think Dave was saying that there's no point to using FP24 as partial precision with FP32 as full precision. It would offer nothing in terms of performance benefits (which is dependant on the architecture, anyway).

 

[Dave Baumann]

I was going to answer, but realised the futility of such an action.

 

[andypski]

I was going to answer, but realised the futility of such an action.

Good call. I went through the same process.

 

[IgnorancePersonified]

You will feel a burden lift...

 

[KimB]

I thought we agreed FP24 was a strange (though valid) number where _PP is concerned, but, hey thats the precision ATi has chosen for their chips - what do you want me to do about it?

Sure, but it makes no sense. You couldn't save register space with such a system, and any extra processing units would be large enough that you might as well just make them FP32 anyway.

 

[Pete]

I know somebody will attack this post with nVidia playing up FP32, I'd encourage people to remember back to pre NV30 launch and a .pdf (can't remember the exact one, but I think there is a link to it in the nvnews archives) that features a boot rendered as FP16 and FP32. Even back then nVidia reccomended FP16 over FP32 for everyday rendering.

What's there to attack? You contradicted yourself in two sentences. First you tell us to remember the nV boot rendering, that showed precision errors (strikingly similar to what the 5800 displayed in 3DM03's PS test after nV supplied "better" drivers). Then you say that they recommended FP16 over FP32--oddly enough in a thread about sufficient precision--despite the fact that FP16 could show errors.

If you are going to bring up the issue of art assets as a defense, then you first need to explain why ATi's Doom3 shader replacement doesn't degrade image quality and why the HL2 DX8 water shaders look so much better.

ATI doesn't replace one shader with another in Doom 3, AFAIK. It replaces a texture op with a shader op. And HL2 DX8 water reflections look better than what, the default non-reflection (IOW, better than nothing)? :?

 

[KimB]

Then you say that they recommended FP16 over FP32--oddly enough in a thread about sufficient precision--despite the fact that FP16 could show errors.

If it shows errors, then FP32 can be used. Really, the first place that any shaders are going to show precision issues are in dependent texture reads. Put simply, if you use an FP16 value for a texture read, there just won't be enough precision to address most texture sizes used today. So, it would be relatively easy to make a macro that would examine the HLSL shader files, and add _pp hints on every instruction that has a result that doesn't later lead to a texture read.

Anyway, it just makes sense to use FP16 whenever possible for the NV3x or NV4x architectures. They're faster with FP16 (the NV4x less so).

ATI doesn't replace one shader with another in Doom 3, AFAIK. It replaces a texture op with a shader op.

Huh? That is shader replacement.

 

[Pete]

I'm not arguing against _pp, just pointing out the apparent illogic of radar's example. You don't argue for _pp with an example that shows its limitation. I don't think nV was arguing the merits of FP16 with that boot example. (That's not to say that FP16 isn't sufficient in most current cases.)

As for the D3 swap, is it (in the usual sense of simply differing precisions)? I suppose technically both are reading from memory based on a calculation, but the nV "shader" looks for a precomputed value (the texture), no? It's seems slightly different from the "shader replacement" accusations bandied about WRT 3DM03 and Far Cry.

Apologies for the totally clueless (and perhaps illogical) Q, but for the default D3/nV lighting algo, do we say the precision is that of the calculation used to determine what part of the texture to access, that of the texture itself, or that of the "TMU"?

 

[Reverend]

I feel no enthusiasm to re-visit this "debate" with sireric. Some things of note however :

Sarcasm noted. Amusing. End of thread for me.

Hey, I was serious!!

C'mon, lighten up Eric... everyone knows I'm an arrogant SOB.

For applications that do a lot of procedural operations, such as some of the CPU/VPU items (fluid dynamics, linear algebra solutions, etc...) that I've seen, 32b seems required to be useful (in fact, in some cases it's not enough). However, there aren't enough commercial apps in this category to justify this for the mainstream commercial market (might be a chicken-egg thing though).

And there it is (the chicken and the egg, that is).

My comments only appear to be conclusive because that's the way I view things. I might (and often) am wrong, but that doesn't mean I don't believe my own opinions. I speak only for myself.

And that's the case usually for everyone here. Includingly a certain arrogant SOB.

Look Eric, your points that there are more important things to tackle than demanding 32b is absolutely true. But this should mean either a re-naming of this thread's title or we should start another thread called "The Higher Priorities". Instead of talking only about how many floating point bits may be a limit in games, like this thread author wanted to discuss.

 

[nelg]

Look Eric, your points that there are more important things to tackle than demanding 32b is absolutely true. But this should mean either a re-naming of this thread's title or we should start another thread called "The Higher Priorities". Instead of talking only about how many floating point bits may be a limit in games, like this thread author wanted to discuss.

Sometimes I think you are trying to re-frame the debate here to state the obvious. Of course FP32 > FP24. The intent of the thread is to see if FP24 was in fact a real (i.e.. real world) limitation or, in conjunction with the absence of the other considerations sireric mentioned, is the argument academic? Reverend, are you suggesting that, with all else being equal and if ATI supported FP32, games may appear different than they do today (referring to DX9 games)?

 

[Reverend]

Reverend, are you suggesting that, with all else being equal and if ATI supported FP32, games may appear different than they do today (referring to DX9 games)?

That's a loaded question and one I do not want to dare risk answering (because I'm not in the business of selling games). Who knows what the ATI folks posting here would've responded if the R300 had reasonable FP32 performance...

I think we have to look at a wider picture (that some probably hadn't thought of) -- that of the business of making games. Games such as space-constrained first-person-shooters (perfect latest example is Doom3) atm gain very little from FP32. This is not due to lack of 3D knowledge from such game programmers but from probably a collective lack of creativity from a single development house. The trend appears to be that gamers want bigger "worlds" to play/explore, and this applies to first-person-shooters as well. Bigger worlds has much bigger demands. Higher precision counts, as an example of such demands. Creating a game engine that works well in small and large worlds, with the thought of licensing business, should be the smart move -- the costs and complexity would be too high for a programmer to make a game engine that only applies to small worlds. If it isn't obvious, what I'm saying is that one of the things where higher precision is a big deal is a game set in a large world, which IMO is the way gamers like their games to be.

What does the majority of the folks here know about the importance of "floating point" itself?

PS. I've just had some beer, so excuse me if I appear to be going OT.

 

[dksuiko]

If FP24 is not yet the bottleneck in majority of the cases, then why spend the extra resources on attaining FP32? It sounds to me like the situation is similar to choosing the amount of RAM when building a gaming system. Which would be better: 1GB RAM or 2GB RAM? Obviously, having 2GB RAM would be better, but if it's benefits can not be realized - as RAM will hardly be the bottleneck, then you are better off focusing your resources on other aspects of the system that are the bottleneck. Of course, that is all assuming FP24 (and 1GB RAM) has not yet become a bottleneck in gaming and brings us back to the start of this thread:

"Has FP24 (in the PS) been proven to be a limitation yet?

 

[Ostsol]

If FP24 is not yet the bottleneck in majority of the cases, then why spend the extra resources on attaining FP32?

API requirements.

 

[dksuiko]

The trend appears to be that gamers want bigger "worlds" to play/explore, and this applies to first-person-shooters as well. Bigger worlds has much bigger demands. Higher precision counts, as an example of such demands.

This is the crux of the whole entire thread, I think. In what way does higher precision count and are there any examples of it being a limitation yet? Or to take your example into question, what games or situations do you know of that have been effectively limited by FP24 in that they had to make their world smaller? Any examples? And if FP24 is the bottleneck there, are there not any other more important limitations that need to be addressed before addressing FP24?

 

[arjan de lumens]

If you need to place vertices in your world accurate down to an error of +/-1cm, FP24 allows a world that is about 5 kilometers wide (assuming a coordinate system origin at the center of the world), but why you need full-world coordinates in a pixel shader is a bit unclear to me. FP32, with similar precision requirements, allows a world that is about 670 kilometers wide, which AFAICS is overkill for anything else than perhaps flight simulators.

 

[Dave Baumann]

"Bigger worlds" can also fall into Eric's "other constriants" pot - for "bigger worlds" you'll probably want the system to have 64-bit addressing capabilities.

 

[olivier]

correct me if i am wrong but in this case (vertice) doenst ati use 32fp ?

 

[nelg]

Here is the only example that I know of that shows the difference in IQ between FP24 and FP32. LINK . At the bottom of the page.

BTW Reverend what ever happend to your PS research ?

There should be more, as I've already discovered them in my PS research so far, but I'll prefer to present them in an official B3D article in the future, if I can find the time to complete my research and write it all down.

 

[Ostsol]

Larger worlds by itself is a non-issue. If a map is segmented reasonably, there are some relatively easy tricks to get around this. How else do you think Morrowind and Dungeon Siege managed? Even FP32 is not enough. The only issue is for a large visible world -- the amount of the world one can see in a given frame. Really, the only games that have such a massive viewable area are space-sims (the Independence War series, for example).

 

[OpenGL guy]

I think we have to look at a wider picture (that some probably hadn't thought of) -- that of the business of making games. Games such as space-constrained first-person-shooters (perfect latest example is Doom3) atm gain very little from FP32. This is not due to lack of 3D knowledge from such game programmers but from probably a collective lack of creativity from a single development house. The trend appears to be that gamers want bigger "worlds" to play/explore, and this applies to first-person-shooters as well. Bigger worlds has much bigger demands. Higher precision counts, as an example of such demands.

What does any of this have to do with FP24 vs. FP32 in the pixel shader? All R3xx/R4xx products use FP32 in the vertex shader and it's vertices that define a large world, right? Please explain how FP24 pixel shaders somehow limit your "bigger world".