Recent content by 3dc_member

Just to confuse you: The peak pixel fillrate can also be limited by the memory bandwidth if there isn't enough write cache with sufficient bandwidth available for the ROPs. I.e. you got 17 GB/s (~DDR3-1066 @ 128 Bit) of memory bandwidth and 4 ROPs @ 2000 MHz (overclocked Intel HD Graphics...

A user at the forums of 3DCenter.org tried your testbuild with a GeForce GTX 460 and it seems to work: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9055220&postcount=359 He also measured the pixel fillrate which gave a peak of around 9.5 GPixel/s for color fills while your testbuild...

I've got no Fermi-GPU available, so other users with a GeForce 400/500 should check it out and compare with those values (the ones with GPixel/s as unit): http://de.wikipedia.org/wiki/Nvidia-Geforce-400-Serie#Leistungsdaten (the value for the GeForce 405 and GT 420 seems to be wrong)...

According to the benchmarks of hardware.fr i can confirm that for GF100, GF104, GF106, GF110, and GF114 at least: http://www.hardware.fr/articles/795-4/tests-theoriques-pixels.html http://www.hardware.fr/articles/818-6/tests-theoriques-pixels.html...

This moment seems to last forever. :(

Some additional background information on this topic: http://www.beyond3d.com/content/reviews/55/9 http://www.beyond3d.com/content/reviews/55/13 If you are looking for the correct peak pixel fillrates of reference GeForces have a look at the German Wikipedia...

The pixel fillrate in GPU-Z is displayed wrong for Nvidia Fermi based graphics cards. The pixel fillrate seems to be calculated by multiplying the number of ROPs and the GPU clock. But in case of Fermi gpus the pixel fillrate is generally not limited by the number of ROPs but by the number of...

A bandwidth is a physical quantity not a binary one.

The GB/s in v0.40 is neither a decimal prefix nor a binary prefix. It is more like a W1zzard prefix. Some people also call it a bug.

I am dealing with bandwidths in a scientific way. It is not dodgy to use bandwidths with decimal prefixes. In fact it is the absolutely common way. The usage of binary prefixes on bandwidths should be accentuated by writing down GiB/s instead of GB/s. Every examiner would agree to that. Btw...

Yes: http://forums.techpowerup.com/showpost.php?p=1831855&postcount=24

Using binary prefixes with bandwidths is not common because bandwidths rise from frequencies. And the calculation of the bandwidth in GPU-Z 0.40 was wrong both for a decimal and a binary interpretation.

Thank you for reverting to SI prefixes in version v0.42. But you didn't mention the calculation error from v0.40 in the changelog. "It introduces too much confusion" .. wrong things confuses people. ;)

We are talking about bandwidths, GB/s. It is common sense to prepend SI (decimal) prefixes to units of bandwidths. If you are interpreting the unit with binary prefixes you should also display the binary prefix (GiB/s) because using binary prefixes with bandwidths is neither common sense nor...

Use double memBw=c->m_busWidth*mem/8./1000.; if (c->GetMemType().Find(_T("DDR"))!=-1) memBw*=2; if (c->GetMemType().Find(_T("DDR5"))!=-1) memBw*=2; m_result.Set(_T("MemBandwidth"), Format(_T("%.1f"), memBw)); and display it as GB/s (which is what i prefer). Or use double...