You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.
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_shadershd=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.
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 asSG_RESOURCESTATE_VALID
, but it's not really valid and I think we would know that from checking status ofID3D11Device_CreateVertexShader
andID3D11Device_CreatePixelShader
.The text was updated successfully, but these errors were encountered: