[x3d-public] GPU APIs and X3D

[Andreas Plesch]

Thanks. True, the first step may be to translate webGL2 code to WebGPU in a
1:1 manner, with some helpers or wrappers.

Since frameworks such as threejs or Babylonjs already have WebGPU support
in parallel to WebGL2 it will make sense to look at those for such a
translation.

 My understanding is that webGL2 will be supported for an extended period
of time. So there will be time to understand better how WebGPU could be
leveraged best.

For example, a major difference is that WebGPU does not have global state.
Sharing resources may be more important. Speculating, in terms of X3D it
may mean that it would more appropriate to collect all textures in an
indexed node and then refer to them by index as needed.

Andreas



---on the phone---

On Sat, Jul 15, 2023, 2:59 AM John Carlson <yottzumm at gmail.com> wrote:

> Andreas, I didn’t read the whole article, but my first non-performant
> thought is to provide an ANGLE-like WebGL3 polyfill on top of WebGPU that
> makes initial porting easier.   I realize there are new things in WebGPU we
> want to leverage that might be added to WebGL3.
>
> Not exciting, I realize.
>
> John
>
> On Fri, Jul 14, 2023 at 10:35 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230715/84b533c1/attachment-0001.html>