4 ms·
Huh, TIL: the K6 came from an acquisition. > Graphics Core Next (GCN). This design would last for nearly 8 years […] still in use today as the integrated GPU
by floatboth 6y ago
Huh, TIL: the K6 came from an acquisition.
> Graphics Core Next (GCN). This design would last for nearly 8 years […] still in use today as the integrated GPU
And in desktop GPUs.
The goddamn power of marketing! Even tech writers seem to assume that "RDNA" is some kind of revolutionary from-scratch change. It's still the same ISA!! Look at the drivers and compilers. It's simply the regular evolution, just with a rebrand.
(upd: even later in this article they do say it's "a significant reworking of GCN"… well, why did the first mention sound kinda like it wasn't acknowledging this?)
- dragontamer 6y ago> The goddamn power of marketing! Even tech writers seem to assume that "RDNA" is some kind of revolutionary from-scratch change. It's still the same ISA!! Look at the drivers and compilers. It's simply the regular evolution, just with a rebrand. GCN 1.2 changed the opcodes from GCN 1.0. If the machine code doesn't line up anymore, is it really fare to call it the same ISA? In the case of RDNA: its all 32-wide SIMD instead of 64-wide SIMD. That dramatic difference completely destroys the bpermute / permute / DPP assembly instructions (https://gpuopen.com/learn/amd-gcn-assembly-cross-lane-operations/ https://gpuopen.com/learn/amd-gcn-assembly-cross-lane-operat...), which have gone from 64-way permutes (in GCN) into 32-way permutes (in RDNA). GCN 1.2 was already looking pretty different from GCN 1.0, I'd say RDNA absolutely deserves the name "new ISA". After all, GCN 1.2 is about as similar to GCN 1.0 as 8080 was to 8086 (same assembly language and registers, but new opcodes). I think most people are willing to call 8080 and 8086 different ISAs. RDNA is extremely different at a base level because of that 32x SIMD vs 64x SIMD.
- floatboth 6y agoIn the gpu world it's common to change instructions in iterative updates, since assembly is not really a popular way to program these. I think it's fair to call it the same as long as the compiler backends and drivers are still the same ones. Still amdgpu in LLVM, still RadeonSI and RADV in Mesa, etc.