Bug 29404

Summary:	"Cannot yet select" LLVM error with r300g, softpipe and llvmpipe
Product:	Mesa	Reporter:	steckdenis
Component:	Other	Assignee:	mesa-dev
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	LLVM's SelectionDAG when trying to run Neverball with r300g /proc/cpuinfo file Output from LLVM when trying to run Neverball Output of glxgears when running with llvmpipe

Description steckdenis 2010-08-05 00:43:11 UTC

Created attachment 37581 [details]
LLVM's SelectionDAG when trying to run Neverball with r300g

Hello,

I use mesa git (commit "glx: Move deref after NULL check", Wed Aug 4 12:50:36 2010 -0400) and LLVM svn 110215.

When I try to test the r300g driver, or the llvmpipe one, a "Cannot yet select" error message is output to the console by LLVM. It happens when I run glxgears or any other 3D program (extreme tux racer, neverball, super tux kart). I attached the complete output of the LLVM error when I run neverball, because the output is way larger with the others.

The first line is always the same : it's always a "f32 = add f32 f32" pattern that causes this bug.

I use an AMD Athlon 64 L110 (1,2Ghz, single core, mobile) with the MMX, 3DNOW, SSE and SSE2 instruction sets. I also attached the contents of /proc/cpuinfo to this bug. My graphics card is an ATI Radeon X1270 (RS690m, with 256MB of shared memory, and 128MB of sideport memory).

lspci of the card : 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]

Uname -a : Linux my-laptop 2.6.35 #11 SMP PREEMPT Wed Aug 4 11:47:54 CEST 2010
x86_64 AMD Athlon(tm) Processor L110 AuthenticAMD GNU/Linux. I run this kernel with ArchLinux, Xorg Server 1.8.1.902, libdrm git and mesa git.

I also reported this bug in the LLVM bugtracker : http://llvm.org/bugs/show_bug.cgi?id=7813 .

I add that I was never able to use any LLVM-based Gallium rendering with this computer I bought four months ago. It worked fine before on my other computer : an AMD Athlon 64 X2 4000+ (2,4Ghz, MMX, 3DNOW, SSE, SSE2 (same instruction sets as the ones I have now)) and an ATI Radeon X1250 (RS690, 128MB shared memory, no sideport).

Btw, is it possible to ask Draw or any other Gallium module to output its LLVM assembly (in the source form, if possible) before trying to assemble it ? It will greatly help the LLVM devs to have a test for this bug.

Thanks.

Comment 1 steckdenis 2010-08-05 00:44:24 UTC

Created attachment 37582 [details]
/proc/cpuinfo file

Comment 2 steckdenis 2010-08-05 10:05:47 UTC

Created attachment 37592 [details]
Output from LLVM when trying to run Neverball

Hello,

I attach to this bug the output of Gallium and LLVM when trying to run neverball. I also saw the bug #29407 (and commented it). It's possible that that bug has something to do with this one. Gallium seems to wrongly manage the type of the instructions it uses.

I also tried the patch found in the third comment of #29407. Unfortunately, I could not test with r300g because recent changes in Mesa (the changes of today I think) broke the memory allocator ("util/u_mempool.c:89:util_mempool_malloc_st: Assertion `block->magic == 0xcafe4321' failed."). I tried with llvmpipe, and I didn't encountered this assertion.

Instead, the assert here is raised (src/gallium/drivers/llvmpipe/lp_state_fs.c:820):

#ifdef DEBUG
   if(LLVMVerifyFunction(function, LLVMPrintMessageAction)) {
      if (1)
         lp_debug_dump_value(function);
      abort();
   }
#endif

The stack trace given by GDB is :

#0  0x00007ffff727d565 in raise () from /lib/libc.so.6
#1  0x00007ffff727e9e6 in abort () from /lib/libc.so.6
#2  0x00007ffff49dac57 in generate_fragment (lp=<value optimized out>, shader=0x400088, variant=0x1fdde20, partial_mask=0)
    at lp_state_fs.c:695
#3  0x00007ffff49db496 in generate_variant (lp=0x61d2a0) at lp_state_fs.c:820
#4  llvmpipe_update_fs (lp=0x61d2a0) at lp_state_fs.c:1157
#5  0x00007ffff49d8488 in llvmpipe_update_derived (llvmpipe=0x61d2a0) at lp_state_derived.c:171
#6  0x00007ffff49cd34a in llvmpipe_draw_vbo (pipe=0x61d2a0, info=0x7fffffffdbc0) at lp_draw_arrays.c:60
#7  0x00007ffff4abd0f8 in st_draw_vbo (ctx=0x1f2feb0, arrays=<value optimized out>, prims=0x1fbda90, nr_prims=2, ib=0x0, 
    index_bounds_valid=<value optimized out>, min_index=0, max_index=161) at state_tracker/st_draw.c:722
#8  0x00007ffff4ae9419 in vbo_save_playback_vertex_list (ctx=0x1f2feb0, data=0x1fbd2f8) at vbo/vbo_save_draw.c:287
#9  0x00007ffff4a0a8da in ext_opcode_execute (ctx=0x1f2feb0, list=<value optimized out>) at main/dlist.c:533
#10 execute_list (ctx=0x1f2feb0, list=<value optimized out>) at main/dlist.c:6876
#11 0x00007ffff4a0d352 in _mesa_CallList (list=1) at main/dlist.c:8133

The program produces output. I will attach it after sending this comment.

Comment 3 steckdenis 2010-08-05 10:06:26 UTC

Created attachment 37593 [details]
Output of glxgears when running with llvmpipe

Comment 4 Jose Fonseca 2010-08-09 09:43:37 UTC

I believe this covers the same problem as bug 29407. Although chronologically first, marking this one as duplicate as the there's more detail on 29407.

Thanks for your testing steckdenis.

*** This bug has been marked as a duplicate of bug 29407 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.