[x3d-public] GPU APIs and X3D
GPU Group
gpugroup at gmail.com
Sat Jul 15 05:36:49 PDT 2023
Raytracing on mouse-up, or real-time raytracing.
Large calculations on images at runtime, for GIS-like applications.
On Sat, Jul 15, 2023 at 4:03 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:
> 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
>>>
>> _______________________________________________
> 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/127c22b1/attachment.html>
More information about the x3d-public
mailing list