On Thu, Nov 9, 2017 at 2:23 PM, Matt Turner <matts...@gmail.com> wrote:
> On Thu, Nov 2, 2017 at 3:54 PM, Jason Ekstrand <ja...@jlekstrand.net> > wrote: > > Register strides higher than 4 are uncommon but they can happen. For > > instance, if you have a 64-bit extract_u8 operation, we turn that into > > UB -> UQ MOV with a source stride of 8. Our previous calculation would > > try to generate a stride of <32;8,8>:ub which is invalid because the > > maximum horizontal stride is 4. To solve this problem, we instead use a > > stride of <8;1,0>. As noted in the comment, this does not work as a > > destination but that's ok as very few things actually generate that > > stride. > > Please put the tests you fixed in the commit message. It's not okay to > leave that out for all the reasons that I'm sure you know. > I didn't because the test passes before and after the patch. I guess I could have included that information though. > Looks like this doesn't work on CHV, BXT, GLK :( > > KHR-GL46.shader_ballot_tests.ShaderBallotBitmasks now fails on CHV, > BXT, GLK with: > > mov(8) g21<1>UQ g19<8,1,0>UB { align1 > 1Q }; > ERROR: Source and destination horizontal stride must equal and > a multiple of a qword when the execution type is 64-bit > ERROR: Vstride must be Width * Hstride when the execution type is > 64-bit > > Modulo the typo in the first error, I think both of these are correct. > I don't think we can extract_u8 to a 64-bit type on Atom :( > That's unfortunate... Quickly racking my brain, I don't see a slick way to implement that opcode. How would you feel about some late opt_algebraic lowering? > This is filed as https://bugs.freedesktop.org/show_bug.cgi?id=103628 >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev