[x3d-public] GPU APIs and X3D

[Michalis Kamburelis]

Thank you for posting this,
https://toji.github.io/webgpu-gltf-case-study/ is very valuable. Lots
of information I needed given in a practical form :)

Regards,
Michalis



pon., 17 lip 2023 o 22:57 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> 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