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

sokol_gfx D3D11 backend: return invalid shader handle if shader creation fails. #353

Closed
floooh opened this issue Aug 2, 2020 · 3 comments
Assignees

Comments

@floooh
Copy link
Owner

floooh commented Aug 2, 2020

From #179:

There is one extra thing I did notice in production. I've encountered users with SM below 4.0 and for that I had some fallback renderers. However, Sokol actually never fails with shader creation and the shader returned from sg_make_shader appears to be valid, so users end up with black window. The application doesn't know it failed since otherwise it would fallback to another renderer if it could detect that.

I think this is related to the same issue as described here. The shader compilation never fails, even on hardware which does not support specified SM version since I ship it with d3dcompiler_47.dll. The only way to detect that the shader won't work is by using assertion code, but we don't do that in production, so why not make the shader invalid if it fails at the lines pointed by the author of this issue? Currently from what I can see it just sets the resource as SG_RESOURCESTATE_VALID, but it's not really valid and I think we would know that from checking status of ID3D11Device_CreateVertexShader and ID3D11Device_CreatePixelShader.

@floooh floooh self-assigned this Aug 2, 2020
@iryont
Copy link

iryont commented Aug 2, 2020

I took the liberty of shipping the application with assertion enabled to user with SM lower than 4.0 and he fails with following reason: 20200802_160550.png

Unfortunately the application in production mode cannot detect if shader actually failed because the compiled shader appears to be valid and therefore those users do end up with a black window instead. If shader creation would fail I could simply notify user about it and switch to a different renderer.

@floooh floooh closed this as completed in c59c411 Aug 2, 2020
@floooh
Copy link
Owner Author

floooh commented Aug 2, 2020

Ok, one important difference to the issue title: instead of returning an invalid shader handle, the shader will be created in SG_RESOURCESTATE_FAILED resource state, sg_make_shader() will still return a "valid" shader handle.

To check if the shader is actually valid, you need to call sg_query_resource_state(), for instance:

    sg_shader shd = sg_make_shader(cube_shader_desc());
    if (sg_query_shader_state(shd) == SG_RESOURCESTATE_FAILED) {
        printf("Shader creation failed!\n");
        sg_destroy_shader(shd);
    }

I also fixed a related bug in the validation layer for sg_make_pipeline() which was triggered when a shader handle with a SG_RESOURCESTATE_FAILED shader was used as the pipeline's shader in this commit.

@iryont
Copy link

iryont commented Aug 3, 2020

I do very much appreciate it.

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

No branches or pull requests

2 participants