<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body><a class="email" href="mailto:eero.t.tamminen@intel.com" title="Eero Tamminen <eero.t.tamminen@intel.com>"> Eero Tamminen</a> changed <a class="bz_bug_link bz_status_NEW " title="NEW - [i965] Compiler backend uses too much stack with Alien: Isolation" href="https://bugs.freedesktop.org/show_bug.cgi?id=93840">bug 93840</a> <table border="1" cellspacing="0" cellpadding="8"> <tr> <th>What</th> <th>Removed</th> <th>Added</th> </tr> <tr> <td style="text-align:right;">Summary</td> <td>[i965] Alien: Isolation fails with GL_ARB_compute_shader enabled </td> <td>[i965] Compiler backend uses too much stack with Alien: Isolation </td> </tr></table> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [i965] Compiler backend uses too much stack with Alien: Isolation" href="https://bugs.freedesktop.org/show_bug.cgi?id=93840#c21">Comment # 21</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [i965] Compiler backend uses too much stack with Alien: Isolation" href="https://bugs.freedesktop.org/show_bug.cgi?id=93840">bug 93840</a> from <a class="email" href="mailto:eero.t.tamminen@intel.com" title="Eero Tamminen <eero.t.tamminen@intel.com>"> Eero Tamminen</a> <pre>(In reply to Matt Turner from <a href="show_bug.cgi?id=93840#c14">comment #14</a>) > Created <a href="attachment.cgi?id=126122" name="attach_126122" title="patch">attachment 126122</a> <a href="attachment.cgi?id=126122&action=edit" title="patch">[details]</a> <a href='page.cgi?id=splinter.html&bug=93840&attachment=126122'>[review]</a> [review] > patch > > (In reply to Darius Spitznagel from <a href="show_bug.cgi?id=93840#c1">comment #1</a>) > > Created <a href="attachment.cgi?id=121746" name="attach_121746" title="Alien: Isolation GDB log">attachment 121746</a> <a href="attachment.cgi?id=121746&action=edit" title="Alien: Isolation GDB log">[details]</a> > > 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 ../../../../../../src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp:991 -> 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 Continuing. [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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>