Skip to content

turnip: Rewrite state handling

Connor Abbott requested to merge cwabbott0/mesa:review/tu-state-rewrite into main

This is something that I've had in mind for a while. Currently we try to bake as much state as possible, that means we have to manually merge dynamic and static state when only one of multiple states making up a draw state is dynamic. While this was reasonable enough for Vulkan 1.0 pipelines, as we started adding more and more dynamic states, it started to break down.

The new model uses the common Mesa state-tracking infrastructure. There are a series of draw-state-emission functions, shared between draw-time and static emission, together with their state dependencies. We check for each draw state whether all of the required states are statically set by the pipeline, and if so emit it. If we can determine that a given state is guaranteed entirely consumed by the pipeline, then we also set it as "dynamic" to avoid the overhead of tracking it at CmdBindPipeline time. Otherwise, Mesa will effectively call CmdSet* at CmdBindPipeline time for the part of the draw state that is defined by the pipeline. There are some dynamic states that are shared between draw states, in which case one of the resulting draw states may be precompiled by the pipeline while the underlying dynamic state is still tracked. There are some states which aren't draw states per-se but still fit into this framework, like the color blend bandwidth calculations.

There were a few fixes/improvements required for the common code, some are more WIP still.

This is a step towards EXT_shader_objects, as it makes it much easier to merge more draw states which will be required to split out the program state into a per-stage state. Now we can easily combine or split out draw states as we see fit, and let mesa handle state merging.

There are still a few areas that could be cleaned up more by putting them in this framework, in particular LRZ stencil determination and MSAA. I also need to do a bit more debugging, but this is hopefully good enough for review to start and to avoid conflicts as this touches many, many things.

This is based on !20304 (merged) to avoid having to rewrite things once it lands.

Edited by Connor Abbott

Merge request reports