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

NoAvailablePixelFormat error #913

Closed
gheoan opened this issue Jul 20, 2017 · 18 comments

Comments

@gheoan
Copy link

commented Jul 20, 2017

Running the window example on Windows 10, with Intel GMA X4500 GPU results in error NoAvailablePixelFormat at .\examples/window.rs:11. Glutin version is 0.9.1. Is it possible to configure the context to support this GPU? Let me know if more information is needed.

@jrmiller82

This comment has been minimized.

Copy link

commented Jul 20, 2017

Try commenting out the .with_multisampling(x); line in your rust file. You'll lose antialiasing, but that should work. Don't forget to add a terminal semicolon to the line above if your commenting out the other line changes the semicolon flow.

But, yes, this is definitely a bug, glutin needs to check if the underlying system's OpenGL is high enough version to support the features called by glutin.

@jrmiller82

This comment has been minimized.

Copy link

commented Jul 20, 2017

Devs, I have this same issue on Debian unstable on an older Lenovo Thinkpad x201, as well as on an Ubuntu 17.04 system running on a virtualbox VM.

@gheoan

This comment has been minimized.

Copy link
Author

commented Jul 20, 2017

This is not neccesary a bug. I do not expect glutin to support a GPU with OpenGL version 1.1 (Intel GMA X4500). However, the error is not very descriptive and there is no documentation regarding minimum supported OpenGL version.

@jrmiller82

This comment has been minimized.

Copy link

commented Jul 20, 2017

% glxinfo | grep "version"
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.3
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 17.0.3
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

Here's the output from my virtualbox machine. Looking like max core is 3.3. Not 1.1.

@tomaka

This comment has been minimized.

Copy link
Member

commented Jul 21, 2017

The error is not a matter of supported OpenGL version.
Glutin queries the system for the configuration you request (multisampling, sRGB, depth buffer size, etc.) and if the system doesn't support this configuration, then NoAvailablePixelFormat is returned.

@lo48576

This comment has been minimized.

Copy link

commented Aug 10, 2017

Same error occured in my environment (gentoo linux amd64) with gfx_device_gl and gfx_window_glutin crates and glutin::GlProfile::Core, gfx::format::Srgba8 and gfx::format::DepthStencil config.

The error happened with mesa-17.2.0_rc3 but didn't happen with mesa-17.1.6 or older versions.

@C-Bouthoorn

This comment has been minimized.

Copy link

commented Sep 11, 2017

This issue also appears on Linux (Antergos - Arch based)

$ glxinfo | grep "version"
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.0 Mesa 17.2.0
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.2.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

GPU is Nvidia GTX 1050. This error seems to have happened after updating mesa from 17.1.8-1 to 17.1.8-2. Also the most recent version of 17.2.0-2 gives this error.
Update: Not fixed with mesa 17.2.0-3

Also see PistonDevelopers/piston#1202 for more details.

@stevebob

This comment has been minimized.

Copy link

commented Sep 16, 2017

I'm having the same issue on archlinux on a macbook air with intel integrated graphics. Downgrading mesa from 17.2.0-2 to 17.1.8-1 is my temporary workaround.

@lolzballs

This comment has been minimized.

Copy link

commented Sep 19, 2017

I'm having the same issue on both Intel HD Graphics 630 and GTX 1050 via bumblebee.
GTX 1050 directly with proprietary drivers works however.

I'm running Arch with mesa 17.2.0-2.

@C-Bouthoorn

This comment has been minimized.

Copy link

commented Sep 21, 2017

Update: Still the case with mesa-17.2.1-3, glutin v0.9.2 and updated subdependencies.

Update 2: No change for mesa-17.2.2-1, glutin v0.9.2, rust 1.20.0

@norru

This comment has been minimized.

Copy link

commented Oct 8, 2017

Mee Too!™

