TextureKernels

Remarks

Embedded rather than compiled to a committed .spv, and the reason is a property of the target rather than a preference. A storage image's texel format is part of its type — SPIR-V puts it in OpTypeImage, GLSL in the layout qualifier — and Raven's [Permutation] values are bool, int and uint, so a format cannot be one. A kernel that writes rgba8 in one plan and rgba16f in the next is therefore two modules, and there is no spelling of the source that makes it one.

⚠ So the variant is produced by rewriting the one [Format(…)] the source carries, which is a shader variant in the plainest sense and is named as one rather than hidden. Variant refuses a source that does not carry exactly one, so a kernel that grew a second storage image is a failure here rather than a silent rewrite of whichever came first.

What this arrangement gives up, and what it buys. It gives up CheckShaders' editor half: that gate proves a committed module matches the source beside it, and there is no committed module to be stale. What replaces it is stronger and runs on every machine — TextureKernelTests puts every kernel through the real Raven front end in every format a plan can ask for, with no device, so a kernel that does not compile fails a test that never skips. A gate that can only run where there is a GPU is a gate that reports success on the day it does not run.

Fields and properties (1)

• public static IReadOnlyList<string> Names

  Every kernel this assembly ships, by the shader name a TextureOp gives.

Methods (4)

• public static string Source(string kernel)

  The source of one kernel, exactly as committed.

• public static string Variant(string kernel, TextureFormat output)

  The source of one kernel, writing into an image of a given format.

• public static string Variant(string kernel, string source, TextureFormat output)

  The same rewrite over a source this assembly did not ship.

• public static string VariantName(string kernel, TextureFormat output)

  What the compiler is told the variant's file is called, so a diagnostic points at it.

Used by (23)

• TextureAdjustTestsVixen.Editor.TextureGraph.Tests
• TextureAnalysisKernelTestsVixen.Editor.TextureGraph.Tests
• TextureAngleUnitTestsVixen.Editor.TextureGraph.Tests
• TextureCeilingTestsVixen.Editor.TextureGraph.Tests
• TextureCellMetricTestsVixen.Editor.TextureGraph.Tests
• TextureColourKernelTestsVixen.Editor.TextureGraph.Tests
• TextureFilterKernelTestsVixen.Editor.TextureGraph.Tests
• TextureGraphCompilerTestsVixen.Editor.TextureGraph.Tests
• TextureKernelLanguageSeamTestsVixen.Editor.TextureGraph.Tests
• TextureKernelSabotageTestsVixen.Editor.TextureGraph.Tests
• TextureKernelSurfacesVixen.Editor.TextureGraph.Tests
• TextureKernelTestsVixen.Editor.TextureGraph.Tests
• TextureKernelUnitDocTestsVixen.Editor.TextureGraph.Tests
• TextureMetalReflectanceTestsVixen.Editor.TextureGraph.Tests
• TextureMixParityTestsVixen.Editor.TextureGraph.Tests
• TextureNodeLibraryTestsVixen.Editor.TextureGraph.Tests
• TexturePlacementKernelTestsVixen.Editor.TextureGraph.Tests
• TexturePlanVixen.Editor.TextureGraph
• TexturePlanEvaluatorVixen.Editor.TextureGraph
• TexturePlanKernelDeviceTestsVixen.Editor.TextureGraph.Tests
• TexturePlanKernelTestsVixen.Editor.TextureGraph.Tests
• TextureSourceKernelTestsVixen.Editor.TextureGraph.Tests
• TextureSurfaceKernelTestsVixen.Editor.TextureGraph.Tests