|Summary:||Wine DirectDraw programs showing only a blackscreen when using Mesa Gallium drivers|
|Product:||Mesa||Reporter:||Fabian Maurer <dark.shadow4>|
|Status:||RESOLVED FIXED||QA Contact:||mesa-dev|
|Priority:||medium||CC:||dark.shadow4, joseph.kucia, quentin, stu_dby, t_arceri|
|i915 platform:||i915 features:|
apitrace that mesa renders as completely black
Log for swrast
Apitrace from the editor for a game called N-Ball
mesa/st: Add both front and back buffer if the visual is double-buffered
nball replay output with patch applied
Description Fabian Maurer 2016-12-17 00:14:10 UTC
Created attachment 128505 [details] apitrace that mesa renders as completely black The program works fine with other drivers, but with mesa it returns a black-screen. Apitrace attached. (Size 4MB, 115MB unpacked) Using -32bit program on Arch 64bit -Mesa 13.1.0-devel (git-47351b843a) -Radeon R9 285 The corresponding wine bug report: https://bugs.winehq.org/show_bug.cgi?id=42002 See Comment 2 for a hack and a possible cause of the issue.
Comment 1 Ilia Mirkin 2016-12-17 00:21:25 UTC
Replays fine on Intel SKL GT2 (Mesa 13.0.2 with Intel DDX + DRI3). Probably an issue with st/mesa's logic somewhere.
Comment 3 Fabian Maurer 2016-12-17 14:57:50 UTC
I just tried LIBGL_ALWAYS_SOFTWARE=1, but still got a black-screen.
Comment 4 almos 2016-12-17 15:10:49 UTC
(In reply to Fabian Maurer from comment #3) > I just tried LIBGL_ALWAYS_SOFTWARE=1, but still got a black-screen. If your software driver is llvmpipe, and the bug is in mesa/st, then it will be black. For me radeonsi and llvmpipe render black, swrast renders the trace correctly.
Comment 5 Fabian Maurer 2016-12-17 15:23:32 UTC
Created attachment 128523 [details] Log for swrast (In reply to almos from comment #4) > For me radeonsi and llvmpipe render black, swrast renders the > trace correctly. Ah I see. Well, when I try to use swrast, it always crashes, so I can't test that. But it sounds logical.
Comment 6 Fabian Maurer 2017-01-15 23:34:47 UTC
Created attachment 128976 [details] Apitrace from the editor for a game called N-Ball Probably a second instance of this issue, this time with a program called N-Ball editor. Same issue, just a blackscreen with Mesa. Works fine on Windows. Attached the apitrace for the program. Tested with 13.0.3 on amdgpu (R9 285). If someone wants the download: http://www.ragdollsoft.com/nballeditor.zip Just run it with the newest wine (wine2.0rc4) Wine Bugreport: https://bugs.winehq.org/show_bug.cgi?id=40791 I really can't tell if it's the same issue, but it seems very likely.
Comment 7 Boyan Ding 2017-01-17 04:03:12 UTC
Created attachment 128992 [details] [review] mesa/st: Add both front and back buffer if the visual is double-buffered After tracking the command stream with the help of virgl and vtest, I found the problematic traces request for a double buffer visual but render to the front buffer. In this case, st will only add back buffer to the attachments of the window framebuffer. When rendering, the front buffer cannot be found and the frame is rendered with no color attachments. Meanwhile, i965 adds both front and back buffer in this case so it renders okay. The patch attached changes st's way to that of i965's and seems to fix the problem. If it is reasonable, I'll send it to the ML.
Comment 8 jr 2017-04-17 15:20:00 UTC
The patch fixes the problem on NVA5 for both games mentioned above and also similar symptoms in Septerra Core and Gothic (both also using wine). Whether the patch is correct I have no clue.
Comment 9 Boyan Ding 2017-04-17 15:40:39 UTC
(In reply to jr from comment #8) > The patch fixes the problem on NVA5 for both games mentioned above and also > similar symptoms in Septerra Core and Gothic (both also using wine). Whether > the patch is correct I have no clue. JFYI, https://patchwork.freedesktop.org/patch/134178/ is the most recent version, but somehow got stuck in review.
Comment 10 Erno K 2017-05-05 11:49:36 UTC
I tried to replay attachment in first post with mesa 17.0.5 (archlinux) and R9 285 and it shows only black unless I run it with "apitrace replay --sb wine.trace" which shows animation but in very fast speed.
Comment 11 jr 2017-05-20 23:19:24 UTC
(In reply to Boyan Ding from comment #9) > JFYI, https://patchwork.freedesktop.org/patch/134178/ is the most recent > version, but somehow got stuck in review. Thanks, testing that version I can confirm that it also fixes the problem with the N-Ball editor on my NVA5 system with current wine. But the original problem (black screen in Chuckie Egg) remains when run in wine. Which options do I need to see whether the patch is working with apitrace? 'replay -sb' plays both traces fine even in unpatched mesa git while 'replay -db' gives a black screen still with all patch versions.
Comment 12 Erno K 2017-05-21 17:23:10 UTC
Created attachment 131428 [details] nball replay output with patch applied I can confirm nball works after applying the patch. apitrace shows lots of errors on my system though. Radeon R9 285 Display Server: X.Org 1.19.3 driver: amdgpu Resolution: email@example.com, firstname.lastname@example.org GLX Renderer: Gallium 0.4 on AMD TONGA (DRM 3.15.0 / 4.12.0-rc1-g2ea659a9ef48, LLVM 5.0.0) GLX Version: 3.0 Mesa 17.2.0-devel (git-1586768e74)
Comment 13 Józef Kucia 2017-05-29 11:37:09 UTC
We've got a piglit test for this bug: https://cgit.freedesktop.org/piglit/commit/?id=eae8e3d1f2d33729fbad9a9433c1c91fd29dae2b
Comment 14 Erno K 2017-05-29 22:11:26 UTC
(In reply to Józef Kucia from comment #13) > We've got a piglit test for this bug: > https://cgit.freedesktop.org/piglit/commit/ > ?id=eae8e3d1f2d33729fbad9a9433c1c91fd29dae2b "out": "Probe color at (0,0)\n Expected: 0 255 0\n Observed: 0 0 0\n", "result": "fail",
Comment 15 Quentin Quaadgras 2017-06-21 14:09:11 UTC
I can confirm this bug affects me.
Comment 16 Timothy Arceri 2018-04-13 11:37:24 UTC
*** Bug 96543 has been marked as a duplicate of this bug. ***
Comment 17 Timothy Arceri 2018-04-24 02:27:02 UTC
Created attachment 139032 [details] [review] WIP fix I've attached and updated patch which is rebased on the merging of DrawBuffer/DrawBuffers. The outstanding issue is that this can cause some of the classic drivers (i915, radeon, r200) to get stuck in an infinite loop. The problem is these drivers call _mesa_update_framebuffer() from within the driver when Driver.DrawBuffer() is called.
Comment 18 Timothy Arceri 2018-04-24 04:56:19 UTC
Ok, new series sent: https://patchwork.freedesktop.org/series/42155/
Comment 19 Timothy Arceri 2018-04-24 23:14:22 UTC
Should be fixed by: commit 6695f9d5c5c94df080efc720ed532217618a28c3 Author: Boyan Ding <email@example.com> Date: Sat Apr 14 14:45:23 2018 +1000 mesa: call DrawBufferAllocate driver hook in update_framebuffer for windows-system FB When draw buffers are changed on a bound framebuffer, DrawBufferAllocate() hook should be called. However, it is missing in update_framebuffer with window-system framebuffer, in which FB's draw buffer state should match context state, potentially resulting in a change. Note: This is needed because gallium delays creating the front buffer, i965 works fine without this change. V2 (Timothy Arceri): - Rebased on merged/simplified DrawBuffer driver function - Move DrawBuffer call outside fb->ColorDrawBuffer != ctx->Color.DrawBuffer check to make piglit pass. v3 (Timothy Arceri): - Call new DrawBuffaerAllocate() driver function. Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> (v2) Reviewed-by: Brian Paul <firstname.lastname@example.org> (v2) Reviewed-by: Marek Olšák <email@example.com> Reviewed-by: Ian Romanick <firstname.lastname@example.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99116