AMD Vega 10, Vega 11, Vega 12 and Vega 20 Rumors and Discussion
Anarchist4000
Veteran
Seems to be something software related going off Linux's open vs proprietary drivers. While AMD actively contributes to the open one, it's 30-500% ahead of the closed driver in OpenGL benchmarks. Even giving 1080ti a run and it's still a work in progress. Good Phoronix benchmarks with those numbers.
The pro and compute drivers would be a different team and resource model. Possibly even a higher priority if AMD anticipated a supply constraint on Vega with Ryzen hogging fab space. Focusing on higher margin Vega parts is logical.
Should work well for console gaming too! I'd still withholding judgement until the drivers mature a bit.
A smaller Vega would indeed be a good thing, imagine something like a 580 but with the clock speeds of Vega it might give the 1070 a run for its money. I'm still not sold on HBM2 for consumer cards, maybe GDDR6 will be a good fit for the next AMD GPUs.
I think the brunt of what we are seeing is the result of the fact that years ago AMD made a strategic decision that locked their high-end GPUs into the HMBx development path and GoFlo foundry process, with former being a mistake and latter an economic necessity. The combination has not worked out nearly as well as hoped.
Ok. So that's the benefit of merging multiple shaders into one: the buffer that you're talking about resides in between two earlier conventional shader stages.
Now is your 99%/1% example realistic for some games or is it just for the sake of explanation? Would games optimize their triangle strips such that you get a more balanced ratio between culling and non-culled triangles?
Do those buffers reside in DRAM/L2 cache or are we talking hard RAMs on the die? From what you write, it seems to be the latter.
Got it. So those non-pos attributes are created by one of the pre-buffer shader stages and need to be stored temporarily. And, again, those are not stored in DRAM either. And there are probably not enough triangles in flight to warrant the round trip to DRAM or L2 cache to store them there.
Now that gets us back to part of my initial question: what kind of extra HW is needed for primitive shaders that wasn't already there?
gamervivek
Regular
Another 1980Mhz Vega 64 on overclockers uk forum, however is behind a 1817Mhz with same HBM2 memory speed,
https://forums.overclockers.co.uk/threads/firestrike-ultra-4k-benchmark.18629665/#post-27044551
14nm+ could help with clocks further.
https://forums.overclockers.co.uk/threads/firestrike-ultra-4k-benchmark.18629665/#post-27044551
14nm+ could help with clocks further.
Rasterizer
Newcomer
From what I have been seeing around of people overclocking RX Vega, it appears that core overclocking may be too bugged on the current drivers to be able to draw any conclusions about its effectiveness. I'm seeing wildly inconsistent results from core overclocks compared to just setting a +50% power target, maxing out the HBM2 overclock, an undervolting to minimize throttling. I'm really looking forward to GN's upcoming video on undervolting Vega 56 as they appear to have the best grasp of the foibles of overclocking on the current drivers.
On a side note, it was mentioned that reviewers found an extra non-functional Vega package with their samples. If they're actual silicon, any chance someone could send one to the same person who got the Polaris and Fiji shots.
There's apparently some Zen pics now.
There's apparently some Zen pics now.
That would be fantastic. And we had Zen shots directly from AMD for a while now.
Jawed
Legend
In a conventional GPU primitive assembly is fixed function and that's where fixed function culling occurs (page 6 of the whitepaper). That stage needs buffering and if you swamp the buffer with useless triangles which have lots of attributes, that's the saturation problem.
In a pipeline configured with a GS, then there will need to be vertex buffering to hold the output of VS while it queues to be assembled into workgroups for GS shading.
So primitive shader "replaces" either:
- programmable VS + fixed-function culling (though I expect culling in primitive assembly isn't turned off)
- programmable VS + programmable GS
99%/1% was illustrative. But very high culling rate is realistic: e.g. very high poly count animated characters have a lot of back-facing triangles. When you start to shadow map, with multiple light sources, then each light will have an independent set of back-facing triangles.
But it's saturation that's the underlying problem. When you move the buffering problem into a primitive shader you now gain access to VGPR and LDS capacity: megabytes, so saturation is now a function of load-balancing and thread allocation.
Games can do all sorts of tricks to improve the ratio of desired versus culled triangles, e.g.
- using level of detail (reduced count of triangles for high poly models that are distant from the camera, so a lower percentage of all scene triangles)
- occlusion-querying (choosing not to draw triangles because they're known to be occluded, e.g. by terrain or other objects or view frustum
- using geometry shaders to perform developer originated culling
Conventionally they'd be RAM near the fixed function block that consumes the data. The fixed function block is a choke point in a sense, all the data it receives can come from any programmable shader units, since all of the programmable shader units can run VS (or GS).
Yes, primitive shading (mostly) obviates the capacity problem while dealing with in-flight vertices (triangles) and their shaded attributes until they are rasterised. Don't forget the rasteriser still has an input buffer: it is throughput limited, so it uses a buffer to smooth its handling of work, but this buffer can still be saturated even after primitive shader culling has already done a sterling job of reducing the effective triangle count.
GS was originally designed with a mode to stream out vertices to DRAM, ready for a second pass (or third etc.) through VS, before pixel shading (if there was even going to be pixel shading). So back in the D3D10 era, it was possible to come up with algorithms where stream out to DRAM was viable, but it was extremely rarely used.
NVidia's distributed geometry architecture has for years used L2 as an adaptive buffer to support the distribution of triangle data around the GPU after vertex shading.
None that I can discern.
True, but I think at least one of the shots is either a bit more detailed or maybe just has better contrast.
Does that mean that also Nvidia has Primitive Shader?
I never read something about this.
AMD's bridgman is writing some interesting tidbits on phoronix:
https://www.phoronix.com/forums/for...opengl-proprietary-driver?p=970697#post970697AMD bridgman said:
Jawed
Legend
I expect NVidia is doing the same thing. I am going to guess NVidia has been doing it for a long time.
It's just code.
AMDs word on that slide were:
Primitive Shaders
Hm, they explicitly say „hardware shader stage“. But given how much you needed to put words on a fine scale lately... Maybe it's just worded this way because it made sense to enable this, because the geometry engines could share data via L2 cache now.New hardware shader stage combining vertex and primitive phases
Enables early primitive culling in shaders
Enables early primitive culling in shaders
Faster processing of content with high culling potential
Faster rendering of depth pass
Speed up for vertex shaderswith attribute computations
A world of potential usesFaster rendering of depth pass
Speed up for vertex shaderswith attribute computations
Shadow maps
Multi-view and multi-resolution rendering
Particles
Multi-view and multi-resolution rendering
Particles