Just got NoAvailablePixelFormat error on Devuan Ceres, Lenovo Thinkpad X1 (Intel 520), rust 1.22.0-nightly, glutin 0.10.0. I have resumed work on my gfx "demo" and just managed to port and run from rust 1.12, just to see it panicking. As it stands, this is a showstopper.

  nico@lenovo-devuan:~/Projects/itadinanta/rust-oids$ glxinfo | grep version
  server glx version string: 1.4
  client glx version string: 1.4
  GLX version: 1.4
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
  OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0
  OpenGL core profile shading language version string: 4.50
  OpenGL version string: 3.0 Mesa 17.2.0
  OpenGL shading language version string: 1.30
  OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.2.0
  OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
@norru

This comment has been minimized.

Copy link

commented Oct 9, 2017

It is Srgb's fault. Uncommenting the "does not work" line below reproduces the error. As a result I had to replace all Srgba8 pixelformats in my gfx calls to Rgba8 - perhaps one for @kvark - and do the gamma correction in the tonemapper's fragment program.

	const WIDTH: u32 = 1024;
	const HEIGHT: u32 = 1024;

	let mut events_loop = glutin::EventsLoop::new();

	let builder = glutin::WindowBuilder::new()
		.with_title("Box2d + GFX".to_string())
		.with_dimensions(WIDTH, HEIGHT);

	let context_builder = glutin::ContextBuilder::new()
		//.with_srgb(true) <--- does not work
		.with_gl(glutin::GlRequest::Latest)
		.with_gl_robustness(glutin::Robustness::TryRobustNoResetNotification)
		.with_gl_profile(glutin::GlProfile::Core)
		.with_multisampling(1)
		.with_depth_buffer(24u8)
		.with_stencil_buffer(8u8)
		.with_pixel_format(24u8, 0u8)
		.with_vsync(true);


	let window = glutin::GlWindow::new(builder, context_builder, &events_loop).unwrap();
@lo48576

This comment has been minimized.

Copy link

commented Oct 10, 2017

@rivertam

This comment has been minimized.

Copy link

commented Nov 11, 2017

I'm not sure exactly what's happening, but with mesa 17.4.0-devel and 17.3.0-devel, this issue is still occurring despite indications that it should be fixed on master (which I believe is currently 17.3.0; versions are confusing me because oibaf has 17.4.0 available while mesa's website only has 17.3.0. Both have been updated since the patch should have gone out, as far as I can tell). .with_srgb(true) does not fix the issue for me. I'm unclear on how to downgrade mesa safely, so I'm probably going to hold off until mesa resolves the issue on newer, accessible packages, unless someone has any guidance for me.

glxinfo | rg opengl yields:

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.4.0-devel
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.4.0-devel
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.4.0-devel
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
@C-Bouthoorn

This comment has been minimized.

Copy link

commented May 2, 2018

This issue seems to be fixed with the latest mesa 18.*. Please see PistonDevelopers/piston#1202 for more information

@fasihrana

This comment has been minimized.

Copy link

commented Oct 15, 2018

I'm working on a webrender based GUI framework and I get this error when executing the program via a remotedesktop connection on windows. Might this issue be causing the same error for me which is NoAvailablePixelFormat ?

@nickelc

This comment has been minimized.

Copy link

commented Jan 4, 2019

The problem is gone on my laptop with archlinux for X11 and wayland.

$ glxinfo | grep -i opengl
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 965GM 
OpenGL version string: 2.1 Mesa 18.3.1
OpenGL shading language version string: 1.20
$ cargo run --example window
    Finished dev [unoptimized + debuginfo] target(s) in 0.18s                                                                
     Running `target/debug/examples/window`
Pixel format of the window's GL context: PixelFormat { hardware_accelerated: true, color_bits: 24, alpha_bits: 8, depth_bits: 24, stencil_bits: 8, stereoscopy: false, double_buffer: true, multisampling: None, srgb: false }
OpenGL version 2.1 Mesa 18.3.1
@ZeGentzy

This comment has been minimized.

Copy link
Member

commented Feb 25, 2019

@ZeGentzy ZeGentzy closed this Feb 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.