Agreed but within reason.
My understanding was that the geometry processors still leaned on a CU/LDS for the shading/interpolation and part of the tessellation work. Single permanent wave per SE, not necessarily adhering to the cadence. I'll admit I don't fully understand that part of the pipeline though.
The question is how they optimized it though? The clock difference from Polaris seems too significant for simply offsetting the power savings of a RF cache.
Yes, but you are still going at it the wrong way. OpenCL has no concept of "geometry". Unless this benchmark uses OpenGL/D3D/Vulkan then it doesn't matter the tiniest bit what the geometry throughput of a GPU is because none of the geometry features are not going to be visible to it. It's a general purpose OpenCL code (running on CUs) that happens to process geometry.
I realize that, but the bulk of the code and OpenCL throughput I'd expect to be representative of what a fully programmable card could push. Only difference being instead of a fixed function unit filling a wave, it's accomplished through software and there is no raster.
Because to my understanding, a CU encompasses part of that pipeline. Only difference being the OpenCL version would have saturated the card with triangles. If Vega removed the first stage and all that's left is shaders, then Vega can't handle graphics by your definition. All that would be left is a kernel dividing triangles.
OpenCL has no concept of triangles.
With OpenCL no GPU can handle graphics.
As said by MDolenc already: With OpenCL all what is left are compute shaders/kernels processing some data (as there is no concept of a triangle).
Again: there are no triangles in OpenCL. Graphics APIs have concept of triangles and yes in that case hull/domain/geometry/(primitive) shaders will invoke CUs. There is no such thing in OpenCL (or CUDA). It's just data that goes into the kernel and data that comes out of the kernel. It does not matter one bit if data happens to be triangles it does not affect anything.
I'd guess that Anarchist4000 expects the Catmull-Clark compute shader to exhibit similar load to GPU SIMDs as tessellated games do. However this isn't the case, since the geometry/tesselation bottleneck of early GCN versions was elsewhere, not in the SIMDs. SIMDs were poorly utilized in these games. OpenCL compute kernel isn't using these parts of the GPU, so that bottleneck doesn't apply.
No triangles, but the same algorithms and series of instructions mapped to generic hardware. What could occur if the fixed function hardware was removed entirely. Not unlike matrix multiplication at a low level as a bunch of MUL and ADD instructions. Too my understanding this is what primitive shaders are doing, but with far more flexibility at the cost of some efficiency.
In early GCN yes, but Nvidia hardware for example spreads that load across all SMs. A move away from the fixed function would likely entail some form of compute shader. That would put all the load, somewhat less efficiently, onto the SIMDs and probably ACE hardware. Moreso with extremely high levels of tessellation. While that result may have been anomalous, it would indicate how well part of the algorithm mapped to the underlying hardware. If accurate it might indicate Vega required tessellation for acceptable performance, the opposite of prior GCN hardware. For what should be a standard compute kernel, Vega was executing it differently from past generations.
The fixed function tessellator hardware is simply generating barycentric coordinates based on edge¢er tessellation factors (received from hull shader). These barycentric coordinates will be the input to the domain shader invocations. The problem with old AMD hardware was that the hull shader and domain shader had to run on the same CU. This is problematic when the hull shader outputs large tessellation factors -> lots of domain shader invocations. Geometry shaders have similar problems with load balancing (one of the reasons of GS slowness).
It is apparent that for some reason Vega benchmark score was bad in this particular benchmark. However it is important to understand that the geometry pipeline changes between the GCN4->GCN5 architectures play no role in this result. OpenCL doesn't use geometry pipelines at all. Most likely there are some changes in the shader cores (NCU) or shader compiler that explain this difference. Or simply that beta hardware has some units disabled and this test is heavily bottlenecked by that. Or their preliminary NCU shader compiler still needs some work before it's ready.
Not denying it could be a regression, but it's also possible GCN5 emulates the entire geometry pipeline with a primitive shader and some new capabilities. In that case the OpenCL result would be part of the pipeline. AMD devs did say they were doing a lot of shader work to get Vega running on linux with the first stage removed. It could be a software based pipeline.
The ACEs should be able to do that with some modifications to my understanding. Each having essentially unlimited inactive as pointers in ram. Just need some sort of fork to invoke the new shaders by kicking the dispatch back to the ACEs. HBCC could probably handle allocation as everything is virtual and capable of being evicted.
You don't want to store the intermediate data between pipeline stages to RAM. You want to use fast on-chip memories, such as LDS and GDS. There's a total of 4 MB LDS on the chip. If we want to use memory instead, we need significantly larger L2 cache.
Agreed, but that wouldn't be intermediate data as much as shader invocations filling a work queue. Ideally that stays in cache, but a deep queue has the possibility to overflow already.
I'm pretty sure the "Primitive Shader" refers to this (from the open-source driver):
/* Valid shader configurations:
*
* API shaders VS | TCS | TES | GS |pass| PS
* are compiled as: | | | |thru|
* | | | | |
* Only VS & PS: VS | | | | | PS
* GFX6 - with GS: ES | | | GS | VS | PS
* - with tess: LS | HS | VS | | | PS
* - with both: LS | HS | ES | GS | VS | PS
* GFX9 - with GS: -> | | | GS | VS | PS
* - with tess: -> | HS | VS | | | PS
* - with both: -> | HS | -> | GS | VS | PS
*
* -> = merged with the next stage
*/Those shader stages use something called the "ESGS ring" for exporting values. If I understood things correctly, prior to VI this was indeed just memory, but VI can use LDS for it, and Vega uses LDS exclusively. Therefore, I can't see how you could execute later stages in a different CU. Albeit I could certainly be wrong...