parasyte / pixels

A tiny hardware-accelerated pixel frame buffer. 🦀
https://docs.rs/pixels
MIT License
1.78k stars 120 forks source link

Error: AdapterNotFound #354

Closed v1ckie closed 1 year ago

v1ckie commented 1 year ago

I really don't know what is wrong but EVERY single example (apart from some moaning about missing libs that I didn't test) builds successfully but just suddenly flashes some sort of window and then the window disappears and the error in the terminal is "Error: AdapterNotFound" With nothing else.

My current system specs: CPU: I3-4030U CPU (1 physical processor; 2 cores; 4 threads) @ 1.9 GHz RAM: 8 GB Graphics: Mesa DRI Intel(R) HD Graphics 4400 (HSW GT2) OS: Ubuntu 20.04.6 LTS Kernel: Linux 5.4.0-146-generic (x86-64)

Could this be because the GPU is integrated or isn't supported?

parasyte commented 1 year ago

Could this be because the GPU is integrated or isn't supported?

Maybe. Intel GPUs are notoriously sketchy. The most common issue with them is outdated drivers, and the fix is pretty easy. I have some tips to help you troubleshoot, before you decide to make any changes to your system.

  1. First, run the wgpu-info app to get a list of compatible adapters. This will probably fail with the same error.

  2. Second, try the wgpu examples by running cargo run --example hello. Replace hello with any of the examples listed in the link. This will probably fail the same way, also.

If those examples work, then the issue is in pixels, and not your system. This is something that would require more information for us to address. If the examples have the same problem, then the next thing to try is updating the driver.


Mesa is perpetually outdated on Ubuntu. The best way to update it is by adding the kisak-mesa PPA and running sudo apt upgrade to get the latest mesa packages. You may also need to explicitly install the mesa-vulkan-drivers package if you don't already have it. With that, everything should just start working.

One challenge is that Mesa includes software renderers that you probably don't want to use (they have caused many crash bugs in the past). The renderers are drivers called LavaPipe and LLVMPipe. You can tell if these are being used by looking at the output from wgpu-info.

Hope that helps!

v1ckie commented 1 year ago

info.txt

Heres what wgpu-info gave me and yes all of the examples worked for me

parasyte commented 1 year ago

Thank you for the extra info! I think I have determined what is happening, here. It looks like something worth fixing on our end.

wgpu-info says you don't have a Vulkan driver at all. It may or may not be worth installing mesa-vulkan-driver, but the risk is that the driver for Intel GPUs is not guaranteed to work well. You can enable all wgpu backends (which will include OpenGL) with PixelsBuilder::wgpu_backend(). For instance, by patching the minimal-winit example:

diff --git a/examples/minimal-winit/src/main.rs b/examples/minimal-winit/src/main.rs
index 716e6aa..d89b73b 100644
--- a/examples/minimal-winit/src/main.rs
+++ b/examples/minimal-winit/src/main.rs
@@ -3,7 +3,7 @@

 use error_iter::ErrorIter as _;
 use log::error;
-use pixels::{Error, Pixels, SurfaceTexture};
+use pixels::{Error, PixelsBuilder, SurfaceTexture};
 use winit::dpi::LogicalSize;
 use winit::event::{Event, VirtualKeyCode};
 use winit::event_loop::{ControlFlow, EventLoop};
@@ -39,7 +39,9 @@ fn main() -> Result<(), Error> {
     let mut pixels = {
         let window_size = window.inner_size();
         let surface_texture = SurfaceTexture::new(window_size.width, window_size.height, &window);
-        Pixels::new(WIDTH, HEIGHT, surface_texture)?
+        PixelsBuilder::new(WIDTH, HEIGHT, surface_texture)
+            .wgpu_backend(pixels::wgpu::Backends::all())
+            .build()?
     };
     let mut world = World::new();

The explanation is that pixels defaults to using only the wgpu backends that are marked "PRIMARY", which roughly corresponds to the green checkmarks in this table: https://github.com/gfx-rs/wgpu#supported-platforms

image

This is admittedly a conservative default, since we don't need a lot of backend support to draw a single texture! It's also problematic for running the examples on WSL2, where the supported driver is OpenGL; we instead end up inappropriately preferring llvmpipe, a non-conformant software driver.

This is actually a pretty bad situation, and I think I would prefer to just allow wgpu to fallback to OpenGL if it's available, or even ANGLE.

v1ckie commented 1 year ago

thank you for the swift response!

I shall try this again!

parasyte commented 1 year ago

No problem. I intend to publish a new release after I have had a chance to test everything thoroughly!