@mcc @MaddieM4 @ireneista This was done for a couple reasons. One is that LLVM IR is not actually a stable target, it is ultimately an implementation detail of LLVM and changes as LLVM changes so you have to follow upstream LLVM or maintain your ancient version forever. Which is not desirable in a standard interchange format. The other is that LLVM isn't really a good fit for GPU code for a number of reasons, and was even less of a good fit at the time.

@MaddieM4 @mcc @decay @riley @ireneista @amarioguy GPU shader processor architectures did go through a few different evolutions so there was something to that but I think they've more or less stabilized on what is and isn't a good idea (access memory through a plain pointer, do SIMD between shader invocations, not within one, that sort of thing). But even so there are a lot of subtly different approaches to things like flow control or sampler state to give just two examples.

@mcc @MaddieM4 The original SPIR was a fork of LLVM IR. SPIR-V is more or less "GLSL encoded as an SSA-based VM bytecode". @decay @riley @ireneista @amarioguy

@mcc DRI/DRM is the kernel part which handles confiuring displays, but also allocating memory for the GPU and managing the submission of command buffers to the GPU. The commands in the command buffers are produced by Mesa though.

@mcc I was thinking of making a 2D GPU, it's something I might still take up one day if I end up with a lot of free time for whatever reason.

@mcc Mesa does make implementing Vulkan somewhat easier, I think in some of the same ways that just implementing webgpu directly would, in that a lot of the redundant API surface is provided by shared code. And in particular you probably want to use Mesa for the compiler framework it provides, something that would be a pretty big lift otherwise. I think it doesn't have a WGSL frontend but that doesn't seem like it would be too hard to write.