<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22 February 2018 at 14:33, Chuck Atkins <<a href="mailto:chuck.atkins@kitware.com">chuck.atkins@kitware.com</a>> wrote:<br>
> This fixes a segfault exposed by a29d63ecf7 which occurs when swr is<br>
> used on an unsupported architecture.<br>
><br>
> v2: re-work to place logic in xmesa_init_display<br>
><br>
> Signed-off-by: Chuck Atkins <<a href="mailto:chuck.atkins@kitware.com">chuck.atkins@kitware.com</a>><br>
> Cc: <a href="mailto:mesa-stable@lists.freedesktop.org">mesa-stable@lists.freedesktop.<wbr>org</a><br>
> Cc: George Kyriazis <<a href="mailto:george.kyriazis@intel.com">george.kyriazis@intel.com</a>><br>
> Cc: Bruce Cherniak <<a href="mailto:bruce.cherniak@intel.com">bruce.cherniak@intel.com</a>><br>
</span>FWIW<br>
Reviewed-by: Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>><br></blockquote><div><br></div><div>Thanks for the review.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Gut feeling suggests that this and perhaps the choose_visual() hunks<br>
are signs of other preexisting bugs.<br>
If you decide to stick around with xlib-glx it is worth nuking the<br>
XMesa abstraction/API.<br></blockquote><div><br><div>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 <span class="gmail-gr_ gmail-gr_78 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_disable_anim_appear gmail-ContextualSpelling gmail-ins-del gmail-multiReplace" id="gmail-78">xlib</span>-<span class="gmail-gr_ gmail-gr_79 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_disable_anim_appear gmail-ContextualSpelling" id="gmail-79">glx</span> since using <span class="gmail-gr_ gmail-gr_155 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_disable_anim_appear gmail-ContextualSpelling gmail-ins-del gmail-multiReplace" id="gmail-155">dri</span>
 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.<br><br></div>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-<span class="gmail-gr_ gmail-gr_690 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_disable_anim_appear gmail-ContextualSpelling gmail-ins-del gmail-multiReplace" id="gmail-690">xlib</span>-<span class="gmail-gr_ gmail-gr_720 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_disable_anim_appear gmail-ContextualSpelling" id="gmail-720">glx</span> is our path for that.<br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>- Chuck</div></div></div></div></div></div></div></div></div><br></div><br></div></div>