SFML community forums

Help => Graphics => Topic started by: jmcmorris on May 02, 2015, 03:44:04 pm

Title: Shader Unavailable when it should be
Post by: jmcmorris on May 02, 2015, 03:44:04 pm
Hello, I have a player who is currently running into an issue with Shaders not working at all and am hoping to get some help figuring out why that is.

The information I have collected so:

OS: Mageia 4 x64
"OpenGL version string: 4.4.0 NVIDIA 331.113"
VGA compatible controller: NVIDIA Corporation GF104 [GeForce GTX 460] (rev a1)

He says he has played many games on this system such as Borderlands 2. From what I can tell he should be able to use shaders but he is definitely running into this error.

"Failed to bind or unbind shader: your system doesn't support shaders (you should test Shader::isAvailable() before trying to use the Shader class)"

Am I wrong in thinking that he should be able to use shaders? Any other information I should ask for or something for him to try? Regardless, thanks for reading this and any help.
Title: Re: Shader Unavailable when it should be
Post by: binary1248 on May 02, 2015, 04:15:01 pm
What SFML version (or revision) are you using? Can you provide the full output of glxinfo?
Title: Re: Shader Unavailable when it should be
Post by: jmcmorris on May 02, 2015, 04:18:28 pm
Fairly recent build from SFML2.2: https://github.com/LaurentGomila/SFML/tree/e0d27358fb9d62fcba96e1d14fa3185ce63668e9

I'll ask for the full glxinfo ouput.
Title: Re: Shader Unavailable when it should be
Post by: jmcmorris on May 02, 2015, 05:21:15 pm
Ok, we have the full output which is apparently massive. Instead of copying and pasting it all here I'm going to just link to it. I hope that isn't a problem. If it is just let me know and I can post it here instead. Thanks for the help!

http://steamcommunity.com/app/280520/discussions/1/620712364032377205/#c620712364033363826
Title: Re: Shader Unavailable when it should be
Post by: binary1248 on May 02, 2015, 06:22:18 pm
Hmm... strange. The reporter's GLX exposes all the required extensions.

Is there any way you/they can provide more information from within the application? The OpenGL context that is created is very specific to the settings you try to create it with. Sometimes something goes wrong and we end up with a context that is borderline unusable (might be the case here). The values in sf::ContextSettings that you get back from the sf::RenderWindow/sf::Window after its creation would help here.

Also, when do you check for shader support or maximum texture size the very first time? This might provide clues as to when the extensions are actually loaded. In a normal scenario, this shouldn't be a problem since the proper (extension supporting) context is used to load in all the extensions which itself is only created after the shared context exists already.

