-
Notifications
You must be signed in to change notification settings - Fork 269
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
Unit test failure on gfx-unit-test-tool/precompiledTargetModule2Vulkan #6170
Comments
The test needs to be updated to match development in slang for the spirv backend. I don't understand the issue that was causing the test to "pass" when running on Release with "-use-test-server" incorrectly, but it's clear the test should not be passing. When the test was written, getEntryPointCode() would return the whole spirv program even if one module was precompiled, but Slang was updated to only return "glue" spirv, and the precompiled bits have to be separately queried. I've got the bit to query the remaining blobs of spirv and am working on getting them linked using SPIRV-Tools. In the past, I've been able to use "spirv-link.exe" to link in test apps, but for the CI test, it has to use the library version of spirv-tools. The app is linking to SPIRV-Tools.lib now and some symbols from the library are resolved, but Link() is not resolved, still investigating that. |
The intermittence became higher after upgrading the graphics driver, although I am not sure if it is really related to the graphics driver or not.
|
It's fine to have it disabled while I'm fixing the test. |
The SPIRV-Tools-link.lib based linker is loaded properly now, but Link() reports an error: Linking 2 binaries Dumping the same binaries to disk and using "spirv-link.exe" shows that the bins are legal and linkable, so it must be API usage. |
The API expects spv sizes to be reported in units of uint32_t instead of bytes, so Link() was reading past the end of the valid data. Linkage is working now and producing valid kernel code. Need to get it loaded as the replacement kernel code now. |
Another test keeps failing too.
|
Interesting, there may be multiple issues then. |
I have what appears to be a working fix for the Vulkan tests, but D3D tests are failing. Need to investigate that. This draft PR needs cleaned up still: #6236 @jkwak-work What was the cause of the false "passing" status of this test, could you tell? I didn't catch the "incorrect" aspect of this:
|
In the SPIR-V backend of Slang, compiling a shader that contains some modules with precompiled target blobs will produce only a "glue" SPIR-V output which needs to be linked with the assorted precompiled blobs to be complete. Closes shader-slang#6170
In the SPIR-V backend of Slang, compiling a shader that contains some modules with precompiled target blobs will produce only a "glue" SPIR-V output which needs to be linked with the assorted precompiled blobs to be complete. Closes shader-slang#6170
In the SPIR-V backend of Slang, compiling a shader that contains some modules with precompiled target blobs will produce only a "glue" SPIR-V output which needs to be linked with the assorted precompiled blobs to be complete. Closes shader-slang#5435 Closes shader-slang#6170
The proposed fix is #6253 but the change is causing "error 127" failures in examples that use the "compileShaders" function from gfx that was fixed by the change. Reducing priority for the next couple weeks. |
https://github.com/shader-slang/slang/pull/6455/files fixes the issue and passes CI. Just needs to be rebased. |
Fixed by #6455 |
gfx-unit-test-tool/precompiledTargetModule2Vulkan
is failing.Not sure when it started failing.
Note that the test is passing when running with a Release build with "-use-test-server" option incorrectly. That's why CI has been passing; incorrectly.
You can reproduce it with debug build or when running with release build, don't use "-use-test-server" option.
When debugged, the "result" variable holds four zero values.
The text was updated successfully, but these errors were encountered: