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

glslang shader processing #285

Merged

Conversation

syntheticmagus
Copy link
Contributor

Preliminary work to process shaders using glslang instead of other custom processing mechanisms.

…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!
Copy link
Contributor Author

@syntheticmagus syntheticmagus left a 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 to vec4s being assigned to vec3s, for example.).

@syntheticmagus syntheticmagus marked this pull request as ready for review June 8, 2020 06:57
@CedricGuillemet
Copy link
Contributor

marble tower on Windows tested ok.
Metal/MacOS: brainstem, cesium man tested ok.

Todo:

  • the default cube lighting is wrong
  • error at metal shader link time for marble tower, avocado
  • test on simulator/device

@CedricGuillemet
Copy link
Contributor

CedricGuillemet commented Jun 15, 2020

The 2 issues I have seem to be linked to the same root: location in varying between VS and FS.
VS Output:

struct xlatMtlMain_out
{
    float3 vNormalW [[user(locn0)]];
    float3 vPositionW [[user(locn1)]];
    float4 gl_Position [[position]];
};

FS Input:

struct xlatMtlMain_in
{
    float3 vPositionW [[user(locn0)]];
    float3 vNormalW [[user(locn1)]];
};

I'm adding a new traverser to support that. @syntheticmagus

@CedricGuillemet
Copy link
Contributor

marble tower, avocado render good with my latest chances. I will test iOS tomorrow.

@CedricGuillemet
Copy link
Contributor

Validation tests passing on Linux. I had to change the version to 330.

@CedricGuillemet
Copy link
Contributor

on iOS, tested OK: cesiumman, avocado and marble tower.

Copy link
Contributor

@bghgary bghgary left a 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?

Comment on lines +52 to +53
target_compile_definitions(NativeEngine
PRIVATE NOMINMAX)
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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);
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@syntheticmagus syntheticmagus merged commit d22508e into BabylonJS:master Jun 18, 2020
@syntheticmagus syntheticmagus deleted the glslangShaderProcessing branch June 18, 2020 22:38
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

Successfully merging this pull request may close these issues.

3 participants