AMD Vega Hardware Reviews
- Thread starter ArkeoTP
- Start date
Pretty pixels in games? Current picture painted by „FE“ seems to indicate „roughly in between 1070 and 1080“ with power draw comparable to some third-party 1080 Tis while working at default throttles (temp, fan speed, power), i.e. 260-300 watts.
But with RX Vega, the full potential will be shown soon enough. Whether that's +1, +10 or +1000 %.
But with RX Vega, the full potential will be shown soon enough. Whether that's +1, +10 or +1000 %.
Or +0%. If you take minor hardware differences like different clock speeds or fan curve out of the equation.
I'm holding out hope for i% myself. It's complex, just like Vega.
I'm quite sure it will be more than 0% at least until Vega FE gets gaming drivers. It's current drivers are some odd mix of professional optimizations, some gaming optimizations missing bunch of everything and certificates. And no, "switching driver" doesn't switch driver, it just switches the control panel skin at this time.
I'm holding out hope for i% myself. It's complex, just like Vega.
Seriously, and again, while running the retail product through the test suites is obviously both valid and interesting, I would really appreciate the inside story of Vega. The hows and whys, what projections the design was based on, what hurdles they faced and maybe tripped on. At this point, it is as interesting as the numbers, maybe more.
Definitely deserves a post mortem! How it won't take too long for RTG to spill the beans.
Seriously, and again, while running the retail product through the test suites is obviously both valid and interesting, I would really appreciate the inside story of Vega. The hows and whys, what projections the design was based on, what hurdles they faced and maybe tripped on. At this point, it is as interesting as the numbers, maybe more.
Rootax
Veteran
Seriously, and again, while running the retail product through the test suites is obviously both valid and interesting, I would really appreciate the inside story of Vega. The hows and whys, what projections the design was based on, what hurdles they faced and maybe tripped on. At this point, it is as interesting as the numbers, maybe more.
I was waiting that kind of stuff for R600, but we never knew in the end, I believe...
Well, this was partially done in the post-RV770 Eric Demers interview. He blamed TSMC 80nm and too much resources dedicated for at that time unused filtering formats. IIRC, there were also strange AA related things and bloat created by still-chaning DX10 spec.
Rootax
Veteran
Nice ITW, thx.
But, the big question for me was "ok, wtf went wrong with AA, was it broken ? Why do that through shaders", etc...
And honestly, if clock for clock Vega does perform like Fiji, I would have a lot of question too, like "eh, what about the fake slides you showed us about improved architecture" (I'm kidding, don't worry. Well, for now
)My reading of the response on the R600's node wasn't that it was only blaming the node, but something of a combination of the design and the choice of node.
It's also not the full story as given by the interview. The inclusion of filtering was due to the interviewer's question leading to that response being included there.
Later sections hinted at a slew of re-balancing changes for features and performance with regards to current software and greater efficiency per unit. Physical optimization was part of the change.
Whether what was stated even then was the whole story is unclear. There were discussions as to whether R600 missed out on later tools that would have helped with its density. That might fit under the umbrella of blaming 80nm, or some other element of the platform they were developing with. It's doubtful AMD would officially cast blame or admit to a failing that specifically.
I believe Nvidia blamed some of the issues with Fermi on faulty validation or characterization of its interconnect, though I do not recall much specificity in the claim.
DavidGraham
Veteran
Yep, Jen-Hsun did blame the interconnect for the power consumption and delay of Fermi. Also mismanagement between engineering groups.
http://hexus.net/tech/news/graphics/26594-nvidia-explains-initial-fermi-delays/
At the end Fermi had bad luck, GTX 480 was cut down and underclocked, still it was the fastest chip available and few months later it got fixed, GTX 580 was the full chip, clocks were back on target, and performance lead lasted for Fermi through both AMD's VLIW5 and VLIW4.
GTX 580 was released 14 months after HD 5870 and 8 months after GTX 480. Isn't it a bit more than "a few"?
It is.
Just like Vega today? ;-)
I didn't know that R600 had full rate RGBA16f filtering. All ATI/AMD cards have been half rate since (R11G11B10f is the only full rate float format with more than 2 channels). Both Intel and NVidia offer full rate RGBA16f nowadays. I would guess that this originates to the R500 (Xbox 360 GPU) limited and slow support of 16 bit float texture formats and render targets. They heard developer complaints and overreacted. Half rate RGBA16f filtering would have been good enough (assuming full rate unfiltered loads) and is still good enough. The new R11G11B10f formats combined with temporal AA (hiding dithering) have reduced the need to use FP16 formats.
D
Deleted member 13524
Guest
I find it hilarious how FP16 was dismissed during the early DX9 days due to visually degrading implementations and now it is all the rage again.
AFAIK, FP16 was considered "not enough" for some (not al) pixel shaders during the transition fo Shader Model 2, hence why DirectX9 compliant cards required FP24 pixel shaders. But vertex shaders always needed to be FP32 IIRC.
So when the GPUs transitioned to unified shaders, these had to be FP32 only because they needed to be running pixel or vertex shaders.
Having a single FP32 ALU being able to do 2*FP16 operations (which are only relevant to pixel and compute shaders) is relatively new. I think it started with Skylake Gen9 graphics in 2015 and Tegra X1 in the same year. PowerVR had/has separate dedicated FP16 units for a while.
Regardless, I don't think it's all the rage at all. Not in the PC gaming space, at least. Even in the console world, the fact that Scorpio doesn't have it may be a significant blow to its adoption.
nvidia will probably do their best to downplay FP16 within everything gameworks until they release consumer cards with 2*FP16 ALUs, so for we'll probably only see adoption either on Bethesda games using idTech6 or EA games using the traditionally non-partisan Frostbite.
I bet Unreal Engine is going to postpone FP16 pixel shaders until nvidia consumer cards are doing 2*FP16 throughput, even though the Switch compiler supports it for sure.
It never was a bad idea, but with new GPUs every single year and performance increasing by leaps and bounds, why bother with the hassle? Promote everything to FP32 and move on to the next task. But now that the performance gains have slowed down and we can't just throw more joules at the problem, suddenly everyone has to start thinking about efficiency again.I find it hilarious how FP16 was dismissed during the early DX9 days due to visually degrading implementations and now it is all the rage again.
Though I don't envy devs here. Yes, you can use FP16 for pixel shaders, but you need to be careful with how you use it. Errors add up quickly at low precision.
D
Deleted member 2197
Guest
Why would Unreal Engine to postpone use of FP16 when competitors like Id are embracing FP16 in their next gen engines.
https://www.golem.de/news/id-softwa...massiv-auf-fp16-berechnungen-1704-127494.html
I find the idea that FP16 is good enough for pixel shaders and compute shaders rather funny. Developers need to consider what shader is actually doing and in general only parts of the shader will be run in FP16. That's why yes vertex shaders always required at least FP32, and pixel shaders were FP24+. Calculating texture addresses for example simply won't be accurate in FP16 for textures larger then 2048. And even in graphics you can't just say "well the color will be slightly off", you could sample a wrong part of the texture for example.
So just as in DX9 there was an option for developers to use half data type within shaders this option is back with DX11.1. And now there's PC GPU hardware support coming back. But there is nothing stopping hardware from simply promoting FP16 to FP32.
So just as in DX9 there was an option for developers to use half data type within shaders this option is back with DX11.1. And now there's PC GPU hardware support coming back. But there is nothing stopping hardware from simply promoting FP16 to FP32.
Similar threads
