https://bugs.freedesktop.org/show_bug.cgi?id=37171
Summary: half-life 2 with -dxlevel 90 crashes system Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: aaalmosss@gmail.com
After starting the game and watching the menu for ~10 secs the screen goes black, and even the magic sysreq doesn't work. Both wine and mesa prints tons of error messages to the console, but I couldn't yet capture it.
With -dxlevel 80 and 81 it doesn't crash, but runs with lots of rendering errors (lighting and water are messed up). I can't tell if it's wine's fault or mesa's.
I'm using wine 1.3.15 and mesa from git.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
Sven Arvidsson sa@whiz.se changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sa@whiz.se
--- Comment #1 from Sven Arvidsson sa@whiz.se 2011-05-13 04:25:59 PDT --- I have played through all of HL2 on my RV570, so it was at least working a couple of months ago.
Keep in mind that the game itself is broken with -dxlevel 80 or 81, but there are workarounds available: http://forums.steampowered.com/forums/showpost.php?p=15422575&postcount=...
IIRC with dxlevel 90 Wine caused the game to hit hardware limitations so it wasn't rendering correctly, but it didn't cause any crashes or hangs for me.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #2 from almos aaalmosss@gmail.com 2011-05-13 05:02:30 PDT --- Well, I first tried HL2, when Mesa 7.10 came out, and it was the same back then, and I see no change since. I just didn't want to open too much bugreports at once, and it is not easy to test, when the computer has to be restarted after each try.
I'm not surprised HL2 is broken in dx8 mode. I found on windows that it's broken in dx9 mode as well: it frequently turns HDR off, but that way it's fullbright on most levels and the sky is wrong, too. I haven't yet had the courage to install the unofficial workaround for that.
HL2 shouldn't hit any hardware limitation on an r500 series card, BTW.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #3 from Sven Arvidsson sa@whiz.se 2011-05-13 06:07:34 PDT --- (In reply to comment #2)
HL2 shouldn't hit any hardware limitation on an r500 series card, BTW.
Keep in mind that system requirements are different when Wine is used.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #4 from almos aaalmosss@gmail.com 2011-05-13 10:11:28 PDT --- (In reply to comment #3)
(In reply to comment #2)
HL2 shouldn't hit any hardware limitation on an r500 series card, BTW.
Keep in mind that system requirements are different when Wine is used.
I can run HL2 on my rv350 on windows with the highest settings, with HDR and everything turned on. On r500 series cards the shader size limits are several times larger, Wine overhead can't be that much. Even if HL2 has a separate, more complicated shader set for SM3 cards (Portal does), it shouldn't hit any hardware limitation IMHO.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #5 from Sven Arvidsson sa@whiz.se 2011-05-13 10:21:50 PDT --- (In reply to comment #4)
I can run HL2 on my rv350 on windows with the highest settings, with HDR and everything turned on. On r500 series cards the shader size limits are several times larger, Wine overhead can't be that much. Even if HL2 has a separate, more complicated shader set for SM3 cards (Portal does), it shouldn't hit any hardware limitation IMHO.
I don't really recall if this was the exact problem with HL2 or not, but Wine does raise the limit quite a bit and Mesa doesn't seem to handle this as well as some other drivers, see bug 29137.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #6 from almos aaalmosss@gmail.com 2011-05-22 10:14:48 PDT --- Created an attachment (id=47008) --> (https://bugs.freedesktop.org/attachment.cgi?id=47008) steamhl2.log.gz
I now captured the console output of steam and hl2. It seems to me that some shaders don't compile, but wine repeatedly tries to use them, and after a while the video driver gives up.
Since the initial report I upgraded wine to 1.3.20 and updated mesa git as well.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #7 from Marek Olšák maraeo@gmail.com 2011-06-07 16:16:37 PDT --- The messages like this:
fixme:d3d:debug_d3dformat Unrecognized 0x36314644 (as fourcc: DF16) WINED3DFORMAT! fixme:d3d:wined3d_get_format Can't find format unrecognized (0x36314644) in the format lookup table
should be fixed in Wine. I can help if needed. All the FOURCC codes can be implemented. ATI's formats are described here: http://developer.amd.com/gpu_assets/Advanced%20DX9%20Capabilities%20for%20AT...
Next. Compiler failures. You hit quite a lot of hardware limitations. The one that's really weird is "Couldn't flatten if statement". I don't see any "if" statements in the dumped shaders. I will send a patch to silence that.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #8 from Marek Olšák maraeo@gmail.com 2011-06-07 16:20:33 PDT --- Created an attachment (id=47694) View: https://bugs.freedesktop.org/attachment.cgi?id=47694 Review: https://bugs.freedesktop.org/review?bug=37171&attachment=47694
patch
Could you post the log again with the patch applied? Also, does it fix anything?
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #9 from almos aaalmosss@gmail.com 2011-06-08 13:36:35 PDT --- Created an attachment (id=47733) --> (https://bugs.freedesktop.org/attachment.cgi?id=47733) new_console.txt.gz
(In reply to comment #8)
Created an attachment (id=47694)
View: https://bugs.freedesktop.org/attachment.cgi?id=47694 Review: https://bugs.freedesktop.org/review?bug=37171&attachment=47694
patch
Could you post the log again with the patch applied? Also, does it fix anything?
New log attached. The patch doesn't seem to fix anything.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #10 from Marek Olšák maraeo@gmail.com 2011-06-08 16:13:30 PDT --- The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 error messages seem to be unfixable hardware limitations.
Is there a way to disable the shader model 3.0 in Wine/DX9? The shader model 2.0, which the hardware was designed for, doesn't have loops, and HL2 must support that (otherwise it wouldn't work on Windows either).
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #11 from Sérgio M. Basto sergio@serjux.com 2011-06-08 22:53:22 PDT --- hl2 ep2 crashes a lot with nvidia and ati even in windows , what episode are you trying to run ? and the fixes also for what HL2 is ?
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #12 from almos aaalmosss@gmail.com 2011-06-09 02:31:46 PDT --- (In reply to comment #10)
The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 error messages seem to be unfixable hardware limitations.
OK, but why does it hardlock the kernel?
As I understand section 7.5.5 of Radeon R5xx Acceleration (page 77), r3xx and r4xx do support loops. I'm confused.
Is there a way to disable the shader model 3.0 in Wine/DX9? The shader model 2.0, which the hardware was designed for, doesn't have loops, and HL2 must support that (otherwise it wouldn't work on Windows either).
I don't think wine advertises SM3.0, as s.t.a.l.k.e.r. shadow of Chernobyl doesn't let me choose dynamic lighting, which is expected (BTW it's almost platinum quality with wine 1.3.20 and mesa 7.11-dev, great work :)
Isn't there a d3dwinfo tool that does the same as glxinfo?
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #13 from Marek Olšák maraeo@gmail.com 2011-06-09 03:38:24 PDT --- (In reply to comment #12)
(In reply to comment #10)
The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 error messages seem to be unfixable hardware limitations.
OK, but why does it hardlock the kernel?
No idea.
As I understand section 7.5.5 of Radeon R5xx Acceleration (page 77), r3xx and r4xx do support loops. I'm confused.
There are some loops in vertex shaders, but they're so oversimplified that implementing GLSL loops with that is impossible and we haven't been able to make it work even for simple cases anyway.
Please attach a new log with RADEON_DEBUG=vp
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #14 from Henri Verbeet hverbeet@gmail.com 2011-06-09 03:57:31 PDT --- (In reply to comment #10)
Is there a way to disable the shader model 3.0 in Wine/DX9?
Not at the moment, but I'm considering adding a registry key to limit the maximum exposed shader model.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #15 from Sven Arvidsson sa@whiz.se 2011-06-09 04:02:32 PDT --- Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it?
So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod" would cause it to fall back to 2.0?
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #16 from Henri Verbeet hverbeet@gmail.com 2011-06-09 04:27:59 PDT --- (In reply to comment #15)
Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it?
So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod" would cause it to fall back to 2.0?
We enabled SM3 if ARB_shader_texture_lod is present, but it's not currently a requirement for SM3. I'm seriously considering changing that, but currently disabling ARB_shader_texture_lod doesn't necessarily disable SM3.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #17 from Henri Verbeet hverbeet@gmail.com 2011-06-09 04:30:29 PDT --- I.e., you'd need to apply http://bugs2.winehq.org/attachment.cgi?id=35068 to Wine first for that to work.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #18 from almos aaalmosss@gmail.com 2011-08-03 05:37:15 PDT --- Now I tried this again with linux 3.0, mesa 7.12-dev and wine 1.3.20.
HL2 started with the 'city17 under siege' menu background, and it didn't crash (I waited for ~1 minute). I started a new game at 'red letter day', and it didn't crash (I waited for ~3 minutes, looking around in the Kleiner's lab). In both cases only the static wall geometry was shown, because basically none of the vertex shaders compiled successfully.
Then I started a new game at 'route canal', and it hardlocked after the first frame shown. In this frame the weapon seemed correct, but the water was completely black. This frame was on the screen for ~5 seconds, then complete blackness.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #19 from almos aaalmosss@gmail.com 2011-10-16 05:19:23 PDT --- Bad news, everyone!
I tried this again with kernel 3.0.1, mesa 7.12-dev 1350882e4950bc957e60e68a685b8fea08693e13, wine 1.3.30, and now half-life 2 crashes even with '-dxlevel 81'.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #20 from Stefan Dösinger stefandoesinger@gmx.at 2012-03-16 09:41:21 PDT --- Note that Shader Model 2 in d3d kinda supports loops and conditions on hardware that shouldn't be able to handle them. The caveat of this support is that they do not support dynamic branching. The loop counter is a uniform and cannot be changed at shader runtime, and there are no break statements or other ways to abort the loop before the iteration counter is reached. If statements only support uniforms as conditions as well.
Wine translates those constructs into GLSL for loops and if statements that only read uniforms, the compiler should be able to unroll them. With ARB shaders we unroll them ourselves and generate one GL shader for each control uniform combination that is used by the application.
https://bugs.freedesktop.org/show_bug.cgi?id=37171
Tomasz P. son_of_the_osiris@interia.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #21 from almos aaalmosss@gmail.com --- Why was this set to resolved without any comment, and why as 'notourbug'?? Unfortunately I cannot test this on an rv350 anymore.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org