Tuesday, December 20th 2011

TechPowerUp GPU-Z 0.5.7 Released

TechPowerUp today released GPU-Z version 0.5.7, the latest version of our popular graphics system information and diagnostic utility. This release of GPU-Z comes just in time for the launch of AMD's Radeon HD 7000 series. It packs tested support for Radeon HD 7970 and HD 7350. It packs an updated PCI Express 3.0 detection routine, with better detection reliability. It fixes a bug related to "APIC counter broken" on AMD Fusion APU platforms. Detection is improved for some rare GPUs, such as HD 6450A, HD 6470M, and the more popular HD 5570.

Several reliability updates were introduced. This includes fixed (improved) fillrate calculation on Fermi architecture, fixed ROP count on GT 420, GT 520, HD 5450, HD 6450; fixed random values showing as default clocks on some NVIDIA cards; fixed random value showing as shader clock on NVIDIA cards without shader clock; and addition of process size, die size, transistor count for Radeon E6760.

DOWNLOAD: TechPowerUp GPU-Z 0.5.7 and TechPowerUp GPU-Z 0.5.7 ROG-Themed
Add your own comment

24 Comments on TechPowerUp GPU-Z 0.5.7 Released

#2
Derek12
Cool corrected ROPS and Pixel fillrate in HD 5450 :toast:

and now says I have PCIe 1.1 which is true
Posted on Reply
#3
W1zzard
by: Derek12
and now says I have PCIe 1.1 which is true
before it showed "@ x16", now it shows "@ x16 1.1", kinda the same thing but easier to understand. It looked especially weird with "PCI-E x16 3.0 @ x16"
Posted on Reply
#4
Maban
Here comes the flood of angry Fermi owners.
Posted on Reply
#5
Isenstaedt
What about the ATi Radeon image instead of the AMD Radeon image on the 6000 series cards?
Posted on Reply
#6
Dj-ElectriC
Agree, no more ATI ( :(). Has to be AMD Radeon logo
Posted on Reply
#7
Completely Bonkers
I have found a bug
[spoiler="ticket"]Christmas giveaway tab missing! ;)[/spoiler]
Posted on Reply
#8
Derek12
by: W1zzard
before it showed "@ x16", now it shows "@ x16 1.1", kinda the same thing but easier to understand. It looked especially weird with "PCI-E x16 3.0 @ x16"
In my case it showed previously "PCIE x16 @ x16" (no 1.1 in either side) I though that it wasn't unable to measure it :)

Posted on Reply
#9
LAN_deRf_HA
I noticed my card switching between 1.1 and 2.0 because of power savings. Does gpu-z make all cards shoot up to 3d clocks when it first launches? Seems to on mine, which means you could probably solve that issue by making it check once at startup and never again.
Posted on Reply
#10
psti
by: btarunr
It fixes a bug related to "APIC counter broken" on AMD Fusion APU platforms.
Thanks a lot! :toast:
Posted on Reply
#11
kaktus1907
unfortunately it breaks GTX460 pixelfillrate



it seems like it reads Pixel per SM(2) x SM(7) counts.. it is actually true unless you crank msaa up but i would prefer the old way..
Posted on Reply
#14
kaktus1907
by: Maban
It doesn't break it, it fixes it. Fermi pixel fillrate is more based on the SM count than the ROP count for Fermi. (I don't know why, it just is.) You can read about it in this thread: http://www.techpowerup.com/forums/showthread.php?t=155459


Basically fillrate = core clock x SMs x 2.
Yes, It is if there is no MSAA as i said.. when you use MSAA all ROPs are available.. because MSAA doesnt increase the amount of data to be transmitted between the SMs and ROPs..
Posted on Reply
#15
Maban
by: kaktus1907
Yes, It is if there is no MSAA as i said.. when you use MSAA all ROPs are available.. because MSAA doesnt increase the amount of data to be transmitted between the SMs and ROPs..
I'd like to see info on that worded in such a way my head wouldn't explode from reading it. (Supertired Maban is supertired)
Posted on Reply
#16
kaktus1907
by: Maban
I'd like to see info on that worded in such a way my head wouldn't explode from reading it. (Supertired Maban is supertired)
by: Googlish
We were also able to learn more about limiting the fillrate of GF100 and GF104 to share it. It is at the level of communication between the SMs and ROPs which is limited to 64 bits per cycle. Thus, traditional rendering, each SM can output two pixels per cycle or 32 in total for the GF100 and 16 in total for the GF104. Whether the first to be equipped with 48 ROPs and the second 32 ROPs, the limit will be 32 and 16 pixels per cycle. The rasterizers also offer the same speed. We could say that the ROPs are slower in rendering FP16 (64 bits per pixel) and FP32 (128 bits per pixel), they will all be able to help with these reports. But it is not because, again, the datapath between the SMs and ROPs is limited to 64 bits. We do not know if this is a limitation due from the beginning by Nvidia, s it is a compromise made ​​short drive or a backup set up following a problem. Nevertheless we believe it is an important limitation of the architecture that prevents the full benefit of all ROPs and to a lesser extent the available memory bandwidth. Consolation prize, the ROPs "useless" are involved when antiliasing is used as the filter increases the load on the ROPs without increasing the amount of data to be transmitted between the SMs and ROPs.
http://www.hardware.fr/articles/795-3/architecture-suite-specifications.html
Posted on Reply
#17
faramir
HD 6470M isn't rare - it's used in a multitude of (cheaper) notebooks sold in Europe. I imagine same models are sold in the US as well (HP).
Posted on Reply
#18
DrunkenMafia
It says tested on 7970.... come on w1zz can you pm me some benchies... :) I won't share em, promise!!
Posted on Reply
#19
btarunr
Editor & Senior Moderator
by: DrunkenMafia
It says tested on 7970.... come on w1zz can you pm me some benchies... :) I won't share em, promise!!
Hold your horses for another...24 hours.
Posted on Reply
#20
DOM
by: btarunr
Hold your horses for another...24 hours.
no :roll:
Posted on Reply
#21
Derek12
hmmm Intel GMA 3150 wasn't fixed.
Posted on Reply
#22
W1zzard
by: Derek12
hmmm Intel GMA 3150 wasn't fixed.
whats the problem? also post a screenshot please
Posted on Reply
Add your own comment