Giters

floooh / sokol

minimal cross-platform standalone C headers

Home Page:https://floooh.github.io/sokol-html5

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

sokol_gfx.h: WebGPU Backend TODO

floooh opened this issue · comments

commented
  • new validation error: "Buffer binding size cannot be zero."
  • cgltf-sapp: needs compressed texture extension
  • cubemaprt-sapp: rendering to MSAA layered textues (e.g. cubemap) not allowed in WebGPU
  • cubemaprt-sapp: Buffer binding size cannot be zero (new issue after the above MSAA rendering problem had been fixed)
  • sokol_fontstash.h: add WebGPU shader
  • sokol_gl.h: add WebGPU shader
  • pixelformats_sapp.h: fix renderable pixel formats caps for WebGPU
  • plmpeg_sapp.h: decoded textures broken (green tint and junk on right border, the latter is most likely a bug in the texture data upload)
  • the sgl-lines-sapp demo has rendering artefacts (every few frames one object is rendered at wrong position, uniform update problem?)
  • the cubemaprt-wgpu sample has a very quickly growing memory leak with the Metal backend (not tested elsewhere yet). About 20 MB per frame.
  • sokol-gfx needs to add 64 KB to the uniform-buffer size (since this is the max uniform block size on NVIDIA)
  • update sokol-gfx and sokol-app documentation
  • update sokol_gl.h, sokol_imgui.h and sokol_fontstash.h documention (new SOKOL_WGPU macro)
  • add "sample_count" to sg_context_desc, and add a sapp_sample_count() function to sokol_app.h
  • example code in sokol-glue documentation header
  • blog post
  • README update

Other:

  • put d3d11, gl, mtl and wgpu specific members in sg_desc into nested structs
  • Move the following sg_desc members from the backend-specific context nested struct into the backend-agnostic part:
    • global_uniform_buffer_size (rename to uniform_buffer_size)
    • global_staging_buffer_size (rename to staging_buffer_size)
    • sampler_cache_size (rename to sampler_cache_size... or sample_cache_num_items?)
    • render_format (rename to color_format)
    • add depth_format
      Use color_format and depth_format as defaults for pipeline state creation (and in the validation layer)
  • emscripten builds currently don't support closure, need to investigate whether there's something missing from emscripten's WebGPU support, or whether it's in my own code.
  • fix all sokol-samples for the new sg_desc
  • fix the chips emulators for the new sg_desc
  • fix v6502r for the new sg_desc
commented

[FIXED]

...sg_setup(&(sg_desc)...) is becoming unwieldy because of all the external backend-context-specific data that must be passed in (D3D11/Metal/WGPU device pointer etc...).

Solution:

  1. Put all those backend-specific 'context parameters' into a sg_context_desc struct embedded into sg_desc.
  2. Add a header sokol_glue.h which adds special glue functionality for combinations of sokol headers. For instance when sokol_app.h and sokol_gfx.h is used together, a helper function is added which returns an initialized sg_context_desc struct. The sokol_glue.h header would be included last and automatically detects the header included before it...
commented

...the sgl_lines_sapp problem was actually a bug in sokol_gl.h: e5ca86f

commented

...the plmpeg problem was a bug in the staging offset computation when uploading dynamic texture data.

commented

Which commit from Dawn should Sokol WebGPU backend be used? I am trying it out but I'm getting compile errors due to dawn API changes.

commented

Which commit from Dawn should Sokol WebGPU backend be used? I am trying it out but I'm getting compile errors due to dawn API changes.

Unfortunately I'm behind with the Dawn/WebGPU API updates, and hadn't updated the sokol WGPU backend code yet to the latest API changes. If you want to experiment with the WebGPU backend already I think it's best if you create a fork of sokol-gfx for now and fix the parts that no longer compile (it should be mostly renamed type- and function names).

commented

Hey @floooh I was going to mention maybe it would be better to base your code off of the gfx-rs adaptation of WebGPU over the Google version? They even offer prebuilt binaries for C. In theory the C header is the same between both but the gfx-rs version is easier to compile by a long shot 😄

See:
https://github.com/gfx-rs/wgpu-native
https://github.com/gfx-rs/wgpu-native/releases

commented

The prebuilt libraries would be an option if they came as static linker libs, unfortunately there's only a DLL + C header in those zips. I'm also not thrilled about adding another compiler toolchain (Rust) to the mix when building from source.

In the end this is the user's choice though, sokol_gfx.h will not depend on one or another, at least once the differences between the different "WebGPU flavours" (Google vs Mozilla vs Apple) are resolved. Using one over another would only be relevant for the sokol-samples repository.

commented

If I am not mistaken the internals methods (wgpu_platform_start etc) used in wgpu_entry.h are only implemented in emscript and for MacOS, right? Any plan to have a Windows version (based on dawn?).

Btw the https://github.com/gfx-rs/wgpu-native/releases contains now static linker libs.

commented

The current state in the wgpu branch is still very WIP, especially for "native" bindings (and yes, ATM it's only Emscripten and macOS). Currently the wgpu branch is also in a lull again waiting for the various implementations to consolidate (e.g. what's in the spec vs. what's in libdawn, Emscripten SDK and browsers - also not just for the API but also for WGSL).

The plan is definitely to support native WebGPU implementations (at least gfx-rs/wgpu-native and libdawn) in sokol_app.h, assuming the initialization can be done entirely through a C API (this is surprisingly tricky because part of the swapchain setup and window system glue isn't or at least wasn't entirely covered by the WebGPU API itself, for instance libdawn required to call into "private" C++ APIs in the past). C++ might actually be doable, the same way like the sokol_app.h UWP backend currently requires to be compiled in C++, or the macOS/iOS backend must be compiled in ObjC, but if wgpu-rs requires any part to be implemented in Rust it would be a showstopper of course.

The plan is to finish all this stuff right before WebGPU 1.0 is officially "unlocked" in browsers.

commented

Any eta yet? I have a key for publishing webgpu apps in chrome.

commented

During the last round of updates, the WebGPU API (or rather WGSL) was still very much in flux, I'll look into the branch again when it looks like 1.0 is closer.

commented

This might interest you while developping: https://github.com/eliemichel/WebGPU-distribution

I developped this for my WebGPU C++ guide in order to always leave the choice of the backend (Dawn vs wgpu-native), and for me to easily switch to test that my examples are compatible with both. It is more particualrly introduced in this chapter of the guide.

Note that in theory your code should neither be based on Dawn nor on wgpu-native, it is solely based on the standard webgpu.h and the backend choice is a compilation detail. But well of course this is theoretical because both backends are still a bit different.

Some notable differences that I have noticed:

  • First there is the Drop vs Release question. It is likely that the final word will be in favor of Release. Note that as long as you do not use Reference to increment the reference counter that Release decreases, Release is equivalent to Drop.

  • Implicit release: wgpu-native releases/drops objects in some procedures (for instance wgpuCommandEncoderFinish drops the command encoder). Dawn never does.

image

  • Dawn still does not have a wgpuSurfaceGetPreferredFormat.

  • wgpu-native has a more basic support of WGSL (no type aliases, more conservative typing).

  • wgpu-native does not implement wgpuInstanceProcessEvents yet (it processces events upon any call to the API). This can be worked around by calling a no-op like wgpuQueueSubmit(queue, 0, nullptr).

commented

The WebGPU backend has been released now.