Hoping for glTexBuffer and Geometry Shader extensions for WebGL2

[Jon Marbach]

Hi all,

I saw some slides from "forever ago" asking about priorities for extensions (from the Siggraph 2018 slides) and I thought "better late than never" on answering...

I've been reviewing what WebGL lacks for porting my desktop GL engine and so far the main missing bits are Buffer Textures (which are in ES 3.2) and Geometry Shaders. 

Given the pushback in my other thread on Geometry Shaders I'll just say I can live without them, but it would make the engine easier to port if they were there.

For Buffer Textures (glTexBuffer), again, we could adapt the code not to use them, but it would make porting the engine easier / palatable. Since glTexBuffer is in ES 3.2 maybe it's not a huge stretch to imagine an extension for that?

My targets are "desktop" systems (Nvidia and Intel, and AMD to a lesser extent) and Chrome is the only browser I need to support in the short term.

Just putting this out there. I know I'm "late to the party".

Cheers,

Jon

[Jon Marbach]

Also, instructions like the ones from OES_shader_image_atomic extensions are used for OIT in our engine. We could live without OIT, but again, it would make the transition simpler. Again, not hoping for much here, just letting everyone know what's of interest to us.

Jon

[Ken Russell]

Hi Jon,

Thanks for telling us about the functionality you depend on. At this point in WebGL's evolution I don't think it's likely we'll specify a WebGL 2.0 extension to add Buffer Textures and shader image atomics, but will keep them in mind.

Take a look at the WebGPU specification and outstanding issues. I don't remember whether creating textures from buffers is planned to be supported, but you could join the community group and ask on the email list.

-Ken

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/4a44030a-01dc-442a-ad4b-dcc3e42a94b1n%40googlegroups.com.

[Kai Ninomiya]

I'm not very familiar with Buffer Textures, but I'm not sure they're necessary in WebGPU because we have storage buffers.

This page:

https://www.khronos.org/opengl/wiki/Buffer_Texture

seems to say buffer textures exist to access larger buffers than allowed by uniform buffers. However, OpenGL ES 3.1 has storage buffers (SSBOs), which can be much larger (larger, even, than 1d textures, I think) so I'm unclear on why buffer textures are added in ES 3.2. Maybe for desktop compatibility? Or more likely I'm missing something else about them.

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAMYvS2e8qbqzaETCtP8qjPZK09U%2BQsUvzgUHQxyNhSvoT%3DFrCw%40mail.gmail.com.

[Jon Marbach]

Hey all - Thanks for the tips. 

RE SSBO vs Texture Buffer - That's a good point. SSBO should be fine and would work the same way for us - we use the Buffer Textures for big 1d arrays which we index into based on vertex id or instance id, so SSBO sounds like an identical fit assuming SSBO read perf is on par with Buffer Texture read perf. (We don't need the write capability of SSBO, but as low as it comes without a downside, that's fine.)

Maybe that's the key difference... Does anyone know how Buffer Texture and SSBO read performance compare? As long as they are generally comparable, I'm comfortable with that. (I.E., I don't concern myself typically with performance differences in small percentages. I.E., if SSBO read perf is , say, 10-20% slower that's OK, if it's 3-5x slower that's more of an issue.)

Thanks,

Jon

[Kai Ninomiya]

I don't know what the relative performance is - it is probably highly architecture dependent - but I would strongly suspect it to be within your 20% range.

WebGPU can bind buffers as read-only storage:

https://gpuweb.github.io/gpuweb/#dom-gpubufferbindingtype-readonly-storage

so there shouldn't be any detriment due to the fact storage buffers are writable.

Note the current plan is to *not* bring SSBOs to WebGL; only WebGPU.

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/c858024c-ab14-435d-8ec0-e741678bbdc0n%40googlegroups.com.

[Ken Russell]

Jon, out of curiosity, if your goal is to feed large amounts of read-only data into shaders, would Uniform Buffer Objects (available in WebGL 2.0) work?

-Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CANxMeyB3wzW1WMFJ3SdUNNQ0ht2yo0H7qLJHYeH2_Vk3rMcLpA%40mail.gmail.com.

[Jon Marbach]

Hey Ken,

I thought UBOs were still pretty small these days, but I could be wrong... I don't assume I'm right about much these days :) I would typically need an array of floats > 32000 elements long or >128k if I'm doing the math correctly, so the appeal of TBOs is that they're "always big enough".

Jon

[Jon Marbach]

(Sorry, to be clear, I don't have a fixed number of elements that I need to support - it's data-dependent, but what I mean is that the data often is larger than 16k elements and sometimes more than 32k elements could be in 100s of k elements. TBOs, if I remember correctly, have a max size of ~2GB on my target hardware, which is plenty of "wiggle room" - i.e., the implementation doesn't need to take different paths depending on data size, which is very nice.)  

[Jeff Gilbert]

There's definitely mixed support for (I'll call them) full-size UBOs.
Since you seem ok choosing a subset of machines to support, it's worth
checking the limits on those machines. I bet the OpenGL drivers on
those machines likely do support full-size UBOs, though it seems like
ANGLE has limits on the smaller side when running on D3D, as it does
on most all Windows machines. It may be worth investigating checking
whether this is a hard limit coming out of D3D11, or just a design
choice in ANGLE.

Depending on your access patterns, you may be able to get away with
mapping offset->(x,y) for a 2D texture fetch. However, if you do very
random access into it, perf may be subpar this way.

> To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/503d36bf-9147-4069-84de-56a780dea6ebn%40googlegroups.com.

[Jon Marbach]

Hey Jeff - Well you make a good point about going with a 2d texture. I guess I didn't think of these alternatives because I had buffer textures available to me. (I could maybe even do a zigzag for better cache hits... But now we're just getting nutty.) Thanks for the inspiration!

Jon

You received this message because you are subscribed to a topic in the Google Groups "WebGL Dev List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/webgl-dev-list/PRzOG-NMHnM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to webgl-dev-lis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAOztSJ1at%3DTuVK1u5GZLiFw-%3DRwTHiYkqp8Dtt%3DFOQmYRSaXKg%40mail.gmail.com.