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.tammi...@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.tammi...@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
