With the mesa llvmpipe or r300 in either Firefox or Chrome, navigate to: https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html It fails with the mesa drivers, but passes with the nvidia proprietary driver on my GTX650. The intel driver was fixed here Bug 78770. Sample failure output: failed: getError expected: NO_ERROR. Was OUT_OF_MEMORY : there should be no error for level: 12 1x1 failed: getError expected: NO_ERROR. Was OUT_OF_MEMORY : there should be no error for level: 11 2x2 failed: getError expected: NO_ERROR. Was OUT_OF_MEMORY : there should be no error for level: 10 4x4 failed: getError expected: NO_ERROR. Was OUT_OF_MEMORY : there should be no error for level: 9 8x8 failed: getError expected: NO_ERROR. Was OUT_OF_MEMORY : there should be no error for level: 8 16x16
The test passes by forcing softpipe with: $ export LIBGL_ALWAYS_SOFTWARE=1 $ export DRAW_USE_LLVM=0 $ export GALLIUM_DRIVER=softpipe So for swrast, this is llvmpipe specific. Adding Roland to the case.
It is not really llvmpipe specific, it is more or less luck this passes with softpipe, the actual logic refusing too large textures is very similar. But softpipe announces a limit of 4k for cube maps, whereas llvmpipe says 8k. It is true though that with the memory limit we impose (1GB) we can't actually even handle a 2 (with mips) or 4 channel (even without mips) (with just 8 bits per channel, uncompressed) cube map, but this isn't required unless I'm missing something, and it is quite ok to simply say out_of_memory (this could be queried via proxy textures). That the test only ever tries to submit the smallest mip levels doesn't matter, we allocate the whole thing in any case. I'm inclined to mark this as NOTABUG, the test looks bogus. If you'd try the same with, say, RGBA32F textures, you'd see this fail on softpipe as well. (We could, of course, increase the limit, but even twice that would not quite be enough for what the tests wants - not sure if all the math would be unsigned-safe to increase it further to the required "some bytes more than than 2GB due to padding" but in any case I don't think we really want to do that.)
Forgot to mention, I tested this with firefox. I am no longer able to use chromium at all for this with the xlib based driver - there's some error about threads in use "InitializeSandbox() called with multiple threads in process gpu-process" and it just seems to hang, with LP_NUM_THREADS=0 it gets past that but somehow llvm doesn't like getting used within the sandbox (I assume): "static llvm::sys::Path llvm::sys::Path::GetCurrentDirectory(): Assertion `false && "Could not query current working directory."' failed". But in any case the result should be the same if you somehow manage to use llvmpipe with chromium.
Roland, Yes, chromium's sandbox can be a hassle if it gets misconfigured. When I was running daily builds, I configured it (also can be disabled) with this: https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment I'm currently using Chrome, which installs with a working/preconfigured sandbox. It still gives the "InitializeSandbox() called with multiple threads in process gpu-process" warning but still works. llvmpipe is working with both webgl demos and the webgl conformance tests. Thanks for investigating this issue. I'll close it as NOTABUG.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.