5 ms·

> where "rest of us" is everybody who isn't a highly specialized rendering engineer in an AAA-game engine team Then you should be looking at WebGL, not WebGPU!

pjmlp 6y ago
Those kind of advises would make sense if they were parallel APIs, however neither WebGL 3.0 nor OpenGL 5.0 will happen.
- jfkebwjsbx 6y ago
  They say they are not making an AAA engine. They are looking for a simple way to get into graphics. They have no need for parallel, low-level APIs.
  - gpm 6y ago
    > Please don't comment about the voting on comments. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html In this case specifically I'd just use the second half of your comment, the first half just detracts from the message and sounds petty.
    - jfkebwjsbx 6y ago
      I edited it, but let me say I don't agree with your policy, because downvoting is reserved for high-score accounts. If it would be open to (almost) everyone, then it would be fine. In fact, if you think about it, what is "petty" isn't talking about downvoting, but the ability to downvote itself. Flagging is fine, because trolls will always be around.
  - pjmlp 6y ago
    Except going forward, those are going to be the only APIs available, regardless of one is doing AAA or not. It would be the same as using SVAlib or Allegro nowadays. They are still there, but not longer map to existing graphics hardware.
    - jfkebwjsbx 6y ago
      > Except going forward, those are going to be the only APIs available That is false. There are already library implementations of legacy OpenGL, modern OpenGL, OpenGL ES, WebGL, legacy Direct3D, Direct3D 10/11, Direct3D 12, Vulkan and others. Major players like Microsoft, AMD, Khronos, Valve and others already depend and employ people on providing those APIs and libraries long-term. Those APIs are not going anywhere, even if a hardware vendor decides to only provide a low-level one (which is understandable, by the way...). > They are still there, but not longer map to existing graphics hardware. They have never mapped to hardware, so there is no real difference between now and then.
      - pjmlp 6y ago
        Those wrapper libraries are yet another layer to debug and not 100% the real deal, and will get further away as the underlying technology evolves. That is like telling someone that coding against POSIX.1 is all they will ever need for their applications.
kvark 6y ago
My recent talk at Fosdem started with a rant about OpenGL/WebGL. Cant express this better still: https://fosdem.org/2020/schedule/event/rust_webgpu/ https://fosdem.org/2020/schedule/event/rust_webgpu/
flohofwoe 6y ago
WebGL follows the OpenGL programming model, which isn't "simple" either, we just got used to it over time. Also, there's a lot of room for sane APIs between GLES2 and Vulkan, so much room that a single "standard" 3D-API doesn't make much sense TBH since there are many different opinions on where the "sweet spot" for a 3D-API lies between ease-of-use, feature coverage and acceptable layering overhead.
skocznymroczny 6y ago
No, WebGPU will be easier to use than WebGL, because it doesn't have the global state. Global state is the worst thing about OpenGL and requires a lot of code to get it under control.
- jfkebwjsbx 6y ago
  WebGL is different than legacy OpenGL from 20 years ago. WebGL is pretty easy to work with. WebGPU is a low-level API is more flexible than WebGL, which means more complexity. That is why it is being introduced, after all!
  - mmis1000 6y ago
    However It still use global state, you need to flush state everywhere when switch scenes. Run another filter? good, switch everything on global state. Render another scene with different texture? Set everything again. Moreover... if you forgot to reset something after change it. You got weird bug that only happen under some specific order of operation. Because everything share a global state. And it is full sync. A shader takes long time for render also makes your whole page non responsive, which is a pain. (open the list page of shadertoy, you will know what am I saying)
    - jfkebwjsbx 6y ago
      You don't need to reset everything, only whatever you change. Yeah, other APIs allow you to keep the state pre-packaged and switch from what appears a single command, but the state is still there nevertheless. The full sync is a problem of how WebGL is provided. They could easily change it to allow parallel rendering as long it is to independent contexts.
      - rezmason 6y ago
        I'd like to chime in by pointing you fine folks to http://regl.party http://regl.party — a functional, partial-application, "stateless WebGL" library that lets you model rendering commands as nested little scopes. It offers "the rest of us" a graphics programming foundation that's lower level than three.js, and I can't recommend it enough. IMO, WebGL's implementation has some glaring wrinkles that REGL-like libraries can't smooth away, but at least REGL does a decent job of tackling the state problems you're discussing, while offering a more flexible approach (I think?) than the out-of-the-box WebGPU API's render pass command encoder.

