Bug 93178

Created attachment 120219 [details]
The expected image to be rendered for frame 1 in the attached apitrace

Replaying the trace on radeonsi generates lots of GL API errors:

Mesa: User error: GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
Mesa: User error: GL_INVALID_FRAMEBUFFER_OPERATION in glDrawArrays(incomplete framebuffer)
Mesa: 1 similar GL_INVALID_FRAMEBUFFER_OPERATION errors
(repeated several times)

Mesa: User error: GL_INVALID_ENUM in glRenderbufferStorage(internalFormat=GL_SLUMINANCE8)
Mesa: User error: GL_INVALID_ENUM in glRenderbufferStorage(internalFormat=GL_SLUMINANCE8_ALPHA8)

(the first three lines repeated several times again)

I think those errors could explain the incorrect rendering. Which driver was the apitrace captured with? Does the same problem occur when running the application with radeonsi directly?

(In reply to Michel Dänzer from comment #2)
> Replaying the trace on radeonsi generates lots of GL API errors:
>
> I think those errors could explain the incorrect rendering. Which driver was
> the apitrace captured with? Does the same problem occur when running the
> application with radeonsi directly?

The GL errors should not be related. Those are generated by format support detection code.

This particular apitrace was captured with nouveau. The application generates different GL errors in this part of code when run with radeonsi. However, it exhibits exactly the same problem when run directly. I'll upload another apitrace later.

https://drive.google.com/file/d/0Bz0HXJUyjAh3ZkFEOHdNVnAyWWM/view

This apitrace was captured with radeonsi. It is not trimmed. The problem appears at 935th frame. The previous frames are rendered correctly.

This is a game bug.

The game tries to be clever by uploading some of its textures from a different OpenGL context, but never uses any kind of synchronization between the texture upload and the main context, so the texture upload never actually happens. This is a serious programming mistake, and it is merely by chance that this works on other drivers.

For your own purposes, you can work around the game bug in the driver by applying the following patch:

---- SNIP ----
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -105,6 +105,7 @@ static void r600_copy_from_staging_texture(struct pipe_context *ctx, struct r600
        rctx->dma_copy(ctx, dst, transfer->level,
                       transfer->box.x, transfer->box.y, transfer->box.z,
                       src, 0, &sbox);
+       rctx->b.flush(&rctx->b, NULL, 0);
 }
 
 static unsigned r600_texture_get_offset(struct r600_texture *rtex, unsigned level,
---- SNIP ----

However, doing this seriously hurts the performance of games that are programmed properly. I encourage you to forward this message to the developers, telling them they should take a look at Section 5.3.1 of the OpenGL 4.5 (Compatibility Profile) specification, specifically the part about using Finish or FenceSync/WaitSync.

(In reply to Nicolai Hähnle from comment #5)
> This is a game bug.
 
Thanks for debugging this. I am sorry for reporting invalid bug. This is actually a bug in Wine. For now the workaround is to enable StrictDrawOrdering. I will do more investigation before reporting a bug next time.