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

remove pixel size and try to calculate texture sizes more correctly #6788

Closed
wants to merge 6 commits into from

Conversation

hymm
Copy link
Contributor

@hymm hymm commented Nov 28, 2022

Objective

Solution

  • more complicated alternative to [Merged by Bors] - get pixel size from wgpu #6820
  • this mostly be considered a rebase of Texture formats #4124. Though some of the details are modified.
  • remove the TextureFormatPixelInfo trait. It is inaccurate to use pixel_size to calculate bytes when a texture is compressed
  • create a trait to calculate the usages of pixel_size directly. These are bytes_per_row, total_bytes, and rows_per_image.
  • use format.describe().block_size directly in situations where it is obvious that the format is uncompressed or where surrounding code assumes the texture is uncompressed.
  • add some debug asserts to functions that assume the texture is uncompressed.
  • note that all the internal uses of TextureFormatPixelInfo were on uncompressed textures. A smaller change would be to panic if in the pixel_info function if the texture is compressed and return block_size for type_size otherwise.

Breaking Changes

TextureFormatPixelInfo has been removed. PixelInfo::components can be gotten from texture_format.describe().components. PixelInfo::type_size can be gotten from texture_format.describe().block_size/ texture_format.describe().components. But note this can yield incorrect results for some texture types like Rg11b10Float. You might prefer to use the new functions on texture_descriptor instead. These include bytes_per_row, total_bytes and rows_per_image.

@james7132 james7132 added A-Rendering Drawing game state to the screen C-Code-Quality A section of code that is hard to understand or change labels Nov 28, 2022
@hymm
Copy link
Contributor Author

hymm commented Nov 28, 2022

I think block_size =! type_size, so need to investigate more on what the equivalence is.

edit: I think it's block_size = type_size * components, but will go through the whole table and check

@hymm hymm force-pushed the get-texture-info-from-wgpu branch from 2846343 to 9781f12 Compare November 28, 2022 22:09
@james7132 james7132 added the M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide label Nov 28, 2022
@hymm hymm changed the title get pixel info from wgpu get pixel size from wgpu Nov 29, 2022
@hymm
Copy link
Contributor Author

hymm commented Nov 29, 2022

So there's one mismatch and that is on Depth24Plus. The size on that one before this PR is 3 and after this PR is 4. There is a FIXME on that line, so I'm inclined to trust wgpu on this one. Ideally we'd test it somehow, but I'm not sure how at the moment.

@hymm
Copy link
Contributor Author

hymm commented Nov 30, 2022

I now see there's an old PR that tried to do something similar. #4124. It seems like there's some issues around compressed textures that this PR might not be dealing with correctly.

Co-authored-by: Kurt Kühnert <kurt@kuhnert.dev>
@superdump
Copy link
Contributor

I now see there's an old PR that tried to do something similar. #4124. It seems like there's some issues around compressed textures that this PR might not be dealing with correctly.

I knew I’d seen a PR for this before.

