[Bug 93840] [i965] Compiler backend uses too much stack with Alien: Isolation

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Feb 10 17:43:31 UTC 2017


Eero Tamminen <eero.t.tamminen at intel.com> changed:

           What    |Removed                     |Added
            Summary|[i965] Alien: Isolation     |[i965] Compiler backend
                   |fails with                  |uses too much stack with
                   |GL_ARB_compute_shader       |Alien: Isolation
                   |enabled                     |

--- Comment #21 from Eero Tamminen <eero.t.tamminen at intel.com> ---
(In reply to Matt Turner from comment #14)
> Created attachment 126122 [details] [review]
> patch
> (In reply to Darius Spitznagel from comment #1)
> > Created attachment 121746 [details]
> > Alien: Isolation GDB log
> The memset() at line 935 of
> a4cff18:src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp is
> >   memset(last_grf_write, 0, sizeof(last_grf_write));
> The backtrace shows
> #1  0x00007fffe79015fe in memset (__len=482688, __ch=0,
> __dest=0x7fffa216e550) at /usr/include/x86_64-linux-gnu/bits/string3.h:84
> __len=482688?!

In my case with today's Mesa & Alien Isoation:
Thread 17 "WinMain" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f09cc122700 (LWP 23775)]
__memset_avx2 () at ../sysdeps/x86_64/multiarch/memset-avx2.S:161
161     ../sysdeps/x86_64/multiarch/memset-avx2.S: No such file or directory.
(gdb) bt
#0  __memset_avx2 () at ../sysdeps/x86_64/multiarch/memset-avx2.S:161
#1  0x00007f09de059b0c in memset (__len=349056, __ch=0, __dest=0x7f09cc0c98c0)
at /usr/include/x86_64-linux-gnu/bits/string3.h:90
#2  fs_instruction_scheduler::calculate_deps (this=0x7f09cc11ee90) at

-> 349056 byte memset.

After applying patch similar to yours, game crashes in startup when compiler is
using another stack array.

> last_grf_write is sized as
> >   schedule_node *last_grf_write[grf_count * 16];
> and 482688 / 16 is 30168. So we have 30168 virtual registers?!

This is 64-bit program and pointers are 8 bytes, so 482688/16/8 = 3771, or in
my case, 349056/16/8 = 2727.

After a lot of reading assembly, head scratching of how the memset() could
crash when according to GDB memory addresses are fine, I went through process
memory mappings and it all came clear...

By default, thread stacks are with Glibc 8MB except for the main thread.
However, this game sets several of the threads stacks sizes to few hundred kB
(one thread was set to only 34KB).

Process' thread stack mappings are followed by 4kB "canary" page which doesn't
have read/write access rights.  The segfaults happen when Mesa crosses the
boundary from 384 kB stack to that.

When I manually tried following with Gdb:
(gdb) b pthread_attr_setstacksize
Breakpoint 6 at 0x7f7ea34f21d0: file pthreadP.h, line 631.
(gdb) c
[New Thread 0x7f7e84532700 (LWP 3333)]

Thread 6 "WinMain" hit Breakpoint 6, __pthread_attr_setstacksize
(attr=0x7f7e85bf7890, stacksize=393216) at pthread_attr_setstacksize.c:38
38      in pthread_attr_setstacksize.c
(gdb) finish
Run till exit from #0  __pthread_attr_setstacksize (attr=0x7f7e85bf7890,
stacksize=393216) at pthread_attr_setstacksize.c:38
0x0000000000b1dd75 in ?? ()
Value returned is $12 = 0
(gdb) delete 6
(gdb) print __pthread_attr_setstacksize(0x7f7e85bf7890, 4194304)
$13 = 0
(gdb) b pthread_attr_setstacksize
Breakpoint 7 at 0x7f7ea34f21d0: file pthreadP.h, line 631.
(gdb) c

To change too small stack sizes to something larger (in this case 4MB) at
run-time, the game started fine, it just takes a *long* time.

So, either this game needs some LD_PRELOAD that maps
pthread_attr_setstacksize() function to a no-op, or Mesa compiler needs to be
changed to use heap for anything that might be even a bit larger (which can
make it a bit slower).

It's interesting why the other compilers work fine with this, are they much
more frugal in their stack usage?

You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20170210/99738bef/attachment-0001.html>

More information about the intel-3d-bugs mailing list