[Mesa-dev] [PATCH v2] intel/ppgtt: memory address alignment

[Sergii Romantsov]

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 at 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 at 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 at entry=0x7f284f4fb62f "size % 4096 == 0",
file=file at entry=0x7f284f4fb58f
"brw_bufmgr.c", line=line at entry=405,
    function=function at 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.landwerlin at 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.landwerlin at 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 <kenneth at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
Sergii Romantsov
GlobalLogic Inc.
www.globallogic.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180725/15a3a3e0/attachment-0001.html>