[Mesa-dev] [PATCH 04/14] mesa: remove redundant _NEW_BUFFERS setting in ReadPixels

[Eric Anholt]

Marek Olšák <maraeo at gmail.com> writes:

> The main motivation behind NewDriverState is to map GL states to driver
> state groups in a driver-specific manner. For example, some driver may want
> the colormask to be in the framebuffer state, while some other driver may
> want the colormask to be in the blend state. So let's say we have
> ctx->DriverFlags.NewColorMask. The first driver would set NewColorMask =
> DRV1_NEW_FRAMEBUFFER, while the other driver would set NewColorMask =
> DRV2_NEW_BLEND. And there might be another driver wanting the color mask in
> several state groups, so it would do for example NewColorMask =
> DRV3_NEW_FRAMEBUFFER|DRV3_NEW_BLEND.
>
> And if the colormask is changed, core Mesa would just do: NewDriverState |=
> DriverFlags.NewColorMask;
>
> What we have now is horrible. Setting _NEW_COLOR for the colormask causes
> revalidation of the depth-stencil-alpha state in st/mesa and the
> fixed-function fragment shader, even though the states don't need it, so
> there is obviously some CPU time wasted. And I could go on, some of the
> _NEW_* flags cover a lot of mutually unrelated states.
>
> My plan is to add as many flags as needed to perfectly map GL states to
> driver state groups. For example, I want to map Multisample._Enabled and
> Multisample.SampleMask to different state groups. I want to map
> Stencil._Enabled and Stencil.Ref to different state groups as well. I don't
> want updating Color.ClampFragmentColor to cause revalidation of any driver
> state group, but I want Color._ClampFragmentColor to revalidate the state
> group of my choice (which is either the fragment shader or the rasterizer
> state depending on the corresponding gallium CAP, so the state flag has to
> be mutable).
>
> If I have to add one hundred flags to gl_context::DriverFlags to accomplish
> my plan, that's fine.
>
> Hopefully this email makes it clear.

OK, I think it makes sense, now that I see it as a step in a long term
plan, and I definitely like the end goal.

I cringe when our hot path ends up taking up more space, but in this
case we're talking about 100 flags maybe in the worst case * 4 bytes =
not much cache space, while avoiding a single state update per drawing
loop will probably save us that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130415/33c5b8cd/attachment.pgp>