AMD Vega Hardware Reviews

But are they referring to an "overall" performance improvement of 30%?
The context was frame time to hit their 30 or 60 fps target so yes. That's along the lines of cutting the time for 60% of the work in half. It definitely wasn't insignificant, but part of that was reduced register pressure and not double rate math. That would apply to most recent architectures on PC.

I'm not saying sebbbi/DICE are wrong, but if FP16 is that big of a deal then going to all FP32 ALUs back in the DX10 era would have to be considered a colossal fuckup right? And this decision was made 10+ years ago when IQ was nowhere near what we have today.
The issue was that FP32 is needed for positions and depth in most cases with modern titles. Used to have FP24 in there with FP16. At the time there was separate hardware for vertex and pixel shaders so they coexisted, but everyone transitioned to unified shaders. Therefore the least common denominator (FP32) won out. FP16 works on mobile because the titles generally lack complex scenes.

And outside RGBA color mapping, all that offers a lot values in those ranges:
RGBA should work with dithering. I believe that's what Sebbbi mentioned before
 
I'm not saying sebbbi/DICE are wrong, but if FP16 is that big of a deal then going to all FP32 ALUs back in the DX10 era would have to be considered a colossal fuckup right? And this decision was made 10+ years ago when IQ was nowhere near what we have today.

We can even go further back. Microsoft increased the minimum precision to FP24 PS with DX9 (SM2.0) in 2002 and to FP32 with SM3.0 in 2004. Valve announced a "multi precision" path for CineFX hardware but scratched it because of the increasing workload...
 
It's a comparison of geometry throughput versus Fury, giving the same start and end architectures. Maybe it's not the same if the original presentation's claim of polygons/clock is different from the whitepaper's primitives/clock.
The original mention was sufficiently vague with: „Vega is designed to handle up to 11 polygons per clock with 4 geometry engines“ from the footnotes of the Sonoma Techday 2016 pressdeck.
 
We can even go further back. Microsoft increased the minimum precision to FP24 PS with DX9 (SM2.0) in 2002 and to FP32 with SM3.0 in 2004. Valve announced a "multi precision" path for CineFX hardware but scratched it because of the increasing workload...
Just remember SM3 offered only pixel and vertex shaders, no integer support, no compute shaders, no tesselation pipeline, blend state, a lot of surface formats etc, removed shader limits etc...
FP32 requirement for SM3 was a sop due the to compensate a lot of missing features that were added in the future.
 
I wonder why so few reviewers even acknowledged (let alone study) the power saving mode of Vega 64.
We have reviewers saying Vega 56 is very well placed because if offers 90% of the V64's performance at 80% of its power consumption. Some even go as far as suggesting the Vega 56 is higher binned (Gamer Nexus I believe?).
But then they omit the fact that the Vega 64 in power saving mode offers 96% of the standard mode performance while consuming <75% of the power consumption.
The only thing that's seemingly dragging Vega56's power consumption down are its lower clocks, and Vega 64 at similar clocks consumes the same or less.

Maybe this is just the result of AMD putting pressure on reviewers to put more weight on the Vega 56, but it's really odd to just omit such an important feature on their flagship card.

I guess it makes sense why people hope for a magic driver.
And other people hope it's broken hardware.
Realistically, at this point I think it could go either way, and AMD driver devs themselves may not know yet what can be fully enabled or not, let alone when. Just like the absence of DSBR in Vega FE's launch drivers, as they may have not known if it would be ready in time for the RX launch..
 
I'm just blown away that they released another high-cost card built around cutting edge HBM and didn't make damn sure they would beat the little cheapo GP104 cards. It's the same story as Fury vs GM204. It's shocking! I'm certainly not going to sit around and hope they can get their shit together and bet on drivers saving the day as people do every time this company releases a turd.

Or the standard "it's future proof because of xx feature that's useless right now!". I should catalog which magic feature/function was going to save each generation of AMD bummer...
 
Last edited:
FP16 works on mobile because the titles generally lack complex scenes.
Indeed, and I don't think this makes a great case for FP16 on the desktop..

To be clear, I hope devs take advantage of fast low precision math as much as possible. It's not like I'm pulling against it or anything. FP16 is absolutely useful for some things in rendering and compute and should result in a nice little speedup in certain cases. But let's be realistic - it ain't gonna turn Vega into GP102.
 
I wonder why so few reviewers even acknowledged (let alone study) the power saving mode of Vega 64.
We have reviewers saying Vega 56 is very well placed because if offers 90% of the V64's performance at 80% of its power consumption. Some even go as far as suggesting the Vega 56 is higher binned (Gamer Nexus I believe?).
But then they omit the fact that the Vega 64 in power saving mode offers 96% of the standard mode performance while consuming <75% of the power consumption.
The only thing that's seemingly dragging Vega56's power consumption down are its lower clocks, and Vega 64 at similar clocks consumes the same or less.
What is the default power mode for the Vega cards?
 
An interesting difference between Zen and Vega is that the data fabric is not slaved to the memory clock, according to the reviews. Would there be a ratio or heuristic for the fabric's speed, or could someone overclock the GPU and memory bus while the interface that connects the two remains fixed?
 
And I should note that it's not currently exposed to DXVA. I asked AMD about this, but I haven't had a response so far.

Does anyone know how much integrated memory AMD's previous designs (Hawaii, Fiji and Ellesmere) have, to help put the 45MB number in some perspective?
Asked AMD that question. The short answer is that they declined to answer, since the actual math involves a large number of different structures. It's not just L1/LDS/L2, but also registers, dedicated parameter caches, other caches for latency hiding, etc.

I wonder why so few reviewers even acknowledged (let alone study) the power saving mode of Vega 64.
Because we only had 3 days.

According to Compubase.de, primitive shaders are not enabled on RX Vega yet.
FWIW, AMD told me that they are enabled. AMD has confirmed that they are definitely, absolutely not enabled.

I ran it. I cannot currently find any conclusive evidence one way or another on whether tiling is being used on that application.

http://images.anandtech.com/doci/11717/vegaraster.png

The behavior of the application is not much different from Fiji. Certainly nothing that looks like Maxwell/Pascal. However the absence of evidence is not evidence of absence, as this program was originally created to poke at NVIDIA GPUs. It essentially hits an edge case on NVIDIA's cards, one that may not exist on AMD's.
 
Last edited:
FWIW, AMD told me that they are enabled.
Maybe not everybody is exactly talking about the same thing? So, if by "primitive shader" you just mean the merged shader stages, that has to be enabled, it cannot be turned off.
But if that merged shader actually does something more than just what those fused shader stages are supposed to do based on the actual shaders, like figuring out front/backface and do culling already in the shader, is certainly up to the driver (and I could see a bunch of reasons why that may not always be an advantage and possibly be better placed under app developer's control, which isn't possible right now).
 
Back
Top