Kode/Kha

RGBA128 texture is silently changed to R8_UNORM on d3d11

MoritzBrueckner opened this issue · 1 comments

MoritzBrueckner commented

Describe the bug
When passing an RGBA128 texture to a shader on windows-hl/d3d11, the texture format seems to get silently changed to R8_UNORM according to both RenderDoc and Intel GPA. This creates unexpected results in the shader.

I noticed that there are some places in the Kinc code where the usage of formats seemingly gets restricted (like here), however I'm not sure if the linked code is actually run in my case. Because of that, Kode/Kinc#623 might be a related issue. I'm not sure if it is possible at all to use RGBA128 textures on all targets, but if not this is something that needs to be documented somewhere.

To Reproduce

  1. Create an RGBA128 texture: 
    tex = Image.create(256, 256, TextureFormat.RGBA128);
texData = tex.lock();
// Write something...
tex.unlock();
  2. Pass the texture to a shader: 
    g4.setTexture(textureUnit, tex);
// ...
g4.drawIndexedVertices(...);
  3. Build for windows-hl with d3d11 and compile the project in Visual Studio.
  4. Open the project in a graphics debugger and inspect the texture, the format is now R8_UNORM.

Expected behavior
The texture format should be DXGI_FORMAT_R32G32B32A32_FLOAT instead of DXGI_FORMAT_R8_UNORM so that you can directly sample vec4 values in the shader.

Screenshots
RenderDoc screenshot

Execution Environment:

  • Host system (where you compile your code): Windows 10
  • Target system (where you run your code): Windows 10
  • IDE used (if any): VSCodium/Visual Studio
  • Kha revision: ad815d6, all submodules are checked out to the specified versions.
RobDangerous commented

This was purely an HL problem and wasn't related to any actual graphics implementation things.
The HL backend isn't really actively maintained (I don't use it myself), would be great if somebody could jump in.

  • 👍1