Recent content by bridgman

Yep - each MEC block has 4 processor threads. If I remember correctly each thread can either run "pipe" microcode (multiplexing between 8 queues on the pipe and managing/submitting work from those queues) or "HWS" microcode (a layer above the pipes/queues which dynamically maps queues from a...

G is for GEMM :yes:... what were you thinking ? Seriously, it's a fair question... we do refer to it as an "accelerator" frequently but it is still more GPU-ish than non-GPU-accelerator-ish and there's an argument for using familiar terminology for a while.

For a while yes, but not forever... ... for exactly this reason. My original assumption was that we added it to make it fit better in Dr. Su's hand, but supposedly the corresponding internal guide helps with airflow as well.

Yep. The RDNA CU's are larger and have a definite performance advantage when running a wide mix of game shaders, but you don't get the same performance gain on typical compute workloads where most of the shader instructions are coming from optimized math libraries rather than game code.

Section 10.3 is the closest I remember seeing: In WGP mode, the waves are distributed over all 4 SIMD32’s and LDS space maybe allocated anywhere within the LDS memory. Waves may access data on the "near" or "far" side of LDS equally, but performance may be lower in some cases.

Sorry, I think I was a bit short of coffee on the last post... you get back compatibility anyways, but you aren't taking full advantage of the RDNA hardware because each workgroup is limited to a single CU. If you run in WGP mode you can spread a workgroup's waves across both CUs and the waves...

I don't think you are missing anything. CU's have had 64 CUs since Cayman (VLIW4, 16-way SIMD) although all the GCN ones were organized as 4 16-way SIMDs with a separate scalar ALU, so arguably 65. When we doubled the size of each SIMD we could either say "hey CU's are twice as big now" (which...

Correct... each pipe has its own fixed-function hardware. The microcode mostly does PM4/AQL packet decoding.

Rage 128 was the first GPU to include the Command Processor, which supported the move from what we called Programming Model 3 and Programming Model 4 (the pm4 packets you see mentioned in driver code get their name from the new HW programming model). I don't remember if PFP (pre-fetch parser)...

Right... both are scalar SIMD. We call the SIMD unit "vector" to distinguish it from the scalar non-SIMD processor, but each ALU in the SIMD is working on a different thread.

I guess if we actually wanted attention we could drop a couple of patches into llvmpipe or softpipe to support thousands of rendering threads.

Just curious, why 390 ? The RX480/580/590 has a similar number of CU's and generally outperforms the 390, doesn't it ?

You're thinking "semi-conducted" would have been more appropriate ?

Right... Arcturus is a "pick a random star" code name we're using in the Linux drivers for an as-yet-unannounced product. Using roadmap names in the code made it harder to get approval for early upstreaming.

I don't think I said "rebuilt every block"... I was just trying to make the point that changes in the underlying implementation did not necessarily have to be driver-visible. When the first GCN parts were launched we talked about ISA and implementation without drawing a line between them... so...