Closed FrankenApps closed 2 years ago
Thanks for filing!
This seems to be because we changed how exactly we pull which surface formats so we're now returning Bgra first. The source of the error is https://github.com/FrankenApps/wgpu_formats_repro/blob/v0.13/src/main.rs#L180 which mismatches with the surface format (used for all the other texture formats). You would need to adapt the cpu side code to swizzle the bytes back into rgba if the swapchain format is Bgra.
You would need to adapt the cpu side code to swizzle the bytes back into rgba if the swapchain format is Bgra.
Two other options an application could implement:
Rgba
format if the supported formats contain oneRgba
outputprefer a
Rgba
format if the supported formats contain one
Sadly these are all the supported formats I am getting: [Bgra8UnormSrgb, Bgra8Unorm, Rgba16Float, Rgb10a2Unorm]
.
Can I count on Bgra8UnormSrgb
beeing supported on most platforms? In that case I will just swizzle the bytes as suggested by @cwfitzgerald
Unfortunately you can't - I know that at least android can't do bgra surfaces.
I see something suspicious here: if the platform doesn't support Rgba8UnormSrgb
, then why did the original code work under 0.12? Is wgpu
0.13 accidentally hiding the Rgba format now? (Or was there a missing validation and the Rgba only worked as some driver make-it-work-anyway-at-a-cost fallback?)
I suspect so, RGBA isn't a valid format for CAMetalLayer - https://developer.apple.com/documentation/quartzcore/cametallayer/1478155-pixelformat
Description I have a small section of code that can be used to render the current scene to a texture and export it as an image. This used to work fine with the
wgpu::TextureFormat::Rgba8UnormSrgb
in version0.12
. However after I recently updated to0.13
it does not work anymore and I am getting a validation error:Repro steps I made a separate repro for this. As you can see, if you checkout the
0.12
branch and pressSPACE
a picture is taken in RGBA format and after checking out the0.13
branch the same operation results in the error from above.Expected vs observed behavior Since the format worked with version
0.12
I am under the impression, that the metal backend on my machine does in fact support this and would therefore expect that it is still available in the latest version.Additional information I think this might be related to the new feature detection in
v 0.13
, but it still occurs on the latest master even after https://github.com/gfx-rs/wgpu/pull/2856 was merged.Platform MacOS 12.3.1, wgpu 0.13 and current master