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.
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=11 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.
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.
(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.
(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.
(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.
Created attachment 47008 [details] 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.
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%20ATI%20Radeon%20Cards_v2.pdf 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.
Created attachment 47694 [details] [review] patch Could you post the log again with the patch applied? Also, does it fix anything?
Created attachment 47733 [details] new_console.txt.gz (In reply to comment #8) > Created an attachment (id=47694) [details] > 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.
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).
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 ?
(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?
(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
(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.
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?
(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.
I.e., you'd need to apply http://bugs2.winehq.org/attachment.cgi?id=35068 to Wine first for that to work.
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.
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'.
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.
Why was this set to resolved without any comment, and why as 'notourbug'?? Unfortunately I cannot test this on an rv350 anymore.
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.