[Mesa-dev] [PATCH 2/4] gallium: add initial support for conservative rasterization
Marek Olšák
maraeo at gmail.com
Sat Mar 24 01:12:23 UTC 2018
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>
More information about the mesa-dev
mailing list