GPU panic in GDeflateDemo /decompressgpu

[MennoVink]

I'm trying to use the GDeflate reference shader implementation but i'm running into gpu panics because the shader is accessing out-of-bounds memory.

The blob im using is inside this zip.
output_003.zip

1. Clone repo and make it buildable.
2. GDeflateDemo /compress "output_003.bc6" "myfolder/"
3. GDeflateDemo /decompressgpu "myfolder/output_003.bc6.compressed" "myfolder/output_003.bc6.uncompressed"

If i cut the blob up in smaller 32K blocks, the panic happens on the [1507282 .. 1540049) block (in byte indices)

[coopp]

MennoVink , Could this be because of Issue: #41 where compress bounds may be returing incorrect sizes causing an overrun? We haven't done a deep investigation yet here but this sounds like a related cause of the decompressor running off into other memory.

[MennoVink]

Anything is possible. I'd be very surprised though since that issue is about the cpu compressor and this issue is about the gpu decompressor.

[coopp]

MennoVink , I am going to take a quick peek at this today. One thought I had which I want to validate is the version of the DXC compiler that is being pulled down via vcpkg to compile the GDeflate shader.

A while back the DirectStorage team hit an issue with the GDeflate fallback shader acting strange. This was due to us taking a newer DXC compiler internally and using it to compile the built-in shader.

The latest HLSL DXC compiler was changed a while back to have a different default HLSL language version setting. ( was 2018 and is now 2021 ). Since we do not explicitly set the preferred language (Example -HV 2018) in the compiler options, we are pick up whatever the compiler's current default is.

If you beat me to this investigation, my plan was to add the following to the arguments vector in the CompilerShader( ) helper.

std::vectorstd::wstring arguments;
arguments.push_back(L"-HV 2018");

[MennoVink]

Unfortunately both 2018 and 2021 have these panics. The DeviceRemovedReason being:
The GPU will not respond to more commands, most likely because of an invalid command passed by the calling application.

If you are able to use the shader when using an internal DXC compiler, would you be able to provide the spir-v shader? The target application i'd be interested to use this in uses Vulkan.

[coopp]

Thanks for trying out the 2018 compiler option. Looks like there needs to be some more investigation then. We will keep this active in our bug list then.

Unfortunately I don't have a spri-v version of the shader. It is pretty interesting that you are trying this out with Vulkan. I think the public shader compiler when you build it, can be configured to generate spir-v..
https://github.com/Microsoft/DirectXShaderCompiler/wiki/SPIR%E2%80%90V-CodeGen

[MennoVink]

I think the public shader compiler when you build it, can be configured to generate spir-v..

Yeah i'm compiling it with dxc to spir-v and loading that, but it causes the same gpu panics. I just thought if you guys are using this shader without much issues when compiling it with an internal version then perhaps you could do it since i dont have access to that version.

Anyway, i dont want to derail this issue too much. This issue is about the demo panicing with this blob.
If you need more help reproducing the issue, or if there's more info i can provide please let me know, for now i can continue internal development using the cpu decompressor.

[MennoVink]

What is the status of this issue in your internal bug list?

I'll be developing a new version of our video codec next year and would like to know whether gpu decompression would be a viable next-gen feature i could include.