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

Vulkan Backend errors when creating a texture array with a layer size of 6. #2439

Closed
StarArawn opened this issue Jan 30, 2022 · 2 comments
Closed

Comments

@StarArawn
Copy link
Contributor

Description
I'm attempting to use texture arrays for my tilemap crate. If I create a texture array with 6 layers the vulkan backend attempts to treat the array as a cube map texture and I get the following error:

vkCreateImage(): pCreateInfo->flags contains VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT, but pCreateInfo->extent.width (=64) and pCreateInfo->extent.height (=32) are not equal. The Vulkan spec states: If imageType is VK_IMAGE_TYPE_2D and flags contains VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT, extent.width and extent.height must be equal and arrayLayers must be greater than or equal to 6

Repro steps
Checkout out this repo: https://github.com/StarArawn/bevy_ecs_tilemap/
run: cargo run --example iso_diamond

Workaround: Add +1 to count here:
https://github.com/StarArawn/bevy_ecs_tilemap/blob/main/src/render/texture_array_cache.rs#L63
No more errors.

Expected vs observed behavior
I expect that my texture array is treated like an array and not a cube map. The texture width/height shouldn't have to match here.

Extra materials
n/a

Platform
Windows 10, Vulkan, wgpu 0.12.0

@StarArawn
Copy link
Contributor Author

Looking at the code this seems to be the issue here:

if desc.dimension == wgt::TextureDimension::D2

Not sure what a fix would be.

@kvark
Copy link
Member

kvark commented Jan 30, 2022

It was fixed in #2331 but not backported to crates because it changes the errors, which are public API of wgpu-core.
I think we need to port over a smaller version of this PR that doesn't affect the errors but fixes the problem here.

@kvark kvark closed this as completed Jan 30, 2022
cwfitzgerald pushed a commit that referenced this issue Oct 25, 2023
* [wgsl-in] Avoid splatting all binary operator expressions

Fixes #2439.

* [wgsl-in] Expand binary_op_splat function comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants