On Thu, Jul 5, 2018 at 6:34 PM Caio Marcelo de Oliveira Filho < caio.olive...@intel.com> wrote:
> On Wed, Jun 27, 2018 at 07:00:56PM -0700, Jason Ekstrand wrote: > > The back-end compiler emits the number of color writes specified by > > wm_prog_key::nr_color_regions regardless of what nir_store_outputs we > > have. Once we've gone through and figured out which render targets > > actually exist and are written by the shader, we should restrict the key > > to avoid extra RT write messages. > > --- > > src/intel/vulkan/anv_pipeline.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/src/intel/vulkan/anv_pipeline.c > b/src/intel/vulkan/anv_pipeline.c > > index 523202cf3d9..6a27d305dbc 100644 > > --- a/src/intel/vulkan/anv_pipeline.c > > +++ b/src/intel/vulkan/anv_pipeline.c > > @@ -965,6 +965,11 @@ anv_pipeline_compile_fs(struct anv_pipeline > *pipeline, > > var->data.location = rt_to_bindings[rt] + FRAG_RESULT_DATA0; > > } > > > > + /* Now that we've determined the actual number of render targets, > adjust > > + * the key accordingly. > > + */ > > + key.nr_color_regions = num_rts; > > + > > Question: earlier in the code we call > > populate_wm_prog_key(pipeline, info, &key); > > which does > > key->nr_color_regions = pipeline->subpass->color_count; > > key->replicate_alpha = key->nr_color_regions > 1 && > info->pMultisampleState && > info->pMultisampleState->alphaToCoverageEnable; > > so key->replicate_alpha is calculated based on the old value. Should > this be (re)calculated using the new value? > We could but it would have no effect. 100% of the uses of replicate_alpha in the back-end have it ANDed with inst->target > 0. --Jason
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
