Nouveau - Jul 2015 - [Bug 91171] New: Space Rangers 2 (in Wine) shows only black screen

https://bugs.freedesktop.org/show_bug.cgi?id=91171

            Bug ID: 91171
           Summary: Space Rangers 2 (in Wine) shows only black screen
           Product: Mesa
           Version: git
          Hardware: Other
               URL: http://www.fileplanet.com/162972/160000/fileinfo/Space
                    -Rangers-2:-Rise-of-the-Dominators-Demo
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: gyebro69 at gmail.com
        QA Contact: nouveau at lists.freedesktop.org

The game starts and runs fine except that the screen remains black during the
intro videos and in the menu, only audio can be heard.
This is with the default OpenGL renderer in Wine. When using the legacy GDI
renderer the game displays properly. 
>From the http://wiki.winehq.org/UsefulRegistryKeys page:
"The "gdi" option mostly exists for legacy reasons. Aside from
bugs in the GL
renderer, only change this if you have a setup without OpenGL. Installing a
software GL implementation is the preferred solution in that case though."

The problem doesn't occur with the binary drivers.
When using the software renderer (LIBGL_ALWAYS_SOFTWARE=1) 2 out of the 4 intro
videos and the menu is displayed properly.

Trace:
https://drive.google.com/open?id=0B-tTbLKBl-tOOGEwLXMtdmt2T1U
The trace consists of only a single frame which contains >100k calls.

Fedora 22 32-bit
VGA compatible controller: NVIDIA Corporation G92 [GeForce GTS 250] (rev a2)
(prog-if 00 [VGA controller])
Mesa 10.6-branchpoint-773-g1de93f9
Kernel 4.0.6-300.fc22.i686+PAE
Xorg 1.17.2
libdrm-2.4.61-3.fc22.i686

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150701/3d59de6c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91171

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150702/4353ce33/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91171

--- Comment #2 from Béla Gyebrószki <gyebro69 at gmail.com> ---
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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150704/14496e60/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91171

Henri Verbeet <hverbeet at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hverbeet at gmail.com

--- Comment #3 from Henri Verbeet <hverbeet at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150704/a2c00c68/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91171

--- Comment #4 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150704/da26d9f8/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91171

--- Comment #5 from Henri Verbeet <hverbeet at gmail.com> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150704/0e42ecce/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91171

--- Comment #6 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Some frontbuffer-related fixes went into mesa 11.0.3. Can you check if the
issue persists?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151022/57776f2e/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91171

Béla Gyebrószki <gyebro69 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gyebro69 at gmail.com

--- Comment #7 from Béla Gyebrószki <gyebro69 at gmail.com> ---
(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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151023/aa595a0b/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91171

GitLab Migration User <gitlab-migration at fdo.invalid> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |MOVED

--- Comment #8 from GitLab Migration User <gitlab-migration at
fdo.invalid> ---
-- 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20190918/be990f0d/attachment.html>