@@ -16,16 +16,12 @@ impl AssetLoader for HdrTextureLoader {
) -> BoxedFuture<'a, Result<()>> {
Box::pin(async move {
let format = TextureFormat::Rgba32Float;
debug_assert_eq!(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this debug assert is sort of meaningless since we're hard coded to Rgba32Float

@hymm hymm changed the title get pixel size from wgpu remove pixel size and try to calculate sizes more correctlier Dec 1, 2022
@hymm hymm changed the title remove pixel size and try to calculate sizes more correctlier remove pixel size and try to calculate sizes more correctly Dec 1, 2022
@hymm hymm force-pushed the get-texture-info-from-wgpu branch from 5d9b8dd to fe17713 Compare December 1, 2022 03:53
@hymm hymm changed the title remove pixel size and try to calculate sizes more correctly remove pixel size and try to calculate texture sizes more correctly Dec 2, 2022
@alice-i-cecile
Copy link
Member

Closing now that #6820 is getting merged. We can add the extra step in a new PR.

bors bot pushed a commit that referenced this pull request Dec 11, 2022
# Objective

- Get rid of giant match statement to get PixelInfo. 
- This will allow for supporting any texture that is uncompressed, instead of people needing to PR in any textures that are supported in wgpu, but not bevy.

## Solution

- More conservative alternative to #6788, where we don't try to make some of the calculations correct for compressed types.
- Delete `PixelInfo` and get the pixel_size directly from wgpu. Data from wgpu is here: https://docs.rs/wgpu-types/0.14.0/src/wgpu_types/lib.rs.html#2359
- Panic if the texture is a compressed type. An integer byte size of a pixel is no longer a valid concept when talking about compressed textures.
- All internal usages use `pixel_size` and not `pixel_info` and are on uncompressed formats. Most of these usages are on either explicit texture formats or slightly indirectly through `TextureFormat::bevy_default()`. The other uses are in `TextureAtlas` and have other calculations that assumes the texture is uncompressed. 

## Changelog

- remove `PixelInfo` and get `pixel_size` from wgpu

## Migration Guide

`PixelInfo` has been removed. `PixelInfo::components` is equivalent to `texture_format.describe().components`. `PixelInfo::type_size` can be gotten from `texture_format.describe().block_size/ texture_format.describe().components`. But note this can yield incorrect results for some texture types like Rg11b10Float.
alradish pushed a commit to alradish/bevy that referenced this pull request Jan 22, 2023
# Objective

- Get rid of giant match statement to get PixelInfo. 
- This will allow for supporting any texture that is uncompressed, instead of people needing to PR in any textures that are supported in wgpu, but not bevy.

## Solution

- More conservative alternative to bevyengine#6788, where we don't try to make some of the calculations correct for compressed types.
- Delete `PixelInfo` and get the pixel_size directly from wgpu. Data from wgpu is here: https://docs.rs/wgpu-types/0.14.0/src/wgpu_types/lib.rs.html#2359
- Panic if the texture is a compressed type. An integer byte size of a pixel is no longer a valid concept when talking about compressed textures.
- All internal usages use `pixel_size` and not `pixel_info` and are on uncompressed formats. Most of these usages are on either explicit texture formats or slightly indirectly through `TextureFormat::bevy_default()`. The other uses are in `TextureAtlas` and have other calculations that assumes the texture is uncompressed. 

## Changelog

- remove `PixelInfo` and get `pixel_size` from wgpu

## Migration Guide

`PixelInfo` has been removed. `PixelInfo::components` is equivalent to `texture_format.describe().components`. `PixelInfo::type_size` can be gotten from `texture_format.describe().block_size/ texture_format.describe().components`. But note this can yield incorrect results for some texture types like Rg11b10Float.
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request Feb 1, 2023
# Objective

- Get rid of giant match statement to get PixelInfo. 
- This will allow for supporting any texture that is uncompressed, instead of people needing to PR in any textures that are supported in wgpu, but not bevy.

## Solution

- More conservative alternative to bevyengine#6788, where we don't try to make some of the calculations correct for compressed types.
- Delete `PixelInfo` and get the pixel_size directly from wgpu. Data from wgpu is here: https://docs.rs/wgpu-types/0.14.0/src/wgpu_types/lib.rs.html#2359
- Panic if the texture is a compressed type. An integer byte size of a pixel is no longer a valid concept when talking about compressed textures.
- All internal usages use `pixel_size` and not `pixel_info` and are on uncompressed formats. Most of these usages are on either explicit texture formats or slightly indirectly through `TextureFormat::bevy_default()`. The other uses are in `TextureAtlas` and have other calculations that assumes the texture is uncompressed. 

## Changelog

- remove `PixelInfo` and get `pixel_size` from wgpu

## Migration Guide

`PixelInfo` has been removed. `PixelInfo::components` is equivalent to `texture_format.describe().components`. `PixelInfo::type_size` can be gotten from `texture_format.describe().block_size/ texture_format.describe().components`. But note this can yield incorrect results for some texture types like Rg11b10Float.
@hymm hymm deleted the get-texture-info-from-wgpu branch October 5, 2023 16:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Code-Quality A section of code that is hard to understand or change M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants