Llvmpipe: The Jitted OpenGL software renderer inside Mesa | Hacker News Reader

Llvmpipe: The Jitted OpenGL software renderer inside Mesa

mesa3d.org

38 pointsvmorgulis22 comments

This looks interesting. I wonder if browsers could implement this as a fallback for WebGL when the drivers are missing or blacklisted? Chrome on Windows uses SwiftShader to fallback to software-rendered WebGL, and I think IE11/Edge use WARP, a DX11 software renderer. Firefox and other browsers on non-Windows platforms could benefit. But by the sound of it running this against the WebGL conformance tests could be spotty!

Does Chrome still use SwiftShader? I've tried on a reasonably large number of machines to verify this, with no luck. Including machines that have blacklisted GPUs.

It's clear that there seems to be some cases where it kicks in (or at least theres some legacy cruft that references it if not) but hell if I've ever seen it happen.

FWIW, OS X at least used to, and I think still does, use a JITed software renderer using LLVM.

See <http://lists.llvm.org/pipermail/llvm-dev/2006-August/006497.... for a short overview and <http://www.llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf> (slides, PDF) for a longer one.

fixed links: HN is keeping the > at the end of them.

[1] http://lists.llvm.org/pipermail/llvm-dev/2006-August/006497.... [2] http://www.llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf

Links are dead for me too, but IIRC that was in reference to the GLSL shader compiler.

links does not work for me

Potentially relevant sidenote:

Using VirtualGL (http://www.virtualgl.org/About/Introduction) and TurboVNC (http://www.turbovnc.org/About/Introduction), you can drop a GPU in a server and serve up OpenGL applications rendered using the GPU in the server via VNC over the network.

VGL pools the GPU(s) between multiple VNC displays, allowing for excellent performance.

Virgil (https://virgil3d.github.io/) is a similar effort for virtualizing GPU(s) in QEMU. The virtio-gpu guest DRM driver just shipped yesterday with Linux 4.4, making it possible to accelerate multiple VMs using host hardware.

A Direct3D guest driver, if it performs well enough, could finally end the hacky VFIO passthrough setups that are currently in vogue.

Wow, this looks really cool.

One curious idea that might be worth exploring: writing a Vulkan guest driver on top of this stack. It would be a novel approach, as the guest would see a Vulkan-centric view of the world (making development really simple), but that "world" would be easily transportable between machines, regardless of said machines' host graphics stacks.

I followed planet.freedesktop.org around the time that Gallium3D was being developed, so I knew that LLVM was being used inside Mesa. However, the only time I actually noticed it was when I hit https://github.com/NixOS/nixpkgs/issues/11467 last week

Looking at this: https://codereview.chromium.org/1548893004/ and this, is there chance that there will be decent option for headless webgl testing or making screenshots? Phantomjs doesnt want to do that, slimmerjs also (on xvfb), anybody have a working solution?

For http://Clara.io, we explored a bunch of headless gl solutions and none worked. It may have changed by now. But even if you got a headless gl solution working, it likely would have poor extension support, which means the results will suffer anyhow. :(

So did you take any other solution? I was thinking about renting or collocating server with gpu and just automate whole process with ansible/fabric or just vnc. About exentions - thats true. I was able to run software rending for shaders (llvm, xvfb, ec2), framerate was acceptable (1-5 fps, which is more than fine for screenshots), but issues like having max anisotropy = 1 make it unusable for this use case.

Mozilla's WebGL CI tests for Linux and Android run on Mesa's software renderer, though I'm not sure if we use LLVMPipe specifically. It works...ok.

Could you provide some links to results? Are you talking about mochitest-gl?

Primarily mochitest-gl, but also others. You can get an idea of what uses it by seeing what is blocking updating our ancient version of Mesa.[1] We anticipate that this update should improve the reliability of our tests.

I don't think there are specific results that are useful to anyone but us, other than that Mesa is viable for these sorts of things. We don't have a centralized tracking list for Mesa issues.

Like usual, if you try running WebGL on Mesa and run into unfixed issues, file a bug and we'll fix it.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1220658

Multiple times I've read about the better software renderer. If I read it correctly it's because of LLVM. What has LLVM to do with that? Why wasn't there a faster software renderer before there was LLVM? Is it easier to create a performant software renderer with LLVM? Could someone explain this to me or maybe provide a link for more information?

In OpenGL, you take vertex attributes in some user-specified format, run them through a user-supplied program, and rasterize it with a user-supplied program to generate pixel data. These programs are specified in GLSL. You want to run them, you have to interpret or compile. No surprise the compiled version is faster.

Even unpacking attributes is going to be faster with JIT.

Even pre vertex buffers the OpenGL rendering pipeline was highly customizable, even the difference between phong and gauraud shading has deep impact on the triangle rasterizer inner loop. So basically you have jit all the way down, to see maximum performance in software.

LLVM features lots and lots of optimization passes. Simpler hand-written shader compilers typically don't.

The "LLVM" bit is that it is using the IR JIT compiler that is part of the LLVM suite, which makes it relatively easy to build a high-performance native runtime for a custom language.

These days, GLSL does a LOT of heavy lifting. GLSL naturally benefits from JIT.

Reply on news.ycombinator.com