kinc_g4_texture_lock() returns null for RGBA128 textures

[MoritzBrueckner]

Describe the bug
Original issue: https://github.com/armory3d/armorcore/issues/17. When locking an RGBA128 texture in Kha/Krom on d3d11, the application crashes. The reason for this seems to be that kinc_g4_texture_lock() returns null when using the RGBA128 format (that's why I'm opening the issue in this repo).

To Reproduce
Minimal example code for Kha:

var img = kha.Image.create(16, 1, TextureFormat.RGBA128, Usage.StaticUsage);
img.lock();

This is the stack trace (the screenshot was made for the original Armorcore issue in March but the problem persists):

In the original issue I also mentioned that it looks like RGBA128 is reserved for compute shaders only (source) and that the CPU might not able to write to the data. I wonder how floats should be written into textures then if the minimum floating point size in Haxe is 32 bit (kha.FastFloat)?

I know about kha.Image.fromBytes() but I need to change data in the texture on each frame and a full re-creation of the texture is too slow.

Expected behavior
The application shouldn't crash and allow access to write 32 bit floats to a buffer.

Execution Environment:

• Host system (where you compile your code): WIndows 10
• Target system (where you run your code): Windows 10
• IDE and/or compiler used: VSCodium/Visual Studio 2019
• Kinc revision: 003aa18

[RobDangerous]

It's indeed only for compute currently (or more specifically for UAVs). Kinc needs some explicit options for that - in the meantime you can just change the D3D11_TEXTURE2D_DESC to the same values as in the else branch and remove the if-block at the end of the function to make it work.
I do not understand what you mean with the float-writing question. KINC_IMAGE_FORMAT_RGBA128 contains 32bit floats so there's no problem. If you use a texture-format that uses 16bit floats you have to do some bit-twiddling - same as in C which also doesn't support 16bit floats natively.

PS: When something doesn't work, please run a debug-build. In this specific case it would have triggered an assert and printed an error message.

[MoritzBrueckner]

Thanks a lot, I will definitely test this as soon as I'm continuing my work on the project I had this issue with.

I do not understand what you mean with the float-writing question.

I was a bit imprecise. What I meant is that if there is no way to write to RGBA128 textures there is probably no easy way in Kha to write floats to a texture (for LUTs for example)? It looks like there is also a grayscale 32 bit float format but that would require multiple samples for reading 3 or 4 floats in the shader if they would otherwise be accessible by sampling just one texel. Or is this irrelevant in terms of performance?

PS: When something doesn't work, please run a debug-build. In this specific case it would have triggered an assert and printed an error message.

Thanks, that's good to know (I didn't even realize that I was using release mode).