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

[Marek Olšák]

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.

Marek



On Mon, Apr 15, 2013 at 7:40 PM, Eric Anholt <eric at anholt.net> wrote:

> s/ReadPixels/ReadBuffer/ in the subject.
>
> I need a bit more time to think about the NewDriverState idea in the
> surrounding patches.  I don't see there being a meaningful distinction
> between which state ends up in NewState versus NewDriverState in this
> patch series, and I'd like to actually understand what the point is.
> Unless the point is just "we're running out of bits", in which case 64
> bits seems like a better solution.
>
> I approve of more granular state updates, though.  Is this part of a
> long-term plan to replace _NEW_* with more or less per-state-value
> bitmasks (not just single bits) that would get set in NewDriverState?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130415/fcca5a57/attachment.html>