<div dir="ltr"><div><div><div>FYI glmark2 segfaults with mesa_glthread=true. Expected that some programs will segfault?<br><br>ATTENTION: default value of option mesa_glthread overridden by environment.<br>[New Thread 0x7fffed73d700 (LWP 23060)]<br>_mesa_glthread_init<br>=======================================================<br>    glmark2 2014.03<br>=======================================================<br>    OpenGL Information<br>    GL_VENDOR:     X.Org<br>    GL_RENDERER:   Gallium 0.4 on AMD FIJI (DRM 3.9.0 / 4.10.0-rc3+, LLVM 5.0.0)<br>    GL_VERSION:    3.0 Mesa 17.1.0-devel (git-c91d721)<br>=======================================================<br>[New Thread 0x7fffecf3c700 (LWP 23061)]<br>_mesa_glthread_init<br>_mesa_glthread_destroy<br>[Thread 0x7fffed73d700 (LWP 23060) exited]<br><br>Thread 1 "glmark2" received signal SIGSEGV, Segmentation fault.<br><br></div>Here's the backtrace:<br><a href="http://pastebin.com/0FrM0Q0A">http://pastebin.com/0FrM0Q0A</a><br><br></div>Regards<br></div>//Ernst<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-06 1:11 GMT+01:00 Marek Olšák <span dir="ltr"><<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Back in 2012-2013, then-Intel employees Eric Anholt and Paul Berry<br>
wrote this threaded GL dispatch where GL calls are queued and executed<br>
in a different thread. It was supposed to deal with high CPU overhead<br>
of Mesa, but at the time most games used the compatibility profile and<br>
Steam didn't really exist on Linux, so it didn't help many (if any)<br>
apps.<br>
<br>
Things are different today. We have Steam and most games use the GL<br>
core profile. We know of several games that have better performance<br>
with glthread, namely Borderlands 2, and some people reported to me<br>
that some other games also benefit. It's about time we put this into<br>
mainline Mesa.<br>
<br>
My plan is that we merge it as-is or with minor changes, and then<br>
we'll clean it up and improve it while it's in master. It's disabled<br>
by default, so it shouldn't bother anyone who doesn't want it. There<br>
is a drirc option to turn it on (just use the corresponding env var).<br>
All Gallium drivers support it.<br>
<br>
A note on synchronizations. Borderlands 2 has 170 thread syncs per<br>
frame. That means the app thread has to stop and wait 170x per frame.<br>
Despite that, it still has 70% higher performance in some cases. My<br>
theory is that if you have a lot of draw calls, you can have a lot of<br>
syncs, because the sheer amount of draw calls will just make those<br>
syncs irrelevant. 200 syncs per 4k draw calls is like 1 sync per 20<br>
draw calls.<br>
<br>
Here it is: <a href="https://cgit.freedesktop.org/~mareko/mesa/log/?h=glthread" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/~<wbr>mareko/mesa/log/?h=glthread</a><br>
<br>
The plan is to merge everything up to the gallium commit (without the<br>
Intel commits, I'll let Intel decide what to do with them). I can send<br>
the whole series to the list if that's preferable.<br>
<br>
Opinions?<br>
<br>
Marek<br>
______________________________<wbr>_________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
</blockquote></div><br></div>