Wgpu: Support for arrays of textures

Created on 18 Mar 2019  Â·  15Comments  Â·  Source: gfx-rs/wgpu

Hey, I'm trying to build a sprite renderer on top of wgpu, and one issue I'm running into is how to easily switch between textures on a per-frame basis. Ideally I don't want to have to create a BindGroup for each texture, and 2D textures aren't ideal either as the textures are not all the same size. One option that is interesting is to create an array of texture descriptors that I can index with a uniform. Something like this:

layout(set = 0, binding = 1) uniform texture2D textures[1024];

but this doesn't seem to be supported by wgpu - looking through the code I found: https://github.com/gfx-rs/wgpu/blob/master/wgpu-native/src/device.rs#L840 - which suggests that the descriptorCount cannot be configured.

Is this something in the works, or is there a better way I haven't considered?

Thanks

bug question

Most helpful comment

Arrays of textures is now supported as a native-only extension to wgpu in #711. See the texture-array example in wgpu-rs for a simple example of use. Dynamic and non-uniform indexing coming in #715.

All 15 comments

I'm trying to build a sprite renderer on top of wgpu

That would be great!

but this doesn't seem to be supported by wgpu

The working group hasn't yet discussed the semantics of arrays (and array textures) in bind groups, so we don't have it implemented either. But we certainly will, especially if there is an immediate need for it.

In your case, this doesn't look like a blocker. Creating a bind group per texture is absolutely fine to start with. I imagine that if that's the only thing changing between draw calls, you can still spew out thousands of them per frame.

Another option is texture atlases: pack your data into a larger 2D texture(array). I bet this would be most performance solution as well, since there isn't any dynamic indexing into a resource involved - just texture coordinates computation.

Great to hear! I'll be tracking this issue then.

Another option is texture atlases: pack your data into a larger 2D texture(array). I bet this would be most performance solution as well, since there isn't any dynamic indexing into a resource involved - just texture coordinates computation.

Definitely planning on using those anyway, but since there's a max texture size, it needs to be combined with either multiple bind groups or arrays :+1:

~Correct me if I'm wrong, but doesn't TextureArrays (an approach to avoid texture packing) require all textures to have the same size, no?~

Edit: sorry confused it with 2D Textures.

Looking forward to being able to use texture arrays! Also looking forward to being able to combine textures, samplers and other uniforms in the same binding group.

@danaugrs

Also looking forward to being able to combine textures, samplers and other uniforms in the same binding group.

That's what bind groups are for, and have always been (analogous to VkDescriptorSet).

@kvark Oops I meant to say in the same binding not binding group. E.g. one uniform block with textures, samplers, and more:

layout(set = 0, binding = 0) uniform TexturesSamplersAndOthers {
    texture2D tex;
    sampler   samp;
    vec3      other;
};

That's not currently possible right? But maybe it will be in the future?

No, that's not going to be ever possible.

On Aug 28, 2019, at 10:43, Daniel Salvadori notifications@github.com wrote:

@kvark Oops I meant to say in the same binding not binding group. E.g. one uniform block with textures, samplers, and more:

layout(set = 0, binding = 0) uniform Textures {
texture2D tex;
sampler samp;
vec3 other;
};
That's not currently possible right? But maybe it will be in the future?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@kvark What's the technical reason behind that? Or is it just to keep the API simple?

That's not how things work in any of the native apis. One binding = one resource, or possibly an array of same-typed resources.
Different resources go jnto different bindings inside a group.

On Aug 28, 2019, at 11:56, Daniel Salvadori notifications@github.com wrote:

@kvark What's the technical reason behind that? Or is it just to keep the API simple?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Hello, any updates on this? Are texture arrays possible with wgpu yet?

@harrisonthorne no update. The working group doesn't have a proposal to discuss on this. If you want to help, there needs to be an investigation done on how these are supported in the API, and the issue with the results filed to https://github.com/gpuweb/gpuweb

@harrisonthorne you only did the last step, while skipping the meat of the problem: doing the actual investigation. See labeled issues for inspiration.

My bad, I'm way too new at this haha. Should I change the original issue or create a new one for the investigation?

I'd just edit the description (since there is not much in there anyway) to have the investigation in place there

Arrays of textures is now supported as a native-only extension to wgpu in #711. See the texture-array example in wgpu-rs for a simple example of use. Dynamic and non-uniform indexing coming in #715.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

LaylConway picture LaylConway  Â·  3Comments

buxx picture buxx  Â·  4Comments

rukai picture rukai  Â·  5Comments

tuzz picture tuzz  Â·  4Comments

rukai picture rukai  Â·  5Comments