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.
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.
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.
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.
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.
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
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.
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.
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.
23 comments
[ 3.0 ms ] story [ 67.5 ms ] threadEven unpacking attributes is going to be faster with JIT.
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
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.
[1] http://lists.llvm.org/pipermail/llvm-dev/2006-August/006497.... [2] http://www.llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf
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.
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.
A Direct3D guest driver, if it performs well enough, could finally end the hacky VFIO passthrough setups that are currently in vogue.
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.