LLVMpipe Is Now Officially Conformant With OpenGL 4.5

[phoronix]

Phoronix: LLVMpipe Is Now Officially Conformant With OpenGL 4.5

Beginning with Mesa 20.2 is OpenGL 4.5 support for LLVMpipe, the LLVM-based software rasterizer built as a Gallium3D driver. This succeeded LLVMpipe for years being limited to OpenGL 3.3. While the OpenGL 4.5 support has been enabled for weeks, The Khronos Group has now officially confirmed its implementation...

http://www.phoronix.com/scan.php?page=news_item&px=LLVMpipe-OpenGL-4.5-Conformant

[tildearrow]

This is an accomplishment...

I don't think there are any other software renderers out there that implement OpenGL 4.5 o-o

[uid313]

Can softpipe, swr and zink get OpenGL 4.5 now too?
LLVMpipe, softpipe, swr and Zink are all software renders, but LLVMpipe has much more OpenGL support. What does all these different software renderers do different? And can't they borrow code from each other?

[tildearrow]

Can softpipe, swr and zink get OpenGL 4.5 now too?
LLVMpipe, softpipe, swr and Zink are all software renders, but LLVMpipe has much more OpenGL support. What does all these different software renderers do different? And can't they borrow code from each other?

LLVMpipe uses LLVM to generate the render code, which has allowed it to catch up with the latest OpenGL versions pretty quickly (since LLVM is used on the AMD driver too).
Softpipe is a pure software renderer that does not rely on LLVM (in case it is not available), but is much slower for this reason.
SWR is OpenSWR from Intel, which was conceived years ago as a high-performance software renderer, but it seems to be abandoned now.

Zink on the other hand isn't really a renderer, but rather a translation layer which converts OpenGL to Vulkan for consumption by other drivers.

Nope, it would be too hard for them to borrow code...

[ix900]

LLVMpipe uses LLVM to generate the render code, which has allowed it to catch up with the latest OpenGL versions pretty quickly (since LLVM is used on the AMD driver too).
Softpipe is a pure software renderer that does not rely on LLVM (in case it is not available), but is much slower for this reason.

I only recently paid any attention to llvm but feel like this is an understatement of what llvm is. I mean when you check if llvm is being used or the GPU, it can mean something entirely different from what is suggested here. https://bugs.launchpad.net/ubuntu/+s...g/+bug/1752938

It feels like it just depends on how llvm is being used and what the comparison is.

[karolherbst]

LLVMpipe uses LLVM to generate the render code, which has allowed it to catch up with the latest OpenGL versions pretty quickly (since LLVM is used on the AMD driver too).

only difference is that llvm doesn't really help with any of this. You still have to write the entire graphics pipeline in code, LLVM is really just used to write the shaders, it doesn't make texture stuff magically work or any of the other OpenGL features, besides the pure shader language ones.

[airlied]

AMD llvm work didnt really help here, the big change was llvmpipe NIR support that opened up adding a lot of features, importing the microsoft tessellator and finally getting mutlisample rendering.

swr could leverage a lot of this if they moved to NIR and they have the tessellator and msaa in theory already. Softpipe would need a fair bit of work and is unlikely to proceed. Zink allready do 4.6 in a branch and shares nothing with this,

[Jabberwocky]

I really wish I could talk about this achivement over a beer or two. Bloody well done!!

[smitty3268]

Softpipe would need a fair bit of work and is unlikely to proceed.

Can you expand on that a bit? My understanding was that softpipe was a lot easier to work on than llvmpipe, so I'm a bit surprised.

Is it just that some bits like hooking up the tessellator would be too much work for no good reason since we already have llvmpipe working?

[airlied]

Can you expand on that a bit? My understanding was that softpipe was a lot easier to work on than llvmpipe, so I'm a bit surprised.

Is it just that some bits like hooking up the tessellator would be too much work for no good reason since we already have llvmpipe working?

Yeah just lots of work to add tessellation shaders and multisampling and I'm not really motivated too much, softpipe is usually only interesting to me personally as a learning tool and I already did all the work in llvmpipe