webatintel / aquarium Goto Github PK

Currently, Aquarium using instance rendering to config different WorldUniforms and Seaweed moves.
Maybe dynamic buffer offest is a option solution.

The rough idea is to export conventional environment variables like CC and CXX for Emscripten, use getenv() to define the commands and flags of a custom toolchain, and then one can override the default toolchain with the help of custom_toolchain.

Some early experiment shows that a bunch of GN args may be needed apart from custom_toolchain, due to the incompatibility between Emscripten and Clang/GCC. That is to say, the Emscripten build will not be supported as perfect as native builds.

Our current main trouble is that the exsitence of libatomic and its friends is assumed in //build, while Emscripten uses musl and there's a longstanding known issue that only a monolithic libc is shipped. Therefore, an Emscripten side patch is expected.

Aquarium seaweedVertexShader has a uniform buffer seaweedper here. It's layout is std140. Refer to OpenGL 4.5 spec, Chapter 7.6.22, the padding rules is :

If the member is an array of scalars or vectors, the base alignment and array
stride are set to match the base alignment of a single array element, according
to rules (1), (2), and (3), and rounded up to the base alignment of a vec4. The
array may have padding at the end; the base offset of the member following
the array is rounded up to the next multiple of the base alignment.

Aquarium needs to follow the padding rules to calculate created buffer size. This will resolve a metal backend debug layer error.

Hi,

Thanks for providing a native implementation of the well known WebGL Aquarium scene using the not yet finished WebGPU specification. This project nicely brings together different aspects of a more complex scene such as: MSAA, instanced draws, MIP mapping, Cube maps, etc.

I could not yet find a javaScript version of the Aquarium scene using the WebGPU API, so I had a look into porting the 'aquarium-optimized' version to TypeScript which transpiles to JavaScript. I followed the native implementation as close as possible and added type information similar to the native version. Therefore the code has types such as int, uint32_t, size types that are all aliases of a TypeScript number. To reduced the amount of files, I grouped texture and model classes into single files.

The WebGPU API is very similar to the Dawn api so a one-to-one mapping was very straightforward. I only struggled with the textures:

• Mip maps were not properly rendered. Most of the meshes appeared with a gray texture, only the seaweed texture was more or less ok. Each mip map appeared correct on a canvas but not on the mesh. I could not really find the cause of the issue so I used an alternative approach from here.
• At this moment I have not figured out how to properly render a cube map. The arrayLayerCount parameter seems to be missing on the SamplerDescriptor. Setting a depth of 6 in the size parameter of the SamplerDescriptor, resulted in no errors but the resulting Cube map is not as expected. Maybe I overlooked something, but further testing is needed.

Below you can find a screenshot of the current version. Every entity from the scene is enabled, except the inner globe (due to the cube map issue described above).

The screenshot below shows the full scene with the (faulty) inner globe enabled.

As a reference, the latest code is available in this git repo, I also pushed an online demo on this link. Chrome Canary with the enable-unsafe-webgpu flag set is needed in order to see the online demo. Other browsers such as firefox nighly were not tested yet.

There are still some todos left for the next weeks. It might be interesting to evaluate the performance of this WebGPU version to its native counterparts in the future.

Are there any plans to add other aspects from the WebGL Aquarium scene, such as view switching and bubbles?

Best regards,
Sam

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?

