add wgpu4k backend

[ygdrasil-io]

Still a lot of work to do.
Most of the scenes on web are working perfectly, but there are some artifacts like this:

Any idea what is wrong ?

[ygdrasil-io]

I've made quite a bit of progress. I had skipped the FP16 texture processing, but that's now fixed. Now all the examples work perfectly on the web, even those that aren't in the menu. I removed the old WebGPU backend since the behavior is now identical.

As for the desktop, it's more complicated. I fixed the colors by better selecting the surface texture format. I prioritize 8Unorm formats without sRGB, and now I have the same colors as on the web.

However, certain scenes like the island crash with the following logs:

   1,235 s|f:   9  D  AssetLoader.loadBlob: Loaded blob https://kool.blob.core.windows.net/kool-demo/heightmaps/terrain_ocean.raw (0.5 mb, 16.091667ms)
   1,432 s|f:  10  D  Wind: Generated wind density in 0.179 s, tex saturation: min = 0.08506501, max = 0.9578181
   1,488 s|f:  12  I  OpticalDepthLutPass: Updating atmosphere depth LUT: atmosphere radius = 65.0, surface radius: 60.0, falloff: 9.0
19 actionable tasks: 5 executed, 14 up-to-date

thread '<unnamed>' panicked at src/lib.rs:417:5:
wgpu uncaptured error:
Validation Error

Caused by:
  In wgpuRenderPassEncoderEnd
    In a pass parameter
      The color attachment at index 0's texture view is not renderable:
        The dimension of this texture view is not 2D. View dimension: D2Array

Not sure what is causing the crash yet, but that happened during the offscreen pass of "sky-cube". Maybe it's an issue when creating the texture, but that works on the web, so... @fabmax, any idea where to dig?

[fabmax]

Hmm that sounds like something is going wrong with rendering to cube textures. Iirc these are represented as 2d array textures with an array size of 6 (one for each side of the cube). Rendering to a cube texture than basically is a loop where you create a 2d view for each cube side and set that as the render target. The error sounds like it is trying to set the entire array as color attachment and not only a single side.

[ygdrasil-io]

Not all examples necessarily work, but we now have similar behaviors between Firefox and the desktop (which is logical since it's the same backend).

There are still some samples that crash with the message:

  In wgpuDeviceCreateBindGroupLayout, label = 'up-sample-shader-bindGroupLayout[PIPELINE]'
    Binding 4 entry is invalid
      Read-write and read-only storage textures are not allowed by baseline webgpu, they require the native only feature TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES

But wgpu4k does not yet support enabling platform-specific features, I will fix this in the next version.

(Almost) the same code on Java/Firefox/Chrome/Safari (Island is crahsing on safari)

I tried on Mac and Windows, not sure if that is working on Linux.

Android-specific implementation still needs to be implemented, but that can be done in the next iteration.

@fabmax can we merge it in the current state, or do you want some changes?

[fabmax]

That is pretty awesome! On first glance it looks good already. I will give it a closer look + try tomorrow.

For the read-write storage texture access, I remember vaguely that that used to be a problem but at some point was supported by Chrome.

[fabmax]

I gave it a test. A few observations:

Browser (I only tried Chrome)

• Everything works fine, but the instancing test (with instancing disabled) is a lot slower than it was. That test is a stress-test which draws 5000 individual cubes (one draw call per cube). The Scene recording time basically is the time spent in the backend. This isn't super critical because its a rather synthetic test and for typical browser scenes the number of draw calls is usually not the bottleneck. But the size of the difference is weird never the less. I haven't looked into the code too much yet. Maybe it's caused by the changed buffer data upload or something like that.

  Left is yours, right is how it was:
  

Desktop (with WGPU backend)

• Scaled display resolutions seem to not work. If I try to start it on a scaled display, it immediately crashes with this message (I only tried macOS):

wgpu uncaptured error:
Validation Error

Caused by:
  In wgpuRenderPassEncoderEnd
    In a set_viewport command
      Viewport has invalid rect Rect { x: 0.0, y: 0.0, w: 3200.0, h: 1800.0 }; origin and/or size is less than or equal to 0, and/or is not contained in the render target (1600, 900, 1)

• When running the Fighting Bees demo, the console gets spammed with the following log message:
  20:41:16.761 [main] INFO io.ygdrasil.webgpu.Buffer_native -- mapped
  The log output even continues after switching away to another demo (but after restarting, it only begins when opening Fighting Bees)

• Demos that use a skybox seem to only render the first mip-level of the skybox. That results in very glossy looking surfaces, because the higher mip-levels of the skybox are missing (the higher mip-levels are usually used for reflections of surfaces with higher roughness values). In the browser it looks fine.
  

[fabmax]

Ok, I changed stuff a little bit, since there were a few things I didn't like:

• wgpu4k seems to require jdk version at least 22 (correct me if I'm wrong, but 21 doesn't work because some dependecies require at least v22). I wouldn't mind moving to a newer min jdk version but it should at least be an LTS version, so 21 currently. As a solution I moved wgpu4k into a separate module kool-backend-wgpu4k, so that kool-core can stay the way it is jdk version-wise.
• The way the suspending functions were wrapped on js (with GlobalScope.launch {}) seemed a bit unsafe. Especially the way the backend was created with a lateinit member. I therefore reverted these functions to be non-suspending and moved the suspend wrapper code into the wgpu4k backend implementation. Only weird thing is that now GPUShaderModule.checkErrors in WgpuPipelineManager fails with some coroutine handler exception. I commented it out, so no error message currently if shader compilation fails.
• I also restored the old WebGPU implementation in kool-core for now, since it seems to be faster.

kool-demo adds kool-backend-wgpu4k as a dependency so it is usable by simply setting config.renderBackend = Wgpu4kBackendProvider in code and adding &backend=wgpu4k to the url if it's running in the browser.

I think this is now mergable.

[ygdrasil-io]

Thanks for the changes.

The project indeed requires Java 22 to use the stable Panama API. The next LTS is in September, which gives us time to fix the remaining issues.

I'm a little busy right now, but I will get back to this in a few weeks. If that's alright with you, you can merge it as is, and I will create dedicated issues and merge requests to fix what's wrong, starting with the web.