On Die, 2013-01-22 at 16:10 +0100, Tom Stellard wrote: > On Tue, Jan 22, 2013 at 04:06:05PM +0100, Michel Dänzer wrote: > > On Mon, 2013-01-21 at 23:03 +0100, Tom Stellard wrote: > > > > > > I don't think we emit the int_AMDGPU_mul intrinsic anymore, but it > > > probably > > > doesn't hurt to keep it around until we sort out all of the legacy vs > > > non-legacy > > > instruction issues. > > > > Right. BTW, emitting int_AMDGPU_mad for TGSI_OPCODE_MAD doesn't fix the > > glxgears problem I reported on IRC with current master (in contrast to > > 0ad1fefd6951aa47ab58a41dc9ee73083cbcf85c, where that problem was > > introduced). Looks like the intrinsic ends up generating cmp/select > > pairs instead of V_MAD in some cases now, which breaks somehow. > > > > > > In the meantime, I've come to realize that this patch breaks a bunch of > > piglit tests in the glsl-1.[12]0/execution/variable-indexing groups (I > > previously thought those tests were broken by the array uniform related > > changes). I'm attaching a diff of the generated code. Not sure if this > > is some kind of bad interaction between this change and the control flow > > code, or another instance of tests which passed accidentally. > > > > Do these tests use indirect addressing? If so, they were probably passing > by chance.
tgsi_shader_info::indirect_files is 0 for all shaders. So I think this patch shouldn't go in without more investigation why it breaks these tests. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
