Question about GPUz v0.5.9 Probably been asked but...
Is the pixel fill-rate correct in the latest version? Because if so, it would show that the GTX 400/500 series has little to no extra performance, in terms of fill rates, over the 9000 series and GTX 200 lines.

For example, and using GPUz 0.5.7:

The 9800GTX has [i]16 Raster Operators[/i] and [i]64 Texture Mapping Units[/i] backed by [i]128 CUDA Cores[/i].
At the clock speeds given, 675/1688 for the core/shader respectively, it produces a [u]pixel fill-rate of 10.8 GPixels/s[/u] and a [u]texture fill-rate of 43.2 GTexels/s[/u].

My GTX 460M has [i]24 Raster Operators[/i] and [i]32 Texture Mapping Units[/i] backed by [i]192 CUDA Cores[/i].
At the clock speeds given, 675/1350 for the core/shader respectively, it produces a [u]pixel fill-rate of 16.2 GPixels/s[/u] and a [u]texture fill-rate of 21.6 GTexels/s[/u].

Yet, with the supposed "new calculation based on how Fermi's architecture works with Raster Operators now" with GPUz v0.5.8 and onward, my GTX 460M's pixel fill-rate at the same stock clocks of 675/1350 dropped down to a measly [b][i]5.4 GPixels/s[/i][/b]. At this point, it would technically be slower than even a low power 9800GT ECO Edition, which my GPU draws rather close to the 5770 after my overclocking.

So my question stands at thus:

[b]Is GPUz correct about the calculation and can someone give me some kind of an official answer here?[/b]

Over at Overclock.net, we're baffled by this and there are a few others like myself who would really like to know if this is correct. :( We liked having our lovely 40 billion pixels a second fill-rates. :(
Is the pixel fill-rate correct in the latest version? Because if so, it would show that the GTX 400/500 series has little to no extra performance, in terms of fill rates, over the 9000 series and GTX 200 lines.



For example, and using GPUz 0.5.7:



The 9800GTX has 16 Raster Operators and 64 Texture Mapping Units backed by 128 CUDA Cores.

At the clock speeds given, 675/1688 for the core/shader respectively, it produces a pixel fill-rate of 10.8 GPixels/s and a texture fill-rate of 43.2 GTexels/s.



My GTX 460M has 24 Raster Operators and 32 Texture Mapping Units backed by 192 CUDA Cores.

At the clock speeds given, 675/1350 for the core/shader respectively, it produces a pixel fill-rate of 16.2 GPixels/s and a texture fill-rate of 21.6 GTexels/s.



Yet, with the supposed "new calculation based on how Fermi's architecture works with Raster Operators now" with GPUz v0.5.8 and onward, my GTX 460M's pixel fill-rate at the same stock clocks of 675/1350 dropped down to a measly 5.4 GPixels/s. At this point, it would technically be slower than even a low power 9800GT ECO Edition, which my GPU draws rather close to the 5770 after my overclocking.



So my question stands at thus:



Is GPUz correct about the calculation and can someone give me some kind of an official answer here?



Over at Overclock.net, we're baffled by this and there are a few others like myself who would really like to know if this is correct. :( We liked having our lovely 40 billion pixels a second fill-rates. :(

#1
Posted 03/01/2012 08:15 PM   
[quote name='Imglidinhere' date='01 March 2012 - 03:15 PM' timestamp='1330632948' post='1377274']
Is the pixel fill-rate correct in the latest version? Because if so, it would show that the GTX 400/500 series has little to no extra performance, in terms of fill rates, over the 9000 series and GTX 200 lines.

For example, and using GPUz 0.5.7:

The 9800GTX has [i]16 Raster Operators[/i] and [i]64 Texture Mapping Units[/i] backed by [i]128 CUDA Cores[/i].
At the clock speeds given, 675/1688 for the core/shader respectively, it produces a [u]pixel fill-rate of 10.8 GPixels/s[/u] and a [u]texture fill-rate of 43.2 GTexels/s[/u].

My GTX 460M has [i]24 Raster Operators[/i] and [i]32 Texture Mapping Units[/i] backed by [i]192 CUDA Cores[/i].
At the clock speeds given, 675/1350 for the core/shader respectively, it produces a [u]pixel fill-rate of 16.2 GPixels/s[/u] and a [u]texture fill-rate of 21.6 GTexels/s[/u].

Yet, with the supposed "new calculation based on how Fermi's architecture works with Raster Operators now" with GPUz v0.5.8 and onward, my GTX 460M's pixel fill-rate at the same stock clocks of 675/1350 dropped down to a measly [b][i]5.4 GPixels/s[/i][/b]. At this point, it would technically be slower than even a low power 9800GT ECO Edition, which my GPU draws rather close to the 5770 after my overclocking.

So my question stands at thus:

[b]Is GPUz correct about the calculation and can someone give me some kind of an official answer here?[/b]

Over at Overclock.net, we're baffled by this and there are a few others like myself who would really like to know if this is correct. :( We liked having our lovely 40 billion pixels a second fill-rates. :(
[/quote]

Did you ask W1zzard?
[quote name='Imglidinhere' date='01 March 2012 - 03:15 PM' timestamp='1330632948' post='1377274']

Is the pixel fill-rate correct in the latest version? Because if so, it would show that the GTX 400/500 series has little to no extra performance, in terms of fill rates, over the 9000 series and GTX 200 lines.



For example, and using GPUz 0.5.7:



