39 ms·

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

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.
  - mmis1000 6y ago
    I am not sure it is easy to change opengl to run parallelly given it all shares a global state. How do you not mess up anything when render two scene at same time if two pipeline shares the same variable but you want to fill it with different value? And if you really want to change it so hard to give pipelines standalone context. Why not use the webgpu? It seems just designed in a stateless way that I just described.
    - skocznymroczny 6y ago
      OpenGL wasn't designed with multithreading/parallel execution in mind. Before running any OpenGL call, you have to bind the application-wide context to a specific thread. Vulkan, DX12 work differently - they allow you to create command lists from separate threads, but in exchange you have to work on the synchronization yourself via semaphores and fences.

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.
- mmis1000 6y ago
  I am not sure it is easy to change opengl to run parallelly given it all shares a global state. How do you not mess up anything when render two scene at same time if two pipeline shares the same variable but you want to fill it with different value? And if you really want to change it so hard to give pipelines standalone context. Why not use the webgpu? It seems just designed in a stateless way that I just described.
  - skocznymroczny 6y ago
    OpenGL wasn't designed with multithreading/parallel execution in mind. Before running any OpenGL call, you have to bind the application-wide context to a specific thread. Vulkan, DX12 work differently - they allow you to create command lists from separate threads, but in exchange you have to work on the synchronization yourself via semaphores and fences.