headless_defaults example panics

[rparrett]

Bevy version

main
bisected to #3884

Operating system & version

MacOS 12.2.1 (M1)

What you did

cargo run --example headless_defaults

What you expected to happen

I think that this example is meant to display a blank window? At least that's what it did prior to #3884

What actually happened

thread 'main' panicked at 'Requested resource bevy_render::renderer::render_device::RenderDevice does not exist in the `World`. 
                Did you forget to add it using `app.add_resource` / `app.init_resource`? 
                Resources are also implicitly added via `app.add_event`,
                and can be added by plugins.', crates/bevy_render/src/texture/image_texture_loader.rs:74:23
stack backtrace:
   0: rust_begin_unwind
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/panicking.rs:116:14
   2: bevy_ecs::world::World::resource
             at ./crates/bevy_ecs/src/world/mod.rs:748:21
   3: <bevy_render::texture::image_texture_loader::ImageTextureLoader as bevy_ecs::world::FromWorld>::from_world
             at ./crates/bevy_render/src/texture/image_texture_loader.rs:74:17
   4: <bevy_app::app::App as bevy_asset::assets::AddAsset>::init_asset_loader
             at ./crates/bevy_asset/src/assets.rs:325:22
   5: <bevy_render::texture::ImagePlugin as bevy_app::plugin::Plugin>::build
             at ./crates/bevy_render/src/texture/mod.rs:50:13
   6: bevy_app::app::App::add_plugin
             at ./crates/bevy_app/src/app.rs:764:9
   7: <bevy_render::RenderPlugin as bevy_app::plugin::Plugin>::build
             at ./crates/bevy_render/src/lib.rs:282:9
   8: bevy_app::plugin_group::PluginGroupBuilder::finish
             at ./crates/bevy_app/src/plugin_group.rs:118:21
   9: bevy_app::app::App::add_plugins
             at ./crates/bevy_app/src/app.rs:791:9
  10: headless_defaults::main
             at ./examples/app/headless_defaults.rs:4:5
  11: core::ops::function::FnOnce::call_once
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[rparrett]

Pinging @Shatur and @kirusfg who previously worked on headless-related stuff and @superdump .

It looks like there's now some code in the image loaders that use the render device to determine which compressed textures are supported by the GPU.

Does it make sense to use a theoretical CompressedImageFormats::all() if no RenderDevice is present and things aren't going to be rendered anyway?

Is there a simple example of compressed texture usage somewhere that I could test with?

[superdump]

An example could be added but it would have to have feature dependencies and would probably have to either load a format that would only work on some GPUs or depend on basis-universal that currently will not work on wasm.

I don’t think we can just claim support for all. I think if there is no render device we would have to claim support for none as there is no GPU to do any compression. But does headless have to be GPU-less? Isn’t it just windowless?

[superdump]

Probably a simple scene with quads with textures with text labels as to the formats of the textures and all texture formats (well, not all variants of ASTC or anything, just JPEG/PNG/ASTC/ETC2/BCN/BasisU.) That would be a good test to have. I could put that together.

[Shatur]

Does it make sense to use a theoretical CompressedImageFormats::all() if no RenderDevice is present and things aren't going to be rendered anyway?

I agree with this. This is how it done in Godot.

I don’t think we can just claim support for all. I think if there is no render device we would have to claim support for none as there is no GPU to do any compression.

Then users have to handle all logic that contains images in a special way which is unusual.

But does headless have to be GPU-less?

Yes. The main purpose of it is to run it on server.

[superdump]

So headless is GPU-less but for some reason, say software rendering, you may still want to load textures on a GPU-less server? They will not currently be able to decompress any of the compressed formats without further extension. Do they not need to for some reason?

[Shatur]

So headless is GPU-less but for some reason, say software rendering, you may still want to load textures on a GPU-less server?

The use case is to execute systems that have images, but don't do anything with them. I assumed that CompressedImageFormats::all() is required. If not, then let's just remove the panic if there is no GPU :)

[superdump]

Also, GPUs provide the support for decompression of the textures, built into the hardware. There are software decompressors. But what I would advise to do really depends on the use case. When shipping games, you would either ship a universal format (UASTC or the Basis format) and transcoder (to convert to ASTC/BCN/ETC2) or you would ship those compressed formats directly. ASTC is supported on most mobile, ETC2 on a bit older mobile, and BCN on desktop GPUs. Apple M1 is an exception and supports all of them. Intel iGPUs have supported ASTC I think. So compressed texture format wise, it’s just a complicated and fragmented world in terms of support.

What are the use cases?

[superdump]

So headless is GPU-less but for some reason, say software rendering, you may still want to load textures on a GPU-less server?

The use case is to execute systems that have images, but don't do anything with them. I assumed that CompressedImageFormats::all() is required. If not, then let's just remove the panic :)

Ok. I guess we could just load anything.