> > On 22 February 2018 at 14:33, Chuck Atkins <chuck.atk...@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.atk...@kitware.com> > > Cc: mesa-sta...@lists.freedesktop.org > > Cc: George Kyriazis <george.kyria...@intel.com> > > Cc: Bruce Cherniak <bruce.chern...@intel.com> > FWIW > Reviewed-by: Emil Velikov <emil.l.veli...@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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
