[x3d-public] GPU APIs and X3D

Andreas Plesch andreasplesch at gmail.com
Wed Jul 19 19:31:58 PDT 2023 

The problem is one cannot mix and match WebGPU and WebGL, or Vulcan
and OpenGL. It is one or the other. So it is not possible to render
glTF with WebGPU and the rest with WebGL. So targeting just glTF would
not be very useful.

As for targeting X3D, I am afraid, spending not a lot of time is not
an option. Both, three,js and Babylon.js now have WebGPU renderers. So
it would be possible to target either and get WebGPU more or less as a
by-product. But this is a huge task. Limited attempts have been made
(there is an old three,js X3D importer) but these are different enough
from X3D in their scene graph structure that full support is hard and
time consuming. For example, both do not allow multiple parents, so
USE nodes would have to.be copied. I remember it was quite difficult
to implement a full Background node in Babylon.js. The event systems
are very different, eg. no cascades. But even ignoring any dynamic
aspects, just supporting all graphical X3D nodes is a lot of work.
Cheers, Andreas

On Wed, Jul 19, 2023 at 9:58 PM John Carlson <yottzumm at gmail.com> wrote:
>
> 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



-- 
Andreas Plesch
Waltham, MA 02453

More information about the x3d-public mailing list