public sealed class TexturePlanEvaluatorRuns a TexturePlan on a device.
Remarks
The whole of doc 48 § D3's evaluator, and there is exactly one of it. A graph compiles to a plan and so does a layer stack, so both front ends reach a picture through this and neither can develop an opinion of its own about what a blend mode means.
⚠ An evaluation is not a frame. It opens one, submits every op's dispatch in a single command list and waits for the device — so it must not be called between a caller's own BeginFrame and EndFrame. A bake is a modal operation an artist starts; the interactive per-node preview of doc 48 § M4 is a different caller with a different budget, and it will want the recording half of this split out rather than this method called sixty times a second.
⚠ That rule is now checked, and it was a sentence with nothing behind it for four batches — #775. The paragraph above has been here since this class was written and every route that obeyed it obeyed it by accident of where it was called from, because a caller had no way to ask: IGraphicsDevice published BeginFrame, EndFrame, FrameCount and FramesInFlight, and FrameCount's own remarks forbid deriving the answer. IsFrameOpen is what closed that, and RefuseInsideAFrame is where the sentence became a refusal.
⚠ Every command list a bake records — the dispatches, and every later read-back — goes to ComputeQueue, recorded for that submitter's own Kind, and that is a correctness requirement rather than a preference. (On a unified adapter that kind is Graphics, because the backend collapses a queue sharing the graphics family — which is precisely why the defect below was invisible here.) The pool's textures are created with TextureDescription.Sharing at its default, ResourceSharing.Exclusive, so on an adapter whose QueueFamilySelection found a compute family of its own — a discrete AMD or NVIDIA card — touching one of them from a second family without a queue-family ownership transfer leaves its contents undefined by specification. The validation layers say nothing, because it is undefined behaviour and not invalid usage, and VulkanBarriers.cs records in as many words that a separate compute family is no device this engine has been developed on — so this would have been a corrupt bake on somebody else's machine and a clean run on every machine here.
One queue rather than the ownership-transfer pair, and a future reader should not "optimise" it back. A transfer is two barriers with identical parameters plus a semaphore edge between the submissions (TextureBarrier.TransfersOwnership) — and the release half would have to be recorded at the end of the bake's own list, for every image, before anybody knows which ones will ever be read, how often, or whether at all. An image released to a queue that never acquires it is exactly the corruption that pair exists to prevent. There is also nothing to buy: a bake is modal, Evaluate waits for the device before it returns, and the read-back has no frame to overlap with. The precedent is Platform/Vixen.Raven.Gpu.Tests/ShaderRun.cs, which dispatches and copies on one compute list for this same reason.
Variants are compiled once and kept. The cache is keyed on the kernel and the format it writes, which is the only thing that changes between two uses of one kernel — everything else an op varies is a uniform. Compilations is public because "a plan of forty ops compiles three shaders" is a claim about that number and nothing else.
⚠ "Kept" is true of an embedded kernel and bounded for an authored one — #1091. A kernel the plan carries is named after a digest of its own source, so a front end that recompiles per edit — which TextureGraphPreviews is — produces a distinct key per keystroke. Those are held least-recently-used up to AuthoredVariantCeiling and destroyed past it; embedded variants are never evicted, because the library bounds them. Variants is what a test reads to tell a cache that evicts from one that only ever grows, and Compilations cannot: it counts what was built and never what is held.
Fields and properties (8)
public const int GroupSizeThe workgroup size every kernel in Shaders/ declares.
public IGraphicsDevice DeviceWhere this evaluator's images, modules and pipelines live.
public int CompilationsHow many kernel variants have been compiled.
public int DispatchesHow many dispatches have been recorded, across every evaluation.
public int VariantsHow many compiled variants are held right now — modules and pipelines on the device.
public int EvictionsHow many authored variants have been destroyed to stay under the ceiling.
public int AuthoredVariantCeilingHow many authored variants this evaluator keeps before it starts destroying them.
public int AuthoredCountHow many of the held variants came from a kernel the plan carried.
Methods (4)
public TexturePlanEvaluator(IGraphicsDevice device)Builds an evaluator on a device.
public TextureBake Evaluate(TexturePlan plan, IReadOnlyDictionary<int, TextureHandle>? externals = null)Evaluates a plan whose external images are only ever sampled.
public TextureBake Evaluate(TexturePlan plan, IReadOnlyDictionary<int, TextureExternal> externals)Evaluates a plan, with the caller declaring what its own textures can be used for.
public void Dispose()Performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources.
Used by (55, showing 40)
- BakedMaterialImageTestsVixen.Graphics.Golden.Tests
- FilterLayerTestsVixen.Editor.Texturing.Tests
- LayerCoverageDeviceTestsVixen.Editor.Texturing.Tests
- LayerStackBakeDeviceTestsVixen.Editor.Texturing.Tests
- LayerStackPreviewVixen.Editor.Texturing
- LeaseVixen.Editor.TextureGraph.Tests
- LentEvaluatorVixen.Editor.Texturing.Tests
- MaskStackTestsVixen.Editor.Texturing.Tests
- MaterialBakeRouteVixen.Editor.Texturing
- SplatCoverageDeviceTestsVixen.Editor.Texturing.Tests
- TextureAnalysisDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureAspectDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureBlendDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureBudgetDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureCellMetricTestsVixen.Editor.TextureGraph.Tests
- TextureColourDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureCompoundBakeDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureCpuOpDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureEvaluationCostTestsVixen.Editor.TextureGraph.Tests
- TextureExternalGraphDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureExternalUsageTestsVixen.Editor.TextureGraph.Tests
- TextureFilterDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureFrameLoopTestsVixen.Editor.TextureGraph.Tests
- TextureGraphDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureGraphPreviewVixen.Editor.Texturing
- TextureGraphPreviewDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureGraphPreviewsVixen.Editor.TextureGraph
- TextureGraphRunnerVixen.Cli
- TextureHarnessPatternTestsVixen.Editor.TextureGraph.Tests
- TextureKernelSabotageTestsVixen.Editor.TextureGraph.Tests
- TextureKernelTestsVixen.Editor.TextureGraph.Tests
- TextureLevelDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureMetalReflectanceTestsVixen.Editor.TextureGraph.Tests
- TextureMixDeviceTestsVixen.Editor.TextureGraph.Tests
- TextureNormalToHeightDeviceTestsVixen.Editor.TextureGraph.Tests
- TexturePixelProcessorTestsVixen.Editor.TextureGraph.Tests
- TexturePlacementDeviceTestsVixen.Editor.TextureGraph.Tests
- TexturePlacementParameterDeviceTestsVixen.Editor.TextureGraph.Tests
- TexturePlanDeviceTestsVixen.Editor.TextureGraph.Tests
- TexturePlanKernelDeviceTestsVixen.Editor.TextureGraph.Tests