[Mesa-dev] [PATCH 2/4] gallium: add initial support for conservative rasterization

[Marek Olšák]

On Fri, Mar 23, 2018 at 8:54 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> On Fri, Mar 23, 2018 at 8:51 PM, Marek Olšák <maraeo at gmail.com> wrote:
> > diff --git a/src/gallium/include/pipe/p_state.h
> > b/src/gallium/include/pipe/p_state.h
> >>
> >> index 4dce399f84..913a79faee 100644
> >> --- a/src/gallium/include/pipe/p_state.h
> >> +++ b/src/gallium/include/pipe/p_state.h
> >> @@ -113,6 +113,7 @@ struct pipe_rasterizer_state
> >>     unsigned line_smooth:1;
> >>     unsigned line_stipple_enable:1;
> >>     unsigned line_last_pixel:1;
> >> +   unsigned conservative_raster_mode:2; /**< PIPE_CONSERVATIVE_RASTER_x
> >> */
> >>
> >>     /**
> >>      * Use the first vertex of a primitive as the provoking vertex for
> >> @@ -186,6 +187,7 @@ struct pipe_rasterizer_state
> >>     float offset_units;
> >>     float offset_scale;
> >>     float offset_clamp;
> >> +   float conservative_raster_dilate;
> >>  };
> >>
> >>
> >> @@ -199,6 +201,10 @@ struct pipe_viewport_state
> >>  {
> >>     float scale[3];
> >>     float translate[3];
> >> +   /*
> >> +    * Conservative rasterization subpixel precision bias in bits
> >> +    */
> >> +   uint16_t subpixel_precision[2];
> >
> >
> > Actually, there is one thing that I disagree with. pipe_viewport_state is
> > per-viewport and there are up to 16 viewports, but the extensions don't
> > allow per-viewport settings of subpixel_precision. The obvious thing to
> do
> > is to add a new pipe_context function that only sets subpixel_precision,
> but
> > how about this:
> >
> > Would it be possible to move all the new states into a new CSO:
> > pipe_conservative_raster_state?
>
> FWIW the hardware does support this per viewport. But you're right -
> that level of detail is not exposed in GL. I think gallium tends to be
> closer to the hw, but I'd be fine with moving this out if you're
> concerned about context/etc size.
>

Yeah, it could be uint8_t subpixel_precision[16] in the new CSO in the
future, but I don't see a reason for it to be 16x now when no code uses it.
uint8_t seems enough for 2 4-bit values since nvc0 only allows values
between 0 and 8.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180323/b2527683/attachment.html>