[Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

Eero Tamminen eero.t.tamminen at intel.com
Fri Feb 10 10:32:36 UTC 2017


Hi,

On 09.02.2017 20:27, Ernst Sjöstrand wrote:
> 2017-02-09 18:06 GMT+01:00 Eero Tamminen <eero.t.tamminen at intel.com
>     My personal feeling is that minimal merging criteria should be:
>     * no known segfaults
>
> I bet that glmark2 just does something that's not allowed. Mesa can't
> prevent all application bugs? Seems like it has a very buggy history
> with lots of segfaults in other situations also.

You don't know which one is at fault without investigating it.

glmark2 is open source, so it's easy to debug, and based on my 
experience has active maintenance:
	https://github.com/glmark2/glmark2/issues/25

If bug turns out to be in glmark2 instead of glthread code, file a bug:
	https://github.com/glmark2/glmark2/issues/

If developers agree that it's bug on glmark2 side (or at least don't 
point out an issue at Mesa side), segfault is OK.

(It would be best to test latest glmark2 git version, but IMHO waf usage 
makes it a bit pain to build.)


glxgears uses old GL stuff:
https://cgit.freedesktop.org/mesa/demos/tree/src/xdemos/glxgears.c

If glthread doesn't work with that (e.g. glBegin() / glEnd()), it should 
either disable threading, or abort with warning.  Silently corrupting 
things is not OK even for optional code paths.


I forgot one more thing from the minimum requirements:
* Once the segfaults and piglit failures have been investigated & fixed, 
or explained not to be glthread issues, glthread still shouldn't slow 
Mesa down when it's _disabled_

(Marginal slowdown at startup might be OK. At run-time slowdowns, when 
glmark is not enabled, are not going to fly as most programs will be run 
without enabling glthread.)


	- Eero



More information about the mesa-dev mailing list