[Mesa-dev] gallium bound checking patch broke r600g in weird way

[Keith Whitwell]

On Sun, 2010-08-01 at 00:55 -0700, Chia-I Wu wrote:
> On Sat, Jul 31, 2010 at 7:10 AM, Zack Rusin <zackr at vmware.com> wrote:
> > On Friday 30 July 2010 17:51:21 Jakob Bornecrantz wrote:
> >> On 30 jul 2010, at 14.02, Jakob Bornecrantz wrote:
> >> > On 30 jul 2010, at 13.32, Brian Paul wrote:
> >> >> On 07/30/2010 12:38 PM, Jerome Glisse wrote:
> >> >>> Hi Brian,
> >> >>>
> >> >>> I am facing a strange segfault with r600g on top of lastest git,
> >> >>> git bisect pointed to gallium: implement bounds checking for
> >> >>> constant buffers
> >> >>> My feeling is that it should only affect software pipeline but
> >> >>> somehow r600g seem to take different path now, attached if full
> >> >>> but i can't make much sense out of it, do you have a clue on what
> >> >>> might went wrong ?
> >> >>
> >> >> I took a quick look but didn't find anything.
> >> >>
> >> >> Maybe try a make clean and rebuild just in case?
> >> >
> >> > I'm getting the same with swrastg on in 32bit VM, "git clean -fdx":ed
> >> > even.
> >>
> >> Me and Jerome tracked it down to the SSE code generated by the tgsi
> >> runtime. Exporting GALLIUM_NOSSE avoids the bug. I'm guessing you are
> >> either using LLVM or 64bit which doesn't have SSE codegen.
> I am having this warning
> 
>   draw/draw_vs_sse.c: In function ‘draw_create_vs_sse’:
>   draw/draw_vs_sse.c:172: warning: assignment from incompatible pointer type
> 
> It seems the prototype of vs_sse_run_linear was not updated in the commit and
> the function body is accessing the wrong arguments.
> > We actually talked about removing the SSE code from draw. We have the
> > interpreted paths (safe and easier to debug) and the LLVM paths (for
> > performance) and the no one is too keen to maintain the SSE code.
> >
> > Unless someone would like to maintain the SSE paths if I'll have a bit of time
> > I'm probably going to remove them next week. They'll be still in the git
> > history if someone will ever want to bring them back but right now they tend
> > to crash a bit (like in this case) which is more trouble than it's worth.
> Yeah, that sounds good.  This is not the first time (#28752) the SSE
> path gives weird bugs.
> 

I'm very happy to see that code go away also.  

I'd also be happy to see a stronger dependency on llvm -- eg expect it
by default in the build and require a flag or special option to build
without it.

Kieth