On Sun, 2010-08-01 at 00:55 -0700, Chia-I Wu wrote: > On Sat, Jul 31, 2010 at 7:10 AM, Zack Rusin <za...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
