AMD Vega 10, Vega 11, Vega 12 and Vega 20 Rumors and Discussion

If I wasn't obvious, the hw simply does not have separate shader stages for all these api shader stages. So, I'd very much say shader stage merging happens "automatically" (in the driver), regardless if the app knows anything about primitive shader.

 

Wait - is that the benchmark, where Vega FE scores 114-ish at gamersnexus? And downclocked to Fury X leel 97-ish and Fury X is at 70-ish? Don't you think something's fishy here?

 

That would only work for DX12 and Vulkan since the Pipeline State Object is monolithic, all the older api's would be left to explicitly program for it.

^would/could

 

Can we get your perspective over the matter? Anything weird you noticed during your playtime with Vega, do you feel the drivers are not working in full capacities or the hardware have limitations or something?

 

No. Monolithic PSOs or not, the driver _has to_ merge these shader stages.
(In practice, this shouldn't be that much of a problem. Typically there shouldn't be too many different combinations for all those separately specified vs/gs/tesselation shaders - the driver maintains multiple binaries for even single shaders in much the same way already anyway, since there's still non-shader state which will force it to recompile a shader.)

 

That's an option yes. But how do you map this VS/GS merger to SIMDs? They don't run at the same frequency...

 

do we have an idea of when vega for gamers is hitting ?

 

I think it's launching on the 29th at siggraph.

 

You can figure out how it works with the mesa driver, this was commited about 2 months ago. I don't quite follow the details, it's rather complex (and would probably be easier to understand with hw docs) albeit there's a barrier between two parts of such a merged shader . Also, actually it may not even be necessary to compile multiple shaders together, as it may be possible to compile them independently and stitch the binary pieces together (the driver could do something similar even before for non-merged shaders, by having pre- and post-amble sections so it's not necessary to recompile everything for non-shader state changes).
Maybe somehow more/different threads are spawned for executing the second part, I really didn't study it...

 

They've already stated it won't be available to order during that week. They haven't guaranteed it's going to be the week after but it hasn't been discounted either, so we'll see. It looks like they'll be talking about Vega in detail at SIGGRAPH though so we should get a lot more details and possibly depending on how work goes on drivers and such over the next few weeks, maybe a more firm actual launch.

 

For me i just want to see the final product and benches. I wont buy anything till late fall anyway and if vega is a dud i may upgrade my cpu and wait with my 290

 

I'm not quite sure how DX11/OpenGL drivers handle shader permutations... don't remember. But some insight can be garnered from these two diagrams back when D3D12 first came out: page 6 and 7 of the following presentation https://www.slideshare.net/DevCentralAMD/introduction-to-dx12-by-ivan-nevraev

They are both merged and seperated under DX11, leading me to believe there is "module" reuse by the driver. Would primitive shader's breakdown to different hardware states or fewer states? Maybe we don't know yet. Either way the driver would need to keep track of shader permutations and compile outputs to match the HW states from the diagram. I don't know, I just get the feeling it has to be done explicitly since the way it was introduced by AMD.

 

Somebody knows where I can get the beyond3d suite? It's a cool tool which gives you a good hint about bottelnecks of an GPU. I want to buy a Rx Vega and want to test if the tiles based Rasterizer is working.

 

It's not publicly available.

 

Not public why not? Such a good tool! I think there will be a lot people outside which spend 20-50 buggs for this tool. We are living in a time of benchmarks and this is the king for gpu benchmarks

 

I've never gotten round to polishing it enough for regular use. One day this year, I'm just not sure when.

 

The Tech Report conclusion is incorrect. Nvidia had a faster culling rate prior to the tiled rasterizer.

 

is this where they said it wouldnt be available that week? because, if so, he was talking about computex.

 

Ever since they have distributed setup, to be exact (with the "polymorph engine", starting with fermi). (The tiled rasterizer would not help in any case for that.)
FWIW gp102 is a bit of an anomaly as it shows no scaling over gp104 with the culled polygon throughput test (which I think is what techreport must have been using). Since the theoretical culled throughput is nominally simply 1/3 tri per clock per smm, suggesting it hits another limit on gp102.

 

Efficient sparse matrix-vector multiplication on parallel processors

Wave level operations like Nvidia's Tensor Core.

METHOD AND APPARATUS FOR PERFORMING HIGH THROUGHPUT TESSELLATION

Programmable substitutions for microcode
Looks like IF routing updates.

Method and system for yield operation supporting thread-like behavior

Volta's sync threads?

Memory access monitor

Possibly HBCC, but may be Zen or both.

Stacked memory device with metadata management

Computer architecture using rapidly reconfigurable circuits and high-bandwidth memory interfaces

Configuring Infinity to make pipelines on the fly?