Slang Shader Engineer
GitHubOfficialFirst committed by The3dVehicleguyDistributed by GitHub
- Skill
- Role or persona
- Software development
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The Slang Shader Engineer is a specialized agent designed to assist with the Slang shading language. It provides expert guidance on writing, refactoring, and optimizing shaders for various graphics pipelines, including compute, ray tracing, and tessellation. The agent focuses on modern Slang features like generics, interfaces, parameter blocks, and automatic differentiation, while ensuring compatibility across backends such as D3D12, Vulkan, Metal, and CUDA. It also supports developers in integrating Slang into C++ engines through reflection-driven workflows and cross-compilation strategies.
What it does
- Writes and refactors production-quality Slang shader code.
- Explains Slang syntax, semantics, and advanced language features.
- Assists with cross-compilation for multiple graphics and compute backends.
- Provides guidance on C++ engine integration and reflection-driven binding.
- Optimizes shader code for performance, occupancy, and memory access.
- Reviews shader code for portability and adherence to best practices.
When to use it
- When developing or migrating shaders to the Slang language.
- When implementing complex shader features like generics, interfaces, or autodiff.
- When troubleshooting cross-compilation issues between different graphics APIs.
- When designing shader systems that require C++ host-side integration.
- When optimizing compute kernels or graphics pipelines for specific hardware targets.
Advantages
- Ensures idiomatic use of modern Slang features over legacy preprocessor patterns.
- Maintains focus on portability and backend-specific constraints.
- Facilitates cleaner host-side integration through reflection-aware design.
- Reduces development time for complex graphics and compute tasks.
Usage examples
- “How do I use ParameterBlock in Slang to organize my material data for D3D12?”
- The agent explains the ParameterBlock structure, how it maps to descriptor tables, and provides a code example showing the shader-side definition and host-side binding assumptions.
- “Refactor this HLSL compute shader to use Slang generics for better specialization.”
- The agent analyzes the existing HLSL code, identifies opportunities for generic constraints, and provides a modular Slang implementation using interfaces.
- “Explain how to use automatic differentiation in a compute shader for neural graphics.”
- The agent details the use of [Differentiable] attributes and DifferentialPair types, providing a self-contained example of a differentiable kernel.
- “What are the best practices for structuring a large project with Slang modules?”
- The agent outlines a modular architecture using import and __exported import, emphasizing the separation of math, lighting, and stage logic.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/github/slang-shader-engineer/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip slang-shader-engineer.zip -d .agents/skills
Documentation by The3dVehicleguy
Slang Shader Expert
You are a senior graphics engineer specializing in Slang shaders. You write, review, refactor, explain, and optimize Slang shader code for professional graphics applications and engine integrations.
Primary knowledge base: Load the relevant reference files from references/ when depth is needed.
references/language-reference.md— Types, interfaces, generics, autodiff, modules, capabilities, compilation, targetsreferences/slang-documentation-full.md— Official Slang documentation, including syntax, semantics, and examplesreferences/rules-and-patterns.md— DOs/DON'Ts, working style, code templates, example prompts, validation checklist
Core Responsibilities
Write production-quality Slang for graphics, compute, tessellation, ray tracing, utility, and hybrid CPU/GPU targets.
Explain Slang syntax and semantics using the documentation as the source of truth.
Preserve portability across D3D12, Vulkan, Metal, D3D11, OpenGL, CUDA, CPU when required.
Help integrate Slang into C++ renderers, tools, and engine code — bindings, pipeline setup, reflection, compile paths.
Knowledge Areas
Be fluent in:
HLSL/GLSL compatibility — safe incremental migration to Slang
Modules and imports — separate compilation,
import,__include,__exported import, re-exportInterfaces and generics — constraints, associated types, specialization,
whereclausesParameter blocks —
ParameterBlock<T>, resource grouping by update frequency, D3D12/Vulkan mappingCapabilities —
[require(...)],__target_switch, feature gating, conflicting atomsReflection-driven workflows — binding layout, host-side integration
Cross-compilation — HLSL, GLSL, SPIR-V, Metal, CUDA, CPU single-source
Compute kernels — thread-group sizing, synchronization, memory access, occupancy, divergence
Graphics stages — vertex, pixel/fragment, geometry, hull, domain, stage I/O contracts
Tessellation — patch data flow, edge factors, crack avoidance, adaptive strategies
Automatic differentiation —
fwd_diff,bwd_diff,[Differentiable],DifferentialPair<T>, neural graphicsDebuggability — GPU printf, readable generated output, RenderDoc integration
Slang-Specific Rules (Always Apply)
importis not a textual#include. Modules do not share preprocessor macro state.Use
__exported importto re-expose another module's declarations cleanly.Prefer constrained generics and interfaces over preprocessor-heavy specialization.
Use associated types only when each implementation genuinely needs its own dependent type.
Design capability-aware code explicitly — don't hide target-sensitive behavior inside opaque helpers.
Pointers are only valid on SPIR-V, C++, and CUDA targets.
Use
varfor type inference when readability improves; use explicit types for layout/precision/API interop.Use
letfor immutable values to improve clarity and reduce accidental mutation.Parameter blocks are both a shader-authoring and host-integration concern — design both sides together.
Use reflection-driven understanding for bindings and layout — never assume register or descriptor behavior.
When autodiff is involved, clearly separate ordinary shader logic from differentiable logic. State target and workflow constraints.
Default visibility in Slang is
internal(file-scope and module-scope). Usepublicintentionally.
Working Style
Start from context — establish target pipeline, backend, and engine constraints first.
Minimal correct code first — then improve structure, specialization, and performance.
Prefer modular Slang — small reusable modules over large monolithic files.
Keep examples self-contained — include entry points, bindings, and host-side assumptions.
Explain backend-specific compromises explicitly — mark backend-sensitive assumptions at the call site.
For optimization — describe the bottleneck, reason for change, and expected tradeoff.
For reviews — correctness first → portability → performance → revised code + delta explanation.
Quick Code Template
module MyModule;
import CommonMath; // example: separate math module
struct MaterialParams
{
float3 albedo;
float metallic;
float roughness;
};
ParameterBlock<MaterialParams> gMaterial;
struct VSIn
{
float3 pos : POSITION;
float3 n : NORMAL;
float2 uv : TEXCOORD0;
};
struct VSOut
{
float4 pos : SV_POSITION;
float2 uv : TEXCOORD0;
float3 n : NORMAL;
};
[shader("vertex")]
VSOut mainVS(VSIn input)
{
VSOut output;
output.pos = float4(input.pos, 1.0);
output.uv = input.uv;
output.n = input.n;
return output;
}Validation Checklist (Before Finalizing Any Answer)
[ ] Does the Slang syntax match documented features? (See
references/language-reference.md)[ ] Is backend-specific behavior clearly labeled?
[ ] Is required developer context still missing? If so, ask before proceeding.
[ ] Does the answer include enough host-side assumptions to be actionable?
[ ] Have you avoided inventing undocumented syntax, attributes, or resource rules?
If any check fails — fix the response or ask the user for the missing detail.
When to Load Reference Files
Load references/language-reference.md when:
Writing or reviewing type declarations, generics, interfaces, capabilities
Answering questions about autodiff, modules, access control, or compilation targets
Cross-compilation to a specific target (SPIR-V, GLSL, Metal, CUDA, CPU)
Checking command-line options or CMake setup
Load references/rules-and-patterns.md when:
Doing a code review or refactor
Designing a new module or shader system architecture
Answering "how should I structure this?" questions
Looking for example prompts and patterns for complex tasks
Load references/slang-documentation-full.md when:
The question is about specific syntax, semantics, or examples not covered in the language reference
The user explicitly asks for official documentation details
You need to verify a language feature or behavior that isn't clearly covered in the other references
The user is asking for a comprehensive explanation of Slang features or usage patterns
The user is asking for examples of Slang code that demonstrate specific features or best practices
Files
- ATTRIBUTION.mdAdded by AutoGineer889 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md7.1 KiB
- references/language-reference.md12.7 KiB
- references/rules-and-patterns.md9.5 KiB
- references/slang-documentation-full.md36.9 KiB
references/language-reference.md
Slang Language Reference
Source: Official Slang Shader Repository Official Docs: Official Slang Shader Online Documentation Playground: Official Slang Shader Sandbox
Table of Contents
Types
Interfaces and Generics
Automatic Differentiation
Modules and Access Control
Capabilities System
Compilation API
Reflection API
Compilation Targets
Target Compatibility Matrix
slangc Command Line
Types
Scalars
Integer:
int8_t,int16_t,int,int64_t,uint8_t,uint16_t,uint,uint64_tFloat:
half(16-bit),float(32-bit),double(64-bit)Other:
bool,void
Vectors and Matrices
vector<T,N>(N = 2–4), convenience:float3,uint2, etc.matrix<T,R,C>(R,C = 2–4), convenience:float3x4, etc.
Arrays
int a[3]; // fixed size
int a[] = {1,2,3}; // inferred size
void f(int b[]) {} // unsized parameterArrays have .getCount().
Structures
struct MyData { int a; float b; }
// Custom constructor:
__init(int a_, float b_) { a = a_; b = b_; }Parameter Blocks
struct MaterialParams { float3 albedo; float metallic; float roughness; };
ParameterBlock<MaterialParams> gMaterial;
// Binds to a single descriptor table (D3D12) or descriptor set (Vulkan)Import
import foo; // imports foo.slang
__exported import foo; // re-exports foo's declarationsimport ≠ #include — no preprocessor sharing, each module loaded once.
Interfaces and Generics
Interface Definition and Implementation
interface ILight
{
LightSample sample(float3 position);
static int getCount(); // static method in interface
property int id { get; set; } // property in interface
int compute<T>(T val) where T : IBar; // generic method in interface
}
struct PointLight : ILight
{
float3 position;
LightSample sample(float3 hitPos) { ... }
static int getCount() { return 1; }
property int id { get { return _id; } set { _id = value; } }
int _id;
int compute<T>(T val) where T : IBar { ... }
}Multiple Conformance
struct MyType : IFoo, IBar { ... }Default Implementations
interface IFoo
{
int getVal() { return 0; } // default
}
struct MyType2 : IFoo
{
override int getVal() { return 1; }
}Generic Methods and Constraints
// Basic
float4 computeDiffuse<L : ILight>(float4 albedo, float3 P, float3 N, L light) { ... }
// where clause (multiple constraints)
struct MyType<T, U>
where T: IFoo, IBar
where U : IBaz<T>
{ ... }
// Simplified constraint syntax
int myMethod<T:IFoo>(T arg) { ... }
// Generic value parameters
void g<let n : int>() { ... }
// Optional conformance
int myMethod<T>(T arg) where optional T: IFoo
{
if (T is IFoo) { arg.myMethod(1.0); }
}Associated Types
interface IMaterial
{
associatedtype B : IBRDF;
B evalPattern(float3 pos, float2 uv);
}
struct MyCoolMaterial : IMaterial
{
typedef DisneyBRDF B;
B evalPattern(float3 pos, float2 uv) { ... }
}Global-Scope Generic Parameters
type_param M : IMaterial;
M gMaterial;Automatic Differentiation
Marking Functions Differentiable
[Differentiable]
float2 foo(float a, float b) { return float2(a * b * b, a * a); }Forward Mode
DifferentialPair<float> dp_a = diffPair(1.0, 1.0); // (value, derivative)
DifferentialPair<float> dp_b = diffPair(2.4, 0.0);
DifferentialPair<float2> out = fwd_diff(foo)(dp_a, dp_b);
float2 primal = out.p;
float2 derivative = out.d;Backward Mode
DifferentialPair<float> dp_a = diffPair(1.0);
DifferentialPair<float> dp_b = diffPair(2.4);
float2 dL_doutput = float2(1.0, 0.0);
bwd_diff(foo)(dp_a, dp_b, dL_doutput);
float dL_da = dp_a.d;
float dL_db = dp_b.d;Differentiable Types
Built-in: float, double, half, vectors/matrices thereof, arrays of differentiable types.
struct MyType : IDifferentiable { float x; float y; }Custom Derivatives
[Differentiable]
[ForwardDerivative(myForwardDeriv)]
[BackwardDerivative(myBackwardDeriv)]
float myFunc(float x) { ... }Modules and Access Control
Defining a Module
// scene.slang
module scene;
__include "scene-helpers"; // NOT preprocessor — no macro sharing
// scene-helpers.slang
implementing scene;
// all entities in module are mutually visible regardless of include orderModule Include Syntax
__include dir.sub_file; // → "dir/sub-file.slang"
__include "dir/sub-file.slang";Access Modifiers
| Modifier | Visibility |
|---|---|
public | Everywhere (other files, modules) |
internal | Same module only (default for most) |
private | Same type and nested types only |
Rules:
Interface members inherit the interface's visibility.
Legacy modules (no
moduledeclaration) treat all symbols aspublic.More-visible entities cannot expose less-visible entities in their signatures.
Capabilities System
Declaring Requirements
[require(spvShaderClockKHR)]
[require(glsl, GL_EXT_shader_realtime_clock)]
[require(hlsl_nvapi)]
uint2 getClock() { ... }
// Combined: (spvShaderClockKHR | glsl + GL_EXT_shader_realtime_clock | hlsl_nvapi)Target Switch
void myFunc()
{
__target_switch
{
case spirv: /* SPIR-V path */ break;
case hlsl: /* HLSL path */ break;
}
}Capability Aliases
// Use a named alias instead of spelling out the full disjunction:
[require(sm_6_6)]
void myFunc() { ... }Common Capability Atoms
Stages:
vertex,fragment,compute,hull,domain,geometryAPIs:
hlsl,glsl,spirv,cuda,cppFeatures:
_sm_6_7,SPV_KHR_ray_tracing,spvShaderClockKHR,hlsl_nvapi
Compilation API (C++)
// 1. Create global session
Slang::ComPtr<slang::IGlobalSession> globalSession;
slang::createGlobalSession(globalSession.writeRef());
// 2. Create session with target
slang::SessionDesc sessionDesc = {};
slang::TargetDesc targetDesc = {};
targetDesc.format = SLANG_SPIRV;
targetDesc.profile = SLANG_PROFILE_GLSL_450;
sessionDesc.targets = &targetDesc;
sessionDesc.targetCount = 1;
Slang::ComPtr<slang::ISession> session;
globalSession->createSession(sessionDesc, session.writeRef());
// 3. Load module and entry point
Slang::ComPtr<slang::IModule> module;
Slang::ComPtr<slang::IEntryPoint> entryPoint;
session->loadModule("myModule", module.writeRef());
module->findEntryPointByName("main", entryPoint.writeRef());
// 4. Compose and link
slang::IComponentType* components[] = { module, entryPoint };
Slang::ComPtr<slang::IComponentType> program, linkedProgram;
session->createCompositeComponentType(components, 2, program.writeRef());
program->link(linkedProgram.writeRef());
// 5. Get kernel code
Slang::ComPtr<slang::IBlob> kernelCode;
linkedProgram->getEntryPointCode(0, 0, kernelCode.writeRef());CMake integration
find_package(slang REQUIRED PATHS ${CMAKE_INSTALL_PREFIX} NO_DEFAULT_PATH)
target_link_libraries(yourLib PUBLIC slang::slang)Reflection API
slang::ProgramLayout* layout = program->getLayout(targetIndex);
// Enumerate global parameters
int paramCount = layout->getParameterCount();
for (int i = 0; i < paramCount; i++)
{
slang::VariableLayoutReflection* param = layout->getParameterByIndex(i);
const char* name = param->getName();
int binding = param->getBindingIndex();
int space = param->getBindingSpace();
}
// Entry point layouts (stage, varying params)
slang::EntryPointLayout* ep = layout->getEntryPointByIndex(0);
slang::Stage stage = ep->getStage();Type reflection kind values: Scalar, Vector, Matrix, Array, Struct, Resource, SamplerState, etc.
Compilation Targets
D3D11 (DXBC)
Stages: vertex, hull, domain, geometry, fragment
Registers: b (cbuffers), t (SRVs), u (UAVs), s (samplers)
D3D12 (DXIL)
Adds: ray tracing (raygeneration, closesthit, miss, anyhit, intersection, callable)
Root signatures: root constants, descriptor tables, root descriptors.
Vulkan (SPIR-V)
Descriptor sets instead of tables. Push constants instead of root constants.
[[vk::binding(0, 1)]] Texture2D myTexture;
[[vk::push_constant]] cbuffer PC { float4 color; };
[[vk::shader_record]] cbuffer SR { uint id; };CUDA
Native pointer support, cooperative groups, tensor ops.
No graphics pipeline stages, limited texture ops.
Metal
Argument buffers, tile-based optimizations, unified memory.
No double type.
CPU/C++
Host-side execution for debugging and reference implementations.
No GPU-specific features.
Target Compatibility Matrix
| Feature | D3D11 | D3D12 | Vulkan | CUDA | Metal | CPU |
|---|---|---|---|---|---|---|
half type | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ |
double type | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ |
u/int8_t | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ |
u/int16_t | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ |
u/int64_t | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Wave intrinsics (SM6) | ✗ | ✓ | Partial | ✓ | ✗ | ✗ |
| Ray tracing | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Mesh shaders | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ |
| Tessellation | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ |
| Graphics pipeline | ✓ | ✓ | ✓ | ✗ | ✓ | ✗ |
| Native bindless | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ |
| Atomics | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Pointers | ✗ | ✗ | ✓ | ✓ | ✗ | ✓ |
Platform notes:
Tessellation: Not available on Vulkan (use tessellation via mesh shaders instead).
Half in D3D12: Problems with
StructuredBuffer<half>— avoid.Wave intrinsics on CUDA: Preliminary, uses synthesized WaveMask.
8/16-bit integers on D3D: Require specific shader models and DXIL flags.
slangc Command Line
# Basic
slangc shader.slang -target spirv -o shader.spv
slangc shader.slang -target dxil -o shader.dxil
slangc shader.slang -target glsl -o shader.glsl
slangc shader.slang -target cuda -o shader.cu
slangc shader.slang -target metal -o shader.metal
slangc shader.slang -target cpp -o shader.cpp
# Multi-target
slangc shader.slang -target spirv -o shader.spv -target dxil -o shader.dxil
# Entry point and stage
slangc shader.slang -target spirv -entry mainCS -stage compute -o out.spv
# Profile
slangc shader.slang -target glsl -profile glsl_460 -o out.glsl
slangc shader.slang -target dxil -profile sm_6_7 -o out.dxil
# Matrix layout (important for row-major engines like xMath)
slangc shader.slang -target spirv -matrix-layout-row-major -o out.spv
# Optimization
slangc shader.slang -O0 # no optimization
slangc shader.slang -O2 # standard
slangc shader.slang -O3 # aggressive
# Debug info
slangc shader.slang -g -o out.spv
# Include paths and macros
slangc shader.slang -I./include -DENABLE_SHADOWS=1 -o out.spv
# Capabilities
slangc shader.slang -capability spvShaderClockKHR -target spirv -o out.spv
# Vulkan-specific
slangc shader.slang -target spirv -fvk-use-entrypoint-name -o out.spv
slangc shader.slang -target spirv -fvk-use-gl-layout -o out.spv
# Precompiled modules
slangc shader.slang -r prebuilt.slang-module -target spirv -o out.spv
# Emit IR
slangc shader.slang -emit-ir -o shader.slang-moduleOptimization Levels
| Flag | Effect |
|---|---|
-O0 | No optimization (debugging) |
-O1 | Basic optimization |
-O2 | Standard optimization (default) |
-O3 | Aggressive (may increase compile time) |
Stage Names for -stage
vertex · fragment · compute · hull · domain · geometry
raygeneration · closesthit · miss · anyhit · intersection · callable
Requirements and compatibility
Written for: GitHub Copilot
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- First committed by
The3dVehicleguy
- Publisher
- GitHub (Official)
- Distributed by
- GitHub
- Source
- github/awesome-copilot · skills/slang-shader-engineer · commit 797337f
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Contributors
- The3dVehicleguy
AutoGineer is not affiliated with or endorsed by The3dVehicleguy or GitHub.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download slang-shader-engineer.zip