[x3d-public] GPU APIs and X3D

[Andreas Plesch]

I came across this lengthy, in depth write up:

https://toji.github.io/webgpu-gltf-case-study/

It goes into how to use WebGPU appropriately to render glTF, from a
probably OpenGL inspired, straight-forward approach, to an optimized
approach. These are the design patterns which will be helpful.

For example, it is important to reduce the number of pipelines.
Easiest would be one pipeline per shape but there are strategies to
reduce that by collecting reused geometries.

The authors does not like shader variants which is what x3dom is
doing, eg. building a custom shader for each combination of requested
features, and caching it. A change in shader requires a different
pipeline.

StaticNodes may become more important for performance enhancements.

Perhaps there will be an opportunity to take advantage of DEF/USE for
GPU instancing, possibly with special DEF names advertising targets
for GPU instancing.

There is not too much discussion in the article on how to approach a
general purpose renderer which needs to render anything such as the
glTF <model-viewer> but there are some ideas.

-Andreas





On Sun, Jul 16, 2023 at 7:42 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Thank you, Michalis and Doug, for your comments.
>
> Looking around I found that WebGPU is partially based on Vulcan and as such related. Perhaps concepts and strategies would map over. Interestingly, WebGPU or wgpu is also apparently considered a desktop API and not just restricted to the web, probably due to cross-platform considerations.
>
> One aspect of WebGPU is better support for general, massively parallel computation on the GPU, as Doug points out.
>
> One of the simpler points is that X3D custom shaders would move away from glsl to wgsl and spirv. There are translators as well (https://github.com/gfx-rs/naga). As has been discussed, for portability X3D could have a standard set of uniforms.
>
> Andreas
>
>
> On Sat, Jul 15, 2023 at 4:52 PM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
> >
> > We do plan to add Vulkan renderer to Castle Game Engine. Some plans
> > and initial insights are on https://castle-engine.io/roadmap#vulkan .
> >
> > In the meantime, I think OpenGL will remain available for a long time.
> > At this point in time, the "OpenGL family" (OpenGL + OpenGLES + WebGL)
> > is the only way to really have cross-platform API, the includes all
> > desktops (Windows, Linux, macOS, FreeBSD...), mobile (Android, iOS),
> > web (WebGL in all browsers) and even console (Nintendo Switch; ANGLE
> > allows to use OpenGL on Xbox). So I think there's still plenty of time
> > to migrate... but indeed, Khronos explicitly said that after OpenGL
> > 4.6, focus is on Vulkan.
> >
> > Regards,
> > Michalis
> >
> > sob., 15 lip 2023 o 05:35 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
> > >
> > > Although X3D is a high level scene graph, it is influenced by OpenGL
> > > and many, perhaps all X3D browsers use OpenGL or the similar WebGL as
> > > an API to draw pixels.
> > >
> > > OpenGL is not updated anymore and other APIs are now dominant: Metal,
> > > Vulcan, Direct3D12 and now WebGPU. It is already available in most web
> > > browsers as an alternative to WebGL2. WebGPU is cross-platform, close
> > > to GPU instructions and can be very performant.
> > >
> > > Did anybody think about or actually try to use something other than
> > > OpenGL for X3D rendering ?
> > >
> > > It is time to start speculating and mind mapping how one would go
> > > about designing a new X3D browser which uses another low-level API.
> > > Ideally, X3D is abstract enough that the choice of graphics API does
> > > not matter much. But there are certainly many aspects that an
> > > implementation has to consider which depend on the low-level API, from
> > > the design stage to actual coding.
> > >
> > > https://webgpufundamentals.org/webgpu/lessons/webgpu-from-webgl.html
> > > has a detailed comparison between WebGL and WebGPU.
> > >
> > > WebGPU is lower level. One example mentioned above is ImageTexture.
> > > With WebGL it is possible to just change the source image for the
> > > texture, and everything else in the rendering process can stay the
> > > same. With WebGPU it is necessary to destroy the old texture, and
> > > rebuild a pipeline in case the ImageTexture is changed.
> > >
> > > A Shape corresponds to a draw call in WebGL. For WebGPU a Shape
> > > presumably still could correspond to a draw call but it is also
> > > possible to bundle all draw calls for a Scene and submit those in one
> > > call. That seems interesting but it is unclear how event flow may
> > > affect this option.
> > >
> > > Any experience with nonGL APIs may be insightful.
> > >
> > > Andreas
> > >
> > > --
> > > Andreas Plesch
> > > Waltham, MA 02453
> > >
> > > _______________________________________________
> > > x3d-public mailing list
> > > x3d-public at web3d.org
> > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



--
Andreas Plesch
Waltham, MA 02453