-
This issue was solved faster than anyone could think! Thanks to everyone involved, great effort!
At the time of writing you still need the git-version of sfml2 for the fix to be applied
This has been a known problem for a while now and it is really annoying, since RenderTexture is a huge asset to the SFML library.
I would like to gather all information possible on this problem and fix this once in for all (on linux at least, dont know if it happens on windows). I know a lot of people have been working hard debugging this problem, as have I, and I would really love it if we could gather all the people who are willing to work on this and actually fix it.
If you think you can help in any way, reply in this thread. If you need some sort of inspiration, please let it be known that Intel engineers are working fullspeed on fixing their drivers for other issues, mostly because of the Valve-Intel-cooperation on porting Steam to Linux.
The information I've gathered so far, by debugging:
I get error
intel_do_flush_locked No such file or directory
When calling RenderTexture::display(). On my unoptimized testbed it is always the third call of one instance.
gdb does not return any sigtrap/segfault or any other error.
I have tried forcing SFML to use the fallback mechanism (context from hidden window) instead of FBO by forcing priv::RenderTextureImplFBO::isAvailable() to return false, did not do any difference.
Tried both SNA and UXA acceleration.
I have tried to track down the error down to the XFree86's Intel drivers sourcecode(2.20.7) http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/, and I think it's related to the function intel_batch_do_flush on line 119 of file intel_batchbuffer.c:
static void intel_batch_do_flush(ScrnInfoPtr scrn)
{
intel_screen_private *intel = intel_get_screen_private(scrn);
struct intel_pixmap *priv;
list_for_each_entry(priv, &intel->batch_pixmaps, batch)
priv->dirty = 0;
}
I am not sure though, I cant find any file that contains parts of the error I get, so it's a tough nut to crack. Given that it is a "No such file"-error it should be an easy fix though.
I will set up a virtualbox instance a partition on my laptop with a custom linuxsetup as a proper testbed, create a minimal reproduction of the error with the latest SFML so I can truly debug both SFML code as well as driver-code without messing up my box.
Any information hugely appreciated, current set up for these results:
ArchLinux Kernel 3.5.3-1-ARCH x86_64
Intel Core i7 3610-QM
Intel Graphics HD 4000 running xf86-video-intel-sna driverpackage from official arch repos.
4 GB Memory DDR3 (Shared with GPU)
SFML 2.0
-
I have tried forcing SFML to use the fallback mechanism (context from hidden window) instead of FBO by forcing priv::RenderTextureImplFBO::isAvailable() to return false, did not do any difference.
This is strange, because this fallback involves nothing more than what sf::RenderWindow uses.
-
Allright I have been able to locate the "faulty" line of code in SFML. I don't know if it is SFMLs fault, but commenting it out makes my test-unit run perfectly. Will check how well SFML works without it and look for substitutes.
This code:
#include <iostream>
#include <SFML/Graphics.hpp>
int main(int argc, char **argv) {
std::cout << "sfml-intel-debug utility v 0.1" << std::endl;
std::cout << "Instancing RenderTexture dbg_tex" << std::endl;
sf::RenderTexture dbg_tex;
std::cout << "Creating empty 128x128" << std::endl;
dbg_tex.create(128,128);
std::cout << "Initiating clear-display loop" << std::endl;
for(int i = 0; i < 10;i++){
std::cout << i << ": Clearing.. ";
dbg_tex.clear();
std::cout << "Displaying.. ";
dbg_tex.display();
std::cout << "OK." << std::endl;
}
std::cout << "All tests done. Seems to work." << std::endl;
return 0;
}
Crashes if SFML flushes here:
void RenderTextureImplFBO::updateTexture(unsigned int)
{
std::cout << "AlterDBG: Ignoring flush!" << std::endl;
//glFlush();
}
My understanding of glFlush is, that it forces the underlying OpenGL mechanisms to complete its operations (probably in another thread?) before continuing, this would probably create tearing or other distortions to rendertextures, but I do not know yet, I will test another project of mine with the altered libraries.
EDIT: allright I tested looping the clear-display 100 times instead, without the flush, and it seems to crash once the internal operations finish anyway. As I suspected.
-
I tried to debug it further by creating a minimal example of what SFML internally do when creating, clearing and displaying a rendertexture, but I failed miserably to do so because of SFML's complexity and my lack of knowledge of the sfml codebase.
Laurent if you're still uptodate on how rendertextures work internally and have time I'd really appreciate if you could help me out on this.
I basically want:
sf::RenderTexture tex;
tex.create(32,32);
tex.clear();
tex.display();
except the internal code. My efforts so far are really pityful, and involves sf::(priv::Gl?)Context:
sf::Context context;
for(int x = 0; x < 100; x++){
glClear(GL_DEPTH_BUFFER_BIT);
context.display(); // <- this lines fail, I bet you know why
}
It would really be much easier to debug this if you take the higherlevel sfml api and go deeper, instead of starting out and guessing at drivers/gl code and going upwards
-
Here it is:
#include <GL/glew.h>
#include <SFML/OpenGL.hpp>
#include <SFML/Window.hpp>
#include <iostream>
int main()
{
// ----- RenderTexture::create -----
// ----- RenderTextureImplFBO::isAvailable -----
sf::Context dummy;
if (glewInit() != GLEW_OK)
{
std::cout << "glewInit failed" << std::endl;
return -1;
}
if (!GLEW_EXT_framebuffer_object)
{
std::cout << "GLEW_EXT_framebuffer_object not supported" << std::endl;
return -1;
}
// ----- Texture::create -----
GLuint texture;
glGenTextures(1, &texture);
if (glGetError() != GL_NO_ERROR)
{
std::cout << "glGenTextures failed" << std::endl;
return -1;
}
glBindTexture(GL_TEXTURE_2D, texture);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 32, 32, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
if (glGetError() != GL_NO_ERROR)
{
std::cout << "glTexImage2D failed" << std::endl;
return -1;
}
// ----- RenderTextureImplFBO::create -----
sf::Context* context = new sf::Context;
GLuint frameBuffer = 0;
glGenFramebuffersEXT(1, &frameBuffer);
if (!frameBuffer || (glGetError() != GL_NO_ERROR))
{
std::cout << "glGenFramebuffersEXT failed" << std::endl;
return -1;
}
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, frameBuffer);
if (glGetError() != GL_NO_ERROR)
{
std::cout << "glBindFramebufferEXT failed" << std::endl;
return -1;
}
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, texture, 0);
if (glGetError() != GL_NO_ERROR)
{
std::cout << "glFramebufferTexture2DEXT failed" << std::endl;
return -1;
}
if (glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT) != GL_FRAMEBUFFER_COMPLETE_EXT)
{
std::cout << "glCheckFramebufferStatusEXT failed" << std::endl;
return -1;
}
for (int i = 0; i < 100; ++i)
{
// ----- RenderTarget::clear -----
if (!context->setActive(true))
{
std::cout << "context.setActive failed" << std::endl;
return -1;
}
glClearColor(1.f, 1.f, 1.f, 1.f);
glClear(GL_COLOR_BUFFER_BIT);
// ----- RenderTarget::display -----
glFlush();
if (glGetError() != GL_NO_ERROR)
{
std::cout << "glFlush failed" << std::endl;
return -1;
}
}
// ----- RenderTexture::~RenderTexture -----
// ----- RenderTextureImplFBO::~RenderTextureImplFBO -----
glDeleteFramebuffersEXT(1, &frameBuffer);
if (glGetError() != GL_NO_ERROR)
{
std::cout << "glDeleteFramebuffersEXT failed" << std::endl;
return -1;
}
delete context;
// ----- Texture::~Texture -----
glDeleteTextures(1, &texture);
if (glGetError() != GL_NO_ERROR)
{
std::cout << "glDeleteTextures failed" << std::endl;
return -1;
}
return 0;
}
Let me know if it correctly reproduces the error.
I really appreciate that you work hard on this major problem, a lot of users will thank you if you succeed to solve it :)
-
Awesome! I'd really like to see this fixed :)
-
Here it is:
...
Let me know if it correctly reproduces the error.
I really appreciate that you work hard on this major problem, a lot of users will thank you if you succeed to solve it :)
Thanks a lot :) It does reproduce the problem! Will continue debugging today
EDIT: Finally something more specific that seems to work!
If you clear with depth buffer instead of GL_COLOR_BUFFER_BIT it works! WOO more info to debug with :D
EDIT2: Got a hint http://www.google.se/search?sugexp=chrome,mod=2&sourceid=chrome&ie=UTF-8&q=IntelClearWithBlit from https://bugs.kde.org/show_bug.cgi?id=kwin-intel
EDIT3: I've been able to trace the problem back to the mesa drivers http://opensource.apple.com/source/X11server/X11server-85/mesa/Mesa-7.0.4/src/mesa/drivers/dri/i965/intel_blit.c look at IntelClearWithBlit. It does some if-statements on what kind of bufferbit to clear with, and then proceeds to LOCK_HARDWARE if it isnt depth or stencil bit.
EDIT4: Allright, Ofc those are the apple drivers and the linux ones seems to be a bit different(and way more complicated). I will try to debug these but Im not sure I will succeed. Source is here: http://cgit.freedesktop.org/mesa/mesa/ lsmod | grep intel to see wether you use 915/965 mesa drivers.
EDIT5: Some more info, the specific errors that begins with "intel_do_flush_locked" is printed from line 167 in file "intel_batchbuffer.c" .
EDIT6: Traced the actual function that fails to libdrm, function drm_intel_bo_mrb_exec. Have downloaded source of same version I have installed from http://dri.freedesktop.org/libdrm/
EDIT7: Allright I'm taking a break. The DRM code is REALLY ugly (im currently still tracing the drm_intel_bo_mrb_exec function, it returns another function, which in turn returns another function and goes on like that in a long loop. Currently in intel_bufmgr_gem.c. Oh, they also use GOTO statement).
If anyone feels like it, please go ahead and debug this.
-
I started a hunt for this bug. The mesa xdemo manywin gives the same intel error. The code is much easier, And there I could find what happens.
Shortly the problem is multiple XOpenDisplay calls + opengl context sharing. When I changed manywin to use one XOpenDisplay call and reuse the Display struct pointer from that, it started to work.
In detail (I didn't know much about OpenGL and don't really know the X Server so it might say obvious things):
1) Display *XOpenDisplay(...) calls give another pointer back every time, even for same display.
2) __glXInitialize(Display* dpy), which should initialize displays for OpenGl use the address of the Display struct to store which displays has been initialized, so for every pointer from XOpenDisplay it initializes the display, even multiple times the same one, if you use XOpenDisplay for the same display, which is the situation in manywin
3) for every screen intel-drm creates a bufmgr to store buffer-objects, in our case it means different bufmgr for windows on same display
4) bufmgr-s cannot share objects, but manywin use a shared context for the windows
5) when the bufmgr creates the exec_buffer (which is the code that the GPU will run), it cannot reference the shared context's object, and drm gives an ENOENT error, which is translated to "No such file or directory."
I filed a bug to mesa: https://bugs.freedesktop.org/show_bug.cgi?id=54971
If the problem is the same, then a workaround is to limit the XOpenDisplay and similar calls count to 1.
-
And I have a dirty patch to libgl which lets me run the sfml shader example, although it crash with a different error in manywin and in the sample program you gave.
-
So, in the code I posted above, if you remove these lines:
sf::Context* context = new sf::Context;
if (!context->setActive(true))
{
std::cout << "context.setActive failed" << std::endl;
return -1;
}
delete context;
... the error disappears?
-
Not unfortuantely.
Btw a good way to get some info about buffer objects etc, is using the INTEL_DEBUG environment variable.
I use
INTEL_DEBUG="buf bat" ./sfml-test 2>&1 | less
Which shows weird things.
-
Not unfortuantely.
But there's only one OpenGL context and one call to XOpenDisplay, with this modification. So is there something else which causes the error?
Which shows weird things.
Like what? :P
-
XOpenDisplay is called a lot of times. I can see that in gdb. I am almost sure that the last test program would work if they weren't.
-
Hmm yeah, maybe there's something tricky with my internal context management.
Anyway, since you already wrote a patch that makes a single call to XOpenDisplay, it would be easier for people to just test your modified version of SFML.
For anyone who wants to test it, here it is:
https://github.com/Szunti/SFML/tree/1display
-
And if you test pls test the shader exmaple. For me, when I change to the "edge post-effect" effect the pixelate shader is used again on the objects.
-
Had to register just to be able to say that the 1display branch solves the issue for me on my laptop, well done.
The shader example does seem to use the wrong shader for edge though.
-
I'm not able to test this out today (probably), but I will certainly test it out when I have time!
I'll test both shaders and rendertextures :)
Great works, thanks szunti!
-
I think the same intel_do_flush error will happen if you share context between screens regardless of my patch. Is it common to reuse context between screens? Is it allowed at all?
-
SFML always uses the same screen (the default one).
-
I think the same intel_do_flush error will happen if you share context between screens regardless of my patch. Is it common to reuse context between screens? Is it allowed at all?
1display-branch worked flawlessly with rendertextures! Will report back with shaders once I've tested them, but why would they be a problem?
EDIT: Have now tried it with both the minimal example I originally created, as well as a personal project of mine. And it totally works :D This is awesome!
-
Allright I have thoroughly tested this branch, and it seems to do what it should perfectly. I have tried both RenderTextures and Shaders, as well as them both together (to "chainlink" shaders).
Also I might have misunderstood the shader issue, was it just an example that broke? Or the whole shader class? It works flawlessly for me.
Laurent will this be merged anytime soon? I might be able to try it out on AMD hardware as well.
-
Laurent will this be merged anytime soon?
I won't merge it directly because the code doesn't follow my conventions, but I'll try to do the modification soon (I'm starting right now).
-
Laurent will this be merged anytime soon?
I won't merge it directly because the code doesn't follow my conventions, but I'll try to do the modification soon (I'm starting right now).
Great news :) Thanks a lot Laurent and Szunti!
-
Also I might have misunderstood the shader issue, was it just an example that broke? Or the whole shader class? It works flawlessly for me.
The shader example is one of the ones that gives the intel_do_flush_locked failed error. Now it runs at least with 1display branch, but the edge post-processing part is wrong because it uses the pixelate shader instead of the correct one, which can be seen with the software renderer.
It's the case for me, and I was curious if it happens for others too. But I guess it's another unrelated bug in the video driver.
-
I've pushed the modification. Please confirm that it still works :)
And what about other OSes? Does anybody have similar problems on Windows or OS X?
-
Is there a minimal code we can directly test? (Maybe the one from Haikarainen's 2nd post?)
What problems were there exactly?
-
Shader example start, but when I quit gives:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x1a00007
Serial number of failed request: 1000
Current serial number in output stream: 1010
which it doesn't do with 1display branch.
EDIT: it happens at the deletion of the last effect.
It seems I suck with gdb + C++, but if you need more info I can try it harder.
Btw it looks wrong to call window.draw(..) and window.display() after window.close() in the example, but it's not the problem, because I changed the order and the error remains.
The examples in this thread works without problem.
-
Is there a minimal code we can directly test? (Maybe the one from Haikarainen's 2nd post?)
Calling RenderTexture create/clear/display is enough to trigger the problem.
which it doesn't do with 1display branch.
Hum :-\
Do you see any major difference between the new code and your branch?
Btw it looks wrong to call window.draw(..) and window.display() after window.close()
It's not a problem, these are no-op when the window has been closed.
-
And what about other OSes? Does anybody have similar problems on Windows or OS X?
No problem on OS X with the shader example and an integrated Intel GPU.
-
XFlush on GlxContext.cpp:124 is where it gives the error.
Maybe it's something with the deleted m_ownsWindow, but I'm too lazy to find out what that does. :D
-
XFlush on GlxContext.cpp:124 is where it gives the error.
Maybe it's something with the deleted m_ownsWindow, but I'm too lazy to find out what that does. :D
Thanks a lot, I'll have a look ;)
-
It's indeed a stupid mistake with the m_ownsWindow member. I'll fix that this evening.
-
My application dies with:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x640000a
Serial number of failed request: 1434
Current serial number in output stream: 1440
On exit as well
I really cant create minimal code from this, but I use rendertextures and shaders together a lot ("chainlinked" shaders on rendertextures for blur etc)
This didnt happen with 1display-branch
-
As implied by my last post, this problem is already identified and will be solved in a couple of hours.
-
As implied by my last post, this problem is already identified and will be solved in a couple of hours.
Ah, sorry I missed that.
-
Is the X error gone now?
-
Yes, it's gone.
-
I have similar problems on windows. I have a intel graphics card integrated in my laptop. Whenever I use a render texture the screen is just black. I'm not an expert in debugging, but I'll try to help.
-
I have similar problems on windows.
Latest version of SFML and latest graphics drivers?
-
I have similar problems on windows.
Latest version of SFML and latest graphics drivers?
For what its worth:
I just tried it under Windows myself (same computer as I've been tinkering with in Linux on this problem), Rendertextures works flawlessly for me. Windows 7, Intel HD4000, latest SFML-git, Latest drivers.
I recall having the same issue as Foaly, doesnt seem to occur now.
-
I have to admit that it's been a while since I tried it. I'll recompile and try it later today.
-
I have to admit that it's been a while since I tried it. I'll recompile and try it later today.
Make sure your drivers are up to date. Someone reported that the latest drivers solve the problem on Windows.
-
alright. I just did some little tests and it seems to all work fine. awesome! :)
-
I use an Intel HD Graphics 3000 on Windows 7, and sf::RenderTexture seems to work already with the revision 6790904 before the fix.
-
The fix is for Linux only, on Windows it seems that it's the latest Intel drivers that solve the problem(s).
-
I guess the corresponding issue on the tracker can be closed now :) (https://github.com/SFML/SFML/issues/101)
-
Ooohhh yeah 8)
I'd like to thank again those who spent time debugging the drivers and implementing a solution, you did an amazing job, I didn't expect such a quick end to this problem!
-
This is amazing. I've been scrambling around trying to find a way to avoid renderTarget after reading about the intel issue a few days ago. I end up looking up that same issue tracker bug, and seeing it was closed not 6 hours ago.
Kudos!
-
Just wanted to check, do the latest commits from the C and the .Net bindings have this fix?
-
Just wanted to check, do the latest commits from the C and the .Net bindings have this fix?
Yes. They are always up to date, since I maintain them all ;)