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

[Ernst Sjöstrand]

FYI glmark2 segfaults with mesa_glthread=true. Expected that some programs
will segfault?

ATTENTION: default value of option mesa_glthread overridden by environment.
[New Thread 0x7fffed73d700 (LWP 23060)]
_mesa_glthread_init
=======================================================
    glmark2 2014.03
=======================================================
    OpenGL Information
    GL_VENDOR:     X.Org
    GL_RENDERER:   Gallium 0.4 on AMD FIJI (DRM 3.9.0 / 4.10.0-rc3+, LLVM
5.0.0)
    GL_VERSION:    3.0 Mesa 17.1.0-devel (git-c91d721)
=======================================================
[New Thread 0x7fffecf3c700 (LWP 23061)]
_mesa_glthread_init
_mesa_glthread_destroy
[Thread 0x7fffed73d700 (LWP 23060) exited]

Thread 1 "glmark2" received signal SIGSEGV, Segmentation fault.

Here's the backtrace:
http://pastebin.com/0FrM0Q0A

Regards
//Ernst


2017-02-06 1:11 GMT+01:00 Marek Olšák <maraeo at gmail.com>:

> Hi,
>
> Back in 2012-2013, then-Intel employees Eric Anholt and Paul Berry
> wrote this threaded GL dispatch where GL calls are queued and executed
> in a different thread. It was supposed to deal with high CPU overhead
> of Mesa, but at the time most games used the compatibility profile and
> Steam didn't really exist on Linux, so it didn't help many (if any)
> apps.
>
> Things are different today. We have Steam and most games use the GL
> core profile. We know of several games that have better performance
> with glthread, namely Borderlands 2, and some people reported to me
> that some other games also benefit. It's about time we put this into
> mainline Mesa.
>
> My plan is that we merge it as-is or with minor changes, and then
> we'll clean it up and improve it while it's in master. It's disabled
> by default, so it shouldn't bother anyone who doesn't want it. There
> is a drirc option to turn it on (just use the corresponding env var).
> All Gallium drivers support it.
>
> A note on synchronizations. Borderlands 2 has 170 thread syncs per
> frame. That means the app thread has to stop and wait 170x per frame.
> Despite that, it still has 70% higher performance in some cases. My
> theory is that if you have a lot of draw calls, you can have a lot of
> syncs, because the sheer amount of draw calls will just make those
> syncs irrelevant. 200 syncs per 4k draw calls is like 1 sync per 20
> draw calls.
>
> Here it is: https://cgit.freedesktop.org/~mareko/mesa/log/?h=glthread
>
> The plan is to merge everything up to the gallium commit (without the
> Intel commits, I'll let Intel decide what to do with them). I can send
> the whole series to the list if that's preferable.
>
> Opinions?
>
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170206/69d914b2/attachment.html>