[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