Open muni-corn opened 4 years ago
krogovin
commented
4 years ago 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?
kvark
commented
4 years ago wgpu on native exposes the restrictions on the index as different extra features:
cc @cwfitzgerald
jozanza
commented
3 years ago In WGSL, how are we able to access a single texture in an array of textures? A binding such as this seems valid:
[[group(1), binding(0)]] var textures: array<texture_2d<f32>, 2>;However, any attempt to access an index via textures[n] throws various compiler errors. Is there some special array access notation or am I just missing something?
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.
litherum
commented
3 years ago 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.
jozanza
commented
3 years ago 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?
Kangz
commented
3 years ago 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.
kvark
commented
3 years ago 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.
jozanza
commented
3 years ago 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?
kvark
commented
3 years ago That's correct, yes. At least, not in the "standard" WGSL.
kainino0x
commented
3 years ago 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.
jozanza
commented
3 years ago @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.
kainino0x
commented
3 years ago 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.
aloucks
commented
2 years ago Not sure if the support was added to WGSL after this issue, but textureSample and textureSampleLevel both allow you to specify the array layer index when using texture_2d<f32>.
kainino0x
commented
2 years ago Not sure if the support was added to WGSL after this issue, but
textureSampleandtextureSampleLevelboth allow you to specify the array layer index when usingtexture_2d<f32>.
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.
FishHawk
commented
2 years ago I'm also stuck on the array of textures when using wgsl. Any new developments on this issue?
Kangz
commented
2 years ago This is not in scope for v1, but I expect it will be soon after as it is a feature that's often requested.
FishHawk
commented
2 years ago 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.
litherum
commented
2 years ago We currently support array textures (as opposed to texture arrays). Hopefully those can help out in the interim.
kdashg
commented
2 years ago Let's clearly differentiate between texture_2d_array<type> "texture arrays" and array<texture_2d<type>, N> "arrays of textures".
kainino0x
commented
2 years ago For maximal distinguishability I like the terms "2d-array texture" and "array of texture bindings"
gents83
commented
2 years ago Naga and wgpu are now supporting binding_array! Is there any chance it could become a standard?
kdashg
commented
2 years ago We should talk about it post-v1 I think.
kainino0x
commented
1 year ago Dynamic indexing of texture binding-arrays can be in core (EDIT: probably, need to check metal/d3d12):
Requirement "shaderSampledImageArrayDynamicIndexing" loses 2 (and partially loses 0) further deviceNames:
In ALL reports (2 deviceNames):
x Virtio-GPU Venus (llvmpipe): 2 (14801 14867)
x llvmpipe: 161 (13810 13838 13864 14050 14115 14236 14338 14348 14516 14538 14542 14556 14567 14570 14571 14633 14657 14683 14695 14707 14721 14727 14734 14737 14750 14785 14797 14810 14821 14843 14847 14870 14886 14889 14902 14909 14919 14951 14971 14975 15011 15014 15027 15046 15058 15071 15088 15092 15098 15121 15136 15195 15215 15227 15239 15249 15276 15279 15285 15309 15431 15488 15489 15568 15639 15695 15799 15809 15811 15847 15922 15974 15990 16022 16041 16044 16064 16068 16069 16103 16116 16119 16139 16149 16173 16180 16192 16216 16240 16244 16250 16268 16272 16277 16299 16337 16340 16349 16370 16374 16384 16395 16420 16423 16457 16467 16472 16481 16486 16495 16502 16504 16519 16525 16534 16554 16561 16572 16581 16598 16627 16643 16673 16678 16699 16702 16725 16780 16798 16816 16838 16852 16866 16878 16892 16909 16939 16964 16975 17020 17041 17054 17059 17069 17075 17103 17124 17162 17185 17197 17215 17243 17257 17269 17301 17353 17378 17394 17424 17445 17483)
In SOME reports (0 deviceNames):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.
kainino0x
commented
1 year ago Oh, right, yes, it's dynamically uniform. Vulkan spec:
shaderSampledImageArrayDynamicIndexing specifies whether arrays of samplers or sampled images can be indexed by dynamically uniform integer expressions in shader code.
The non-uniform one is shaderSampledImageArrayNonUniformIndexing. It actually has fairly wide support on Vulkan so would be a candidate for an optional feature.
kdashg
commented
1 year ago 
fynv
commented
1 year ago 2 points I want to mention here:
11zouzouzou
commented
1 year ago 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.
kenrussell
commented
11 months ago 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.)
greggman
commented
10 months ago 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
kainino0x
commented
10 months ago Vulkan has 4 features:
kainino0x
commented
10 months ago Similarly in Vulkan 1.2:
greggman
commented
10 months ago From the metal docs
2.12.1 Arrays of Textures, Texture Buffers, and Samplers iOS: Arrays of textures supported since Metal 1.2; arrays of samplers since Metal 2; arrays of texture buffers since Metal 2.1. macOS: Arrays of textures supported since Metal 2; arrays of samplers since Metal 2; arrays of texture buffers since Metal 2.1.
jimblandy
commented
10 months ago kdashg
commented
9 months ago 
TheMostDiligent
commented
2 months ago Any updates on the issue? WebGPU is the only graphics API in existence that does not support array of resources. While dynamically indexing resources may be involved (though all modern graphics APIs do support it), statically indexing resources should not be a problem and is supported supported in GLES1.0 and WebGL1.0.
gitbetter
commented
2 months ago 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 😅
Kangz
commented
2 months ago This issue is not for bindless arrays of textures and buffers (that would be https://github.com/gpuweb/gpuweb/issues/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.
gitbetter
commented
2 months ago 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).
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: https://github.com/gfx-rs/wgpu/issues/106
The idea is to be able to use an array of 2d textures in shaders, as originally shown in the issue above: