WindowError(SdlError("Could not create GL context"))

[FuzzyLitchi]

I compiled this code (the example from the website),

extern crate ggez;
use ggez::conf;
use ggez::event;
use ggez::{GameResult, Context};
use ggez::graphics;
use ggez::graphics::{Color, DrawMode, Point};
use std::time::Duration;

struct MainState {
    pos_x: f32,
}

impl MainState {
    fn new(ctx: &mut Context) -> GameResult<MainState> {
        let s = MainState { pos_x: 0.0 };
        Ok(s)
    }
}

impl event::EventHandler for MainState {
    fn update(&mut self, _ctx: &mut Context, _dt: Duration) -> GameResult<()> {
        self.pos_x = self.pos_x % 800.0 + 1.0;
        Ok(())
    }

    fn draw(&mut self, ctx: &mut Context) -> GameResult<()> {
        graphics::clear(ctx);
        graphics::circle(ctx, DrawMode::Fill, Point { x: self.pos_x, y: 380.0 }, 100.0, 32)?;
        graphics::present(ctx);
        Ok(())
    }
}

pub fn main() {
    let c = conf::Conf::new();
    let ctx = &mut Context::load_from_conf("super_simple", "ggez", c).unwrap();
    let state = &mut MainState::new(ctx).unwrap();
    event::run(ctx, state).unwrap();
}

and it compiles fine, but when I try to run it, I get the following error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WindowError(SdlError("Could not create GL context"))', /checkout/src/libcore/result.rs:906:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I have tried a bunch of different examples and nothing seems to run. This seems to be related to #143 but I'm running on a pretty new machine, specs bellow.

OS: Arch Linux 
Kernel: x86_64 Linux 4.13.7-1-ARCH
WM: i3
CPU: Intel Core i5-7200U @ 4x 3.1GHz [40.0°C]
GPU: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) 
RAM: 2119MiB / 7856MiB

[TatriX]

Try glxinfo | grep "OpenGL version"

[FuzzyLitchi]

OpenGL version string: 3.0 Mesa 17.2.2

[termhn]

I’m not familiar with exactly which Linux drivers you should be using with that processor or if they actually exist yet (kernel 4.13 is relatively up to date I believe but there may be something new since then), but that processor supports up to GL 4.4, so the fact that it’s only using 3.0 isn’t good (and the cause of the crash, we only support > 3.2 at this point).

…

On Oct 19, 2017, at 3:00 PM, Emile ***@***.***> wrote: OpenGL version string: 3.0 Mesa 17.2.2 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#194 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2Ln4s01R7Uxda9eclk50Df8qV2D6nbks5st8aKgaJpZM4P_yls>.

[TatriX]

Mesa 9.x supports the OpenGL 3.1 specification.

https://www.mesa3d.org/faq.html

[TatriX]

I just realized that to make it work on Android it should work with 2.0...

[FuzzyLitchi]

Thanks for the help, This is definitely a problem on my end so this issue should probably be closed. 👍

[icefoxen]

Yeah, ggez targets OpenGL 3.2 by default. Work is (slowly) happening to make it possible to support other OpenGL versions, follow #143 if you are interested.

An Intel HD Graphics 620 GPU should be able to do much better than OpenGL 3.0, my laptop has the previous generation chip (HD Graphics 530) and supports OpenGL 4.5. It sounds like you might be using the Mesa software renderer; it can be hard to tell since the Intel driver also ties into the Mesa framework.

[icefoxen]

This is another common question that needs to be documented somewhere well; we need an FAQ or such.

[rassouly]

I have the exact same problem but I don't believe @FuzzyLitchi 's problem come from lack of openGL 3.3 support. Indeed my glxinfo | grep -i opengl reads

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 515 (Skylake GT2) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.3
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.2.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.2.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

The line that indicates the opengl version is OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.3, not OpenGL version string: 3.0 Mesa 17.2.3.

Moreover the following code runs fine:

extern crate sdl2;

use sdl2::video::GLProfile;

fn main() {
    let sdl_context = sdl2::init().unwrap();
    let video_subsystem = sdl_context.video().unwrap();

    let gl_attr = video_subsystem.gl_attr();
    gl_attr.set_context_profile(GLProfile::Core);
    gl_attr.set_context_version(3, 3);

    let window = video_subsystem.window("Window", 800, 600)
        .opengl()
        .build()
        .unwrap();

    let _ctx = window.gl_create_context().unwrap();

    debug_assert_eq!(gl_attr.context_profile(), GLProfile::Core);
    debug_assert_eq!(gl_attr.context_version(), (3, 3));
}

with the 0.29.1 version of the sdl2 crate.

[icefoxen]

@Biohazard50 That's very interesting, thank you. i have a similar OpenGL version string from glxinfo to you, but can't cause this problem to manifest on my system despite having almost the same graphics card (Intel(R) HD Graphics 530). :-/

If someone wants to dig more into where the ggez setup code causes this error, the exact code in question (for 0.3.3) is at https://github.com/ggez/ggez/blob/0.3/src/graphics/mod.rs#L257-L276 There's other various OpenGL flags that might cause a display to say "I can't support that" such as resolution, color depth, etc, and it always seems a bit more fiddly to mess with than you think it should be. If you can find out where exactly it's going wrong that would be useful information to have!

