[Mesa-dev] [Bug 94522] llvmpipe crash in rendering on Atom

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94522

--- Comment #9 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to comicfans44 from comment #8)
> (In reply to Roland Scheidegger from comment #4)
> > 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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160315/9f3826e1/attachment.html>