SFML community forums
Help => Graphics => Topic started by: jmcmorris on January 15, 2016, 09:26:24 pm
-
Hello! Several players for my game using intel GPUs are running into a crash inside sf::Shader. I have looked around for similar issues and to see if something like this has been fixed but I have not seen anything. I am using SFML 2.2~ with a few things pulled into it from 2.3. I do check if sf::Shader::isAvailable() and it is on these systems.
Here is what one of the stacktraces looks like:
ig7icd33
ig7icd32
ig7icd32
ig7icd32
crea!sf::Shader::bind
crea!sf::RenderTarget::draw
crea!sf::Sprite::draw
crea!sf::RenderTarget::draw
Another one:
ig7icd32
ig7icd32
ig7icd32
ig7icd32
crea!sf::Shader::setParameter
Unfortunately I do not have line numbers to go with these. To start with I was just curious if this been seen before or perhaps even fixed. If I can get one of these players to work with me I'll try coming up with a minimal code repro if that would be helpful here. Cheers!
-
I'm guessing this is on Windows?
Extension loading was overhauled between 2.2 and 2.3 in 3e397bff4b206cdaad9e1e52a75dfacb8676be31 (https://github.com/SFML/SFML/commit/3e397bff4b206cdaad9e1e52a75dfacb8676be31). Context management was gradually overhauled between 2.3 and now. I remember those changes fixing a bunch of weird bugs (including crashes), especially on Windows.
You might want to try out an experimental build using 2.3.2 and see if the problem persists.
-
I'm guessing this is on Windows?
Extension loading was overhauled between 2.2 and 2.3 in 3e397bff4b206cdaad9e1e52a75dfacb8676be31 (https://github.com/SFML/SFML/commit/3e397bff4b206cdaad9e1e52a75dfacb8676be31). Context management was gradually overhauled between 2.3 and now. I remember those changes fixing a bunch of weird bugs (including crashes), especially on Windows.
You might want to try out an experimental build using 2.3.2 and see if the problem persists.
Sure I can try the latest and see if that resolves the issue. I looked over what I exactly have in my fork and I am actually on 2.3.0. I have that massive extension overhaul and pulled this one in, 7c179193e6acf0c3fed97964ebcd1fabcd69dcd7 (https://github.com/SFML/SFML/commit/7c179193e6acf0c3fed97964ebcd1fabcd69dcd7), which fixed another intel gpu crash that was occurring. Thanks for the quick reply!
-
I read some article about intel chipset and it has a little strange opengl driver. It may change gl extension function pointers after call to wglMakeCurrent. I didn't investigated on what is going on with intel graphics, but some peoples recommend to reload gl extensions after each makecurrent call...
-
I read some article about intel chipset...
If you don't even bother linking the source your statements are quite useless, since the article could've been about all kinds of things...
-
I read some article about intel chipset...
If you don't even bother linking the source your statements are quite useless, since the article could've been about all kinds of things...
Sorry, I didn't save the link, recently I read a lot of things about init gl extensions because I'm debugging my own cross platform library. So, I don't remember exactly where I found it.
Try to get shader loginfo and program loginfo when running it on intel chipset, may be it consist of some info
-
I was able to track someone down and dig into this some. I discovered that it is being caused by the RenderTexture substitute that I'm using. Another dev here, eigenbom, shared with me a FBOTargetImpl class that he wrote which provides a framebuffer that uses the same context as the window.
These intel cards do have support for framebuffers but they crash when attempting to bind the shader. I'm currently think that the context state is somehow getting messed up and the shader doesn't like that. FBOTargetImpl is not doing anything too special and after using it I always ensure that the framebuffer is reset as well as the GL states.
Any suggestions on what I could do to fix this? If needed I can post a bunch of the code. Just let me know. Thanks! :)