Multithreading about sokol

[floooh]

Not in sokol_gfx, but most likely in a sokol_gfx 2.0. Here's my thinking:

The main reason why sokol_gfx doesn't expose command buffers at all are basically all the GL platforms, especially WebGL (and actually D3D11 too). Those backends would need to emulate command buffers (but only for the very coarse 'commands' of the sokol_gfx API (beginpass, applydrawstate, ... etc...).

Once WebGPU becomes available I will most likely fork off this sokol_gfx 2.0, which would basically be "sokol for modern 3D APIs", instead of GL, D3D11 and Metal, this would support Vulkan, D3D12, Metal 2.0 (and WebGPU of course). This would still be a very simple and opinionated API, but would expose multithreading via command buffers/lists, and also support compute.

[boberfly]

@floooh would you perhaps add compute support to the current sokol and hide it under a capability flag? For DX11/Metal/GL ES3.1 only that is. I'm thinking of using sokol as a fallback to a framework which is targetting Vulkan/D3D12/Metal2.0 (commands are cpu-only already and fairly coarse). Cheers!

[amerkoleci]

I see, the next webgpu should be part of this project https://github.com/google/nxt-standalone
Maybe you can concept of command context and have immediate context as now and support command list with emulation on OpenGL?
Or capacity flag for command buffers.

You have metal support there, D3D11 support Deferred context, only OpenGL would need emulation probably.

[HiImJulien]

Sorry for resurrecting this closed issue. As an additional note to what @amerkoleci said:
nVidia provides the NV_command_list extension for OpenGL. So, this feature would only require emulation on devices, that do not support this extension.

@floooh Since support for <threads.h> is basically non-existent, how do you plan on synchronizing threads? Are you going to drop in a third-party implementation or are there any plans to roll a custom solution?

I was thinking about rolling an header-only implementation myself (which is NOT just a wrapper for pthreads, unlike those implementations I've found so far); might as well contribute it to the project.

[floooh]

No plans for a command-list API for sokol_gfx.h, IMHO this only really makes sense once traditional 3D APIs can be dropped (e.g. only Metal, D3D12, Vulkan and WebGPU would need to be considered). IMHO that's a topic for "sokol_gfx.h 2.0" (as I wrote above).

What I'm thinking about though is to move resource creation into threads if the underlying 3D API allows this, this wouldn't require public API changes (since asynchronouse resource creation is already "designed into the API"), this would be especially important for pipeline creation, because this can be quite expensive on some APIs (e.g. Metal).

But before that I'd like to overhaul the entire dynamic resource update API area (sg_update_buffer, etc...).