Then if Vega FE is getting an almost exact carbon copy the gaming results of a GCN3 Fiji at similar clocks, whereas GCN4 Polaris 10 showed significant improvements over GCN3 Tonga, what do you think is happening here?
Broken chip using Fiji fallback driver path just to work? Broken chip using Vega driver but since it's broken this is all it can do? Healthy chip using Fiji fallback driver waiting for Vega driver?
There's a constellation of items that occurred to me, that seem like they could factor into it from my standpoint of as an outside observer.
(TLDR: possible fallbacks to unevolved hardware, tradeoffs for same performance per clock, maybe it's not that different)
Architectural features can be disabled or enabled even if they do not need explicit targeting by the driver at runtime.
Some of the most significant alterations could be complex enough or flaky enough to not be turned on if they interact poorly with real-world code.
Risk reduction may have those new features placed in areas that can safely fall back to architectural "bones" that are proven to work. The geometry front end and rasterizer changes could fall back to bones based heavily Fiji, given how closely they match on various parameters.
The primitive discard accelerator in Polaris is something in the same area, and that might mean it doesn't exist separately enough to work if those items aren't active--or there's another possibility I will get to later.
It may also be possible that even with some automatic improvements that there are penalties. One of the changes in the driver patches is a change in how many loads Vega can issue before having to wait, by a factor of 4. That could be a sign of something new not yet revealed, or something GCN was found to be limited by earlier, or a sign that Vega's L2/mem hierarchy needs that much more latency hiding. Something like trading off for higher clocks (or a higher-overhead data fabric?) might leave the designers purposefully aiming for roughly the same per-clock performance, with bonuses and penalties balancing out more closely than one would expect.
One specific oddity to the wait count encoding is that the counter is split, with the portion corresponding to the standard GCN wait count sitting in one portion of the encoding, and the remaining bits set on the far side opposite all the other counts. That may point to wanting some level of binary compatibility, since a more significant architectural departure shouldn't care about a few bits. That could be risk mitigation, the hardware isn't that different, or the different portion is similarly layered on top of something that isn't that different.
Something similar may apply as to why the ROPs changing in position relative to the L2 or the supposed increase in delta compression with Polaris didn't apply here, if some of the features are bypassed or add their own disadvantages. Polaris added some kind of coalescing of L2 client requests, but that might not apply the same way if Vega's L2 changed more significantly.
Comparing Tonga to Polaris may be somewhat unrepresentative because Tonga seemed a little more flaky than usual, as far as gauging improvements versus the Fiji/Vega range.
One other scenario I noted I would get to:
The device IDs for Ellesmere, Baffin, and Greenland showed up quite some time ago. Vega FE was still called Greenland in some areas.
GPU hardware even in the same "generation" isn't wholly equivalent. Tonga and Fiji have some decimal point differences in some of their IP identifiers, so what goes into the various blocks may be variably up to date.
Perhaps some elements were taken as snapshots at times we wouldn't expect, and some of the CU changes that went into Polaris were added after whatever snapshot was taken by Greenland, like specific tweaks to the instruction buffer size. Perhaps some of the other geometry and compression tweaks happened uniquely within the Polaris branch.
In addition to this, Polaris had features touted at launch that were touted at launch for Fiji and Carizzo. Given the overlapping timeframes of the projects and varying delays, perhaps we need to wait and see how many slides Vega RX cribs from prior gens.
Another random bit of comparison:
Since AMD has been touting Vega as being the first GPU with Inifinity Fabric:
One of the marketed benefits is a more modular command fabric, which I noted with the Zen slides has a sensor and control loop that measures and reacts every millisecond.
This was noted in various reviews and AMD's Ryzen page for its precision boost tech. I believe it is also mentioned for EPYC and its more distributed system.
For comparison:
http://www.anandtech.com/show/7457/the-radeon-r9-290x-review/5
For the 290X and 260X, when combined with the IR 3567B controller AMD is currently using, this means translates into the ability to switch voltages as frequently as every 10 microseconds, and to do so by switching between upwards of 255 voltage steps.
AMD has put various items like bees in jar: its highly responsive GPU management, its futuristic fabric, what level of responsiveness was acheived, how much that responsiveness matters, and an unknown level of integration of these items into Vega's hardware. Then it shook the jar. I'm curious what falls out in a month or so.
