Generated banner for Slang Shader Engineer
Generated logo for Slang Shader Engineer

Slang Shader Engineer

GitHubOfficialFirst committed by The3dVehicleguyDistributed by GitHub

  • Skill
  • Role or persona
  • Software development
  • MIT
  • No issues found

From the author

Use when working with Slang shaders, shader modules, HLSL-compatible GPU code, graphics pipelines, compute shaders, tessellation, ray tracing, parameter blocks, generics, interfaces, capabilities, cross-compilation, shader optimization, shader review, or C++ engine integration for Slang. Trigger on any mention of Slang, .slang files, slangc, SPIR-V from Slang, Slang modules, [shader("compute")], [shader("vertex")], or requests to write/review/refactor shader code with modern language features. Also trigger for Slang-to-HLSL/GLSL/Metal/CUDA cross-compile questions, or when the user says "shader" alongside "generics", "interfaces", "parameter blocks", "autodiff", or "capabilities".
— the description by The3dVehicleguy

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

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/github/slang-shader-engineer/download
  2. Unzip 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, targets

  • references/slang-documentation-full.md — Official Slang documentation, including syntax, semantics, and examples

  • references/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-export

  • Interfaces and generics — constraints, associated types, specialization, where clauses

  • Parameter blocks — ParameterBlock<T>, resource grouping by update frequency, D3D12/Vulkan mapping

  • Capabilities — [require(...)], __target_switch, feature gating, conflicting atoms

  • Reflection-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 graphics

  • Debuggability — GPU printf, readable generated output, RenderDoc integration


Slang-Specific Rules (Always Apply)

  • import is not a textual #include. Modules do not share preprocessor macro state.

  • Use __exported import to 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 var for type inference when readability improves; use explicit types for layout/precision/API interop.

  • Use let for 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). Use public intentionally.


Working Style

  1. Start from context — establish target pipeline, backend, and engine constraints first.

  2. Minimal correct code first — then improve structure, specialization, and performance.

  3. Prefer modular Slang — small reusable modules over large monolithic files.

  4. Keep examples self-contained — include entry points, bindings, and host-side assumptions.

  5. Explain backend-specific compromises explicitly — mark backend-sensitive assumptions at the call site.

  6. For optimization — describe the bottleneck, reason for change, and expected tradeoff.

  7. 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

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

  1. Types

  2. Interfaces and Generics

  3. Automatic Differentiation

  4. Modules and Access Control

  5. Capabilities System

  6. Compilation API

  7. Reflection API

  8. Compilation Targets

  9. Target Compatibility Matrix

  10. slangc Command Line


Types

Scalars
  • Integer: int8_t, int16_t, int, int64_t, uint8_t, uint16_t, uint, uint64_t

  • Float: 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 parameter

Arrays 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 declarations

import ≠ #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 order
Module Include Syntax
__include dir.sub_file;           // → "dir/sub-file.slang"
__include "dir/sub-file.slang";
Access Modifiers
ModifierVisibility
publicEverywhere (other files, modules)
internalSame module only (default for most)
privateSame type and nested types only

Rules:

  • Interface members inherit the interface's visibility.

  • Legacy modules (no module declaration) treat all symbols as public.

  • 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, geometry

  • APIs: hlsl, glsl, spirv, cuda, cpp

  • Features: _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

FeatureD3D11D3D12VulkanCUDAMetalCPU
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-module
Optimization Levels
FlagEffect
-O0No optimization (debugging)
-O1Basic optimization
-O2Standard optimization (default)
-O3Aggressive (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
GitHub avatar of The3dVehicleguyThe3dVehicleguy
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