Summary: | Metro Last Light quits(?) on r600g | ||
---|---|---|---|
Product: | Mesa | Reporter: | Krzysztof A. Sobiecki <sobkas> |
Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | beko, eero.t.tamminen, grantipak, j.suarez.agapito, mike, sa, v10lator |
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
strings of MetroLL
It's cloning itself? Config file Patch for ignoring macros starting with __ |
Description
Krzysztof A. Sobiecki
2013-11-05 02:00:49 UTC
Are there any error logs from the application itself ? Created attachment 88659 [details]
strings of MetroLL
(In reply to comment #1) > Are there any error logs from the application itself ? Not even a single pip. Heard it might be a OpenGL 4 game. Will look at it closer tomorrow. Created attachment 88660 [details]
It's cloning itself?
I can confirm setting MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150 gets the game to start for me I'm guessing this game needs either the GLSL 1.50 version or Geometry shaders can anyone with Ivybridge or Haswell confirm that the game runs correctly with Mesa 10 / master. I'm stuck with i965 on Sandybridge and r600g (In reply to comment #5) > I can confirm setting MESA_GL_VERSION_OVERRIDE=3.2 > MESA_GLSL_VERSION_OVERRIDE=150 gets the game to start for me > > I'm guessing this game needs either the GLSL 1.50 version or Geometry > shaders can anyone with Ivybridge or Haswell confirm that the game runs > correctly with Mesa 10 / master. I'm stuck with i965 on Sandybridge and r600g With your override I was able to start new game and to walk around D6 for a bit. Will post my config file. Created attachment 88675 [details]
Config file
(In reply to comment #5) > I can confirm setting MESA_GL_VERSION_OVERRIDE=3.2 > MESA_GLSL_VERSION_OVERRIDE=150 gets the game to start for me > When I force only MESA_GLSL_VERSION_OVERRIDE=150 it also works, but I automatically switch to OpenGL 3.2. (In reply to comment #8) > (In reply to comment #5) > > I can confirm setting MESA_GL_VERSION_OVERRIDE=3.2 > > MESA_GLSL_VERSION_OVERRIDE=150 gets the game to start for me > > > When I force only MESA_GLSL_VERSION_OVERRIDE=150 it also works, but I automatically switch to OpenGL 3.2. => but it automatically switches to OpenGL 3.2. I am on radeonsi and thus I know this bug report could not apply to my system. Forcing the mesa overrides allows me to launch the game. Everything seems to work fine except that in the main menu the menu text is not shown (I get the hud style text that is located in the lower part of the screen and says, for example, "press Esc to exit" and the like, but not the text that should show in the center of the screen, over the ochre coloured background image). I guess that the "New game", "Chapters" and "Options" -I am aware that at the moment it seems the Options submenu in Linux still does not have as many items as the Windows version- submenus should look more or less like this: http://www.notebookcheck.net/fileadmin/Notebooks/Sonstiges/Games/Metro_Last_Light/game2.jpg but I am not getting that text in the menus. This has, so far, prevented me from being able to start a game. I just wanted to ask if the users of r600g can see the menu text and thus determine if this is a separate radeonsi / llvm backend problem so that I can open a new bug report if needed. Yes the same happens for me on i965 (Sandybridge) and r600g (6600M) (In reply to comment #10) > I just wanted to ask if the users of r600g can see the menu text and thus > determine if this is a separate radeonsi / llvm backend problem so that I > can open a new bug report if needed. I'm also unable to see the text in menus Well, I have finally been able to start a new game (you basically have to select "New game" in the menu and then press enter (I can't remember if only once or several times); that seems to accept whatever start new game option the menu text might say). The game runs quite smooth (good job there from the mesa devs) but there are a few rendering bugs, though: (i) The scenes appear too bright while they should be almost completely dark in places. This is specially easy to see and obvious when, after the D6 level ends, you get into the Metro and you are travelling by train through the tube tunnel and subsequently arrive at a station when you are told that it is very dark and you should light your flashlight :D . I guess this is probably related to the fact that mesa's GLSL does not meet the minimum. (ii) When the lighter is lit, it does not show fire or light the scene rendered. (iii) There are graphical glitches sometimes (usually when you are close to openings in walls such as in the shooting range or the elevator in D6). The glitch I experienced is like some part of the screen is totally or partially covered by a black texture. There are probably other bugs which I might have not noticed yet. In any case I was quite impressed by the fact that the game run quite smoothly (Radeon HD 7870 with radeonsi and llvm builds from git as of 5 November). @Developers: Should we wait until mesa effectively hits 3.2, keep posting in this bug report or open new bugs for the incorrect renderings we may find? I've been testing this with Mesa master (2cfbf84) on IVB ultrabook. There's quite a lot of rendering artifacts here and there, my findings so far: 1. all lighting and shadows are missing making the game look terrible 2. a flash of 'outside world' visible in the metro tunnel when game menu comes up 3. text/graphics missing from game menus 4. sudden graphics glitches, looks like parts of low resolution fbo rendered on top of scene now and then when moving the camera 5. flashes of objects rendered with solid red color (just when they become visible for the first time?) Following errors seen on console: Mesa: User error: GL_INVALID_ENUM in glTexParameter(pname=GL_TEXTURE_LOD_BIAS) will continue investigation on what's wrong FYI, I've filed bug #71870 to track Metro issues on Intel. I made a apitrace ( https://github.com/apitrace/apitrace ) : https://www.dropbox.com/s/rn1izcn3htqx18h/metroLastLight.trace This trace has been done by moving MetroLL to MetroLL.orig and then making a script called MetroLL with this content: #!/bin/bash export MESA_GL_VERSION_OVERRIDE=3.2 export MESA_GLSL_VERSION_OVERRIDE=150 export TRACE_FILE=/home/v10lator/metroLastLight.trace LD_PRELOAD=/home/v10lator/git/apitrace/build32/wrappers/glxtrace.so ./MetroLL.orig $@ after that I started the game, let it run till it showed the menu and exited. I made an api trace as well. Perhaps it's helpful. The game works just fine for me: OpenGL renderer string: GeForce GTX 470/PCIe/SSE2 OpenGL version string: 4.2.0 NVIDIA 304.88 http://beko.maxr.org/MetroLL.trace.tar.gz (674M) http://beko.maxr.org/MetroLL.trace.tar.gz.sha1 I started the game, changed the "gfx settings slider" to MAX and loaded a savegame. After that I quit the game. Could be connected with https://bugs.freedesktop.org/show_bug.cgi?id=74717 ? Both uses GL3.2 features. (In reply to comment #18) > Could be connected with https://bugs.freedesktop.org/show_bug.cgi?id=74717 ? > Both uses GL3.2 features. Nope, at least when running on Intel Metro does not use geometry shaders at all. Not sure though if it does some selection on this based on platform or drivers. I can confirm fixed rendering on r600g with this: https://bugs.freedesktop.org/show_bug.cgi?id=71870#c25 Same as comment 20 but with radeonsi (HD 7870). In fact the game runs beautifully now (and really smooth). (In reply to comment #20) > I can confirm fixed rendering on r600g with this: > https://bugs.freedesktop.org/show_bug.cgi?id=71870#c25 It fixed the problem, will make a patch for it. I'm not sure why but the glsl workaround makes my X server crash everytime it starts (dies before it starts properly). I had not noticed until now when I restarted the PC because the test I reported in comment 21 did not involve restarting the X server (I just updated the mesa packages and launched the game without restarting the X server). In the backtrace log I see the radeon driver and the glamor libraries as the source of the problem: [ 1757.414] (EE) [ 1757.414] (EE) Backtrace: [ 1757.414] (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x7f8870012fdd] [ 1757.414] (EE) 1: /usr/bin/X (0x7f886fe70000+0x1a6d49) [0x7f8870016d49] [ 1757.414] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f886ef50000+0xfbb0) [0x7f886ef5fbb0] [ 1757.414] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f40000+0x1865b3) [0x7f88690c65b3] [ 1757.414] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f40000+0x186739) [0x7f88690c6739] [ 1757.414] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f40000+0x1db03f) [0x7f886911b03f] [ 1757.414] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f40000+0x1db15b) [0x7f886911b15b] [ 1757.414] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f40000+0x22c868) [0x7f886916c868] [ 1757.414] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f40000+0x1f53d0) [0x7f88691353d0] [ 1757.414] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f40000+0xdd61a) [0x7f886901d61a] [ 1757.414] (EE) 10: /usr/lib/x86_64-linux-gnu/libglamor.so.0 (0x7f886bf68000+0x708b) [0x7f886bf6f08b] [ 1757.414] (EE) 11: /usr/lib/x86_64-linux-gnu/libglamor.so.0 (0x7f886bf68000+0x8225) [0x7f886bf70225] [ 1757.414] (EE) 12: /usr/lib/x86_64-linux-gnu/libglamor.so.0 (glamor_init+0x32d) [0x7f886bf6bddd] [ 1757.414] (EE) 13: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f8869a38000+0x4c0be) [0x7f8869a840be] [ 1757.414] (EE) 14: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f8869a38000+0xc078) [0x7f8869a44078] [ 1757.414] (EE) 15: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f8869a38000+0x465ea) [0x7f8869a7e5ea] [ 1757.414] (EE) 16: /usr/bin/X (AddScreen+0x71) [0x7f886fec54d1] [ 1757.414] (EE) 17: /usr/bin/X (InitOutput+0x3f8) [0x7f886ff05d88] [ 1757.414] (EE) 18: /usr/bin/X (0x7f886fe70000+0x445cb) [0x7f886feb45cb] [ 1757.414] (EE) 19: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7f886db71de5] [ 1757.414] (EE) 20: /usr/bin/X (0x7f886fe70000+0x44aff) [0x7f886feb4aff] [ 1757.414] (EE) [ 1757.414] (EE) Segmentation fault at address 0x0 [ 1757.414] (EE) Fatal server error: [ 1757.414] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 1757.415] (EE) [ 1757.415] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 1757.415] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 1757.415] (EE) [ 1757.419] (EE) Server terminated with error (1). Closing log file. Xorg is 1.14.5-1ubuntu2~saucy1 (i.e. updated, unmodified Ubuntu saucy packages). I am using KDE's Kwin as the compositor (4.11.5-0ubuntu0.1). A build of the same mesa source without the workaround allows the X server to start properly. Since noone reporting here seems to be using radeonsi and/or glamor (and noone has reported any problem yet), I suppose this could be related to glamor, upon which the radeonsi is dependant for 2D. Is this affecting anyone else? Created attachment 94159 [details] [review] Patch for ignoring macros starting with __ The c file is generated by the src/glsl/glcpp/glcpp-parse.y file - this patch might make things easier for those building from scratch - you might need to make sure the c file is regenerated I had removed too much code (see https://bugs.freedesktop.org/show_bug.cgi?id=71870#c32). Now its working properly. *** This bug has been marked as a duplicate of bug 71870 *** |
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.