Mapbox-gl-native: Add Linux OSMesa support to HeadlessView

[mikemorris]

http://www.mesa3d.org/osmesa.html

For testing OpenSWR rendering. Is building GLFW from source with Wayland/EGL support necessary too?

http://www.glfw.org/docs/latest/compile.html#compile_manual

/cc @zmully

[mikemorris]

Is building GLFW from source with Wayland/EGL support necessary too?

No, this was a red herring related to the linuxapp build.

[mikemorris]

OMG I think I'm hitting https://bugs.chromium.org/p/chromium/issues/detail?id=482787, I can't get OSMesaMakeCurrent to release a context successfully...

[mikemorris]

This is fun.

OSMesaMakeCurrent( OSMesaContext osmesa, void *buffer, GLenum type,
                   GLsizei width, GLsizei height )
{

   if (!osmesa || !buffer ||
       width < 1 || height < 1 ||
       width > SWRAST_MAX_WIDTH || height > SWRAST_MAX_HEIGHT) {
      return GL_FALSE;
   }

[brunoabinader]

I believe I found a way to fix our anti-aliasing issues (#1555) by using OSMesa + post processing.

Replacing GLX with EGL

My efforts towards EGL usage (based on #5843) were unsuccessful - the EGL swrast driver works in non-VM environments, but not otherwise - it fails to find a suitable display, and EGL_DEFAULT_DISPLAY cannot be used in those cases.

Using mesa 12.0.3 or 13.0.0 with GLX (LLVMpipe) also produces the very same render test results as previous mesa versions, and I think I understood _why_: The software renderer must explicitly enable post-processing effects such as MLAA. However, post-processing is only available when using Gallium drivers. Gallium support for GLX library only comes with gallium-xlib, which involves using X and thus not desirable for headless support.

Enter OSMesa

I took liberty of rebasing/updating @mikemorris PR in #4638. I've also re-arranged the mason scripts for mesa 13.0.0 to produce a minimal binary, enabling Gallium implementation of the OSMesa library. Being OSMesa a headless, _simple_ layer on top of OpenGL and by using Gallium to provide _post-processing_ effects such as MLAA, I was then able to obtain 42 passing render tests that are currently ignored (same number as in macOS).

Post-processing can be enabled by calling e.g. OSMesaPostprocess(glContext, "pp_jimenezmlaa", 8); right after creating the context - this enables Jimenez' MLAA filter to be applied.

In sum:

• OSMesa is truly headless - no extra dependencies besides LLVM 3.8 (available via apt-get on Travis)
• Enabling morphological anti-aliasing filter and floating point textures enables us to obtain the same results as in Bitrise macOS

However, there are still a few drawbacks I must deal with:

• debug/overdraw is failing: that is either related to #6799 or a faulty implementation from OSMesa. In any case, I think it is forgivable to skip this test in favor of antialias support
• OSMesa is very rudimentary - I'm obtaining a few runtime throws via MBGL_CHECK_ERROR when running the render tests. Though results are passing, we might need to skip running this in debug mode. I'm still investigating whether we have an actual issue or if it is just OSMesa being faulty.

Related branches:

• https://github.com/mapbox/mason/tree/mesa-13.0.0
• https://github.com/mapbox/mapbox-gl-native/tree/osmesa-v2

/cc @mikemorris @kkaefer

[brunoabinader]

Errata:

• We don 't really need post-processing, OSMesa is already rendering stuff correctly when compared to GLX+LLVMpipe 🎉
• Fixed debug/overdraw
• Fixed issue with context destruction - we just need to make sure the context to be destroyed is active

[jfirebaugh]

Great work, this seems really promising!

Interesting that OSMesa+llvmpipe gives different (correct) results compared to GLX+llvmpipe. I would have expected the rendering issues we have been seeing in the test-suite to be entirely due to the software renderer, rather than the interface. Any theories as to why that's not the case?

Is there a performance delta between test-suite on GLX+llvmpipe and on OSMesa+llvmpipe?

[brunoabinader]

Interesting that OSMesa+llvmpipe gives different (correct) results compared to GLX+llvmpipe. I would have expected the rendering issues we have been seeing in the test-suite to be entirely due to the software renderer, rather than the interface. Any theories as to why that's not the case?

I agree - though I couldn't properly find a reason why GLX produces rendering artifacts, besides the fact its rendering pipeline is more complex due to X indirections than OSMesa.

Is there a performance delta between test-suite on GLX+llvmpipe and on OSMesa+llvmpipe?

Both implementations eventually uses LLVMpipe, so it seems unlikely e.g. duration for node4-clang35-debug is ~8min for both.

[brunoabinader]

Fixed in #6899.