-
Notifications
You must be signed in to change notification settings - Fork 133
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
glslang shader processing #285
glslang shader processing #285
Conversation
…tored implementation needs.
…g yet, hasn't worked but problem might be coming from elsewhere.
… linker object. A robust revision of ALL logic for linker objects is necessary to get the ASTs to match because replacements in the linker object aggregate should be symbol-only, without struct indexers or aggregates. So this is little more than a hack proving to show that, with the a little more logic work, we can render glTFs. On a related note, though, we can render (some) glTFs!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current State
What's done:
- Updated Babylon.js to latest master (with modification to remove NativeShaderProcessor.ts).
- On Windows, correctly renders cube, glTF cube, glTF textured cube, Brain Stem, and Flight Helmet.
- Flight helmet tested both with and without IBL, works both ways.
What's not done.
- 100% untested cross-plat, almost guaranteed to not work considering everything I've done so far has been inside ShaderCompilerD3D.cpp.
- Have not changed names on attributes/varying variables (
a_position
,a_rotation
, etc.). - Have not added swizzle logic (appending
.xyz
tovec4
s being assigned tovec3
s, for example.).
marble tower on Windows tested ok. Todo:
|
The 2 issues I have seem to be linked to the same root: location in varying between VS and FS.
FS Input:
I'm adding a new traverser to support that. @syntheticmagus |
marble tower, avocado render good with my latest chances. I will test iOS tomorrow. |
Validation tests passing on Linux. I had to change the version to 330. |
on iOS, tested OK: cesiumman, avocado and marble tower. |
…cmagus/BabylonNative into glslangShaderProcessing
…ming from glslang.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall. My biggest concern the opengl one which still goes to SPIR-V. Is that necessary?
target_compile_definitions(NativeEngine | ||
PRIVATE NOMINMAX) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Is this a WIN32 only thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if it's only meaningful for Windows or not, but we haven't been treating it as platform-specific so far. What's here matches the CMakeLists.txt files from NAPI, AppRuntime, NativeEngine, and I think everywhere else we use NOMINMAX
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure this is WIN32 only, but we can fix that later if necessary.
} | ||
|
||
program.addShader(&shader); | ||
} | ||
|
||
std::unique_ptr<spirv_cross::Compiler> CompileShader(glslang::TProgram& program, EShLanguage stage, std::string& glsl) | ||
std::pair<std::unique_ptr<spirv_cross::Parser>, std::unique_ptr<spirv_cross::Compiler>> CompileShader(glslang::TProgram& program, EShLanguage stage, std::string& glsl) | ||
{ | ||
std::vector<uint32_t> spirv; | ||
glslang::GlslangToSpv(*program.getIntermediate(stage), spirv); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need to go to SPIRV for OpenGL?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, the logic in NativeEngine
still uses the SPIRV types to build the bgfx representation of the shader. Ultimately that logic should probably be moved out of NativeEngine
and adapted to use glslang features instead of SPIRV. However, that looks like a fairly substantial change with only a tangential connection to this one, so my opinion is that we should leave that to its own PR. I've made an issue to track this: #300.
Preliminary work to process shaders using glslang instead of other custom processing mechanisms.