The Great Move / Rename

[hujiajie]

Obviously: //src/aquarium-optimized/*.{cpp,h} → //src/*.{cpp,h}

Opens:

• //src/common/* → //src/* or //src/util/* or something else?
• .../d3d12/, .../dawn/ and .../opengl/ are named inconsistently: d3d12 is the (abbreviated?) API name, opengl is the (formal) API name, while dawn is the implementation name of the WebGPU API.
• The filename suffix like D3D12 in .../d3d12/*D3D12.{cpp,h} or Dawn in .../dawn/*Dawn.{cpp,h} duplicates the directory name, therefore looking a little redundant. However, I also vaguely remember identical filenames should be avoided in Chromium (?), even if they are in different directories. Perhaps this is due to troubles about debug symbols, say the ambiguity of b Foobar.cpp:42 when using gdb? So I doubt it's a good idea to omit the suffix. But what about .../formal-API-name-as-directory-name/*abbreviated-API-name-as-suffix.{cpp,h}?
• Can someone answer the remaining questions here?

[gyagp]

• //src/common/ → //src/ or //src/util/ or something else? I prefer src/

• .../d3d12/, .../dawn/ and .../opengl/ are named inconsistently: d3d12 is the (abbreviated?) API name, opengl is the (formal) API name, while dawn is the implementation name of the WebGPU API. All the names are fine, and Dawn project uses the same. My understanding of WebGPU API is web API, while Dawn is API to unify 3 native APIs, which has no specific name other than Dawn.

• The filename suffix like D3D12 in .../d3d12/D3D12.{cpp,h} or Dawn in .../dawn/Dawn.{cpp,h} duplicates the directory name, therefore looking a little redundant. However, I also vaguely remember identical filenames should be avoided in Chromium (?), even if they are in different directories. Perhaps this is due to troubles about debug symbols, say the ambiguity of b Foobar.cpp:42 when using gdb? So I doubt it's a good idea to omit the suffix. But what about .../formal-API-name-as-directory-name/*abbreviated-API-name-as-suffix.{cpp,h}? Just leave them as they're now. This is also the naming convention of Dawn.

[hujiajie]

It seems bgfx prefers webgpu, so usually I'm not confident enough just because "this is used in project Foobar". And if we can figure out the final picture earlier, there's a chance that following bulk rename caused by unresolved questions can be squashed here, for easier git blame or cleaner Git history.

[gyagp]

If some famous projects that target similar objection as we do, we may borrow some ideas from them, such as Dawn here. If there is no strong preference that one naming is much better than the other, just keep the current one to save effort. WebGPU and Dawn are two different things for me, WebGPU is web API, while Dawn is a native API. Maybe later on, we will have a webgpu folder to make Aquarium webgpu (web) version run better. And in theory, we can make Aquarium work with another native impl. of WebGPU, like wgpu from Mozilla. So I still prefer to keep the names as now they are.

[shaoboyan]

-while dawn is the implementation name of the WebGPU API.`

Not agree with this, dawn is an native API has its own primitives. and defines its own progress to render something You could take it the same level as D3D12/Metal/Vulkan(Pls ignore the current impl, I'm not surprised if some vendor support dawn API directly in future).

[hujiajie]

It sounds we are on completely different pages...

WebGL ⟷ WebGPU OpenGL / OpenGL ES ⟷ how to call this, Dawn or WebGPU? ANGLE ⟷ Dawn / wgpu

I have strong preference on WebGPU because:

• The API header is named webgpu.h. It's unreasonable to name the API with a word even not found in that file.

• Currently we have these GN arguments:

enable_angle # call OpenGL APIs + build ANGLE
enable_opengl # call OpenGL APIs
enable_dawn # call XXX APIs + build Dawn

Now consider the Emscripten port, which resembles the situation of "some vendor support dawn API directly" a lot. We will call XXX APIs, but without building Dawn, so I think a forth argument should be added:

enable_angle # call OpenGL APIs + build ANGLE
enable_opengl # call OpenGL APIs
enable_dawn # call XXX APIs + build Dawn
yyy_zzz # call XXX APIs

It shows the beauty of symmetry with s/XXX/WebGPU/g and s/yyy_zzz/enable_webgpu/g. How are you going to define the arguments if the API is called Dawn?

• Dawn, a WebGPU implementation, so Dawn is the implementation and WebGPU is the API name, sudo!

[hujiajie]

Note now I'm discussing the API name only, not the final directory hierarchy of Aquarium or how to migrate to that hierarchy.

[shaoboyan]

The API header is named webgpu.h. It's unreasonable to name the API with a word even not found in that file.

That's correct and a pain to integrate into Chromium quickly. If this is the decision base, pls left a comment to describe this and I agree with the API name with WebGPU, but it refers to the native API sets(Important).

But still have some comments:

Currently we have these GN arguments:

enable_angle # call OpenGL APIs + build ANGLE
enable_opengl # call OpenGL APIs
enable_dawn # call XXX APIs + build Dawn

If you take GN args as the reference, then you're right. But I believe GN config is CHROMIUM behaviour and opinion with lots of balance. I don't think they tend to define API and implementation for such compile flags since the final goal is to adopt proper backend implementation on different platform.

Dawn, a WebGPU implementation, so Dawn is the implementation and WebGPU is the API name, sudo!

It means Dawn is A WebGPU implementation, so we may have ”twilight” as A WebGPU implementation too. So how aquarium handle it with the same WebGPU API(unless you add another abstract level which is same to WebGPU) but having totally different native APIs?

[hujiajie]

If you take GN args as the reference, then you're right. But I believe GN config is CHROMIUM behaviour and opinion with lots of balance. I don't think they tend to define API and implementation for such compile flags since the final goal is to adopt proper backend implementation on different platform.

Do you have a concrete plan to cover the Emscripten case? We can vote on this.

It means Dawn is A WebGPU implementation, so we may have ”twilight” as A WebGPU implementation too. So how aquarium handle it with the same WebGPU API(unless you add another abstract level which is same to WebGPU) but having totally different native APIs?

At build time:

enable_webgpu # call XXX APIs
enable_dawn # call XXX APIs + build Dawn
enable_twilight # call XXX APIs + build twilight

At run time:

aquarium --backend webgpu # load system / vendor's implementation
aquarium --backend dawn_foo # load Dawn's implementation
aquarium --backend twilight_bar # load twilight's implementation

Sorry I misread the question. If "twilight" defines a totally different set of APIs:

at build time

enable_twilight # call TOTALLY_DIFFERENT APIs + build twilight
enable_name_of_the_totally_different_api # call TOTALLY_DIFFERENT APIs,
                                         # if the system / vendor provides an implementation of the API

at run time

aquarium --backend twilight_{d3d12,vulkan,metal} # load selt-built twilight
aquarium --backend name_of_the_totally_different_api # load the system / vendor implementation

I don't see the role of WebGPU here.