Bug 109162 - Bugs Bunny: Lost in Time
Summary: Bugs Bunny: Lost in Time
Status: RESOLVED WORKSFORME
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: 18.2
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-27 16:19 UTC by smoki
Modified: 2019-01-20 17:54 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
mess on the screen (615.11 KB, image/png)
2018-12-27 16:22 UTC, smoki
Details

Description smoki 2018-12-27 16:19:07 UTC
Current Debian Buster/Testing, Mesa 18.2.7, Kabini hardware...

 I am trying to run this near 20 years old Windows OpenGL game via WINE of course...

 wine bugs.exe /b00 /full /skip_intro /ogl /x1920 /y1080

 But it shows half garbage as seens in picture, same is in window or whatever.

 LIBGL_ALWAYS_SOFTWARE=true shows same garbage.

 Trace actually render correctly (there are shadow bugs you could maybe ignore, that is on Windows the same), so i am out of idea what this could be.
Comment 1 smoki 2018-12-27 16:22:57 UTC
Created attachment 142904 [details]
mess on the screen


 This is how it looks like. Broken presentation image i would say, as trace shows it OK.
Comment 2 smoki 2018-12-27 16:44:08 UTC
 Link to the trace:

 https://www.dropbox.com/s/tk2i1j6ownzh4px/bugs-trace.7z

 Anyway, this replays fine here too. It is just when i run a game actually this mess came by.

 I tried to run game on a CPU by using software Mesa for Windows from here:

 http://fdossena.com/?p=mesa/index.frag

 With same version of software Mesa for Windows it also plays correctly.

 So no idea what this could be really :D
Comment 3 smoki 2018-12-27 16:46:48 UTC
 So, software Mesa for Windows shows it correctly, while same version of software Mesa for Linux via LIBGL_ALWAYS_SOFTWARE=true show this garbage ;)
Comment 4 smoki 2018-12-27 16:53:24 UTC
 I tried various MESA version overrides and R600_DEBUG variables like no2d, notiling and such to no avail, even tried to disable DRI3 with LIBGL_DRI3_DISABLE and nope - mess is still there.
Comment 5 smoki 2018-12-27 16:56:34 UTC
 And BTW forgot to mention... on AMD proprietary OpenGL driver this is fine.
Comment 6 smoki 2018-12-27 17:18:15 UTC
 Ah OK, that Mesa for Windows uses LLVM 6, while Debian Mesa uses LLVM 7... so could be an LLVM regression.
Comment 7 smoki 2018-12-27 17:21:36 UTC
 But replaying of trace show it fine, so it isn't LLVM :D
Comment 8 smoki 2018-12-28 19:15:46 UTC
 Got this old OpenGL game accelerated, by using gldirect:

 http://sourceforge.net/projects/gldirect/

 That seems supports OpenGL 1.x to D3D9 just fine :) And then asking d3dadapter nine to play opengl game and everything looks fine this way.

 Well, this bug is still there since this is OpenGL game and should play on OpenGL driver fine.
Comment 9 smoki 2018-12-29 13:06:41 UTC
 OK, found an variable that helped :)

 always_have_depth_buffer=true wine bugs.exe

 makes it showing up on screen normally.
Comment 10 Harry Wilson 2018-12-31 17:51:00 UTC
i am also getting same bug
https://pathankottaxi.hatenablog.com/
https://pathankottaxi.in/pathankot-taxi-service/
Comment 11 Roland Scheidegger 2019-01-01 22:52:59 UTC
These kind of bugs is usually due to app error (not requesting a depth buffer but still needing one, relying on the implementation to provide one anyway).
Although in this case, I suppose wine could be involved too, maybe there's some pecularities when emulating wgl with glx.
Seems unlikely to me though that the bug is in mesa code.
Comment 12 smoki 2019-01-20 17:54:35 UTC
 OK, self variabled only in Mesa... closing then as worksforme.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.