-
Notifications
You must be signed in to change notification settings - Fork 978
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
Comments
That would be great!
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.
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 👍 |
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 |
That's what bind groups are for, and have always been (analogous to |
@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 ***@***.***> 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 ***@***.***> 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 |
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>
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>
Use cfg and path attribute instead of cfg_attr for IntelliJ Rust support
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: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
The text was updated successfully, but these errors were encountered: