<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - llvmpipe crash in rendering on Atom" href="https://bugs.freedesktop.org/show_bug.cgi?id=94522#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - llvmpipe crash in rendering on Atom" href="https://bugs.freedesktop.org/show_bug.cgi?id=94522">bug 94522</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>(In reply to comicfans44 from <a href="show_bug.cgi?id=94522#c8">comment #8</a>) > (In reply to Roland Scheidegger from <a href="show_bug.cgi?id=94522#c4">comment #4</a>) > > So, it crashed in the jit fragment shader code. > > Could you tell what the fb size was (the values from scene->fb in > > lp_rast_shade_tile, possibly the ones from the (first) color and zbuffer > > themselves)? I was actually wondering at some point what really ensures if > > buffers have sufficient alignment - buffers allocated within llvmpipe will > > always have that, but the front/back buffers are allocated - elsewhere (they > > need to be allocated to 4x4 alignment). > > my laptop is GMA500, resolution 1024x600 > > scene->fb value in crash stack > {width = 1024, height = 600, nr_cbufs = 1, cbufs = {0x8141e28, 0x0, 0x0, > 0x0, 0x0, 0x0, 0x0, 0x0}, zsbuf = 0x0} > > so maybe cbufs[0] isn't 16 byte aligned? Well the regs below seem to indicate the access was aligned, and width/height are ok too. > > > Other than that I'm not sure what the problem could be. You could try some > > x/i variant to get the disassembly, which should tell you if it was > > framebuffer access or not (as fb accesses are towards the end of the jit > > code, and they'll show some fairly typical patterns). > > crash address and asm: > 0xb755e633 movdqa %ecx,%eax,1),%xmm2 > 0xb755e638 movdqa %xmm7,%xmm1 > 0xb755e63c movdqa %xmm2,0x30(%esp > 0xb755e642 movapd %xmm0,0x80(%esp) > 0xb755e64b movdqa %xmm2,%xmm0 > 0xb755e64f pxor 0xb7fc2080,%xmm1 > 0xb755e657 punpcklbw %xmm3,%xmm0 > 0xb755e65b movdqa %xmm1,%xmm7 > 0xb755e65f punpckhbw %xmm3,%xmm1 > 0xb755e663 punpcklbw %xmm3,%xmm7 > 0xb755e667 pmullw %xmm0,%xmm7 > 0xb755e66b movdqa %xmm2,%xmm0 > 0xb755e66f punpckhbw %xmm3,%xmm0 > 0xb755e673 pxor %xmm3,%xmm3 > 0xb755e677 pmullw %xmm0,%xmm1 > 0xb755e67b cvtps2dq 0x130(%esp),%xmm0 > 0xb755e684 movdqa %xmm7,0x100(%esp) > 0xb755e68d movaps 0xb7fc2040,%xmm7 > 0xb755e694 movdqa %xmm1,0x140(%esp) That could be fb blend (due to the pmullw) but it's difficult to tell (could be texturing too). In your original post it actually looks like gdb couldn't access the color buffer but I'm not sure if that's just gdb not quite figuring out the correct address (there's lots of optimized out stuff too so probably not proper debug build?) or if that's really because the address isn't accessible. If it's the latter that would suggest the buffer simply may have disappeared (buffers allocated by llvmpipe are refcounted, but back buffers are allocated and freed elsewhere, so outside of llvmpipe's control. In any case, this indeed looks like a separate issue to the bug Stephane pointed out, and in contrast to that issue I don't think anything really changed there directly in llvmpipe for ages. Could you bisect?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>