intel_do_flush_locked failed: Input/output error #137
Comments
|
Oh my, that's surely a bug in the driver... Can you try |
$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.0.6
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 12.0.6
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 12.0.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
|
|
Oh, BTW, I'm also working towards solving my other main issue, which is that I do much of my plotting/visualization across a network. Is there a preferred solution? I'm looking into VirtualGL, but maybe there are much better options? |
|
haha, I remember :) This looks good to me... |
|
When it seemingly worked a few weeks ago, same state as now except that I surely have done an Ubuntu update. It was ~6 months ago that I uninstalled the nvidia driver. I could try booting into an older kernel, if you think that would help. |
|
I was trying to debug this a bit and isolate the problem. Not quite sure I understand why the following isn't updating the window: # first, comment out the renderloop call in rotate_robj.jl
julia> include("rotate_robj.jl")
julia> using GLWindow: render_frame, swapbuffers, poll_glfw
julia> render_frame(window)
julia> swapbuffers(window)
julia> poll_glfw()One interesting observation is that But what's weird is that, as you might guess from JuliaGL/GLAbstraction.jl#63, all the tutorials seem to work just fine. Any ideas? Maybe window settings? |
|
Yes, I do pretty fancy buffer setups, which are likely triggering the driver bug ;) |
|
you should also try |
|
This works for me: So maybe part of the bug? |
|
I decided to take the plunge and install the nvidia driver. We'll see how long it lasts (I have to give a talk Tuesday). I'll go back to debugging this if I revert. The demos are really cool! |
|
Thanks :) |
|
At least temporarily I'm back to intel (swapping external monitors/projectors with different resolutions was buggy). I tried your suggestions above:
So no dice yet. Since it did work earlier, can you point me to the places where you set buffer parameters? A little |
|
I would be very surprised if it is because of something that happened in GLVisualize, a kernel update is much more likely. Have you tried reverting to a previous kernel state? |
|
Yeah, I tried every kernel I had installed on my machine. No luck. Of course it's possible I'd done an |
|
Could have been an xwindow update, of course. That's harder to test. |
|
I was just giving GLVisualize a test whirl, and I replicate @timholy's problem. I'm running a Dell Inspiron laptop with Ubuntu 16.10. |
|
Sorry I think I can't offer much help here... |
|
Thanks for the suggestion. I'm definitely prepared to believe this is a kernel/drivers problem. Regardless, glmark2 runs fine (and gave me a nice bit of nostalgia flashback to the demoscene programs my brother used to trade around with his friends on dialup BBSes back in the early '90s). In case it's in any way useful, the output of glmark2 was: I may keep trying to tinker with this in my free time, but looks like a stumbling block for now. |
|
Damn it! ;) Guess I do something odd! |
|
Thanks for the link! I did end up going down a bit of a rabbit hole tinkering with kernel parameters similar to what's described there, to no avail. This definitely seems like some kind of kernel/driver issue that cleverer minds than mine are going to have to fix. I can confirm, though, that whatever it is definitely involves the GPU crashing, as dmesg reports: I'm throwing in the towel on this for now; if a future kernel update resolves the issue I'll report back. |
|
I'm pretty sure I'm not misremembering that an earlier version worked on my platform. @SimonDanisch, were I to try to bisect this, are the only relevant packages GLVisualize, GLWindow, and GLAbstraction? Or do I need to cast an even wider net? |
|
GLWindow might be the most important one! ... But these are just heuristics :( Of course the error can also be in GLVisualize/GLAbstraction, but it should be less likely! |
|
I have found a working configuration, but it's really old:
Next step is to try to narrow it down a bit. |
|
Yeah, quite a bit has changed in GLWindow: The most complex change is the fxaa shader. For simple check if that's the culprit, you can try turning it off: But I rather suspect the rest of the rendering code -.- |
|
Looks like the crucial event was merging #105. Specifically, with GLAbstraction at 748ab69cb1ba6ee58a639dec02318a07d35dd97c, I get the Sadly, commenting out the fxaa shader didn't fix it. Any further ideas? I tried bisecting into #105, but it's not easy because there are all these dependencies that don't seem to exist. |
|
Let me take a look if that narrows it down enough for me to figure things
out!
…On 21 Mar 2017 2:02 p.m., "Tim Holy" ***@***.***> wrote:
Looks like the crucial event was merging #105
<#105>. Specifically, with
GLAbstraction at 748ab69cb1ba6ee58a639dec02318a07d35dd97c, I get the
intel_do_flush_locked error at:
GLWindow: b5cc0b90f255e06e0f4b4a47f1c3ee1503eace75
GLVisualize: e0fcf28
<e0fcf28>
But the rotate_robj example works on
GLWindow: v0.1.4 (one "real" commit prior to the previous one, needed for
compatibility with GLVisualize)
GLVisualize: 8ea5287
<8ea5287>
Sadly, commenting out the fxaa shader didn't fix it.
Any further ideas? I tried bisecting into #105
<#105>, but it's not easy
because there are all these dependencies that don't seem to exist.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#137 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA9rI4EASjHJGOCxJwn_-f09QdV0hQMMks5rn8pXgaJpZM4L90_n>
.
|
|
Hi, just want to mention I get the same issue on a Thinkpad with integrated Intel graphics, running Ubuntu 16.04. glxinfo | grep OpenGL gives: And glmark2 outputs: Both GLVisualize and GLPlot are looking quite promising, it's great to have a native Julia option for this sort of work. |
|
I am getting the same error with a Dell Precision 3620 (i7-6700 with Intel HD graphics 530) on Ubuntu 16.04
and |
|
Yo, I had the same problem on a Dell XPS 15 on Ubuntu 16. Same as @timholy mentioned, I had no issue with it some time ago. http://ubuntuhandbook.org/index.php/2016/04/switch-intel-nvidia-graphics-ubuntu-16-04/ Of course, depending on some configs, switching to the NVIDIA card may not be desired, but that is the only way I was able to work around it thus far. Cheers, |
|
@SimonDanisch, I greatly appreciate your kind offer in #137 (comment) to look into things, but I wonder if it's not so easy for you if you can't replicate the problem locally. I also know you have a lot on your plate, which the whole CPU backend underway. When that work is merged, it will certainly open up (GL)Visualize to a much wider audience, but of course some folks are still going to be curious to know whether they can leverage the hardware of their machines, so I don't think this issue is going to go away. Consequently, I wonder if there's anything that those of us experiencing this issue can do to help take this item off your TODO list. In a few days I might have a little more breathing room to look into this myself. Any chance we could get you to link us to places in the code that might be especially worthy of inspection? E.g., places where the main buffer settings are specified, etc. |
|
Does anyone have experience with more recent Ubuntu releases fixing the problem? I've wondered about upgrading to 17.04 just to see if it fixes this issue. Installing the NVIDIA drivers fixes it, but it causes problems for me when I connect to a projector for teaching or presentations; and I do that so much that in general I've not found that worthwhile. |
|
Sorry for giving this such a low priority.... I want to port the more complex part of my framebuffer/render setup (which I suspect to be responsible for this) to Visualize today. |
|
Let me try to do it in a way, that one can peel of the complexity with each github commit............... |
|
No apologies needed, I know you are moving massive mountains with your work and I'm very excited about what's coming. Mostly I was trying to discourage you dissuading others from pitching in and trying to debug it themselves (or myself) 😉. Given all the things there are to do in the world, it's very easy to say, "oh, Simon says he will take care of it" but perhaps that's not best for the future trajectory of GLVisualize if we all just lean on you. |
|
I believe I'm seeing the same error: What happens:
Here is my glxinfo Happy to add any additional info that might help. I'm relatively new to Julia-- is there any kind of debug mode that might have a richer stack trace? Keen to give this library a try once this bug gets sorted, the examples shown on your website look great. I can't seem to find anything else that allows for real-time animations, but if you happen to know of alternatives that might be usable in the meantime, that would be helpful too. Thanks! |
I'm back to giving this a whirl. I started by running the tests, and I get a segfault with the message
I was able to verify that the GLFW tests pass.
Hardware/driver details:
What's odd is that I briefly tried this a couple of weeks ago, on the same machine, and I remember seeing an impressive-looking window (but got involved in other tasks before I could look further).
The text was updated successfully, but these errors were encountered: