Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NormalMapFiltering.ps.glsl not compiling #101

Closed
nbentyNV opened this issue Jul 15, 2017 · 5 comments
Closed

NormalMapFiltering.ps.glsl not compiling #101

nbentyNV opened this issue Jul 15, 2017 · 5 comments
Assignees

Comments

@nbentyNV
Copy link
Collaborator

Effect/NormalMapFiltering sample (default settings)

The error I'm getting is from glslang - perturbNormal is missing the definition. The definition is actually missing from the GLSL string we send even though _MS_USER_NORMAL_MAPPING is defined.

@tangent-vector-personal

Where is the user definition? Is if in a Slang file or user code?

@nbentyNV
Copy link
Collaborator Author

User code. I'm using #import

@tangent-vector-personal

The fact that we aren't emitting a definition in user code is worrying: we are supposed to emit those unconditionally.

My best theory right now is that the semantic checking is deciding the user definition is a redeclaration, but in that case we should still emit whatever redeclaration has a body.

@tangent-vector tangent-vector self-assigned this Jul 18, 2017
@tangent-vector-personal

My understanding is that this issue has been worked around in the original codbase.

I don't think this is something Slang should support long-term (interfaces and generics should cover most of what we want), so I'd like to close this as a "will not fix" if possible.

@tangent-vector
Copy link
Contributor

Closing this as "will not fix." We will not support the case of a Slang file declaring a function that then gets defined in user HLSL or GLSL.

The basic rules of Slang will be:

  • A Slang "module" (one or more .slang files that get compiled as a unit) can explicitly depend on another module via import, but these can only be other Slang modules.

  • An HLSL/GLSL module (one translation unit_ can explicitly depend on Slang modules, via import

  • Any dependencies in the other direction ("I want this library code to call my code") need to be expressed as explicit parameterization (e.g., a library function takes a parameter of interface type, and the client passes in an instance which implements its members).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants