- last edited on by
ROGBot
My G752VY came out of the box with the VBIOS available here (Firmware node):
https://www.asus.com/ROG-Republic-Of-Gamers/ROG-G752VY/HelpDesk_Download/
but I've noticed it is different from the 980M on my G751JY (now in for the G-Sync upgrade):
Some specs like ROP/TMUs are different on this G752VY (slight OC +120MHz core,
+240 mem using nVidiainspector):
ASUS custom VBIOS confuses GPU-z?
Others confirm these strange specs or different variants of 980M around the globe?
What's your G752VY 980M spec with GPU-z?
No problem if it's just a matter of altered VBIOS clocks for more efficiency when not running heavy 3D applications... but how can ROP/TMUs be different?
https://www.asus.com/ROG-Republic-Of-Gamers/ROG-G752VY/HelpDesk_Download/
but I've noticed it is different from the 980M on my G751JY (now in for the G-Sync upgrade):
Some specs like ROP/TMUs are different on this G752VY (slight OC +120MHz core,
+240 mem using nVidiainspector):
ASUS custom VBIOS confuses GPU-z?
Others confirm these strange specs or different variants of 980M around the globe?
What's your G752VY 980M spec with GPU-z?
No problem if it's just a matter of altered VBIOS clocks for more efficiency when not running heavy 3D applications... but how can ROP/TMUs be different?
Good post.
It's GPU-Z.
I'm not 100% sure if it's because of the size of the VBIOS with G-SYNC ROMs but they are bigger than non G-SYNC ones, so most likely it's not reading everything due to outdated entries. The CUDA cores are the same and that alone is an indication of it being the same 64/128 and it's just GPU-Z not showing it correctly, but.....
It's also normal, even the 540 you see, with the G-SYNC 980M. It's still 1038 base clock and 1126 boost clock. Nothing there has changed at all. Run GPUShark or NVIDIA driver information to verify that.
What is strange though, is even if you do the math on it, GPU-Z is still reading it wrong but the numbers do still work because of that. Example:
Texture FillRate = Core Clock * TMUs.
This formula above is how you can figure this out.
Take the first screenshot in your first post and look at texture fillrate: 132.9 GTexel/s. So do, 1038 (base clock) X 128 (TMUs) = 132,864 OR 132.9 GTexel/s
Now take the second screenshot and look at texture fillrate: 63.4 GTexel/s. So do, 660 (+120 from vanilla) x 96 (TMUs) = 63,360 OR 63.4 GTexel/s (51.8 GTexel/s vanilla)
I'm still going on GPU-Z being the problem.
EDIT: However, just did some more digging. Wiki on it shows 64/96 as well. So maybe they grabbed the G-SYNC model.
Another interesting thing here. Take 1038 x 96 = 99,648 OR 99.6 GTexel/s but divide by 2 and you get 49.8 GPixel/s as well. Yet, with the non G-SYNC you get 1038 x 128 = 132,864 (132.8 GTexel/s) and divide by 2 and you get 66,432 OR 66.4 GPixel/s. The 540 in both is indeed a core clock and they both have 1038/1126. Same CUDA cores with the same die and generation of GPU. That to me is where I find it highly unlikely that 32 TMUs are missing because it's the "G-SYNC" model.
The 980 (notebook) model should be 2048:170:64 on that Wiki screenshot and NOT 2048:128:64, unless that too is wrong!
This is so weird... based off the 64/128, the GPixel/s would be 66.4 like it is shown below, but with 64/96, it simply isn't unless you divide by 1.5 instead of 2 (96 ÷ 1.5 = 64 | 1038 x 96 = 99.6 GTexel/s but divide by 1.5 = 66.4 GPixel/s) which is indeed 64/96! GPU-Z or VBIOS versions (and drivers) between vendors conflicting I'm thinking or WTF.
NOW, here's the kicker...
http://www.notebookcheck.net/NVIDIA-GeForce-GTX-980M.126692.0.html
Based off of that, the 980M's have 64/96 and NOT 64/128. So initially, GPU-Z was displaying the TMU count wrong entirely or I need some sleep.
As Marty McFly would say, "This is heavy".
It's GPU-Z.
I'm not 100% sure if it's because of the size of the VBIOS with G-SYNC ROMs but they are bigger than non G-SYNC ones, so most likely it's not reading everything due to outdated entries. The CUDA cores are the same and that alone is an indication of it being the same 64/128 and it's just GPU-Z not showing it correctly, but.....
It's also normal, even the 540 you see, with the G-SYNC 980M. It's still 1038 base clock and 1126 boost clock. Nothing there has changed at all. Run GPUShark or NVIDIA driver information to verify that.
What is strange though, is even if you do the math on it, GPU-Z is still reading it wrong but the numbers do still work because of that. Example:
Texture FillRate = Core Clock * TMUs.
This formula above is how you can figure this out.
Take the first screenshot in your first post and look at texture fillrate: 132.9 GTexel/s. So do, 1038 (base clock) X 128 (TMUs) = 132,864 OR 132.9 GTexel/s
Now take the second screenshot and look at texture fillrate: 63.4 GTexel/s. So do, 660 (+120 from vanilla) x 96 (TMUs) = 63,360 OR 63.4 GTexel/s (51.8 GTexel/s vanilla)
I'm still going on GPU-Z being the problem.
EDIT: However, just did some more digging. Wiki on it shows 64/96 as well. So maybe they grabbed the G-SYNC model.
Another interesting thing here. Take 1038 x 96 = 99,648 OR 99.6 GTexel/s but divide by 2 and you get 49.8 GPixel/s as well. Yet, with the non G-SYNC you get 1038 x 128 = 132,864 (132.8 GTexel/s) and divide by 2 and you get 66,432 OR 66.4 GPixel/s. The 540 in both is indeed a core clock and they both have 1038/1126. Same CUDA cores with the same die and generation of GPU. That to me is where I find it highly unlikely that 32 TMUs are missing because it's the "G-SYNC" model.
The 980 (notebook) model should be 2048:170:64 on that Wiki screenshot and NOT 2048:128:64, unless that too is wrong!
This is so weird... based off the 64/128, the GPixel/s would be 66.4 like it is shown below, but with 64/96, it simply isn't unless you divide by 1.5 instead of 2 (96 ÷ 1.5 = 64 | 1038 x 96 = 99.6 GTexel/s but divide by 1.5 = 66.4 GPixel/s) which is indeed 64/96! GPU-Z or VBIOS versions (and drivers) between vendors conflicting I'm thinking or WTF.
NOW, here's the kicker...
http://www.notebookcheck.net/NVIDIA-GeForce-GTX-980M.126692.0.html
Based off of that, the 980M's have 64/96 and NOT 64/128. So initially, GPU-Z was displaying the TMU count wrong entirely or I need some sleep.
As Marty McFly would say, "This is heavy".
Good post.
It's GPU-Z.
I'm going to go in stages here, so bare with me.
I'm not 100% sure if it's because of the size of the VBIOS with G-SYNC ROMs but they are bigger than non G-SYNC ones, so most likely it's not reading everything due to outdated entries. The CUDA cores are the same and that alone is an indication of it being the same 64/128 and it's just GPU-Z not showing it correctly, but.....
It's also normal, even the 540 you see, with the G-SYNC 980M. It's still 1038 base clock and 1127 boost clock. Nothing there has changed at all. Run GPUShark or NVIDIA driver information to verify that.
What is strange though, is even if you do the math on it, GPU-Z is still reading it wrong but the numbers do still work because of that. Example:
Texture FillRate = Core Clock * TMUs.
This formula above is how you can figure this out.
Take the first screenshot in your first post and look at texture fillrate: 132.9 GTexel/s. So do, 1038 (base clock) X 128 (TMUs) = 132,864 OR 132.9 GTexel/s
Now take the second screenshot and look at texture fillrate: 63.4 GTexel/s. So do, 660 (+120 from vanilla) x 96 (TMUs) = 63,360 OR 63.4 GTexel/s (51.8 GTexel/s vanilla)
I'm still going on GPU-Z being the problem.
However, just did some more digging. Wiki on it shows 64/96 as well. So maybe they grabbed the G-SYNC model.
Another interesting thing here. Take 1038 x 96 = 99,648 OR 99.6 GTexel/s but divide by 2 and you get 49.8 GPixel/s as well. Yet, with the non G-SYNC you get 1038 x 128 = 132,864 (132.8 GTexel/s) and divide by 2 and you get 66,432 OR 66.4 GPixel/s. The 540 in both is indeed a core clock and they both have 1038/1127. Same CUDA cores with the same die and generation of GPU. That to me is where I find it highly unlikely that 32 TMUs are missing because it's the "G-SYNC" model.
The 980 (notebook) model should be 2048:170:64 on that Wiki screenshot and NOT 2048:128:64, unless that too is wrong!
This is so weird... based off the 64/128, the GPixel/s would be 66.4 like it is shown below, but with 64/96, it simply isn't unless you divide by 1.5 instead of 2 (96 ÷ 1.5 = 64 | 1038 x 96 = 99.6 GTexel/s but divide by 1.5 = 66.4 GPixel/s) which is indeed 64/96! GPU-Z or VBIOS versions (and drivers) between vendors conflicting I'm thinking or WTF.
NOW, here's the kicker...
http://www.notebookcheck.net/NVIDIA-GeForce-GTX-980M.126692.0.html
Based off of that, the 980M's have 64/96 and NOT 64/128. So initially, GPU-Z was displaying the TMU count wrong entirely or I need some sleep.
As Marty McFly would say, "This is heavy".
It's GPU-Z.
I'm going to go in stages here, so bare with me.
I'm not 100% sure if it's because of the size of the VBIOS with G-SYNC ROMs but they are bigger than non G-SYNC ones, so most likely it's not reading everything due to outdated entries. The CUDA cores are the same and that alone is an indication of it being the same 64/128 and it's just GPU-Z not showing it correctly, but.....
It's also normal, even the 540 you see, with the G-SYNC 980M. It's still 1038 base clock and 1127 boost clock. Nothing there has changed at all. Run GPUShark or NVIDIA driver information to verify that.
What is strange though, is even if you do the math on it, GPU-Z is still reading it wrong but the numbers do still work because of that. Example:
Texture FillRate = Core Clock * TMUs.
This formula above is how you can figure this out.
Take the first screenshot in your first post and look at texture fillrate: 132.9 GTexel/s. So do, 1038 (base clock) X 128 (TMUs) = 132,864 OR 132.9 GTexel/s
Now take the second screenshot and look at texture fillrate: 63.4 GTexel/s. So do, 660 (+120 from vanilla) x 96 (TMUs) = 63,360 OR 63.4 GTexel/s (51.8 GTexel/s vanilla)
I'm still going on GPU-Z being the problem.
However, just did some more digging. Wiki on it shows 64/96 as well. So maybe they grabbed the G-SYNC model.
Another interesting thing here. Take 1038 x 96 = 99,648 OR 99.6 GTexel/s but divide by 2 and you get 49.8 GPixel/s as well. Yet, with the non G-SYNC you get 1038 x 128 = 132,864 (132.8 GTexel/s) and divide by 2 and you get 66,432 OR 66.4 GPixel/s. The 540 in both is indeed a core clock and they both have 1038/1127. Same CUDA cores with the same die and generation of GPU. That to me is where I find it highly unlikely that 32 TMUs are missing because it's the "G-SYNC" model.
The 980 (notebook) model should be 2048:170:64 on that Wiki screenshot and NOT 2048:128:64, unless that too is wrong!
This is so weird... based off the 64/128, the GPixel/s would be 66.4 like it is shown below, but with 64/96, it simply isn't unless you divide by 1.5 instead of 2 (96 ÷ 1.5 = 64 | 1038 x 96 = 99.6 GTexel/s but divide by 1.5 = 66.4 GPixel/s) which is indeed 64/96! GPU-Z or VBIOS versions (and drivers) between vendors conflicting I'm thinking or WTF.
NOW, here's the kicker...
http://www.notebookcheck.net/NVIDIA-GeForce-GTX-980M.126692.0.html
Based off of that, the 980M's have 64/96 and NOT 64/128. So initially, GPU-Z was displaying the TMU count wrong entirely or I need some sleep.
As Marty McFly would say, "This is heavy".
Dreamonic wrote:
Good post.
It's GPU-Z.
I'm going to go in stages here, so bare with me.
I'm not 100% sure if it's because of the size of the VBIOS with G-SYNC ROMs but they are bigger than non G-SYNC ones, so most likely it's not reading everything due to outdated entries. The CUDA cores are the same and that alone is an indication of it being the same 64/128 and it's just GPU-Z not showing it correctly, but.....
It's also normal, even the 540 you see, with the G-SYNC 980M. It's still 1038 base clock and 1127 boost clock. Nothing there has changed at all. Run GPUShark or NVIDIA driver information to verify that.
What is strange though, is even if you do the math on it, GPU-Z is still reading it wrong but the numbers do still work because of that. Example:
Texture FillRate = Core Clock * TMUs.
This formula above is how you can figure this out.
Take the first screenshot in your first post and look at texture fillrate: 132.9 GTexel/s. So do, 1038 (base clock) X 128 (TMUs) = 132,864 OR 132.9 GTexel/s
Now take the second screenshot and look at texture fillrate: 63.4 GTexel/s. So do, 660 (+120 from vanilla) x 96 (TMUs) = 63,360 OR 63.4 GTexel/s (51.8 GTexel/s vanilla)
I'm still going on GPU-Z being the problem.
However, just did some more digging. Wiki on it shows 64/96 as well. So maybe they grabbed the G-SYNC model.
Another interesting thing here. Take 1038 x 96 = 99,648 OR 99.6 GTexel/s but divide by 2 and you get 49.8 GPixel/s as well. Yet, with the non G-SYNC you get 1038 x 128 = 132,864 (132.8 GTexel/s) and divide by 2 and you get 66,432 OR 66.4 GPixel/s. The 540 in both is indeed a core clock and they both have 1038/1127. Same CUDA cores with the same die and generation of GPU. That to me is where I find it highly unlikely that 32 TMUs are missing because it's the "G-SYNC" model.
The 980 (notebook) model should be 2048:170:64 on that Wiki screenshot and NOT 2048:128:64, unless that too is wrong!
This is so weird... based off the 64/128, the GPixel/s would be 66.4 like it is shown below, but with 64/96, it simply isn't unless you divide by 1.5 instead of 2 (96 ÷ 1.5 = 64 | 1038 x 96 = 99.6 GTexel/s but divide by 1.5 = 66.4 GPixel/s) which is indeed 64/96! GPU-Z or VBIOS versions (and drivers) between vendors conflicting I'm thinking or WTF.
NOW, here's the kicker...
http://www.notebookcheck.net/NVIDIA-GeForce-GTX-980M.126692.0.html
Based off of that, the 980M's have 64/96 and NOT 64/128. So initially, GPU-Z was displaying the TMU count wrong entirely or I need some sleep.
As Marty McFly would say, "This is heavy".
As Doc Brown would say
"The results of which could cause a chain reaction that would unravel the very fabric of the space-time continuum and destroy the entire universe!."
As I've mentioned, it's GPU-Z. Latest one shows clocks/fillrate properly now.
