I could see that INT SIMD unit could be extended with FP math for Celestial. Turing's 1:1 share for FP:INT was unbalanced.
Intel ARC GPUs, Xe Architecture for dGPUs [2022-]
- Thread starter BRiT
- Start date
I think Volta/Turing's architecture has been partly misunderstood tbh, the 32x32+32 integer multiply-add was the same pipeline as the FP32 FMA reusing some of the HW, so the "integer" path was mostly just the cheap stuff like integer add, bitwise ops, etc... and a key benefit of "underpowering" the FP path is that it meant there was spare instruction fetch/decode performance not just for INT but also control ops like branches etc... which used to be effectively 'free' on Volta/Turing but now effectively prevent the 2nd FMA (or a special function op like rcp/log/etc.) from being co-issued so each control op is quite expensive. The extra FP32 FMA is cheap so it's a clear PPA win but the previous design made a lot of sense, and now it's the fetch/decode that's a bottleneck (which should be cheap area-wise, but hard to increase the throughput of architecturally given how everything else works).
To go back to Intel GPUs, I've never seen much information at this level of detail on how their execution ports work, but based on Figure 4 of Page 5 here, it looks to me like they don't have FP/INT co-issue at all on the "Xe-LP" parts and the Port 1 for "EM" is just for special function (log/exp/rcp/rsq/etc.) but they do allow co-issue of Branch instructions (and SEND, not sure what those are, fragment/vertex output and blending?). So that *might* just be a simple dual-issue with INT/FP on one side and EM/BRANCH/SEND being co-issuable, or something more complex.
But then they have 3 ports on Xe-HPG: FP + INT/EM + XMX... I am a bit skeptical (from my own personal GPU HW architecture experience) of merging the INT & EM ports, because EM is really quite special, they are all "single source, single destination" operations and higher internal latency than most other things (although potentially similar to an INT32 multiply-add if you optimise them a certain way). Just like everything Intel GPUs, AFAICT they seem to gravitate towards more and more complexity with dubious high-level architectural choices like SIMD8/SIMD16 hurting their PPA more than all the same clever tricks put together *shrugs*
Also I wouldn't say NVIDIA is SIMD16, because their register files are physically SIMD32 (2 banks at SIMD32 means an effective 4 reads + 4 writes at SIMD16 per cycle), and you cannot get more than 50% throughput for half-filled warps under *any* cirumstance (unlike on G80, where such a mode did exist for vertex shaders, but even one of their lead compute architects I spoke with in person back in 2008 didn't know about it!) - my assumption is that Intel can achieve 100% throughput for SIMD16 on Battlemage which is a very different set of trade-offs.
This hits home hard though - I've had to argue that exact same thing at previous GPU employers repeatedly over the years sadly, too many GPU architects try to be too clever in their own unique way, and it rarely works out in practice for exactly that reason. Because AMD has both consoles, if you're "AMD-like" rather than "NVIDIA-like" then you're possibly okay as well, but doing something completely different with its own unique unexpected performance cliffs that developers might not expect and certainly won't optimise for is asking for trouble...
Good point. Operand fetch and instruction issue are probably both SIMD32 issuing to each hardware SIMD16 block in alternate clocks.
I know it hurts your ego. I was in the same position. But the only rational decision is to follow the standard, unless you have something that gives a substantial performance advantage (not in a subroutine test but in overall fps) and that the majority of developers will implement (which is the hardest part when you are not the dominant player). Kudos Arun for your honestly on this topic, I feel it's kind of taboo in the engineering world, yet the reason of so many failures...
Game developers don't write/test their applications against some theoretical gfx API specs! They've ALWAYS developed their applications against concrete driver implementations of these said gfx APIs so what Petersen articulated shouldn't really come out as some astonishing revelation. There's going to be developers out there who'll continue to indefinitely brush aside Intel gfx HW ...
Good on them, I hope to see Xe2 supporting all new titles day 1!
Stacking Up Intel Gaudi Against Nvidia GPUs For AI
Here is something we don’t see much anymore when it comes to AI systems: list prices for the accelerators and the base motherboards that glue a bunch of
www.nextplatform.com
Similar threads
- Locked