Moved the discussion (#168) to this issue for better tracking the discussion.

@hujiajie
Dawn provides GN args like dawn_enable_d3d12 to control if a certain backend will be compiled, and AGNLE has similar flexibility. Note these variables are meant to be customized by users since they are in the declare_args() block, so it sounds like an Aquarium bug if the following won't work:

gn gen out --args="dawn_enable_d3d12=false"
ninja -C out
I'm not worried about the readability / maintenance burden at the moment, but @gyagp has a different opinion. Thoughts? @Jiawei-Shao @shaoboyan

@gyagp
The benefit of this can be binary size, which is not a big concern of Aquarium. But the price is readability, maintenance and testability. I don't think we ever tested all these combinations, and I don't think we will have bandwidth to do this in near future.
ANGLE and Dawn have many other GN args we don't need to bring into Aquarium.

https://en.wikipedia.org/wiki/Multiple_buffering#Triple_buffering

In short, the program don't need to wait for vsync to render a frame, but frames are still displayed at 60FPS or less without tearing.

Currently the ANGLE backend cannot be built together with the OpenGL backend, while the expected behavior should be:

• Do not link with system GL or ANGLE at build time
• Dynamically load system GL when Aquarium is asked to use the OpenGL backend
• Dynamically load ANGLE when Aquarium is asked to use the ANGLE backend

When it comes to the WebGL port, there's a problem that Emscripten does not support dlopen("libGLESv2.so", flag) well. However, the WebGL port should always use "system GL", so the plan is to pass -lGLESv2 to the linker as an extra flag and make some C++ code guarded with #ifdef __EMSCRIPTEN__.

This is the WebGPU counterpart of #101, so the following modes should be supported by Aquarium:

• Do not link with system WebGPU at build time, except in the WASM build
• Dynamically load system WebGPU when Aquarium is asked to use the WebGPU backend
• Dynamically load Dawn when Aquarium is asked to use the Dawn backend

Dynamically loading system WebGPU is not a quite useful mode at the moment, but it leaves the door open in case some day Dawn or wgpu-native can be installed system-wide.

One challenge is that dynamic loading implies using the C binding, while Aquarium is built on top of the C++ APIs. It should also be noted that the C++ wrapper is not shipped in Emscripten.

Specify fish number in the render loop is an important functionality. This will benefits for performance tuning and testing. We are going to implement the functionality for every backend.

This is the continuation of #165

1. Does it deserve to introduce ContextANGLE inheriting from ContextGL?

2. If yes to (1), where should ContextANGLE.{h,cpp} be placed?

3. If yes to (1), how will the class and directory hierarchy look like if we want to add a native GLES backend in the future?

Proposal A: Update fish positions according to wall clock time (current behavior, as well as that of the original WebGL implementation)

• Pros: Fish appear to have approximately the same speed on different devices
• Cons: Introduces nondeterminism. E.g., fish positions of the frame at the beginning of the tenth second may be calculated using an elapse of 9.000s in the first run, but 9.001s in the second run, resulting in slightly different rendering results, which is bad for auto testing. How to ensure the frame is captured at the exact time (9.000s) can be another problem.

Proposal B: Update fish positions according to frame number

• Pros: Every frame is deterministic
• Cons: Fish may appear fast on some devices but slow on others

Proposal C: Add an option for switching between A and B

• Pros: Switchable between A and B
• Cons: Code path in auto testing (assuming proposal B) may diverge more from the default (assuming proposal A), which is undesired

@hujiajie would you mind list remain works related to infra/rebase to let us understand the status better? Maybe a checklist is great.

• Depending on glfw and dawn_utils at the same time would cause two occurrences of libglfw.a in the linker command line, and this would violate the one definition rule on macOS. (But Windows and Linux builds are not affected because the error only happens when -Wl,-ObjC is specified)
• Depending on dawn_utils would trigger the build of GLFW, which is something we want to gradually get rid of (#100)
• dawn_utils is not emulated by Emscripten, so building it from source will trigger the full build of Dawn and GLFW, which is not yet possible.

Currently Aquarium renders directly to the framebuffer the window system gives to it. The framebuffer size is determined by the GLFW window size (and DPI), which means the maximum will be limited by screen size. To harness the GPU, sometimes it's desired to use an extremely large offscreen framebuffer for rendering, whose size is given by --framebuffer-size, and then "blit" to the window.

I have mixed feeling about dropping //src/aquarium-direct-map.

Pros

• Our maintenance effort can be reduced.

Cons

• It can work as a perf baseline to tell whether abstraction in the "optimized" variant is over-engineered.
• If we prefer to remove it, further discussion about the new directory hierarchy is needed. For example, //src/aquarium-optimized/* can be moved to //src/*, and //src/common seems no longer necessary as well.
• The overall maintenance effort probably won't be reduced much. Usually the difficult part is to come up with a design out of thin air, instead of mirroring the change from one directory to the other.

OutsideModelDawn hits a validation error when executing diffuseVertexShader with Metal debug layer on in Aquarium Dawn backend that mViewBuffer is not as large as what shader expected worldUniforms to be.

Aquarium has been using GLFW for window system binding. This currently works for the D3D backend thanks to the GLFW_NO_API and native access tricks. However, GLFW advertises itself as a library for OpenGL, OpenGL ES and Vulkan development, which makes the D3D use case somewhat weird. Taking the planned WebGPU port in consideration, it also sounds too hard or even impossible to extend Emscripten's GLFW simulation layer for the related APIs, so the only feasible solution there is to use Emscripten primitives instead. The proposal is to replace GLFW with a home-made window system binding implementation by:

• Introducing a window system abstraction layer, and making GLFW a backend of it
• Implementing the Win32 backend
• Implementing the X11 backend
• Implementing the Cocoa backend
• Implementing the Emscripten backend
• Dropping the GLFW backend

And a Wayland backend may also be needed in the future, so that's why the proposal tends to avoid naming the backends using OS names.

Refer to gpuweb issue 404, Dawn, as implementation of WebGPU, requires vertex stride as a multiple of 4 bytes.
Aquarium vertex strides are all happens to be multiple of 4 bytes(Lucky!), but it still needs to take care of this.

If we have src/Context.h, the build of Tint will fail as below:
In file included from ../../third_party/dawn/src/dawn_native/ShaderModule.cpp:30:
In file included from ../../third_party/dawn/third_party/tint/include\tint/tint.h:21:
In file included from ../..\src/context.h:15:
../..\src/Aquarium.h(155,22): warning: missing field 'blend' initializer [-Wmissing-field-initializers]
MODELGROUP::FISH},

When building Tint, it relies on its own src/context.h. Thus if we also have src/Context.h (case insensitive on Windows) in Aquarium src/ folder, the Tint build will use this file instead of its own.

Aquarium destroys the old buffer and create a new buffer to hold the data every time the fish count changes. We hope to simulate a more dynamic scene in which some fish persist for many frames and some fish come and go so that the application behaves like a real game. The scene is only implemented for Aquarium Dawn backend to to test resource allocation and heuristic methods.