[x3d-public] GPU APIs and X3D

Wed Jul 19 16:47:26 PDT 2023

Hey guys, I’m interested in converting glTF to WebGPU ECMAScript code, but
I can’t spend a lot of time on it, that is, I really need an “SAI-like” API
to convert to.  Do we have something in mind?

John

On Wed, Jul 19, 2023 at 5:33 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Yes, that was the most helpful article I have seen.  Since WebGPU is
> low-level and does not do anything automatically there will be many
> pitfalls, and places for optimization.
>
> I saw there is a planned extension for hardware supported raytracing.
> Perhaps it would make sense to make this the main target since replacing
> shaders and pipelines by itself may not be super exciting.
>
> Andreas
>
> On Wed, Jul 19, 2023, 4:14 PM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
>
>> 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
>>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230719/54d3458d/attachment-0001.html>