| Priority | medium |
|---|---|
| Bug ID | 64323 |
| Assignee | nouveau@lists.freedesktop.org |
| Summary | Severe misrendering in Left 4 Dead 2 |
| Severity | normal |
| Classification | Unclassified |
| OS | Linux (All) |
| Reporter | bryancain3+fdo@gmail.com |
| Hardware | x86 (IA32) |
| Status | NEW |
| Version | git |
| Component | Drivers/DRI/nouveau |
| Product | Mesa |
This should be filed under component "Drivers/Gallium/nouveau", but that doesn't exist for some reason. In the nv50 driver, after loading a map in the Left 4 Dead 2 beta, there are major rendering artifacts that make the game unplayable. Portal shows a similar problem. Noticing that stable versions before Mesa 9.1 don't have this problem, I bisected the regression to this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?h=48a45ec24ae74c0 commit 48a45ec24ae74c00d1487552e94d9f824a428f58 Author: Christoph Bumiller <e0425955@student.tuwien.ac.at> Date: Tue Jan 8 16:13:11 2013 +0100 nouveau: improve buffer transfers Save double memcpy on uploads to VRAM in most cases. Properly handle FLUSH_EXPLICIT. Reallocate on DISCARD_WHOLE_RESOURCE to avoid sync. I don't understand the changes made by this commit well enough to fix the regression myself. I have an apitrace that can be used to reproduce the issue, and will comment on this bug with a link to it as soon as I find a good way to share large (~512 MB) files online.
Here is a much smaller (40 MB bz2'd, 74 MB uncompressed) trace that demonstrates the regression in the loading and title screen of Portal: http://plombofiles.pbworks.com/f/portal.trace.bz2 On the loading screen, the "Loading..." text in the bottom right corner is not shown after the regression: http://plombofiles.pbworks.com/f/loading_bad.png http://plombofiles.pbworks.com/f/loading_good.png On the title screen, several frames have significant rendering artifacts after the regression: http://plombofiles.pbworks.com/f/title_bad.png http://plombofiles.pbworks.com/f/title_good.png
A few notes * Rendering is restored to normal by purging all references of DISCARD_WHOLE_RESOURCE from the original patch * Performance drops by ~8% if dynamic buffers are allocated in vram[1] [1] Tested using a minute long demo, of jumping through the first portal portal in the game
Created attachment 81517 [details] [review] Nuke all reffs of whole_discard introduced by original patch Just to clarify what I've meant previously, I'm attaching the patch using which rendering appears correct - both during the loading screen and in-game.
| What | Removed | Added |
|---|---|---|
| See Also | https://bugs.freedesktop.org/show_bug.cgi?id=64888 |
Created attachment 83839 [details] [review] hack/workaround by calim Attaching a patch/hack which calim shared a few weeks back. Restores rendering back to normal on my nv96 system
Dota 2 exhibits the same issue (patches still seem to work)
Dota 2 exhibits the same issue (patches still seem to wo= rk)
On 09/08/13 16:03, Christ-Jan Wijtmans wrote: > how did you get dota2 to even start? it should not work with the nouveau > drivers. > Downloaded the game and pressed Start. I'm not sure what you're implying there with "it should not work", but it works like a charm with the patch mentioned. Only bugs I can noticed are in dota2 (i.e. they are present with the blob, and ati/amd users :P). Last tested with commit 6a2baf3a06125405aa648e208af782e53f1312c0~1, because of [1]. Cheers Emil [1] https://bugs.freedesktop.org/show_bug.cgi?id=67887 > > Live long and prosper, > > Christ-Jan Wijtmans > http://facebook.com/cj.wijtmans > http://twitter.com/cjwijtmans > > > On Thu, Aug 8, 2013 at 4:48 PM, <bugzilla-daemon@freedesktop.org> wrote: > >> *Comment # 5 <https://bugs.freedesktop.org/show_bug.cgi?id=64323#c5> on bug >> 64323 <https://bugs.freedesktop.org/show_bug.cgi?id=64323> from Emil >> Velikov <emil.l.velikov@gmail.com> * >> >> Dota 2 exhibits the same issue (patches still seem to work) >> >> ------------------------------ >> You are receiving this mail because: >> >> - You are the assignee for the bug. >> >> >> _______________________________________________ >> Nouveau mailing list >> Nouveau@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/nouveau >> >> > > > > _______________________________________________ > Nouveau mailing list > Nouveau@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau >
I'm getting similar rendering issues with a 8800 GT card in all Source Engine games (tested in Team Fortress 2, Counter-Strike Source and Dota 2), but I'm not sure if it's the same bug. Mine is similar to the one reported in Valve's tracker: https://github.com/ValveSoftware/Source-1-Games/issues/200 There's a youtube video with show the exact same problem I am experiencing: https://www.youtube.com/watch?v=XLtl7VqnXoE I'm using ArchLinux. xf86-video-nouveau 1.0.9-1 nouveau-dri 9.2.2-1 libdrm 2.4.47-1 linux 3.11.6-1 mesa 9.2.2-1 Should I open another bug report, or is this the same problem?
(In reply to comment #7) > I'm getting similar rendering issues with a 8800 GT card in all Source > Engine games (tested in Team Fortress 2, Counter-Strike Source and Dota 2), > but I'm not sure if it's the same bug. > Mine is similar to the one reported in Valve's tracker: > https://github.com/ValveSoftware/Source-1-Games/issues/200 > There's a youtube video with show the exact same problem I am experiencing: > https://www.youtube.com/watch?v=XLtl7VqnXoE > You're experiencing exactly the same issue. > Should I open another bug report, or is this the same problem? > That should not be needed. This issue is kind of a sore spot, as even calim (the developer who wrote the gallium driver) is unsure why it occurs. I'm suspecting some sort of a race/missing fence, although that's wild guess. Note that nvc0+ cards seems to render fine with this commit - so either there is some subtle difference between the nv50/c0 codebase or hardware. Any input(comments, ideas, patches) would be appreciated :)
A suspiciously similar bug for nvc0 was fixed with 72295c5f6715555082455072bfd29a1e5ae545de nvc0: restore viewport after blit I think you need to set viewport in nv50_blit_3d in the same way nvc0_blit_3d does, and then restore the old viewport afterwards in similar to the referenced commit. I didn't fix it at the time for nv50, because it wasn't setting the viewport. It looks like this was a bug.
Created attachment 89965 [details] [review] a different workaround Not sure if this is the right thing to do. Would be interesting to see what impact this has on the framerate, but it does seem to fix the rendering issues, at least with the portal trace in comment 1. (Should be applied separately from any other workaround/patch.)
| What | Removed | Added |
|---|---|---|
| Attachment #89965 is obsolete | 1 |
Created attachment 89968 [details] [review] a different workaround actually looks like nouveau_fence_wait does more work than is absolutely necessary. check if it's signalled first.
| What | Removed | Added |
|---|---|---|
| Attachment #89968 is obsolete | 1 |
Created attachment 90011 [details] [review] a different workaround OK, I played around with a lot of different options. It actually turns out that my last patch leaks fences. And it waits on fence instead of fence_wr. The new version fixes all these issues. Sticking in a semaphore acquire instead helped a bit, but the rendering was still not right. Even if I used screen->fence.current. So wait it must be :(
I've tested the last patch on TF2, it fixes the issue. I've done some benchmarking and there is some performance loss though: Without the patch: avg 62 fps With the patch: avg 45 fps (with and without done thrice) Mesa 9.2.4
(In reply to comment #15) > I've tested the last patch on TF2, it fixes the issue. I've done some > benchmarking and there is some performance loss though: > > > Without the patch: avg 62 fps > With the patch: avg 45 fps > (with and without done thrice) > > > Mesa 9.2.4 Well that's a big drop... Of course it's not exactly a decrease since it doesn't work otherwise. Could you try the other suggested patches and see what their performance impact is?
workaround_calim.patch: 46 fps 0001-wait-for-the-buffer-to-be-done.patch: 34 fps 0001-nv50-wait-on-the-buf-s-fence-before-sticking-it-into.patch: 37 fps What about Maarten Lankhorst's suggestion?
Two others benchmarks shows 44 and 48 fps with your latest patch (had 45 before, as written above). I'm not sure, but *maybe* it was more laggy than calim patch (like the getting stuck from time to time, as if I had 1 fps). Could just be a placebo though.
Perhaps I was unclear. I was hoping you would test each of the currently-listed patches under "attachments" individually. i.e. https://bugs.freedesktop.org/attachment.cgi?id=90011 https://bugs.freedesktop.org/attachment.cgi?id=83839 https://bugs.freedesktop.org/attachment.cgi?id=81517 After testing each one, unapply it (you can use "git checkout" or "patch -R" depending on your setup). Thanks!
I did test these two individually: https://bugs.freedesktop.org/attachment.cgi?id=90011 https://bugs.freedesktop.org/attachment.cgi?id=83839 Both gave around 46 fps. There's just this last one I haven't tested yet: https://bugs.freedesktop.org/attachment.cgi?id=81517 I'll test it later.
That one: https://bugs.freedesktop.org/attachment.cgi?id=81517 is the best one, I have same performance with it as without any patch (62 fps).
Just want to confirm a theory -- can you test https://bugs.freedesktop.org/attachment.cgi?id=81517 https://bugs.freedesktop.org/attachment.cgi?id=90011 *together* (i.e. apply both patches). They shouldn't conflict. My theory is that this will have the same "higher" performance.
