OSMesa implementation changing

Development
#1

Hi! I’m a Mesa developer looking to clean up some of the cruft in our tree, and hopefully going to delete our OSMesa implementation based on the old software rasterizer. I’ve got an MR up for that (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1243) and an MR landing for fixing known bugs in the gallium implementation (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7886)

In the past, VTK has been the primary consumer of OSMesa that we know of (at least in terms of volume of bugs filed). While we would love to see users transition to EGL_MESA_device_software to get a software rasterizer (which gives you a specification with defined behavior, plus a faster swrast implementation!), we don’t want to regress your stuff. If you’re still using OSMesa, would someone be able to run your tests against the current gallium osmesa implementation as of !7886 and see if it’s sufficient for VTK?

#2

Thanks for the heads up! We’re in the middle of ParaView 5.9’s release cycle (the main driver for VTK’s OSMesa implementation AFAIK), so it’s too late to do too much change based on it, but we can probably take a look at it after the final release is out.

The best way to test what we’ve got is probably to modify the osmesa build we do for the ParaView package. The recipe is here which chains off to this file and then trigger the osmesa CI job to see the current state of it. If you could provide instructions we could use to change the build of OSMesa to use this (other than changing the source tarball), we could at least get a first pass at how it goes.

If we need code/context creation changes to test it, that’s in portions of the code I’m not as familiar with.

Heads up: @Chuck_Atkins @utkarshayachit @cory.quammen @ken-martin

#3

We’ve been deploying paraview and vtk with gallium osmesa for years now and relying on the llvmpipe and swr drivers. I don’t think loosing the classic osmesa will have any impact. Thanks for the heads up though.

As for egl,.I think long term we’d like to transition to egl entirely for both on and off screen and drop both glx and osmesa, but that’s still a ways out. At least dropping osmesa for egl is more doable in the near term. The current implementation only works with nvidia egl but as of mesa 20 I think we can easily make it work with mesas implementation as well. The biggest hindrance from a deployment standpoint though is that osmesa is pretty compact without a lot of external dependencies while egl in mesa pulls in the whole dri infrastructure (unless that’s changed?). Even when we ship mesa with glx we use xlib-glx to keep a minimal footprint since we’re only shipping the software renderers for llvmpipe and swr.

TLDR: dropping classic osmesa and only having gallium should be fine for us, dropping osmesa entirely for mesa egl is doable, dropping osmesa and glx both for egl would be great but that’s a longer term effort. 2 and 3 have some deployment issues to consider.

#4

Great, glad to hear you’re already on the gallium impl. I guess a warning, then: the depth buffer will now be y-flipped the other way in the next release, to match the original API.

For the future, if you go to just EGL with a surfaceless platform, that should be a very minimal dependency set.

#5

Excellent! I’ll take another look at what it will take to get our egl implementation working with mesa, but it looks like we’re probably good wrt osmesa changes.