Support for arrays of textures #822
Labels
Milestone
Comments
kvark
added
the
feature request
|
What are the expectations for the index into the array? Can it be anything, or must it be "dynamically uniform", i.e. dependent only on values that are derived from uniforms only? |
|
|
|
In WGSL, how are we able to access a single texture in an array of textures? A binding such as this seems valid: However, any attempt to access an index via The texture arrays example only has glsl shaders, and I couldn't find info about this in the spec other than the basic array notation syntax. Edit: This non-uniform shader is the one I'm interested in writing in WGSL. That "flat" specifier also seems to cause errors everywhere I've tried to place it. |
|
I remember that we had a resolution in the group to not allow arrays of textures (as distinct from texture arrays) in the first version of the language, because of uniformity rules. Texture arrays are allowed, though. |
|
I did see that this was supported by wgpu on native with certain extensions. But you're saying there's currently no valid syntax for working with an array of textures in WGSL? |
|
I think you're referring to bindless, and that hasn't been discussed for WebGPU at this point. Because the API doesn't support bindless (even as an extension), it doesn't make sense to add support for it in WGSL. Experimental syntax can be added to wgpu-rs / Naga though. |
|
Correct, we'll need to work on WGSL syntax for this internally (prototyping in Naga), and then potentially returning to the group with a proposal. |
|
Thanks for the comments! I'm not sure what "bindless" means tbh 👀, but to clarify, is it correct to say there's no way to achieve dynamic non-uniform texture indexing/sampling in WGSL at this point? Like those example shaders cannot be converted to WGSL yet? |
|
That's correct, yes. At least, not in the "standard" WGSL. |
|
You should be able to use conditionals to choose dynamically between branches that sample different textures (or perhaps even assign different textures into a pointer variable?). But we don't have a way to bind arrays of textures at the API surface, so you still have to have a separate binding point for each texture. |
|
@kainino0x I had trouble taking that approach because, when compiling my shader, it apparently violated some non-uniformity restriction to selectively use a texture based on an in var from the vertex shader. So I ended up just rolling with a texture atlas. |
|
Got it. I think it should* be valid if the conditional is uniform, but otherwise it will not be. * I don't know if the uniformity rules are actually written out yet, but ultimately I think this will be the case. |
|
Not sure if the support was added to WGSL after this issue, but |
That is for a 2d-array type texture (single texture object), while this issue is about having an array of texture bindings (multiple texture objects). The naming is confusing. |
|
I'm also stuck on the array of textures when using wgsl. Any new developments on this issue? |
|
This is not in scope for v1, but I expect it will be soon after as it is a feature that's often requested. |
Thank you. Hope to see it soon. |
|
We currently support array textures (as opposed to texture arrays). Hopefully those can help out in the interim. |
|
Let's clearly differentiate between |
|
For maximal distinguishability I like the terms "2d-array texture" and "array of texture bindings" |
|
Naga and wgpu are now supporting binding_array! |
|
We should talk about it post-v1 I think. |
|
Dynamic indexing of texture binding-arrays can be in core (EDIT: probably, need to check metal/d3d12): |
|
By dynamic indexing is it dynamically uniform or can it be non-uniform? The latter would be awesome, but I suspect there is fair number of GPU's that do not support that. |
|
Oh, right, yes, it's dynamically uniform. Vulkan spec:
The non-uniform one is Here's the query result for that: |
GPU Web F2F 2023-02-16/17
|
|
2 points I want to mention here:
|
|
Texture arrays are very useful for ray tracing rendering in the entire scene （It can upload textures of different sizes）, we hope to implement them as soon as possible. |
|
In today's WebGPU CG meeting another example was requested: this old WebGL one, https://github.com/WebGLSamples/WebGLSamples.github.io/tree/master/sprites , shows a trick for getting around the requirement that the texture array indices must be constant or constant-uniform-expression. (It doesn't scale, but does demonstrate the workaround, as well as the performance improvements it yields.) |
|
To be on par with WebGL you'd need arrays of samplers and arrays of textures. Certainly it would be nice to just allow arrays of bindings in general if that's possible |
|
Vulkan has 4 features:
|
|
Similarly in Vulkan 1.2:
|
|
From the metal docs
|
Agenda / Minutes for GPU Web meeting 2023-11-01
|
WGSL 2023-12-05 Minutes
|
|
Any updates on the issue? |
|
Wanted to bump this as well. Bindless techniques are pretty common these days for writing GPU driven renderers and it's kind of a bust to not have arrays of textures support. I can be sort of faked by writing image data into storage buffers but then sampler filtering goes out the window and you have to roll out your own filtering solutions in a shader. Would love to know if there's any headway on this. I have no idea what the bureaucracy of open source standards is like 😅 |
|
This issue is not for bindless arrays of textures and buffers (that would be #380), only for fixed-size, bindfull arrays. We'd love to have bindless one day and it's something that's very likely to happen, but the amount of work to make it happen is massive so we aren't entertaining starting it until WebGPU is shipped everywhere. |
|
Oh nice, didn't know there was a separate issue for it! Given that it possibly has a simpler roadmap, statically size bindfull arrays of textures or buffers can give us a sort of starting point for custom bindless implementations (i.e. single global bind group created ahead of time with large arrays of textures and buffers that can be modified on the fly, without recreating bind groups), which is I guess why I'm more interested in this issue for the time being. It seems more tractable and still sort of gives graphics programmer the power of "custom" bindless (albeit not the truest form of bindless). |
Kangz
added a commit
to Kangz/gpuweb
that referenced
this issue
Oct 25, 2024
GPU Web WG 2024-10-29/30 Mountain View F2F
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I just wanted to get the ball rolling on support for arrays of textures in shaders. Coming from this issue on the wgpu-rs repo: gfx-rs/wgpu#106
The idea is to be able to use an array of 2d textures in shaders, as originally shown in the issue above:
The text was updated successfully, but these errors were encountered: