[x3d-public] GPU APIs and X3D

Wed Jul 19 18:58:30 PDT 2023

That is, is there a suitable ECMAScript API that I target, I don’t mind,
X3DOM, X_ITE/VRMLScript, Three.js, glTF->webGPU,  or Babylon.js? It would
make sense that they already support WebGPU, perhaps using “headless”
Node.js for video rendering.   The primary requirement is hiding the WebGPU
 layer, but perhaps later using an “unrolling” method to remove API calls
and use WebGPU directly—think of WebGPU as a sort of Assembly language.   I
realize that the shaders will likely be precompiled.  Perhaps WASM already
supports WebGPU?

Is Chrome the primary WebGPU target presently?

Would it make sense to use Node.js puppeteer (wainwright disappeared?) or
the like to record WebGPU videos?

I’ve tried a bit to write a serializer for X3D DOM document (read
JavaScript object) conversion to Three.js.   Perhaps it’s time to return
there?

I don’t want to get into a big discussion about the merits of generating
code.   Compilers do it all the time.

I’m also fully supporting CLI.  Thanks, Michalis, so there’s other ideas in
the pipeline (support for a Pascal generator).

John

On Wed, Jul 19, 2023 at 6:47 PM John Carlson <yottzumm at gmail.com> wrote:

> 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/2a8835af/attachment-0001.html>