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

[Eero Tamminen]

Hi,

On 10.02.2017 13:00, Marek Olšák wrote:
> The glmark2 issue is not important, because glthread will never
> support glmark2. (because glmark2 is a SwapBuffers benchmark like
> glxgears)

Whether some test is SwapBuffers benchmark or not, or whether it 
benefits from glthread, is irrelevant.  What is relevant is:
* Does glthread cause test to crash
* Is the crash fault of glthread

I.e. is glthread broken.  If glthread is broken, performance numbers 
you've provided for other use-cases cannot be trusted, regardless of how 
promising they look.

(Without performance numbers that can be trusted to prove (current / 
eventual) working version of glthread to improve performance, there's no 
reason why the code would get merged.  I've seen a lot of examples of 
initially promising optimizations that weren't anymore when they had 
been fixed to work correctly.)


Note that while glmark2 test-suite tests with their default settings are 
indeed SwapBuffers tests (except for "terrain" test on weaker Intel 
GPUs), you're free to use some other setting [1].

For example these should be GPU (FS) limited:
	glmark2 -b loop:fragment-steps=4096 --fullscreen
	glmark2 -b conditionals:fragment-steps=1024:vertex-steps=4096
	glmark2 -b function:fragment-steps=4096

Last one gets stack overflow in Mesa, at least on Intel, maybe gallium 
fares better.

(Moving things away from main thread like glthread does could be an 
issue, as on linux only main thread stack grows on-demand, other threads 
have fixed stack sizes, nowadays by default 8MB.)


Btw.  When Mesa gets glvnd support, will glthread need also updates?


	- Eero

[1] Or tell it to use your own, more complex 3DS models and larger 
textures, or even replace the included shaders with something more 
demanding.  If somebody would add an option with which you can specify 
viewport matrix into which tests are rendered before doing buffer swap, 
even with the default options you could get tests GPU limited.  I'm sure 
upstream glmark2 would be happen to receive such changes.

> Marek
>
> On Fri, Feb 10, 2017 at 11:32 AM, Eero Tamminen
> <eero.t.tamminen at intel.com> wrote:
>> 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
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev