1
Graphics / Re: [POSSIBLY FIXED] RenderTexture on Intel GPU's. Let's fix this problem!
« on: September 20, 2012, 10:10:15 pm »
Yes, it's gone.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
Graphics / Re: [POSSIBLY FIXED] RenderTexture on Intel GPU's. Let's fix this problem!
« on: September 19, 2012, 11:10:58 am »
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.
Maybe it's something with the deleted m_ownsWindow, but I'm too lazy to find out what that does.
3
Graphics / Re: [POSSIBLY FIXED] RenderTexture on Intel GPU's. Let's fix this problem!
« on: September 18, 2012, 11:30:56 pm »
Shader example start, but when I quit gives:
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.
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
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.
4
Graphics / Re: [POSSIBLY FIXED] RenderTexture on Intel GPU's. Let's fix this problem!
« on: September 18, 2012, 10:27:41 pm »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.
5
Graphics / Re: RenderTexture on Intel GPU's. Let's fix this problem!
« on: September 16, 2012, 07:51:11 pm »
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?
6
Graphics / Re: RenderTexture on Intel GPU's. Let's fix this problem!
« on: September 16, 2012, 01:36:11 pm »
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.
7
Graphics / Re: RenderTexture on Intel GPU's. Let's fix this problem!
« on: September 16, 2012, 12:13:55 am »
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.
8
Graphics / Re: RenderTexture on Intel GPU's. Let's fix this problem!
« on: September 15, 2012, 11:12:33 pm »
Not unfortuantely.
Btw a good way to get some info about buffer objects etc, is using the INTEL_DEBUG environment variable.
I use
Which shows weird things.
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.
9
Graphics / Re: RenderTexture on Intel GPU's. Let's fix this problem!
« on: September 15, 2012, 10:12:55 pm »
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.
10
Graphics / Re: RenderTexture on Intel GPU's. Let's fix this problem!
« on: September 15, 2012, 10:08:23 pm »
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.
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.
Pages: [1]