| Summary: | i965: Severe 3d performance regression 7.7 -> 7.8-rc2 (bisected) | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Nick Bowler <nbowler> |
| Component: | Drivers/DRI/i965 | Assignee: | Kristian Høgsberg <krh> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | currojerez |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Video of the tunnel demo being jerky.
dri2: Reverse invalidate and swapbuffer compatibility ordering. dri2: Delete invalidate compatibility code. dri2: Fix compatibility with old servers. Make tunnel demo use frontbuffer rendering with glFlush. intel_always_throttle.patch |
||
|
Description
Nick Bowler
2010-03-23 18:23:31 UTC
Created attachment 34382 [details]
Video of the tunnel demo being jerky.
I'm have a GM45 here and I can not reproduce the problem. The tunnel demo runs at 170 fps here and openarena and neverball are both at normal framerates. Can you try a make clean and the build mesa from scratch? Every single build in that bisection run was a completely clean rebuild of mesa, done by: git clean -xfd ./autogen.sh --with-dri-drivers=swrast,i965 --enable-xcb --disable-gallium make -j3. Removing the --enable-xcb and --disable-gallium configure options does not change anything. I can reproduce the problem on another machine, this one is a desktop with a G45. The issue occurs on the master branch, as well. OK: if I install *both* xf86-video-intel-2.10.903 and xorg-server-1.7.99.902, the problem is resolved. With just one, the problem persists. If this sort of dependency on pre-release drivers and server is intended, it should at least be mentioned in the release notes for 7.8. Well, I may have spoken too soon. While the tunnel demo seems to run fine now, neverball is still jerky even after upgrading xf86-video-intel and xorg-server (albeit rather less so). Once again, it's perfectly smooth if I use mesa 7.7, thus I ran another bisection. Due to compile errors near the end, the bisection result was not conclusive, but it seems like the cause is different this time around. There are only 'skip'ped commits left to test. The first bad commit could be any of: 5e1851b144a97bd577409dd5c6f3f6f45b4ff56f c7fc9bfb2207638a479ddaff3ad108ffd9cd294a 7aed23c36288c2b343073d6d06ca0ea167805cd3 We cannot bisect more! Some more data points: * The issue does not occur if I set LIBGL_ALWAYS_INDIRECT=1. * The issue does not occur if I run compiz. * The issue *does* still occur if I run xcompmgr. Created attachment 34732 [details] [review] dri2: Reverse invalidate and swapbuffer compatibility ordering. After studying the commit implicated by the first bisection, I believe I have found the issue. Please apply the attached patch, which fixes this bug. [PATCH] dri2: Reverse invalidate and swapbuffer compatibility ordering. After bisecting a major jerkiness regression on my GM45 to commit 61d26bc82e7c4100a ("dri2: Event driven buffer validation."), I noticed that the patch reversed the ordering between the swapbuffers compatibility code and the invalidate compatibility code. Restoring the original ordering (swapbuffers followed by invalidate) fixes the stuttering problems. Fixes fdo bug #27277. Signed-off-by: Nick Bowler <nbowler@draconx.ca> Created attachment 34742 [details] [review] dri2: Delete invalidate compatibility code. So the last patch is wrong. It fixes the problem for backbuffer rendering only, but (presumably) only because the return in the !swapbuffers case prevents the !invalidate code from running. The previous patch does not fix the issue for frontbuffer rendering. It turns out that everything works when the compatibility code is deleted completely. [PATCH] dri2: Delete invalidate compatibility code. Commit 61d26bc82e7c4100a ("dri2: Event driven buffer validation.") introduced severe stuttering on my GM45 when using X server 1.7. This appears to have been caused by the compatibility code added to handle the case where the server does not emit invalidate events. Removing the code entirely solves the issue. Fixes fdo bug #27277. Signed-off-by: Nick Bowler <nbowler@draconx.ca> Dell Inspiron 1545 Laptop here with GM45 graphics and I do indeed have the issue shown in the video. The patch to remove invalidation code fixes the isssue for me. Running an up to date Arch Linux system. OK, I've done some more testing. First, I cannot reproduce any failures on my r600 card: it works with and without the patch with both servers 1.7 and 1.8 (this might be a fluke). So all this is done with xf86-video-intel-2.11 on two machines, one with a G45 and the other with a GM45. I'm also using mesa git master, but it's just as broken on the 7.8 branch. Next, both servers 1.7.6 and 1.8.0 are detected as not supporting invalidate events. As a result, the invalidate compatibility code (the code removed by my patch) is run on both servers. Perhaps a notable difference is that 1.8.0 supports swap events, but 1.7.6 does not. With server 1.7.6, the invalidate compatibility code is run and causes the problem shown in the video. Applying the patch to delete the code totally solves the problem with this server. With server 1.8.0, the invalidate compatibility code is run and seems to be required: applying the patch to delete the code causes the GPU to hang, requiring a reboot to recover. [seems to be caused by running out of memory, the X log gets spammed with "(WW) intel(0): divisor 0 get vblank counter failed: Cannot allocate memory"]. Created attachment 35351 [details] [review] dri2: Fix compatibility with old servers. This is really looking now like it's because 1.7.6 does not support swap events: the issue is exactly reproducible on 1.8.0 by forcing swapAvailable to 0. So here's a new patch which both solves the problem *and* works on both the old and new servers! [PATCH v3] dri2: Fix compatibility with old servers. Commit 61d26bc82e7c4100a ("dri2: Event driven buffer validation.") introduced code to handle "old" servers which do not support invalidate events (i.e. 1.8.0). However, the compatibility code causes severe stuttering on my GM45 with "older" servers that do not support swap events (i.e. 1.7.6). It seems that the solution is to only run the compatibility code when swap events are supported. Fixes fdo bug #27277. Signed-off-by: Nick Bowler <nbowler@draconx.ca> Even with the last patch, frontbuffer rendering using glFlush() is still broken (even on server 1.8.0). glFinish() is OK, however... (In reply to comment #12) > Even with the last patch, frontbuffer rendering using glFlush() is still broken > (even on server 1.8.0). glFinish() is OK, however... When you say it's "broken" you mean that it's still very slow, right? Created attachment 35550 [details] [review] Make tunnel demo use frontbuffer rendering with glFlush. Yes, "broken" here means "inordinately jerky, as shown in the video". Attached is a patch which modifies the tunnel demo to use frontbuffer rendering with glFlush. This causes the jerkiness shown in the video even with latest git mesa and server 1.8.0, with or without my compatibility fix patch. This works fine with mesa 7.7. (In reply to comment #14) > Created an attachment (id=35550) [details] > Make tunnel demo use frontbuffer rendering with glFlush. > > Yes, "broken" here means "inordinately jerky, as shown in the video". > > Attached is a patch which modifies the tunnel demo to use frontbuffer rendering > with glFlush. This causes the jerkiness shown in the video even with latest > git mesa and server 1.8.0, with or without my compatibility fix patch. > > This works fine with mesa 7.7. Great. I tracked this down independently with another reproducer and then remembered your bug report. The problem is that when we're frontbuffer rendering, intel_prepare_render() to update our drawbuffers we end up calling intel_flush() which then ends up in dri2FlushFrontBuffer() which calls DRI2CopyRegion() and then invalidates the buffers. Which means that when we call intel_prepare_renderbuffers() next time, we end up doing the whole thing (including DRI2CopyRegion()) again. intel_prepare_render() was supposed to be a quick cheap check in most cases... I'll commit an edited version of your patch - we don't need the invalidate call in dri2FlushFrontBuffer() at all, so I'll take that out, and in dri2SwapBuffers, I'll just move the dri2InvalidateBuffers() call below the !pdp->swapAvailable test. Fixes pushed to mesa master, please give it a try and close the bug if it fixes the problem. Thanks! Just tried mesa master: we're not quite in the clear yet. Backbuffer rendering with glutSwapBuffers and frontbuffer rendering with glFlush are fine (both server versions). However, frontbuffer rendering with glFinish has regressed: nothing ever appears in the window. We get an empty window frame (with the usual visual problems). This occurs with both servers 1.7 and 1.8. Argh, of course. That should be fixed now. Looks like victory to me! Thanks a lot. Created attachment 35696 [details] [review] intel_always_throttle.patch (In reply to comment #19) > Looks like victory to me! Thanks a lot. Not quite yet, nouveau-classic and all the gallium drivers depend on the compat code this patch has removed (see [1]). IMHO we do want this code (because otherwise we'll have to put the glViewport hacks back and that'd be pretty ugly, especially in the case of gallium. Moreover it wouldn't be completely correct because the client isn't required to call glViewport() on resize). I suspect that your problem is being caused by the intel code that tries to decide whether to turn frame throttling on or off. If that's the case I think we could fix it using the new useInvalidate loader extension Kristian has implemented or something similar. Could you try the attached patch and check if it has the same effect as 2d00d16da7f5d2255cb37b48edaf4cbb9ca7e930? [1] http://lists.freedesktop.org/archives/mesa-dev/2010-May/000692.html Yes, your patch solves all jerkiness issues with both server versions, just like 2d00d16da7f5d does. Furthermore, your patch *also* fixes fixes bug 28072! Er, I forgot to say that I applied the patch on top of the 7.8 branch. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.