Do you have a hidpi display? Multiple monitors? Does it work if you fiddle with vsync? Stuff like that.

[rassouly]

I think I found something: adding this line gl.set_framebuffer_srgb_compatible(true) makes my minimal crash with SDL returning a "could not create GL context". Reading the code in ggez and gfx_window_sdl (https://docs.rs/gfx_window_sdl/0.7.0/src/gfx_window_sdl/lib.rs.html#112-146) makes me think that maybe this framebuffer_srgb_compatible flag is set to true by default.

I am going to run gdb to check.
Edit: confirmed with gdb that gl.set_framebuffer_srgb_compatible(true) is executed. To change this behavior, we would need to change the RenderFormat type from Srgba8 to Rgba8.
If I understand correctly, the cause of this bug is a lack of srgb support somewhere on my computer (mesa?, screen?, gpu?).
Do you want me to test this change and submit a patch ?

[icefoxen]

Great hunting! Thank you so much.

This kind of isn't a trivial patch because to my knowledge the RenderFormat should be Srgba8 and changing it will screw with the color balance of basically every image ever. I find it very strange that your hardware apparently doesn't like it. Your graphics chipset and driver version appear basically identical to mine, so maybe it's the actual monitor that is having problems? What model of monitor is it?

Can you post a full glxinfo output, please? It apparently lists every supported config, including whether or not it supports SRGB.

@FuzzyLitchi Does this relate to your original problem at all, or have you managed to fix that?

The right solution may be to make SRGB a config flag that can be toggled: https://love2d.org/wiki/love.graphics.isGammaCorrect . However all of gfx-rs's types (framebuffer, texture, shader, etc) are generic on the RenderFormat, so being able to specify it at runtime while making it still convenient to use is a little non-trivial. This is honestly a little related to #143, and the eventual goal of being able to support non-opengl backends (DirectX, Vulkan) which have a similar issue. I am hesitant to just wrap all the genericness up into the GraphicsContext type and then hide it behind a trait object, but that might be the best way...

[rassouly]

I am using a laptop (asus zenbook UX305C) so I don't really know which monitor it is. This is however a fairly recent laptop (2 year old) so this problem might affect many systems.

[est31]

This sounds very much like a known regression of the intel i965 MESA driver from the 17.1 branch to the 17.2 branch. See my comment for the piston engine for more: PistonDevelopers/piston#1202 (comment)

For the users I suggest to obtain MESA 17.1 (e.g. by compiling it yourself). For the maintainers of ggez I suggest to add a non-srgb mode to work on intel hardware on MESA 17.2. Don't please ping the MESA developers, they are already aware of the bug!

[rassouly]

I can confirm that downgrading mesa fixes all my problems.

[FuzzyLitchi]

Downgrading to mesa 17.1 fixed it for me too, thanks :)

[rassouly]

This bug is fixed for me (and for everyone I hope) in Mesa master. So this issue should be closed.

[FuzzyLitchi]

17.1.8-2 -> 17.2.5-1
Version 17.2.5-1 which is the newest version on arch doesn't work for me.

EDIT: Oh, master

[icefoxen]

Ok, closing this since it seems resolved.

[termhn]

Perhaps we should keep this open until the fix is implemented in a standard Mesa update that would be rolled out to common distros to prevent more confusion like #212?

[icefoxen]

You are optimistic about whether people check the issue tracker before posting things! But, can't hurt.

[daboross]

@cider-teeworlds you, uh, don't have to be so dramatic.

"Work in progress game engine has bugs."

[Manghi]

People work on this with whatever spare time they can afford. While we would all love a perfectly functional library today, we are still laborers of time and effort. If you spent either of those to read this thread you would see that it's an issue in the mesa library. There are options listed in this thread that you can follow to get around that.

[icefoxen]

@cider-teeworlds If I started a patreon with the promise that I would work on making ggez support older hardware if people donated, would you donate? :-D

[ibrokemypie]

I believe I am getting the same error when running astroblasto

Adding path "/home/conor/git/blaster/resources"
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WindowError(SdlError("Could not create GL context"))', libcore/result.rs:945:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
             at libstd/panicking.rs:537
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:521
   7: rust_begin_unwind
             at libstd/panicking.rs:497
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:71
   9: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:23
  10: <core::result::Result<T, E>>::unwrap
             at /checkout/src/libcore/result.rs:782
  11: blaster::main
             at src/main.rs:617
  12: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  13: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:479
  14: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  15: std::rt::lang_start_internal
             at libstd/panicking.rs:458
             at libstd/panic.rs:358
             at libstd/rt.rs:58
  16: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  17: main
  18: __libc_start_main
  19: _start

 glxinfo | grep -i opengl
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.3
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: 4.0 Mesa 17.3.3
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.3.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

[icefoxen]

