Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for arrays of textures #106

Closed
cloudhead opened this issue Mar 18, 2019 · 15 comments
Closed

Support for arrays of textures #106

cloudhead opened this issue Mar 18, 2019 · 15 comments
Labels
type: bug Something isn't working type: question Further information is requested

Comments

@cloudhead
Copy link
Contributor

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

@kvark
Copy link
Member

kvark commented Mar 19, 2019

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.

@kvark kvark added type: bug Something isn't working type: question Further information is requested labels Mar 19, 2019
@cloudhead
Copy link
Contributor Author

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 👍

@seivan
Copy link
Contributor

seivan commented Apr 4, 2019

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.

@danaugrs
Copy link
Contributor

danaugrs commented Aug 27, 2019

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.

@kvark
Copy link
Member

kvark commented Aug 28, 2019

@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).

@danaugrs
Copy link
Contributor

danaugrs commented Aug 28, 2019

@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?

@kvark
Copy link
Member

kvark commented Aug 28, 2019 via email

@danaugrs
Copy link
Contributor

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

@kvark
Copy link
Member

kvark commented Aug 28, 2019 via email

@muni-corn
Copy link

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

@kvark
Copy link
Member

kvark commented Apr 27, 2020

@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

@kvark
Copy link
Member

kvark commented Jun 1, 2020

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

@muni-corn
Copy link

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

@kvark
Copy link
Member

kvark commented Jun 1, 2020

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

@cwfitzgerald
Copy link
Member

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.

bors bot added a commit that referenced this issue Jun 12, 2020
715: Implement SAMPLED_TEXTURE_ARRAY_NON_UNIFORM_INDEXING r=kvark a=cwfitzgerald

## Connections

Closes #483. Extends support for #106.

## Description

This forwards the descriptor indexing features gfx-hal up to wgpu. 

Note this PR also changes the name of the `TEXTURE_BINDING_ARRAY` to `SAMPLED_TEXTURE_BINDING_ARRAY` to be more consistent with extensions.

## Testing

Texture-array example was simply extended to use descriptor indexing. This works on all platforms that the feature is supported. (thanks @StarArawn)



Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
bors bot added a commit that referenced this issue Jun 12, 2020
715: Implement SAMPLED_TEXTURE_ARRAY_NON_UNIFORM_INDEXING r=kvark a=cwfitzgerald

## Connections

Closes #483. Extends support for #106.

## Description

This forwards the descriptor indexing features gfx-hal up to wgpu. 

Note this PR also changes the name of the `TEXTURE_BINDING_ARRAY` to `SAMPLED_TEXTURE_BINDING_ARRAY` to be more consistent with extensions.

## Testing

Texture-array example was simply extended to use descriptor indexing. This works on all platforms that the feature is supported. (thanks @StarArawn)



Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
RandyMcMillan pushed a commit to RandyMcMillan/wgpu that referenced this issue Jun 19, 2024
Use cfg and path attribute instead of cfg_attr for IntelliJ Rust support
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working type: question Further information is requested
Projects
None yet
Development

No branches or pull requests

6 participants