Replays fine on Intel SKL GT2 (Mesa 13.0.2 with Intel DDX + DRI3). Probably an issue with st/mesa's logic somewhere.

Probably related to bug 94168

I just tried LIBGL_ALWAYS_SOFTWARE=1, but still got a black-screen.

(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.

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.

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.

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.

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.

(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.

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.

(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.

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: 1920x1080@60.00hz, 1920x1080@60.00hz
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)

We've got a piglit test for this bug: https://cgit.freedesktop.org/piglit/commit/?id=eae8e3d1f2d33729fbad9a9433c1c91fd29dae2b

(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",

I can confirm this bug affects me.

*** Bug 96543 has been marked as a duplicate of this bug. ***

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.

Ok, new series sent:

https://patchwork.freedesktop.org/series/42155/

Should be fixed by:

commit 6695f9d5c5c94df080efc720ed532217618a28c3
Author: Boyan Ding <boyan.j.ding@gmail.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[0] !=
       ctx->Color.DrawBuffer[0] 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 <brianp@vmware.com> (v2)
    Reviewed-by: Marek Olšák <marek.olsak@amd.com>
    Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99116