KHR-GL45.shader_ballot_tests.ShaderBallotBitmasks hits an assertion failure in the EU validator: cts-runner: compiler/brw_reg_type.c:125: brw_hw_type_to_reg_type: Assertion `!"not reached"' failed. It's trying to find an immediate of HW type 15. This is compiling a SIMD8 VS. I know Jason has a bunch of patches out related to ballot, perhaps one of them fixes it?
Yes, I think one of the patches I already reviewed from Jason's series fixes this (not sure why he resent already-reviewed patches in his huge series): [PATCH 27/44] intel/eu/validate: Look up types on demand in execution_type()
I just pushed the patch: commit d496780fb2c7f2cf0e32b6a79dc528e5156dfcb3 Author: Jason Ekstrand <jason.ekstrand@intel.com> Date: Thu Aug 31 15:41:43 2017 -0700 intel/eu/validate: Look up types on demand in execution_type() We are looking up the execution type prior to checking how many sources we have. This leads to looking for a type for src1 on MOV instructions which is bogus. On BDW+, the src1 register type overlaps with the 64-bit immediate and causes us problems. Reviewed-by: Matt Turner <mattst88@gmail.com> Cc: mesa-stable@lists.freedesktop.org Does that fix it?
It fixes the assertion, but the test still fails. Changing the title accordingly.
Seems like the gl_SubGroup??MaskARB is somewhat wrong.
This regressed back to hitting an assertion failure with Matt's commit 2572c2771d0cab0b9bc489d354ede44dfc88547b (i965: Validate "Special Requirements for Handling Double Precision Data Types"). Unfortunately, he had no way to know that because we don't run the modern CTS in the CI yet. It's a trivial fix, I'll send a patch shortly.
(In reply to Kenneth Graunke from comment #5) > This regressed back to hitting an assertion failure with Matt's commit > 2572c2771d0cab0b9bc489d354ede44dfc88547b (i965: Validate "Special > Requirements for Handling Double Precision Data Types"). Unfortunately, he > had no way to know that because we don't run the modern CTS in the CI yet. > > It's a trivial fix, I'll send a patch shortly. commit 03087686ffb8c638831256fd17c124d250d7238b Author: Kenneth Graunke <kenneth@whitecape.org> Date: Sat Oct 7 00:14:34 2017 -0700 i965: Don't try to decode types for non-existent src1.
(In reply to Matt Turner from comment #6) > (In reply to Kenneth Graunke from comment #5) > > This regressed back to hitting an assertion failure with Matt's commit > > 2572c2771d0cab0b9bc489d354ede44dfc88547b (i965: Validate "Special > > Requirements for Handling Double Precision Data Types"). Unfortunately, he > > had no way to know that because we don't run the modern CTS in the CI yet. > > > > It's a trivial fix, I'll send a patch shortly. > > commit 03087686ffb8c638831256fd17c124d250d7238b > Author: Kenneth Graunke <kenneth@whitecape.org> > Date: Sat Oct 7 00:14:34 2017 -0700 > > i965: Don't try to decode types for non-existent src1. This commit landed in upstream, but the test still fails.
To be clear, the patch that Juan refers to did indeed fix the regression which caused the test to *assert*. So now it is back to the failure state, as it was for Ken's comment #3.
Yup, assert -> fail -> assert -> fail. One day we will pass, I'm sure of it! :) Feel free to look at it though, I'm not currently working on this.
I’ve sent some patches for this here: https://patchwork.freedesktop.org/series/32918/ and here: https://patchwork.freedesktop.org/patch/185574/
I’ve pushed the first Mesa patch and the piglit patch thanks to review from Jason and Matt. I’ll leave the other patches because Jason has a series that will make it unnecessary.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.