[Mesa-dev] [PATCH 1/2] mesa: Set the correct ctx->NewState bitfield for rasterizer discard.

[Marek Olšák]

On Thu, Dec 15, 2011 at 7:21 PM, Paul Berry <stereotype441 at gmail.com> wrote:
> On 15 December 2011 08:02, Eric Anholt <eric at anholt.net> wrote:
>>
>> On Thu, 15 Dec 2011 00:00:49 +0100, Marek Olšák <maraeo at gmail.com> wrote:
>> > On Wed, Dec 14, 2011 at 11:25 PM, Paul Berry <stereotype441 at gmail.com>
>> > wrote:
>> > > (c) Do nothing, and rely on programmers to remember that RasterDiscard
>> > > is an
>> > > exception to the usual correspondence between dirty bits and
>> > > substructures
>> > > of gl_context.
>> > >
>> > > I'm really not comfortable with (c) because of the risk of future
>> > > bugs.  I
>> > > suppose I could be talked into (b) if there's popular support for it,
>> > > but
>> > > it's not my favourite, because as I said earlier, I think there are
>> > > actually
>> > > a lot of good reasons to think of rasterizer discard as related to
>> > > transform
>> > > feedback.  My preference is to do (a).
>> >
>> > (d) Rework the _NEW_* flags such that they roughly match hardware
>> > state groups, not OpenGL state groups. Direct3D 11 and Gallium are two
>> > examples of how it could be done.
>>
>> The problem is that everyone disagrees on what "hardware state group" a
>> piece of state is in.  On i965, rasterizer discard is really in the
>> transform feedback state -- the SOL (transform feedback) unit on gen7,
>> and the GS on gen6.
>
>
> I have been thinking about this more this morning, and I have an idea for
> how to accomplish (d) that I think would address this problem.  It's not a
> trivial change, but it's something we could implement incrementally, so we
> apply it to rasterizer discard now, and over time extend it to cover other
> pieces of state.  Here's the idea:
>
> The key problem is that there are so many distinct pieces of state that we
> could never possibly assign a separate bit to each one--we would run out of
> space in the bitfield.  So instead of having core Mesa decide how they are
> grouped (and, inevitably, wind up grouping them in a way that doesn't work
> well for some drivers), let each driver decide how they are grouped.  The
> drivers communicate this grouping to core Mesa by populating a new data
> structure (at initialization time) called ctx->StateFlags.  ctx->StateFlags
> has an entry for each distinct piece of state, which tells which bits in
> ctx->NewState should be set when that state changes.
>
> So, for example, in BeginTransformFeedback() and EndTransformFeedback(),
> instead of doing this:
>
> FLUSH_VERTICES(ctx, _NEW_TRANSFORM_FEEDBACK);
>
> We would do this:
>
> FLUSH_VERTICES(ctx, ctx->StateFlags->TransformFeedback_Active);
>
> In PauseTransformFeedback() and ResumeTransformFeedback() we would do:
>
> FLUSH_VERTICES(ctx, ctx->StateFlags->TransformFeedback_Paused);
>
> And in enable.c, when rasterizer discard is turned on or off, we would do:
>
> FLUSH_VERTICES(ctx, ctx->StateFlags->RasterizerDiscard);
>
> In the i965 driver, where all of these features map to the GS stage of the
> pipeline, we would initialize TransformFeedback_Active,
> TransformFeedback_Paused, and RasterizerDiscard all to the same value.  In
> the r600 driver, where rasterizer discard is implemented using face culling,
> StateFlags->RasterizerDiscard would indicate a totally different bit than
> those used for transform feedback.
>
> In the short term, we could implement this technique just for rasterizer
> discard, to address the differences between r600 and i965 that we're
> discussing in this email thread.  In the long term, our goal would be to
> replace all of the _NEW_* constants with a fine-grained set of values in
> StateFlags.  Once we've done that, each driver can set up StateFlags in a
> way that precisely matches how state is grouped for that particular piece of
> hardware.
>
> What do y'all think?  If there's support for this idea I'd be glad to make
> an RFC patch.

I like this idea very much. However, there is a catch that some _NEW
flags are used for core Mesa, others are used for the vbo module,
others are used for generating fixed function programs, others just
notify about a change in constant buffers (e.g. the gl_* variables in
GLSL) and so on, and finally, most are consumed by drivers to generate
states. I am sure we can do this incrementally though and doing the
easy stuff first.

Marek