What you describe is some stretchy level of “BC” at GCN assembly level. But the ISA in reality is still mildly different with breaking changes (if not instructions, then timing) across e.g. gfx908, gfx90a and gfx940. If that is the “BC” you are referring, one could stretch it further to say that such assembly level (semi-)portability exists across GCN, CDNA and RDNA to varying extent.
Otherwise, many are expected to use AMD’s libraries, HIP or mainstream libraries on top of these, which all present high(er) level abstractions like CUDA-like interfaces and/or kernel languages. “BC at ISA level” does not sound like a relevant concern for the abstraction consumers here, only the implementor (so mostly AMD and the ML infra teams of the “big customers”).
I see no avenue that AMD will replace the “machine code” representation with SPIR-V. Their own libraries and “big customers” would certainly still need that path to distribute e.g. target optimized GEMM kernels.
Even the SPIR-V stack itself needs a target to lower to, eh. So I can’t say I understand how “SPIR-V” ended up provoking these two strong reactions above.
Last edited:
