[Mesa-dev] [PATCH] r600/sb: fix rotated register in while loop

Gert Wollny gw.fossdev at gmail.com
Wed Feb 14 15:26:31 UTC 2018


Am Mittwoch, den 14.02.2018, 17:18 +1000 schrieb Dave Airlie:
> From: Dave Airlie <airlied at redhat.com>
> 
> A bunch of CTS tests led me to write
> tests/shaders/ssa/fs-while-loop-rotate-value.shader_test
> which r600/sb always fell over on.
> 
> This patch fixes it, but I'll probably never be 100% sure why.

Unfortunately it shows quite a number of regressions against 
(git-b9d2ff05a6), in summary:

fixes:
   shaders/ssa/fs-while-loop-rotate-value
   spec/arb_enhanced_layouts/execution/component-layout/
      sso-vs-gs-fs-array-interleave

regressions:

crash with sb/sb_sched.cpp:931:process_fetch: 
   Assertion `f->parent->count() == 1' failed: 
  
spec/
   arb_arrays_of_arrays/execution/sampler/
        vs-struct-nonconst-non-opaque-members

spec/
   arb_gpu_shader5/execution/sampler_array_indexing/
        sampler-nonconst-2d
	sampler-nonconst-2d-array
	sampler-nonconst-2d-array-grad
	sampler-nonconst-2d-grad

Simply fail: 
spec/
   glsl-1.10/execution/variable-indexing/
        vs-output-array-float-index-wr
        vs-temp-array-mat2-col-rd
        vs-temp-array-mat2-index-col-rd
        vs-temp-mat2-col-rd
        vs-varying-array-mat2-index-col-rd
	vs-varying-mat2-col-rd

   glsl-1.20/execution/variable-indexing/
        vs-temp-array-mat2-col-rd
        vs-temp-mat2-col-rd
        vs-varying-array-mat2-index-col-rd
	vs-varying-array-mat3-col-row-wr
        vs-varying-array-mat3-col-wr
        vs-varying-mat2-col-rd

    
   glsl-120/execution/variable-indexing/
        vs-varying-array-mat3-col-row-wr
        vs-varying-array-mat3-col-wr
        
I tried to figure out goes wrong with vs-output-array-float-index-wr,
it is the vertex shader (#18 for me), but why it fails eludes me so
far. 

best, 
Gert 



> Anyways what appears to be happening is when gcm is scheduling
> the copy_movs used for phis, we have 4 copy_movs in the scheduling
> queue, one of them releases a new copy_mov and it gets pushed
> to the the front of the scheduling queue, but for correctness
> we rely on the previous copy_movs getting emitted first. This
> places copy_movs in order on the list.
> 
> So if the list is empty, it puts it at the front, if the list
> has just copy_movs in it, it goes to the end, otherwise
> we iterate the list and insert it between the copy_movs and
> subsequent instructions.
> 
> Signed-off-by: Dave Airlie <airlied at redhat.com>
> ---
>  src/gallium/drivers/r600/sb/sb_gcm.cpp | 19 +++++++++++++++++--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/sb/sb_gcm.cpp
> b/src/gallium/drivers/r600/sb/sb_gcm.cpp
> index 7776a10fc8..7b4df8bd52 100644
> --- a/src/gallium/drivers/r600/sb/sb_gcm.cpp
> +++ b/src/gallium/drivers/r600/sb/sb_gcm.cpp
> @@ -637,8 +637,23 @@ void gcm::add_ready(node *n) {
>  	sched_queue_id sq = sh.get_queue_id(n);
>  	if (n->flags & NF_SCHEDULE_EARLY)
>  		bu_ready_early[sq].push_back(n);
> -	else if (sq == SQ_ALU && n->is_copy_mov())
> -		bu_ready[sq].push_front(n);
> +	else if (sq == SQ_ALU && n->is_copy_mov()) {
> +		if (bu_ready[sq].empty())
> +			bu_ready[sq].push_front(n);
> +		else {
> +			bool inserted = false;
> +			for (sched_queue::iterator I =
> bu_ready[sq].begin(), E = bu_ready[sq].end(); I != E; I++) {
> +				node *a = *I;
> +				if (!a->is_copy_mov()) {
> +					bu_ready[sq].insert(I, n);
> +					inserted = true;
> +					break;
> +				}
> +			}
> +			if (!inserted)
> +				bu_ready[sq].push_back(n);
> +		}
> +	}
>  	else if (n->is_alu_inst()) {
>  		alu_node *a = static_cast<alu_node*>(n);
>  		if (a->bc.op_ptr->flags & AF_PRED && a->dst[2]) {


More information about the mesa-dev mailing list