[Mesa-dev] [Mesa-stable] [PATCH v2] glx: Properly handle cases where screen creation fails

[Chuck Atkins]

>
> On 22 February 2018 at 14:33, Chuck Atkins <chuck.atkins at kitware.com>
> wrote:
> > This fixes a segfault exposed by a29d63ecf7 which occurs when swr is
> > used on an unsupported architecture.
> >
> > v2: re-work to place logic in xmesa_init_display
> >
> > Signed-off-by: Chuck Atkins <chuck.atkins at kitware.com>
> > Cc: mesa-stable at lists.freedesktop.org
> > Cc: George Kyriazis <george.kyriazis at intel.com>
> > Cc: Bruce Cherniak <bruce.cherniak at intel.com>
> FWIW
> Reviewed-by: Emil Velikov <emil.l.velikov at gmail.com>
>

Thanks for the review.



> Gut feeling suggests that this and perhaps the choose_visual() hunks
> are signs of other preexisting bugs.
> If you decide to stick around with xlib-glx it is worth nuking the
> XMesa abstraction/API.
>

Our use case for building Mesa is to have as much of a self-contained
software-only libGL and libOSMesa as possible, hence using the xlib-glx
since using dri brings in a significant number of external dependencies.
We use it in HPC environments with no GPUs with OSMesa on the server-side
and GLX on the client side, which ensures we can pre-package a GLX library
for the GUI client that will support new GL specs while not needing to be
too concerned about performance since the heavy lifting for rendering is
done distributed on the server side.

If there's a better way forward for having a minimal-dependency
software-only implementation, I'd certainly be willing to try it.  At the
moment though, gallium-xlib-glx is our path for that.

- Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180222/505d7f1d/attachment.html>