KhronosGroup / KhronosGroup/SPIRV-Cross

Vulkan GLSL to MSL, sharing sampler state for split-up combined samplers

Open
#1,937 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

question
Dominant language
GLSL
Stars
2.5k
Forks
713
Avg merge
2d 18h
Merged PRs (30d)
16

Description

Hey,
In my workflow the graphics API developer is entirely separate from the GLSL shader writer (who is usually an artist with limited GPU hardware knowledge). They don't want to have to think about hardware limits or sampler states, and so all their shaders just use combined sampler declarations (sampler2D, sampler3D etc). Indeed, the shaders they write are often agnostic to the sampler states, and different usage cases for the same shaders will want different sampler states for the inputs.
On Windows this is fine since modern GPUs have large limits for combined samplers.
However on MSL where the sampler limit is often much smaller than the texture limit, we'd be able to use more textures if we were able to re-use the samplers between multiple textures.
Is this possible right now with SPIRV-cross, or is it always just forced splitting a sampler2D into 1 sampler state and 1 texture, with no ability to share that sampler between other textures?
Thanks

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by examining SPIRV-Cross's MSL translation path and how combined samplers are currently split into sampler states and textures. Determine whether shared sampler allocation is supported, and define the expected behavior and limits for reusing sampler states across multiple textures.

Written by the indexing model from the issue text.

Assessment

Domain
computer-graphics
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.