webatintel / aquarium Goto Github PK
View Code? Open in Web Editor NEWLicense: BSD 3-Clause "New" or "Revised" License
License: BSD 3-Clause "New" or "Revised" License
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:
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.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}
?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:
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:
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
Does it deserve to introduce ContextANGLE
inheriting from ContextGL
?
If yes to (1), where should ContextANGLE.{h,cpp}
be placed?
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)
Proposal B: Update fish positions according to frame number
Proposal C: Add an option for switching between A and B
@hujiajie would you mind list remain works related to infra/rebase to let us understand the status better? Maybe a checklist is great.
-Wl,-ObjC
is specified)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
Cons
//src/aquarium-optimized/*
can be moved to //src/*
, and //src/common
seems no longer necessary as well.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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.