[Mesa-dev] [PATCH v3 06/13] intel/isl: Add support to emit clear value address.

Jordan Justen jordan.l.justen at intel.com
Tue Feb 27 04:12:15 UTC 2018

On 2018-02-26 17:08:12, Jason Ekstrand wrote:
> On Mon, Feb 26, 2018 at 1:14 PM, Jordan Justen <jordan.l.justen at intel.com>
> wrote:
> > On 2018-02-21 13:45:15, Rafael Antognolli wrote:
> > > +   bool use_clear_address;
> >
> > I'm still wondering about this field. I think at the end we can just a
> > assume that if gen >= 10 and aux_usage != ISL_AUX_USAGE_NONE, then
> > we'll use the address.
> >
> That's not going to work if we want to turn this on for blorp, anv, and
> i965 separately.

I guess this goes to the point I mentioned below. Maybe it make it
easier to break it up for enabling it. (I'm not certain that we
couldn't slice it up another way, but the argument seems fine.)

But, after that, is it needed? If it's alway enabled when gen >= 10
and aux_usage != ISL_AUX_USAGE_NONE, then once everything is in place,
then isl can easily check for that condition, and there's no purpose
for use_clear_address. Correct?

I also wonder if clear_address is needed in the info struct. It did
not look like blorp set it by the end of the series, yet blorp was
enabling the feature. (I'm guessing that the reloc must be handing the
aux buf offset for blorp.)


> > I think you mentioned that it could be tough implement the support in
> > steps if we had an all or nothing enaling of the address usage. But,
> > does that mean that at the end of your series you could add a patch to
> > remove this `use_clear_address` field?
> >
> > Maybe as a test in jenkins, you could add a patch that asserts that if
> > gen >= 10 and there is an aux_buffer, then use_clear_address==true in
> > your current series.
> >
> > -Jordan

More information about the mesa-dev mailing list