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

[Emil Velikov]

On 22 February 2018 at 15:18, Chuck Atkins <chuck.atkins at kitware.com> wrote:
>> 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.
>
I was merely mentioning that the xlib-glx are in worse shape than the dri one.

That aside:
IIRC previously you mentioned that libGL/OSMesa must be static
libraries. If that is still the case, then DRI based GLX won't cut it.
Alternatively if you can point out any specifics that would be
amazing. Quick skim shows a few extras needed:

* GL side:
glapi + dri1/dri2 or dri3 specific: eg. xcb-dri2, xcb-dri3, xcb-present...
* [software] driver side:
glapi
* and glapi, itself
pthread, c

I've been wondering about 'splitting out' some of the DRI bits out,
although the topic is very subtle.
Depending on your specifics we might think of something though.

-Emil