pjmlp 6y ago

Those kind of advises would make sense if they were parallel APIs, however neither WebGL 3.0 nor OpenGL 5.0 will happen.

jfkebwjsbx 6y ago
They say they are not making an AAA engine. They are looking for a simple way to get into graphics. They have no need for parallel, low-level APIs.
- gpm 6y ago
  > Please don't comment about the voting on comments. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html In this case specifically I'd just use the second half of your comment, the first half just detracts from the message and sounds petty.
  - jfkebwjsbx 6y ago
    I edited it, but let me say I don't agree with your policy, because downvoting is reserved for high-score accounts. If it would be open to (almost) everyone, then it would be fine. In fact, if you think about it, what is "petty" isn't talking about downvoting, but the ability to downvote itself. Flagging is fine, because trolls will always be around.
- pjmlp 6y ago
  Except going forward, those are going to be the only APIs available, regardless of one is doing AAA or not. It would be the same as using SVAlib or Allegro nowadays. They are still there, but not longer map to existing graphics hardware.
  - jfkebwjsbx 6y ago
    > Except going forward, those are going to be the only APIs available That is false. There are already library implementations of legacy OpenGL, modern OpenGL, OpenGL ES, WebGL, legacy Direct3D, Direct3D 10/11, Direct3D 12, Vulkan and others. Major players like Microsoft, AMD, Khronos, Valve and others already depend and employ people on providing those APIs and libraries long-term. Those APIs are not going anywhere, even if a hardware vendor decides to only provide a low-level one (which is understandable, by the way...). > They are still there, but not longer map to existing graphics hardware. They have never mapped to hardware, so there is no real difference between now and then.
    - pjmlp 6y ago
      Those wrapper libraries are yet another layer to debug and not 100% the real deal, and will get further away as the underlying technology evolves. That is like telling someone that coding against POSIX.1 is all they will ever need for their applications.

kvark 6y ago

My recent talk at Fosdem started with a rant about OpenGL/WebGL. Cant express this better still: https://fosdem.org/2020/schedule/event/rust_webgpu/ https://fosdem.org/2020/schedule/event/rust_webgpu/

flohofwoe 6y ago

WebGL follows the OpenGL programming model, which isn't "simple" either, we just got used to it over time. Also, there's a lot of room for sane APIs between GLES2 and Vulkan, so much room that a single "standard" 3D-API doesn't make much sense TBH since there are many different opinions on where the "sweet spot" for a 3D-API lies between ease-of-use, feature coverage and acceptable layering overhead.

skocznymroczny 6y ago

No, WebGPU will be easier to use than WebGL, because it doesn't have the global state. Global state is the worst thing about OpenGL and requires a lot of code to get it under control.

jfkebwjsbx 6y ago
WebGL is different than legacy OpenGL from 20 years ago. WebGL is pretty easy to work with. WebGPU is a low-level API is more flexible than WebGL, which means more complexity. That is why it is being introduced, after all!
- mmis1000 6y ago
  However It still use global state, you need to flush state everywhere when switch scenes. Run another filter? good, switch everything on global state. Render another scene with different texture? Set everything again. Moreover... if you forgot to reset something after change it. You got weird bug that only happen under some specific order of operation. Because everything share a global state. And it is full sync. A shader takes long time for render also makes your whole page non responsive, which is a pain. (open the list page of shadertoy, you will know what am I saying)
  - jfkebwjsbx 6y ago
    You don't need to reset everything, only whatever you change. Yeah, other APIs allow you to keep the state pre-packaged and switch from what appears a single command, but the state is still there nevertheless. The full sync is a problem of how WebGL is provided. They could easily change it to allow parallel rendering as long it is to independent contexts.
    - rezmason 6y ago
      I'd like to chime in by pointing you fine folks to http://regl.party http://regl.party — a functional, partial-application, "stateless WebGL" library that lets you model rendering commands as nested little scopes. It offers "the rest of us" a graphics programming foundation that's lower level than three.js, and I can't recommend it enough. IMO, WebGL's implementation has some glaring wrinkles that REGL-like libraries can't smooth away, but at least REGL does a decent job of tackling the state problems you're discussing, while offering a more flexible approach (I think?) than the out-of-the-box WebGPU API's render pass command encoder.