Marek Olšák <mar...@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.
pgpJULvlvEsD8.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
