[Mesa-dev] [PIGLIT,radeonsi] crash in spec/glsl-1.50/execution/geometry/max-input-components fixed (was: crash in spec/glsl-1.50/execution/geometry/max-input-components – who's bug is it?)

[Tom Stellard]

On Fri, Apr 18, 2014 at 06:59:37PM +0200, Kai Wasserbäch wrote:
> Hi there,
> Tom Stellard schrieb am 16.04.2014 17:07:
> > On Wed, Apr 16, 2014 at 02:36:19PM +0200, Kai Wasserbäch wrote:
> >> Michel Dänzer schrieb am 15.04.2014 09:27:
> >>> On 23.03.2014 04:53, Kai Wasserbäch wrote:
> >>>> Dear Mesa devs,
> >>>> I'm not sure whether this is a bug in Mesa, LLVM or in eglibc. The crash happens
> >>>> in _int_malloc, but since that is certainly one of the more often used
> >>>> functions, I'm not yet convinced, the fault lies indeed with eglibc.
> >>>>
> >>>> Therefore I'm attaching the full backtrace of the crash in
> >>>> spec/glsl-1.50/execution/geometry/max-input-components (it takes a very long
> >>>> time until the crash actually happens, Piglit recorded an execution time of
> >>>> 1538.0506579875946) and hope you can point me to the right bug tracker.
> >>>>
> >>>> I'm unable to tell, whether this is a regression or not, since today was the
> >>>> first time I was able to run a full Piglit quick test, without crashing my X on
> >>>> this machine with the radeonsi.
> >>>
> >>> It's not a regression. If you build LLVM with assertions enabled, you get:
> >>>
> >>> shader_runner:
> >>> /home/daenzer/src/llvm-git/llvm/lib/CodeGen/RegAllocGreedy.cpp:2268:
> >>> unsigned int
> >>> {anonymous}::RAGreedy::selectOrSplitImpl(llvm::LiveInterval&,
> >>> llvm::SmallVectorImpl<unsigned int>&,
> >>> {anonymous}::RAGreedy::SmallVirtRegSet&, unsigned int): Assertion
> >>> `NewVRegs.empty() && "Cannot append to existing NewVRegs"' failed.
> >>>
> >>> So this is an LLVM issue. It might be worth testing if Tom's register
> >>> spilling patches help.
> >>
> >> Can you point me to those patches? Preferrably as a branch, but ML is ok as well.
> >>
> > 
> > Here is the branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes
> 
> I've just rerun the Piglit test
> (spec/glsl-1.50/execution/geometry/max-input-components) with the patches from
> the si-spill-fixes branch (I needed to massage them a bit into applying on top
> of LLVM's SVN revision 206583, but that was straight forward enough) and can
> report, that the crash is gone. The test (still) fails, however:
> 
> $ gdb --args <PIGLIT-DIR>/build/bin/shader_runner
> <PIGLIT-DIR>/local.git/tests/spec/glsl-1.50/execution/geometry/max-input-components.shader_test
> -auto
> [GNU GDB boilerplate]
> Reading symbols from <PIGLIT-DIR>/build/bin/shader_runner...done.
> (gdb) r
> Starting program: <PIGLIT-DIR>/build/bin/shader_runner
> <PIGLIT-DIR>/local.git/tests/spec/glsl-1.50/execution/geometry/max-input-components.shader_test
> -auto
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7ffff0081700 (LWP 24909)]
> Probe color at (0,0)
>   Expected: 0.000000 1.000000 0.000000 1.000000
>   Observed: 0.000000 0.000000 0.000000 0.000000
> PIGLIT: {'result': 'fail' }
> [Thread 0x7ffff0081700 (LWP 24909) exited]
> [Inferior 1 (process 24905) exited with code 01]
> 
> 
> The stack used for this test is a bit farther ahead as well, in case that makes
> a difference, I'm detailing it below:
> GPU: "PITCAIRN" (ChipID = 0x6819)
> Linux: 3.14.0
> libdrm: Git:master/libdrm-2.4.53
> LLVM: SVN:trunk/r206583
> libclc: Git:master/1e278a7b04
> Mesa: Git:master/352e06ddea
> GLAMOR: Git:master/a4fbc7732a (Standalone)
> DDX: Git:master/ea6d0affe5
> X: 2:1.15.0.901-1
> 
> Thank you for pointing me in the right direction; if you should need me to run
> another test, please let me know.
>

Thanks for tracking this down.  I've been trying to find a good test
case for register spilling and this looks like it might be it.  Most of
the register spilling bugs come from proprietary games that I don't have
access to.  I will try to look at this on Monday.

> Cheers,
> Kai
> 
> P.S.: Any idea, when the si-spill-fixes branch is going to land upstream?
> 

As soon as I can verify that it is working.

-Tom

> 
> 
> -- 
> 
> Kai Wasserbäch (Kai Wasserbaech)
> 
> E-Mail: kai at dev.carbon-project.org
>