Comment # 6
on bug 106533
from Michael Panzlaff
(In reply to Roland Scheidegger from comment #4) > You have the same tcl-less chipset? I'm sorry to say, but I don't really know what a tcl-less chipset is. I'm using a Dell Latitude D531. Perhaps an lspci output helps? 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RS690 Host Bridge 00:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RS690 PCI to PCI Bridge (Internal gfx) 00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RS690 PCI to PCI Bridge (PCI Express Port 1) 00:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RS690 PCI to PCI Bridge (PCI Express Port 2) 00:12.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 Non-Raid-5 SATA 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB (OHCI0) 00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB (OHCI1) 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB (OHCI2) 00:13.3 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB (OHCI3) 00:13.4 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB (OHCI4) 00:13.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600 USB Controller (EHCI) 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 14) 00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI] SB600 IDE 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB600 PCI to LPC Bridge 00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS690M [Radeon Xpress 1200/1250/1270] 03:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21) 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) 09:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5755M Gigabit Ethernet PCI Express (rev 02) 0b:00.0 Network controller: Broadcom Limited BCM4311 802.11a/b/g (rev 01) > This is also mesa 18.0? I'm just asking because according to the line > numbers (r300_render_stencilref.c:113) it's doing two-sided stencil > emulation, which I can't see how it could happen with the emulated clear > (which definitely doesn't enable two-sided stencil), so that looks a little > bit suspect. Although maybe the line numbers aren't quite accurate due to > optimization... I initially used mesa 18.0.? from Debian Unstable but my latest tests with the stacktrace we're made using mesa from the git repository (master). I sadly can't really help with the stencil stuff. I know a bit of OpenGL but I literally have no idea about the implementation behind it. > You could try setting (with a debug build) DRAW_USE_LLVM="0" and see if this > fixes the crash - and if it still crashes it should be easier to figure out > what pointer is zero. Still segfaults. Here is a stacktrace: #0 util_format_r32g32b32_float_fetch_rgba_float (dst=0x7fffffffde70, src="" i=0, j=0) at util/u_format_table.c:10080 #1 0x00007ffff24a9032 in generic_run_one (vert=0x4521aa0, instance_id=0, start_instance=0, elt=0, tg=<optimized out>) at translate/translate_generic.c:629 #2 generic_run (translate=0x49c8bc0, start=<optimized out>, count=<optimized out>, start_instance=0, instance_id=0, output_buffer=<optimized out>) at translate/translate_generic.c:723 #3 0x00007ffff244e040 in fetch (output=<optimized out>, fetch_info=<optimized out>, fetch= {void (char *, const struct draw_fetch_info *, struct pt_fetch *)} 0x7ffff244dec3 <fetch_pipeline_generic+131>) at draw/draw_pt_fetch_shade_pipeline.c:161 #4 fetch_pipeline_generic (middle=0x2bb8f60, fetch_info=fetch_info@entry=0x7fffffffe010, in_prim_info=in_prim_info@entry=0x7fffffffe030) at draw/draw_pt_fetch_shade_pipeline.c:268 #5 0x00007ffff244e48d in fetch_pipeline_linear_run (middle=<optimized out>, start=<optimized out>, count=<optimized out>, prim_flags=<optimized out>) at draw/draw_pt_fetch_shade_pipeline.c:426 #6 0x00007ffff245368a in vsplit_segment_simple_linear (vsplit=0x2bb63a0, vsplit=0x2bb63a0, icount=4, istart=0, flags=0) at draw/draw_pt_vsplit_tmp.h:226 #7 vsplit_run_linear (frontend=0x2bb63a0, start=0, count=4) at draw/draw_split_tmp.h:60 #8 0x00007ffff244b4a8 in draw_pt_arrays (draw=draw@entry=0x2ba3980, prim=6, start=0, count=count@entry=4) at draw/draw_pt.c:149 #9 0x00007ffff244b9c4 in draw_vbo (draw=0x2ba3980, info=0x7fffffffe150, info@entry=0x7fffffffe1f0) at draw/draw_pt.c:564 #10 0x00007ffff257a5c9 in r300_swtcl_draw_vbo (pipe=0x2b7aae0, info=0x7fffffffe1f0) at r300_render.c:862 #11 0x00007ffff2439de7 in cso_draw_arrays (cso=<optimized out>, mode=mode@entry=6, start=start@entry=0, count=count@entry=4) at cso_cache/cso_context.c:1724 #12 0x00007ffff222ec59 in st_draw_quad (st=st@entry=0x2d3a290, x0=x0@entry=-1, y0=y0@entry=-0.899999976, x1=x1@entry=1, y1=y1@entry=0.899999976, z=1, s0=s0@entry=0, t0=t0@entry=0, s1=s1@entry=0, t1=0, color=color@entry=0x2d1692c, num_instances=num_instances@entry=1) at state_tracker/st_draw.c:428 #13 0x00007ffff2213c39 in clear_with_quad (clear_buffers=<optimized out>, ctx=0x2d14ca0) at state_tracker/st_cb_clear.c:293 #14 st_Clear (ctx=0x2d14ca0, mask=2) at state_tracker/st_cb_clear.c:445 #15 0x000000000049e364 in ?? () #16 0x0000000000481fd3 in ?? () #17 0x000000000048359f in ?? () #18 0x00007ffff6c9aa87 in __libc_start_main (main=0x40e130, argc=1, argv=0x7fffffffe5f8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe5e8) at ../csu/libc-start.c:310 #19 0x000000000040f04a in ?? () > You could print out the shader (with a debug build) with > GALLIVM_DEBUG=tgsi,ir,asm to see what the assembly really might do. I think > though this is trying to read a vertex buffer (for position probably) which > just isn't there. I'll provide a new attachment with the output of that.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