@ibrokemypie Yeah, looks like it. So that confirms that Mesa 17.3 has this issue as well... :-(

[dannyfritz]

Been a few weeks, but i think i remember 17.4 being the target release for this change. They have a pretty robust version pipeline to go through to ensure they don't break everything for everyone.

[icefoxen]

They have a pretty robust version pipeline to go through to ensure they don't break everything for everyone.

I appreciate that, and sympathize with them, but the inevitable first thought is "well it didn't bloody work now did it". :-P

[dannyfritz]

PistonDevelopers/piston#1202 (comment)

"soon (within the next few days), we are going to have Mesa 18.0.0 with a fix for this."

[svenstaro]

@cider-teeworlds if you do not stop your harassment, I will block you from the project. You are also risking your GitHub account when you write stuff like that so think about that.

[onelson]

I'm sort of catching up here - revived a project last night and ran into this as soon as I tried to cargo update and rebuild.

I'm wondering if there's some guidance on configuring the target gl version so things will run, even when on the busted mesa.

I see https://github.com/ggez/ggez/blob/master/src/graphics/mod.rs#L227, which I'm planning to add as a binary target in my project. Perhaps this would be nice to have as a separate standalone crate? ggez-gl-probe? Something that could spit out a snippet of config for the graphics system.

[NoraCodes]

I also ran into this issue. It would be great to have a way in conf to specify that an advanced graphics mode isn't needed; my current project just needs to draw pixels, rectangles, and text on the screen, and it would be great to be able to signal that to GGEZ so I can fall back to basics in terms of OpenGL.

In any case, many thanks for all the help on this project.

[termhn]

Unfortunately OGL isn’t really backwards compatible. It’s not as simple as saying "don’t need the new stuff, just let me do basics," we’d need to rewrite shaders and maybe a fair amount of the render pipeline itself because it depends fairly heavily on instanced drawing support which doesn’t exist until close to the version we already use without extensions.

…

On Feb 14, 2018, at 3:46 PM, Leo Tindall ***@***.***> wrote: I also ran into this issue. It would be great to have a way in conf to specify that an advanced graphics mode isn't needed; my current project just needs to draw pixels, rectangles, and text on the screen, and it would be great to be able to signal that to GGEZ so I can fall back to basics in terms of OpenGL. In any case, many thanks for all the help on this project. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#194 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2Ln4zk00g3h0V2BIF_eWFj3pbKe8o_ks5tU2IvgaJpZM4P_yls>.

[NoraCodes]

That makes sense; sorry for the ignorant comment. In happier news, I can confirm that the fix is present in Mesa 18, at least for me.

[est31]

This specific bug has little to do with the provided OpenGL version but rather with sRGB support. That's it.

[bestouff]

How about modifying that "conf" setting on linux to have at least the examples work ? There are countless applications working with mesa 17.x, the fact that ggez doesn't is a bit weird.

[icefoxen]

@bestouff

This kind of isn't a trivial patch because to my knowledge the RenderFormat should be Srgba8 and changing it will screw with the color balance of basically every image ever
...
The right solution may be to make SRGB a config flag that can be toggled: https://love2d.org/wiki/love.graphics.isGammaCorrect . However all of gfx-rs's types (framebuffer, texture, shader, etc) are generic on the RenderFormat, so being able to specify it at runtime while making it still convenient to use is a little non-trivial.

Long story short, it's not currently designed to be modified, hardcoding a different value would be Incorrect, and I'm not yet sure how to redesign it to be easily modified.

You're right though, this is a setting that should be able to be toggled. #299 has been created.

[BORN2LOSE]

Another one solution for Arch/Manjaro user's:

1. Edit /etc/pacman.conf file and enable mesa-git custom repository :

sudo vim /etc/pacman.conf
# ...
[mesa-git]
SigLevel = Optional
Server = https://pkgbuild.com/~lcarlier/$repo/$arch

2. Synchronize packages and install : sudo pacman -Syu mesa-git lib32-mesa-git
3. Reboot OS
4. Check the version:

glxinfo | grep "OpenGL version"   # or glxinfo | grep -i opengl
# ...
OpenGL version string: 3.0 Mesa 18.1.0-devel (git-e1b2e5667c)

[est31]

FINALLY we got mesa 18.0 which should include a fix for this bug. Looking forward to mesa 18.0 hitting all the distros, then this issue should be history.

[bestouff]

This may take a loong time, especially for people using LTS versions which can last a few years.

[C-Bouthoorn]

This seems to have been fixed with the latest mesa 18.*. See PistonDevelopers/piston#1202 for more information.

[icefoxen]

A lot of the innards have been reworked in commit 8356184 and the few previous ones. It might still take some rearranging, and it will definitely involve an API break. GraphicsContext needs to be generic on the color type, since it has to store the surface format information somewhere and it has to be known at compile time for many of gfx-rs's functions, and the ability to go from compile-time to run-time and back is still rather awkward.

What we probably have to do is either make Context generic on the color format, which seems somewhat silly and means you are going to have to do extra work to choose which color format to use at runtime, or to make GraphicsContext a trait object, which is somewhat more work but makes it easier to choose at runtime.

[icefoxen]

Fixed in #415. Followup in #416.