Replays fine with glretrace --sb (at least I think it does). If there's only a single giant frame, that sounds like the definition of single buffering...

Tested on both nvc0 (GF108) and nv50 (GT215).

In case it is a problem in Wine I reported the bug in their bugtracker as well:
https://bugs.winehq.org/show_bug.cgi?id=38863

Single buffering is pretty much expected for ddraw applications. You should be seeing framebuffer blits followed by a glFlush() instead of a glXSwapBuffers() call. I can't rule out that this is a bug in Wine, although the fact that it works with the proprietary driver and mostly works with software rendering seems to suggest it probably isn't.

One thing that's a bit nasty about ddraw applications in general is that they often end up with multiple (independent) GL contexts, not sure if that's the case here or not.

Ah yeah, nouveau fails pretty substantially at multiple concurrent GL contexts used simultaneously from different threads (this is a nouveau shortcoming, not a mesa one). Multiple contexts that are switched around with glXMakeCurrent from a single thread should operate fine though.

Indeed looking at the trace, I see

79407 glBindFramebuffer(target = GL_DRAW_FRAMEBUFFER, framebuffer = 0)
79409 glReadBuffer(mode = GL_COLOR_ATTACHMENT0)
79412 glDrawBuffer(mode = GL_FRONT)
79417 glBlitFramebuffer(srcX0 = 0, srcY0 = 0, srcX1 = 1024, srcY1 = 768, dstX0 = 0, dstY0 = 768, dstX1 = 1024, dstY1 = 0, mask = 
GL_COLOR_BUFFER_BIT, filter = GL_NEAREST)
79419 glFlush()

followed immediately by creating a (actually two!) new contexts, and discarding the old stuff. [Looks like it does both glXCreateContext *and* glXCreateContextAttribsARB, and discards the first one of those.]

I was looking over what flush did, and it does indeed explicitly flush the frontbuffer to screen if it's the current drawbuffer. [or something along those lines]. Tracing through that flow, it's entirely over my head... interactions between multiple modules of which I know nothing. I don't see anywhere where it'd be waiting for that blit to complete either, but that doesn't mean it's not there. Perhaps this should be a glFinish()?

I'm afraid this will have to wait for someone to understand what the issue is before it can be fixed.

(In reply to Ilia Mirkin from comment #4)
> discarding the old stuff. [Looks like it does both glXCreateContext *and*
> glXCreateContextAttribsARB, and discards the first one of those.]
> 
Yeah... we first need a context to be able to call wglGetProcAddress(), to get the wglCreateContextAttribsARB() pointer.

> I was looking over what flush did, and it does indeed explicitly flush the
> frontbuffer to screen if it's the current drawbuffer. [or something along
> those lines]. Tracing through that flow, it's entirely over my head...
> interactions between multiple modules of which I know nothing. I don't see
> anywhere where it'd be waiting for that blit to complete either, but that
> doesn't mean it's not there. Perhaps this should be a glFinish()?
> 
We don't wait for it to finish, but we shouldn't have to.

Some frontbuffer-related fixes went into mesa 11.0.3. Can you check if the issue persists?

(In reply to Ilia Mirkin from comment #6)
> Some frontbuffer-related fixes went into mesa 11.0.3. Can you check if the
> issue persists?

The black screen issue is still present, tested with mesa git and wine 1.7.53..

OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV92
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.0-devel (git-3994ef5)
OpenGL core profile shading language version string: 3.30

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1076.