The 9800GTX has 16 Raster Operators and 64 Texture Mapping Units backed by 128 CUDA Cores.

At the clock speeds given, 675/1688 for the core/shader respectively, it produces a pixel fill-rate of 10.8 GPixels/s and a texture fill-rate of 43.2 GTexels/s.



My GTX 460M has 24 Raster Operators and 32 Texture Mapping Units backed by 192 CUDA Cores.

At the clock speeds given, 675/1350 for the core/shader respectively, it produces a pixel fill-rate of 16.2 GPixels/s and a texture fill-rate of 21.6 GTexels/s.



Yet, with the supposed "new calculation based on how Fermi's architecture works with Raster Operators now" with GPUz v0.5.8 and onward, my GTX 460M's pixel fill-rate at the same stock clocks of 675/1350 dropped down to a measly 5.4 GPixels/s. At this point, it would technically be slower than even a low power 9800GT ECO Edition, which my GPU draws rather close to the 5770 after my overclocking.



So my question stands at thus:



Is GPUz correct about the calculation and can someone give me some kind of an official answer here?



Over at Overclock.net, we're baffled by this and there are a few others like myself who would really like to know if this is correct. :( We liked having our lovely 40 billion pixels a second fill-rates. :(





Did you ask W1zzard?

#2
Posted 03/01/2012 08:21 PM   
That I did not... I just joined the forum here and didn't know where else to potentially ask... Who is this W1zzard you speak of? Where might I find him? (Not going to make a yellow brick road joke... >.>)
That I did not... I just joined the forum here and didn't know where else to potentially ask... Who is this W1zzard you speak of? Where might I find him? (Not going to make a yellow brick road joke... >.>)

#3
Posted 03/01/2012 08:23 PM   
[quote name='Imglidinhere' date='01 March 2012 - 03:23 PM' timestamp='1330633427' post='1377279']
That I did not... I just joined the forum here and didn't know where else to potentially ask... Who is this W1zzard you speak of? Where might I find him? (Not going to make a yellow brick road joke... >.>)
[/quote]

W1zzard, the person who wrote the GPU-Z application.


I believe he would be able to answer your question.


Techpowerup.com
[quote name='Imglidinhere' date='01 March 2012 - 03:23 PM' timestamp='1330633427' post='1377279']

That I did not... I just joined the forum here and didn't know where else to potentially ask... Who is this W1zzard you speak of? Where might I find him? (Not going to make a yellow brick road joke... >.>)





W1zzard, the person who wrote the GPU-Z application.





I believe he would be able to answer your question.





Techpowerup.com

#4
Posted 03/01/2012 08:25 PM   
Oh... O_O

Uhm... I'll ask him then...
Oh... O_O



Uhm... I'll ask him then...

#5
Posted 03/01/2012 08:38 PM   
[quote name='Imglidinhere' date='01 March 2012 - 03:38 PM' timestamp='1330634329' post='1377284']
Oh... O_O

Uhm... I'll ask him then...
[/quote]

http://www.techpowerup.com/forums/forumdisplay.php?f=53
[quote name='Imglidinhere' date='01 March 2012 - 03:38 PM' timestamp='1330634329' post='1377284']

Oh... O_O



Uhm... I'll ask him then...





http://www.techpowerup.com/forums/forumdisplay.php?f=53

#6
Posted 03/01/2012 08:41 PM   
Beyond the point that theoretical equations are merely representative figures, I don't believe contrasting such numbers between a discrete desktop GPU and a mobile GPU is fair ground to extrapolate any far-reaching conclusions, particularly if you're attempting to paint with such a broad stroke like "9 series versus 400/500 series." Comparisons between GPU families should be kept within the product market in that regard, and even with that, always bear in mind that these numbers are purely mathematical maximums; between rarely and never will they be achieved in practice.

Simply put, though: calculating pixel fill-rate for the Fermi architecture has changed to more realistically reflect performance. Previously, the ROPs were used as the basis for fill-rate calculation because they had a lower aggregate pixels/clock capacity than the SMs or pixel pipelines they were fed by - in other words, they were a consistent limitation that was accounted for by such a formula. Fermi is essentially the inverse of this, where the SMs produce fewer pixels/clock than the ROPs, which leaves them (the SMs) as the limitation. Both the "new" and "old" equations relate to capacities that still exist on the chip, but although the "new" figure appears conservative, it is far more realistic.
Beyond the point that theoretical equations are merely representative figures, I don't believe contrasting such numbers between a discrete desktop GPU and a mobile GPU is fair ground to extrapolate any far-reaching conclusions, particularly if you're attempting to paint with such a broad stroke like "9 series versus 400/500 series." Comparisons between GPU families should be kept within the product market in that regard, and even with that, always bear in mind that these numbers are purely mathematical maximums; between rarely and never will they be achieved in practice.



Simply put, though: calculating pixel fill-rate for the Fermi architecture has changed to more realistically reflect performance. Previously, the ROPs were used as the basis for fill-rate calculation because they had a lower aggregate pixels/clock capacity than the SMs or pixel pipelines they were fed by - in other words, they were a consistent limitation that was accounted for by such a formula. Fermi is essentially the inverse of this, where the SMs produce fewer pixels/clock than the ROPs, which leaves them (the SMs) as the limitation. Both the "new" and "old" equations relate to capacities that still exist on the chip, but although the "new" figure appears conservative, it is far more realistic.

GeForce Technical Marketing

#7
Posted 03/01/2012 09:00 PM   
Scroll To Top