Hello, here is a backtrace: Core was generated by `glretrace ./DyingLightGame.trace'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f2852895428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. [Current thread is 1 (Thread 0x7f2854cb48c0 (LWP 15940))] (gdb) bt #0 0x00007f2852895428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007f285289702a in __GI_abort () at abort.c:89 #2 0x00007f285288dbd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7f284f4fb62f "size % 4096 == 0", file=file@entry=0x7f284f4fb58f "brw_bufmgr.c", line=line@entry=405, function=function@entry=0x7f284f4fbc30 <__PRETTY_FUNCTION__.43658> "vma_alloc") at assert.c:92 #3 0x00007f285288dc82 in __GI___assert_fail (assertion=0x7f284f4fb62f "size % 4096 == 0", file=0x7f284f4fb58f "brw_bufmgr.c", line=405, function=0x7f284f4fbc30 <__PRETTY_FUNCTION__.43658> "vma_alloc") at assert.c:101 #4 0x00007f284ef43777 in vma_alloc (bufmgr=0x1414840, memzone=BRW_MEMZONE_OTHER, size=255726400, alignment=4096) at brw_bufmgr.c:405 #5 0x00007f284ef43ef7 in bo_alloc_internal (bufmgr=0x1414840, name=0x7f284f506370 "bufferobj", size=255726400, memzone=BRW_MEMZONE_OTHER, flags=0, tiling_mode=0, stride=0) at brw_bufmgr.c:652 #6 0x00007f284ef43ff7 in brw_bo_alloc (bufmgr=0x1414840, name=0x7f284f506370 "bufferobj", size=255726400, memzone=BRW_MEMZONE_OTHER) at brw_bufmgr.c:677 #7 0x00007f284ef88465 in alloc_buffer_object (brw=0x1598d80, intel_obj=0x1f9c68d0) at intel_buffer_objects.c:100 #8 0x00007f284ef88759 in brw_buffer_data (ctx=0x1598d80, target=34962, size=255726400, data=0x7f282f1b1010, usage=35044, storageFlags=259, obj=0x1f9c68d0) at intel_buffer_objects.c:210 #9 0x00007f284e9f33d7 in buffer_data (no_error=false, func=0x7f284f41a17c "glBufferData", usage=35044, data=0x7f282f1b1010, size=255726400, target=34962, bufObj=0x1f9c68d0, ctx=0x1598d80) at main/bufferobj.c:2065 #10 buffer_data_error (ctx=0x1598d80, bufObj=0x1f9c68d0, target=34962, size=255726400, data=0x7f282f1b1010, usage=35044, func=0x7f284f41a17c "glBufferData") at main/bufferobj.c:2091 #11 0x00007f284e9f37e3 in _mesa_buffer_data (ctx=0x1598d80, bufObj=0x1f9c68d0, target=34962, size=255726400, data=0x7f282f1b1010, usage=35044, func=0x7f284f41a17c "glBufferData") at main/bufferobj.c:2107 #12 0x00007f284e9f38cf in _mesa_BufferData (target=34962, size=255726400, data=0x7f282f1b1010, usage=35044) at main/bufferobj.c:2132 #13 0x00000000004c910b in ?? () #14 0x000000000040bff4 in ?? () #15 0x000000000040c61c in ?? () #16 0x0000000000407e95 in ?? () #17 0x00007f2852880830 in __libc_start_main (main=0x407810, argc=2, argv=0x7ffc8d9394b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc8d9394a8) at ../csu/libc-start.c:291 #18 0x0000000000409999 in _start ()
On Tue, Jul 24, 2018 at 8:43 PM, Lionel Landwerlin < lionel.g.landwer...@intel.com> wrote: > On 24/07/18 18:34, Kenneth Graunke wrote: > >> On Tuesday, July 24, 2018 5:34:57 AM PDT Lionel Landwerlin wrote: >> >>> That looks correct to me (and we do the same in Anv). >>> Also a bit baffled that we haven't run into issues earlier :( >>> >>> But would be good to have Ken's Rb too. >>> >>> Thanks a lot! >>> >>> Reviewed-by: Lionel Landwerlin <lionel.g.landwer...@intel.com> >>> >> Yeah, this is probably for the best...we used to just ask the kernel >> for memory and it would do this for us. Now that we're doing it >> ourselves, we ought to be defensive here. >> >> Reviewed-by: Kenneth Graunke <kenn...@whitecape.org> >> >> But I agree with Chris, I'm surprised that this would actually fix >> anything...all of our allocations ought to multiples of PAGE_SIZE, >> so unless we're starting at a funny address, they ought to remain >> that way... >> >> I wonder if this isn't papering over another bug. >> > > Sergii, > > If you can reproduce this bug locally, would you mind adding > > assert(size % 4096 == 0); > > at the top of vma_alloc() and see if it hits the asserts. > Having a backtrace would be great :) > > Thanks a lot, > > - > Lionel > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- Sergii Romantsov GlobalLogic Inc. www.globallogic.com
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev