6 ms·

Llvmpipe: The Jitted OpenGL software renderer inside Mesa

38 points by vmorgulis 11y ago

starquake 11y ago
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?
- dietrichepp 11y ago
  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.
- asherkin 11y ago
  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.
- deleted 11y ago
  [deleted]
- duaneb 11y ago
  These days, GLSL does a LOT of heavy lifting. GLSL naturally benefits from JIT.
- marktangotango 11y ago
  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.
- pcwalton 11y ago
  LLVM features lots and lots of optimization passes. Simpler hand-written shader compilers typically don't.
yarp 11y ago
Looking at this: https://codereview.chromium.org/1548893004/ 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?
- bhouston 11y ago
  For http://Clara.io 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. :(
  - yarp 11y ago
    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.
- jdashg 11y ago
  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.
  - yarp 11y ago
    Could you provide some links to results? Are you talking about mochitest-gl?
    - jdashg 11y ago
      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 https://bugzilla.mozilla.org/show_bug.cgi?id=1220658
chriswarbo 11y ago
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 https://github.com/NixOS/nixpkgs/issues/11467 last week
gsnedders 11y ago
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.html> 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> http://www.llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf> (slides, PDF) for a longer one.
- FraKtus 11y ago
  links does not work for me
- mwfunk 11y ago
  Links are dead for me too, but IIRC that was in reference to the GLSL shader compiler.
- simcop2387 11y ago
  fixed links: HN is keeping the > at the end of them. [1] http://lists.llvm.org/pipermail/llvm-dev/2006-August/006497.html http://lists.llvm.org/pipermail/llvm-dev/2006-August/006497.... [2] http://www.llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf http://www.llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf
AshleysBrain 11y ago
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!
- yoklov 11y ago
  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.
i336_ 11y ago
Potentially relevant sidenote: Using VirtualGL (http://www.virtualgl.org/About/Introduction http://www.virtualgl.org/About/Introduction) and TurboVNC (http://www.turbovnc.org/About/Introduction 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.
- tadfisher 11y ago
  Virgil (https://virgil3d.github.io/ 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.
  - i336_ 11y ago
    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.

38 points by vmorgulis 11y ago

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?

dietrichepp 11y ago
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.
asherkin 11y ago
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.
deleted 11y ago
[deleted]
duaneb 11y ago
These days, GLSL does a LOT of heavy lifting. GLSL naturally benefits from JIT.
marktangotango 11y ago
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.
pcwalton 11y ago
LLVM features lots and lots of optimization passes. Simpler hand-written shader compilers typically don't.

yarp 11y ago

Looking at this: https://codereview.chromium.org/1548893004/ 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?

bhouston 11y ago
For http://Clara.io 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. :(
- yarp 11y ago
  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.
jdashg 11y ago
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.
- yarp 11y ago
  Could you provide some links to results? Are you talking about mochitest-gl?
  - jdashg 11y ago
    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 https://bugzilla.mozilla.org/show_bug.cgi?id=1220658

chriswarbo 11y ago

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 https://github.com/NixOS/nixpkgs/issues/11467 last week

gsnedders 11y ago

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.html> 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> http://www.llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf> (slides, PDF) for a longer one.

FraKtus 11y ago
links does not work for me
mwfunk 11y ago
Links are dead for me too, but IIRC that was in reference to the GLSL shader compiler.
simcop2387 11y ago
fixed links: HN is keeping the > at the end of them. [1] http://lists.llvm.org/pipermail/llvm-dev/2006-August/006497.html http://lists.llvm.org/pipermail/llvm-dev/2006-August/006497.... [2] http://www.llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf http://www.llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf

AshleysBrain 11y ago

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!

yoklov 11y ago
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.

i336_ 11y ago

Potentially relevant sidenote: Using VirtualGL (http://www.virtualgl.org/About/Introduction http://www.virtualgl.org/About/Introduction) and TurboVNC (http://www.turbovnc.org/About/Introduction 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.

tadfisher 11y ago
Virgil (https://virgil3d.github.io/ 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.
- i336_ 11y ago
  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.