Dawn FP16/FX12 VS FP32 performance - numbers inside
- Thread starter Arun
- Start date
Uttar said:
Ok, I'm being a little dense here I suppose, but isn't each FP16 pixel made up of a RGBA value with each channel a 16bit floating point value?
Or are you saying that each FP16 pixel is created from 4 values that together make a complete 16 bit floating point value? Essentially 4xFP4? Doesn't make sense to me.
If this is the former, then this is exactly what OpenEXR is. Which makes sense seeing as OpenEXR was designed to take advantage of NV's FP16 mode.
The way it is rendered to the frame buffer is irrelevant, I was talking about the calculated pixel format.
MDolenc said:
Psst, they are!
Although they aren't only in one post, but in multiple ones around the thread.http://www.nvnews.net/vbulletin/showthread.php?s=&threadid=12365&perpage=25&pagenumber=1
Uttar
You're right, it doesn't make sense. FX12, FP16, FP32 are respective computing formats that are the respective accuracies of the intermediate storage between computing steps. The numbers represent the number of bits per color channel.cellarboy said:
Storage formats are different and, I believe, include an 8-bit framebuffer, a 16-bit floating point buffer for intermediate rendering, and a 32-bit floating point buffer also for intermediate rendering (that can be used as a packed format, where data can be stored in any combination of 8-bit int, 16-bit float, and 32-bit float data, up to a max of 128 bits per pixel).
Side note: One thing to take away from this is that the way the FX architecture is designed, the output is always 8-bit integer. This means that depending on the intermediate calculations, using 16-bit and 32-bit floating point formats may or may not provide any benefit (from looking at the Dawn shaders, most shaders require at least one or two FP ops).
dominikbehr
Newcomer
openexr is a image file format that uses FP16 pixel format.
you can load images as textures to graphic card in FP16 using ati texture float or nv half float extensions. then you can process textures with shaders. and render them to FP16 render targets using ati pixel format float or nv float buffer extensions then save to openexr again.
you can load images as textures to graphic card in FP16 using ati texture float or nv half float extensions. then you can process textures with shaders. and render them to FP16 render targets using ati pixel format float or nv float buffer extensions then save to openexr again.
Luminescent
Veteran
What are the results of forced fp16 @ 1024x768 on the 5800 ultra? If the 5900 ultra scores ~27 fps and the 5800 ultra scores ~30 fps with the completely mixed format, then it can almost be confirmed that the 5900 has more raw fp performance, especially clock for clock, than the 5800 ultra; this, or the performance figures reflect NV35's higher bandwith (even though the demo seems to be more computationally bound).
What percentage of the original ultra demo instructions were explicitly FX12, FP16, etc.?
All this info seems to lend credibility to this conclusion over here, which we came to in a Beyond3D thread.
What percentage of the original ultra demo instructions were explicitly FX12, FP16, etc.?
All this info seems to lend credibility to this conclusion over here, which we came to in a Beyond3D thread.
Luminescent
Veteran
Do you guys believe that these scores are the result of Nvidia drivers forcing fp16 for the 5900 ultra, along with other instruction optimizations? I belive the Futuremark pixel shader 2.0 test defaults to the highest precision available, so defaulting to to fp16 would seem to help scores a lot. If the dawn demo saw fp32 at 2/3 the performance of fp16 (and the dawn demo originally specified fp32 for some objects), the futuremark shader, which specifies the highest precision for every instruction, should yield an even greater performance delta between fp16 and fp32. As opposed to the dawn situation, futuremark would benefit from increased register usage performance (in the move from fp32 to fp16, if this is the case) accross the board (rather than on a select number of instructions).
The perormance delta between the pixel shader results in versions 320 and 330, of futuremark, ranges between 50% and 53%, where 330 is less than version 320. In dawn, forced fp32 is about 46% percent slower than fp16. The numbers seem to fit.
Being that the NV3x pays a large penalty for register usage (about 50% more latency for using more than 2 registers in fp32 mode), if Nvidia forced fp16 and got these results (33.1 fps vs. 14.5 @ 1024x768), it kind of confirms the fact that NV35 has 12 fp shader units (at least more than the R350).
The perormance delta between the pixel shader results in versions 320 and 330, of futuremark, ranges between 50% and 53%, where 330 is less than version 320. In dawn, forced fp32 is about 46% percent slower than fp16. The numbers seem to fit.
Being that the NV3x pays a large penalty for register usage (about 50% more latency for using more than 2 registers in fp32 mode), if Nvidia forced fp16 and got these results (33.1 fps vs. 14.5 @ 1024x768), it kind of confirms the fact that NV35 has 12 fp shader units (at least more than the R350).
Well, my guess right now really is only that the "register combiners" ( if they still exist and aren't more general than that ) are now upgraded from FX12 to FP16 and that they're capable of doing 1FP32 op/clock or 2FP16 ops/clock compared to 2FX12 ops/clock.
I don't remember nVidia *anywhere* saying that they are capable of 12 FP32 ops. If there was such a claim, I'd love to have a link to it.
What I remember however is nVidia claiming:
- Tbe NV35 is a 12 operations/clock architecture ( see my leaked preliminary PR list )
- The NV35 got doubled FP performance over the NV30
Now, the first doesn't tells us that it's FP32.
And the second is, using my theory, correct for FP32.
So my guess is that nVidia kept the FP32/Tex unit 100% unchanged beside maybe a few minor optimizations, and then they upgraded the register combiners from FX12 to FP16 with the ability of doing FP32 in two clocks or maybe by uniting the two units per "pipeline" ( since I still think the NV3x *might* not have pipelines )
Uttar
I don't remember nVidia *anywhere* saying that they are capable of 12 FP32 ops. If there was such a claim, I'd love to have a link to it.
What I remember however is nVidia claiming:
- Tbe NV35 is a 12 operations/clock architecture ( see my leaked preliminary PR list )
- The NV35 got doubled FP performance over the NV30
Now, the first doesn't tells us that it's FP32.
And the second is, using my theory, correct for FP32.
So my guess is that nVidia kept the FP32/Tex unit 100% unchanged beside maybe a few minor optimizations, and then they upgraded the register combiners from FX12 to FP16 with the ability of doing FP32 in two clocks or maybe by uniting the two units per "pipeline" ( since I still think the NV3x *might* not have pipelines )
Uttar
Luminescent
Veteran
Here it is, quoted from its initial source and confirmed to me in a pm:
In the same thread, I posted this diagram of the NV35 pipeline (according to the confirmed information and thepkrl's research):
The original post also goes on to explain how the register performance impact is still very much present in NV35.
In the same thread, I posted this diagram of the NV35 pipeline (according to the confirmed information and thepkrl's research):
and compared it with one of NV30's supposed pipelines:
Luminescent
Veteran
Read my previous post for a quote which in reference to official information.
Okay, alright then...
But something ain't quite normal here!
All *modified* shader programs are using four FP16 registers ( or sometimes less! )
According to theckprl's results, the difference between 2FP32 registers ( = 4FP16 registers ) and 4FP32 registers is *minimal*, and 4FP32 registers was thus agreed to be the "sweetspot"
I'm sorry, but that's just ridiculous. Either the NV35 got a ten times more problematic register usage problem, or the NV35 isn't as fast, operation wise, doing FP32.
Uttar
EDIT, reply to Luminescent PM ( makes no sense to keep this private ) :
Okay, alright then...
But something ain't quite normal here!
All *modified* shader programs are using four FP16 registers ( or sometimes less! )
According to theckprl's results, the difference between 2FP32 registers ( = 4FP16 registers ) and 4FP32 registers is *minimal*, and 4FP32 registers was thus agreed to be the "sweetspot"
I'm sorry, but that's just ridiculous. Either the NV35 got a ten times more problematic register usage problem, or the NV35 isn't as fast, operation wise, doing FP32.
Uttar
But something ain't quite normal here!
All *modified* shader programs are using four FP16 registers ( or sometimes less! )
According to theckprl's results, the difference between 2FP32 registers ( = 4FP16 registers ) and 4FP32 registers is *minimal*, and 4FP32 registers was thus agreed to be the "sweetspot"
I'm sorry, but that's just ridiculous. Either the NV35 got a ten times more problematic register usage problem, or the NV35 isn't as fast, operation wise, doing FP32.
Uttar
EDIT, reply to Luminescent PM ( makes no sense to keep this private ) :
Okay, alright then...
But something ain't quite normal here!
All *modified* shader programs are using four FP16 registers ( or sometimes less! )
According to theckprl's results, the difference between 2FP32 registers ( = 4FP16 registers ) and 4FP32 registers is *minimal*, and 4FP32 registers was thus agreed to be the "sweetspot"
I'm sorry, but that's just ridiculous. Either the NV35 got a ten times more problematic register usage problem, or the NV35 isn't as fast, operation wise, doing FP32.
Uttar
Damn, I must be tried those days!
There's a ridiculously easy way to test if the problem for the NV32 is *only* register usage: use FP32 registers with FP16 instructions! AFAIK, the compiler does not optimize that
Can't do it now ( in Linux, don't have the files on this PC ) , but I'll try to have it available later today.
Uttar
There's a ridiculously easy way to test if the problem for the NV32 is *only* register usage: use FP32 registers with FP16 instructions! AFAIK, the compiler does not optimize that
Can't do it now ( in Linux, don't have the files on this PC ) , but I'll try to have it available later today.
Uttar
Luminescent
Veteran
Actually, more than 2 registers in fp32 mode causes operations to execute at a 1.45 op per clock cycle (per pipeline) performance rate - a substantial latency impact (50%) in comparison to the 1 op per clock cycle (per pipline) performance of one or two registers. Under such register conditions (4 or 3 v.s 2 or 1), NV35 at fp32 should run at 2/3 the speed if operating at fp16 (1.45 ops per clock vs. 1). This performance delta is exactly the one observable in the Dawn demo.
I'll quote myself to demonstrate how I derived these performance figures:
I'll quote myself to demonstrate how I derived these performance figures:
♪Anode
Newcomer
3dcgi said:
IMO supporting full FP32 would be the way to go in the future. FP 24 is mostly a stop gap thing which ATI did so as to reclaim their performance crown which worked for them at this point of time. But I dont doubt for a second that they would be going FP32 for the future cards. If they dont then they would lose out.
This is sort of similar to the 16bit vs 32 bit stuff. The first line of cards ( TNT) was a bit slow to do 32 bit everywhere but it got the attention on 32 bit and showed the advantages of using 32 bit. The later generations improved on that and we now have 32 bit everywhere.
Doing fp16 at full speed and fp32 at half is as good a choice as ati doing 24 bits if not better. It may not seem so at now but it will pay off as time goes on.
