Has FP24 been a limitation yet?

Ninja Theory (previously known as Just Add Monsters) and the game is Heavenly Sword.
 
DeanoC said:
As the majority of the cards we are targeting (ATI R3x0, R4x0 and NV40) generally don't need this work, having to do it just for NV3x is a pain
Isn't NV4x benefit from this also?
 
arjan de lumens said:
The problem solved by mip-mapping (aliasing/popping/sparkling because features in the texture map become smaller than 1 pixel; mip-mapping is a somewhat crude way of simulating the process of taking multiple samples per pixel) is not the same problem that FP32 would solve.

Yes, I know that. But you store multiple sizes, to be able to use the one that fits the need. That is analogous to the bit depth: you use the one that looks good enough and uses as little space as possible. You might WANT to use the largest textures you can to cover everything, but it is not feasible, unless you think four textures are enough for everything...
 
Chalnoth said:
DiGuru said:
If we talk about precision, why use MIP-maps and detail textures? Why not store all textures in FP 32? And why 32 bits? Just because it seems large enough, it is an easy multiple of 8 and most CPUs use them? In that case, you could make a very convincing case for 80 bits. And why not 100 bits then, just to make sure? And require four such values to be computed at the same time, to ease the use of calculating vectors and color values...
For storage, you want to store objects in power of 2 sizes to make the memory controllers simpler.

That depends. You might want to use a size that has little spill-over for the cache-filling bursts. It might be optimal to use 21 bit color values, 7 bits per color, to be able to use the bandwith to it's full potential in many scenario's. I don't know. As long as the total burst size transfers the data you need and fits a multiple of the bus width, it can be more optimal than an even amount of bytes/words/longs.

Btw. How would you do a 32/48/64/80 bit computation on a R300? I think it probably isn't that hard, so if you need it for some special cases, you might want to use macros that do multi-word calculations.
 
DiGuru said:
Btw. How would you do a 32/48/64/80 bit computation on a R300? I think it probably isn't that hard, so if you need it for some special cases, you might want to use macros that do multi-word calculations.
I don't think current architectures support the bitwise operations you'd need to perform higher-precision operations than officially-supported. You could do some packing to get somewhat better precision, but you won't get FP64 with two FP32 registers.
 
DeanoC said:
I think the problem that often missed in this discussion is that in games we don't really work on 'a' shader but lots. I don't actually know how many pixel shaders we have but I know that total shaders (vertex and pixel) is over 6000.

Any sense how many person-hours (or person-days, if that is easier) were/will be required to do the analysis of which shaders need to be switched to partial-precision and the actual coding to do so for your game?
 
geo said:
Any sense how many person-hours (or person-days, if that is easier) were/will be required to do the analysis of which shaders need to be switched to partial-precision and the actual coding to do so for your game?
Good idea. Then they could calculate how large of a bill to send to nV. :LOL:
 
Back
Top