P.S. Next time, pastebin.com (http://pastebin.com) might help with glxinfo output. ;)
Title: Re: Shader Unavailable when it should be
Post by: jmcmorris on May 03, 2015, 05:26:11 am
Hey binary, I currently do not log details about the OpenGL context but I do happen to log the maximum texture size. In this case he has "Maximum Texture Size: 16384". I will add in code to print out the details of the sf::ContextSettings.

I obviously check for maximum texture size but I do not check for shader support. I will do that as well and log the result. Unfortunately the turn around is not instantaneous since I need to get this new build out to the player. I'll report back here once I have the results in.
Title: Re: Shader Unavailable when it should be
Post by: binary1248 on May 03, 2015, 10:31:56 am
Yeah... before you push out that new build, you might want to add even more debugging information to the log. Even though the glxinfo output showed that the extensions are supported on they're system, getting the picture from inside the application would also help. This (collecting info) is a feature that will be added to SFML soon as well in order to aid in debugging.

I showed how this is done in code here (http://en.sfml-dev.org/forums/index.php?topic=17245.msg128946#msg128946). Just add GL_EXTENSIONS and GL_VERSION to the 2 that are already shown in the snippet we'll have all the strings we need. From those strings we'll be able to tell whether the application is using a software renderer for whatever reason and work from there.
Title: Re: Shader Unavailable when it should be
Post by: jmcmorris on May 03, 2015, 11:28:09 am
Just got back from dinner and saw both your response as well as the player's response with my new build. Fortunately the player is being great and helping figure out what is going on so I can put together another build for him to try. Here are the results from the new update which is ran immediately after the RenderWindow is created and before any rendering or shaders are loaded.

Maximum Texture Size: 16384
Context Settings: version=1.1 antialiasing=0 depthBits=0 stencilBits=0
Shaders are not supported on this system.

I'll work on getting that additional information.
Title: Re: Shader Unavailable when it should be
Post by: jmcmorris on May 03, 2015, 12:38:55 pm
More information!

Vendor: NVIDIA Corporation Renderer: GeForce GTX 460/PCIe/SSE2 Version: 1.4 (2.1.2 NVIDIA 331.113) Extensions: GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_framebuffer_object GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_packed_depth_stencil GL_NV_point_sprite GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_multi_draw_arrays GL_SUN_slice_accum


Something I noticed that's off is that the versions here say 1.4 but the context settings is only at 1.1.
Title: Re: Shader Unavailable when it should be
Post by: binary1248 on May 03, 2015, 03:38:59 pm
I know it sounds silly but, did you remember to check the sf::ContextSettings after it is returned from sf::RenderWindow::getSettings()? :D Those values just happen to be equal to the values in a default-constructed sf::ContextSettings.

Also, we are getting really deep into "driver implementation details" here. Until now, this might have been the first case that I have seen in which the driver chooses not to give us a fully capable context purely because we request version 1.1. According to the specification this is perfectly legal, it's just that this has never happened anywhere else before because any other driver would just give us a 4.4 compatibility context when we request version 1.1.

If the application absolutely requires shaders to run, you can try specifying that you want at least a 2.0 or 2.1 context (this is when shaders became core OpenGL) via the settings sf::ContextSettings parameter when creating your sf::RenderWindow. This should force the driver to give you a context that has to support shaders or SFML will emit a warning if it can't. This will possibly break the application for users with really ancient hardware that can't provide a 2.0+ context, but considering your application requires 2.0+ capability to run, I think this should be acceptable.
Title: Re: Shader Unavailable when it should be
Post by: jmcmorris on May 03, 2015, 04:21:33 pm
Not silly at all. But yes, the settings is coming from RenderWindow::getSettings(). Here is the code that's logging.

m_window = boost::make_shared<sf::RenderWindow>();
Int32 maxTextureSize = sf::Texture::getMaximumSize();
LOG_INFO("Maximum Texture Size: " << maxTextureSize);
const sf::ContextSettings& s = m_window->getSettings();
LOG_INFO("Context Settings: version=" << s.majorVersion << "." << s.minorVersion << " anti=" << s.antialiasingLevel << " depth=" << s.depthBits << " stencil=" << s.stencilBits);
if (!sf::Shader::isAvailable()) {
    LOG_INFO("Shaders are not supported on this system.");
}

Shaders are indeed a requirement for playing the game and I even say so on the store page. I hadn't realized I could specify the required context version. Thank you very much for your help. Let me know if we can look into anything else for you since this seems to be such a special case. Cheers!
Title: Re: Shader Unavailable when it should be
Post by: binary1248 on May 03, 2015, 04:38:21 pm
Umm... I don't know how to put it, but...
m_window = boost::make_shared<sf::RenderWindow>();
doesn't actually create the window. ;D See here (https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/RenderWindow.cpp#L35). If you want to create the window, either specify some parameters or explicitly call create on the object after default-constructing it.

This is something you might end up with when explicitly requesting a 2.0+ context:
m_window = boost::make_shared<sf::RenderWindow>();
m_window->create(sf::VideoMode(100, 100), "Title", sf::Style::Default, sf::ContextSettings(0, 0, 0, 2, 0));
Int32 maxTextureSize = sf::Texture::getMaximumSize();
LOG_INFO("Maximum Texture Size: " << maxTextureSize);
const sf::ContextSettings& s = m_window->getSettings();
LOG_INFO("Context Settings: version=" << s.majorVersion << "." << s.minorVersion << " anti=" << s.antialiasingLevel << " depth=" << s.depthBits << " stencil=" << s.stencilBits);
if (!sf::Shader::isAvailable()) {
    LOG_INFO("Shaders are not supported on this system.");
}
This is all adequately described in the documentation (http://www.sfml-dev.org/documentation/2.2/classsf_1_1Window.php#a30e6edf2162f8dbff61023b9de5d961d).
Title: Re: Shader Unavailable when it should be
Post by: jmcmorris on May 03, 2015, 04:43:03 pm
Oh yeah, you're right haha! It has been awhile since I messed with this side of the code. I remember now that there is a create method or the constructor will call create if I pass in the parameters for it. Well, then. Now I feel a little silly. :P
Title: Re: Shader Unavailable when it should be
Post by: binary1248 on May 04, 2015, 12:47:40 pm
You could try out the bugfix/context_version (https://github.com/SFML/SFML/tree/bugfix/context_version) branch. It's a long shot but the driver might end up providing your application with a better context version when using the newer context creation method paired with the "give me the most recent version" hint (in master it isn't always used even if it is supported).
Title: Re: Shader Unavailable when it should be
Post by: jmcmorris on May 05, 2015, 02:01:11 am
Tried that context_version branch to no avail. I added in logging AFTER the creation of the window and here's what we're getting now.

Context Settings: version=1.4 anti=0 depth=0 stencil=0
Shaders are not supported on this system.
Vendor: NVIDIA Corporation Renderer: GeForce GTX 460/PCIe/SSE2 Version: 1.4 (2.1.2 NVIDIA 331.113) Extensions: GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_framebuffer_object GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_packed_depth_stencil GL_NV_point_sprite GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_multi_draw_arrays GL_SUN_slice_accum

This is with me specifying the version in sf::ContextSettings.
m_window->create(mode, "Crea", style, sf::ContextSettings(0, 0, 0, 2, 1));
Title: Re: Shader Unavailable when it should be
Post by: binary1248 on May 05, 2015, 03:14:50 am
After poking around the internet a bit, I have a feeling that this is caused because of a library architecture mismatch. Often times, Steam games are distributed as 32-bit binaries that rely on multilib. And even if they aren't, they still try to load the 32-bit OpenGL library, and if that isn't found, either because it isn't installed or simply isn't up to date, they end up loading in some other library or version of the library that might be a residue from earlier.

The reason why glxinfo reports the proper data is because it is guaranteed to be native to the operating system architecture (a 64-bit binary on a 64-bit system). glxinfo will always load the proper OpenGL library if one is installed. Steam applications won't half the time (for mysterious reasons), since they for whatever reason decide not to provide native 64-bit binaries for 64-bit systems which make up almost all modern gaming systems these days or the 64-bit binary chooses to load in 32-bit dependencies (I've actually seen this happen before, no idea how that is supposed to work).

The user can figure out if they have a 32-bit or 64-bit system by checking the output of
Code: [Select]
uname -aFind out the absolute path of glxinfo by issuing
Code: [Select]
which glxinfoThe output should be something similar to /usr/bin/glxinfo. Issue
Code: [Select]
ldd /usr/bin/glxinfo(or whatever the real path is from the previous output) to find out which libGL.so it is loading. Compare this to the output of
Code: [Select]
ldd <absolute path to your game's binary>If the game is loading or trying to load another libGL.so than the one that glxinfo loads, the user needs to make sure they have the 32-bit OpenGL library from Nvidia installed as well. I tried looking around, but couldn't find the Mageia package name for the 32-bit OpenGL library from Nvidia, so the user will have to figure that one out on their own.

It would help if you could post the output of each of those commands here as well, there might be some other useful information in them.