[Mesa-dev] [PATCH 17/64] isl/state: Refactor the setup of clear colors
Chad Versace
chad.versace at intel.com
Thu Jun 16 18:18:02 UTC 2016
On Thu 16 Jun 2016, Jason Ekstrand wrote:
> On Thu, Jun 16, 2016 at 11:05 AM, Chad Versace <chad.versace at intel.com>
> wrote:
>
> > On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > > This commit switches clear colors to use #if's instead of a C if. This
> > > lets us properly handle SNB where the clear color field doesn't exist.
> > > ---
> > > src/intel/isl/isl_surface_state.c | 44
> > +++++++++++++++++++--------------------
> > > 1 file changed, 22 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/src/intel/isl/isl_surface_state.c
> > b/src/intel/isl/isl_surface_state.c
> > > index db90936..aa720d8 100644
> > > --- a/src/intel/isl/isl_surface_state.c
> > > +++ b/src/intel/isl/isl_surface_state.c
> > > @@ -372,31 +372,31 @@ isl_genX(surf_fill_state_s)(const struct
> > isl_device *dev, void *state,
> > > }
> > > #endif
> > >
> > > - if (GEN_GEN <= 8) {
> > > - /* Prior to Sky Lake, we only have one bit for the clear color
> > which
> > > - * gives us 0 or 1 in whatever the surface's format happens to be.
> > > - */
> > > - if (isl_format_has_int_channel(info->view->format)) {
> > > - for (unsigned i = 0; i < 4; i++) {
> > > - assert(info->clear_color.u32[i] == 0 ||
> > > - info->clear_color.u32[i] == 1);
> > > - }
> > > - } else {
> > > - for (unsigned i = 0; i < 4; i++) {
> > > - assert(info->clear_color.f32[i] == 0.0f ||
> > > - info->clear_color.f32[i] == 1.0f);
> > > - }
> > > +#if GEN_GEN >= 9
> > > + s.RedClearColor = info->clear_color.u32[0];
> > > + s.GreenClearColor = info->clear_color.u32[1];
> > > + s.BlueClearColor = info->clear_color.u32[2];
> > > + s.AlphaClearColor = info->clear_color.u32[3];
> >
> > The gen9 block looks good.
> >
> > > +#elif GEN_GEN >= 7
> > > + /* Prior to Sky Lake, we only have one bit for the clear color which
> > > + * gives us 0 or 1 in whatever the surface's format happens to be.
> > > + */
> > > + if (isl_format_has_int_channel(info->view->format)) {
> > > + for (unsigned i = 0; i < 4; i++) {
> > > + assert(info->clear_color.u32[i] == 0 ||
> > > + info->clear_color.u32[i] == 1);
> > > }
> > > - s.RedClearColor = info->clear_color.u32[0] != 0;
> > > - s.GreenClearColor = info->clear_color.u32[1] != 0;
> > > - s.BlueClearColor = info->clear_color.u32[2] != 0;
> > > - s.AlphaClearColor = info->clear_color.u32[3] != 0;
> > > } else {
> > > - s.RedClearColor = info->clear_color.u32[0];
> > > - s.GreenClearColor = info->clear_color.u32[1];
> > > - s.BlueClearColor = info->clear_color.u32[2];
> > > - s.AlphaClearColor = info->clear_color.u32[3];
> > > + for (unsigned i = 0; i < 4; i++) {
> > > + assert(info->clear_color.f32[i] == 0.0f ||
> > > + info->clear_color.f32[i] == 1.0f);
> > > + }
> > > }
> > > + s.RedClearColor = info->clear_color.u32[0] != 0;
> > > + s.GreenClearColor = info->clear_color.u32[1] != 0;
> > > + s.BlueClearColor = info->clear_color.u32[2] != 0;
> > > + s.AlphaClearColor = info->clear_color.u32[3] != 0;
> >
> > This block looks broken, both pre- and post-patch. Is this code actually
> > used anywhere in the Vulkan driver? I expect not, as the driver doesn't
> > use the CCS yet.
> >
> > In the for loop, the code asserts clear_color.f32[i] is 0.0f or 1.0f.
> > I believe the assignment expressions should also use f32, not u32. That
> > is,
> >
> > s.RedClearColor = info->clear_color.f32[0] != 0.0f;
> > s.GreenClearColor = info->clear_color.f32[1] != 0.0f;
> > s.BlueClearColor = info->clear_color.f32[2] != 0.0f;
> > s.AlphaClearColor = info->clear_color.f32[3] != 0.0f;
> >
>
> Right. That's probably more correct but given that 0.0f is 0u as bits, I
> don't know if it actually matters. Maybe for -0?
Yes, we should do it for -0. The user inputs to glClearColor may be
calculated in convoluted ways that produce -0.
Also, I think
s.RedClearColor = info->clear_color.f32[0] == 1.0f
is clearer, but it's not important.
More information about the mesa-dev
mailing list