KhronosGroup / KhronosGroup/glslang

Why is 'nointerpolation' applied to 'double' types and default interpolation set for FS inputs but not VS outputs?

Open
#4,087 1 comment 0 reactions 0 assignees View on GitHub
question
Dominant language
C++
Stars
3.6k
Forks
989
Avg merge
1d 2h
Merged PRs (30d)
31

Description

**Question/Issue**

While reading the source code in [glslang/HLSL/hlslParseHelper.cpp](https://github.com/KhronosGroup/glslang/blob/b58249a96fce25cce5d440b265b58fead80d1377/glslang/HLSL/hlslParseHelper.cpp#L2327), I noticed that variables of type `double` are marked with the `nointerpolation` qualifier. Additionally, when handling fragment shader (FS) inputs, the code assigns a default interpolation qualifier by default, but for vertex shader (VS) outputs, this default interpolation is not set.

**Questions:**
1. Why is the `nointerpolation` qualifier applied to variables of type `double`?
2. Why is a default interpolation assigned to fragment shader inputs, but not to vertex shader outputs, even though this seems inconsistent?

**Context:**
- I am seeking clarification on the design or technical motivation behind these behaviors in the codebase.
- Is this decision based on HLSL/GLSL specification requirements, or are there other reasons?

Any insight into the reasoning or relevant specification references would be appreciated.

Thank you!

Contributor guide

Open the contributing guide

Research direction

Start at glslang/HLSL/hlslParseHelper.cpp around line 2327 and trace the handling of double variables and interpolation qualifiers for fragment inputs and vertex outputs. Consult the relevant HLSL and GLSL specification sections, then document the rationale and any intentional asymmetry with precise references.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Documentation
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.