GDDR5 and HBM2 have that as part of their specification, HBM1 notably did not. Not all cards implement the full specification though, for example the first use of GDDR5 in the HD4xxx series didn't.
From a implementation point of view, how do they differ?
A Vertex Shader thread doesn't have access to neighboring vertices like a primitive shader or geometry shader. Nvidia and AMD have supported a "fast path GS" which gives access to all vertices of a primitive but doesn't support amplification. The primitive shader uses a different data path through the hardware than the VS. The whitepaper says "Primitive shaders will coexist with the standard hardware geometry pipeline rather than replacing it" and it's alluding to the different data path.
Are you referring to memory or engine overclocking? Memory overclocking can lead to errors and more repeated transactions, but NOPs aren't inserted for engine overclocking. Fixed function logic will straight up fail if a signal doesn't complete the path by the next clock edge. Parts of the design with EDC or ECC may be fault tolerant and retry, but most of a design won't consist of this logic.
The distinction is just the scope of the shader as I understand. Same hardware being used without any special new functions. Maybe that 4SE one in the ISA, but I'm guessing we haven't seen all the instructions yet. A primitive shader would be inclusive of geometry and vertex shaders. Simply ignoring the greater scope they would be identical. Unless AMD saves overhead with the old way, I'd speculate everything becomes a primitive shader for the purpose of optimization. Coexistence only from the programmers perspective. From the drivers point of view, the hardware and programmable stages would be the same shader, just with internal functions added to the beginning and end. It's only when rasterization kicks in that another pipeline stage truly kicks in as lots more threads are spawned. Will be interesting to see where they go with this in regards to dynamic memory allocations in shaders.
Engine overclocking in a throttled environment. Doing nothing as a means to conserve energy in the presence of a thermal or power limit without adjusting clockspeeds. Not as effective as changing the clocks, but situationally useful. Some overclocking tests have resulted in higher core clocks, but had no appreciable impact on performance. Entirely separate issue from timing constraints.
http://hexus.net/tech/reviews/graphics/109078-asus-radeon-rx-vega-64-strix-gaming/
AMD probably uses way more automated design/layout tools than NVIDIA or Intel. As a result their GPUs appear to be way less efficient at shuffling bits.Hm, I don't really know anything about anything really, but seems likely from a strictly layperson's perspective there's no any single cause of vega's power draw. Would scheduling really account for a hundred watts increase in dissipation? You'd have to have the world's most overengineered scheduler to hit such numbers methinks. (Also comparatively most underperforming one, seeing as vega at a much bigger die doesn't perform a whole lot better than GF1080, or even any better at all in certain titles.)
My analysis - for what it's worth:
NV/Jen Hsun said several years ago now (kepler era maybe?) that moving around data in a GPU costs more power than doing calculations on said data. He also said around pascal's release (prolly the reveal conference) that they'd taken a lot of care in laying out the chip/routing data flow, or words to that effect. Spared no expense, most likely (or very little anyhow - as pascal reportedly cost a billion buckaroos IIRC to develop.)
We know AMD doesn't have billions and billions to spend, and what money they do have must be shared with console SoC and x86 CPU divisions. They've also had issues hiring and retaining highly qualified staff, and from what I've read here and other places, laying out modern microchips is very difficult work, perhaps amongst the most difficult? As a result, doesn't it seem chances are fairly high that vega isn't nearly as efficiently laid out as it could have been, and that much power is spent/lost just on shuffling bits around the die? Hardware units themselves might also be comparatively inefficiently designed compared to NV's chips.
Anyway, I was quite prepared for vega being a power-hungry mother. I've been using RX 290X and 390X cards for years already, they're quite hoggy as it is. I don't really care about power, to be honest. It's not as important to me as raw performance, features and overall capabilities. On that front, vega does pretty well, I like that it seems to be the first fully DX12 capable chip ever. It's also a fast chip in absolute terms, even though it is not the fastest (or even consistently faster than GF1080). Price/performance might be hella dodgy though if the "stealth" price increase ends up being the new status quo from now on.
From pre-release numbers of the ASUS Strix board, this will be the new measuring stock for vega. Forget the default AMD OEM blower cards - they've always sucked really bad. (Well, err...) The Strix is noticeably faster, way quieter and runs around 10C cooler, even though it sometimes seem to draw even more power.
Nobody should settle for anything less.
