<div dir="ltr"><div><div>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.<br>

<br></div>And if the colormask is changed, core Mesa would just do: NewDriverState |= DriverFlags.NewColorMask;<br><br></div><div>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.<br>

<br></div><div>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).<br>

<br></div><div>If I have to add one hundred flags to gl_context::DriverFlags to accomplish my plan, that's fine.<br><br></div><div>Hopefully this email makes it clear.<br></div><div><br></div><div>Marek<br></div><div>

<div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 15, 2013 at 7:40 PM, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">s/ReadPixels/ReadBuffer/ in the subject.<br>
<br>
I need a bit more time to think about the NewDriverState idea in the<br>
surrounding patches.  I don't see there being a meaningful distinction<br>
between which state ends up in NewState versus NewDriverState in this<br>
patch series, and I'd like to actually understand what the point is.<br>
Unless the point is just "we're running out of bits", in which case 64<br>
bits seems like a better solution.<br>
<br>
I approve of more granular state updates, though.  Is this part of a<br>
long-term plan to replace _NEW_* with more or less per-state-value<br>
bitmasks (not just single bits) that would get set in NewDriverState?<br>
</blockquote></div><br></div>