Bug 29363 - [r300g] Starcraft 2: "r300 VP: Compiler error"
Summary: [r300g] Starcraft 2: "r300 VP: Compiler error"
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-02 09:14 UTC by Pavel Ondračka
Modified: 2011-03-05 04:19 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
terminal output (304.82 KB, text/plain)
2010-08-02 09:14 UTC, Pavel Ondračka
Details
screenshot (174.11 KB, image/png)
2010-08-02 09:15 UTC, Pavel Ondračka
Details
output with RADEON_DEBUG=vp (506.74 KB, application/x-7z-compressed)
2010-08-02 09:50 UTC, Pavel Ondračka
Details
Implement vertex shader loops (16.61 KB, patch)
2010-08-05 21:43 UTC, Tom Stellard
Details | Splinter Review
Implement vertex shader loops v2 (17.74 KB, patch)
2010-08-05 22:22 UTC, Tom Stellard
Details | Splinter Review
Implement vertex shader loops v3 (17.67 KB, patch)
2010-08-06 11:18 UTC, Tom Stellard
Details | Splinter Review
output with patch, RADEON_DEBUG=vp (337.90 KB, application/x-bzip2)
2010-08-06 12:24 UTC, Pavel Ondračka
Details
screenshot (392.64 KB, image/png)
2010-08-06 12:25 UTC, Pavel Ondračka
Details
Implement vertex shader loops and branches (24.80 KB, patch)
2010-08-09 22:35 UTC, Tom Stellard
Details | Splinter Review
output with RADEON_DEBUG=vp, with vs-if-loop.patch (263.65 KB, application/x-bzip2)
2010-08-10 01:16 UTC, Pavel Ondračka
Details
screenshot with vs-if-loop.patch (501.18 KB, image/png)
2010-08-10 01:17 UTC, Pavel Ondračka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Ondračka 2010-08-02 09:14:21 UTC
Created attachment 37527 [details]
terminal output

When running with Wine 1.3.0 patched with slightly modified hack from bug 29137, I'm now able to start Starcraft 2, menus are working OK, however in game almost everything is black.
mesa: afa925066c158ac49e3b0f883f67debd8545bf26
GPU: RV530
kernel: 2.6.35

Some chosen terminal output, full log attached:

r300 VP: Compiler error:
Vertex program has too many instructions
Using a dummy shader instead.
If there's an 'unknown opcode' message, please file a bug report and attach this log.

fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #27:
fixme:d3d_shader:print_glsl_info_log     Note: 'for (tmpInt0 ... )' body is too large/complex to unroll

I'm not sure if this is only r300g bug, because some users with intel graphic cards reported similar issues at Wine bugzilla, http://bugs.winehq.org/show_bug.cgi?id=22971. 

BTW disabling use of GLSL in Wine allows the terrain to be displayed more or less properly, however units and buildings are still invisible
Comment 1 Pavel Ondračka 2010-08-02 09:15:13 UTC
Created attachment 37528 [details]
screenshot
Comment 2 Tom Stellard 2010-08-02 09:22:37 UTC
Can you run the program again with the environment variable RADEON_DEBUG=vp and post the output.
Comment 3 Pavel Ondračka 2010-08-02 09:50:35 UTC
Created attachment 37530 [details]
output with RADEON_DEBUG=vp
Comment 4 Tom Stellard 2010-08-05 21:43:17 UTC
Created attachment 37618 [details] [review]
Implement vertex shader loops

Can you test again with this patch and post the output of RADEON_DEBUG=vp.  A screenshot would also be helpful.
Comment 5 Tom Stellard 2010-08-05 22:10:43 UTC
Comment on attachment 37618 [details] [review]
Implement vertex shader loops

This patch has a mistake, another one is one the way.
Comment 6 Tom Stellard 2010-08-05 22:22:27 UTC
Created attachment 37619 [details] [review]
Implement vertex shader loops v2

This patch should be better.
Comment 7 Pavel Ondračka 2010-08-06 08:03:55 UTC
(In reply to comment #6)
> Created an attachment (id=37619) [details]
> Implement vertex shader loops v2
> 
> This patch should be better.

Sorry, I have some troubles when applying this to mesa master:

patching file src/gallium/drivers/r300/r300_emit.c
patching file src/gallium/drivers/r300/r300_reg.h
patching file src/gallium/drivers/r300/r300_state.c
patching file src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c
patching file src/mesa/drivers/dri/r300/compiler/r3xx_vertprog.c
patching file src/mesa/drivers/dri/r300/compiler/r3xx_vertprog_dump.c
patching file src/mesa/drivers/dri/r300/compiler/radeon_code.h
patching file src/mesa/drivers/dri/r300/compiler/radeon_emulate_loops.c
Hunk #1 FAILED at 423.
Hunk #2 FAILED at 435.
Hunk #3 FAILED at 472.
3 out of 3 hunks FAILED -- saving rejects to file src/mesa/drivers/dri/r300/compiler/radeon_emulate_loops.c.rej
patching file src/mesa/drivers/dri/r300/compiler/radeon_emulate_loops.h
patching file src/mesa/drivers/dri/r300/r300_reg.h
Comment 8 Tom Stellard 2010-08-06 11:18:26 UTC
Created attachment 37644 [details] [review]
Implement vertex shader loops v3

Here is a modified patch that should apply cleanly to master.
Comment 9 Pavel Ondračka 2010-08-06 12:24:15 UTC
Created attachment 37649 [details]
output with patch, RADEON_DEBUG=vp

With your patch some units and buildings are being rendered now, however some are not and one quarter of the screen is whole black. Downside of this is dramatic decrease of framerate, from approx. 20-30 to 5-7 in menus and 12-18 to 1-2 in game.
Comment 10 Pavel Ondračka 2010-08-06 12:25:51 UTC
Created attachment 37650 [details]
screenshot
Comment 11 Tom Stellard 2010-08-09 22:35:01 UTC
Created attachment 37755 [details] [review]
Implement vertex shader loops and branches

Here is an updated patch, can you try again with RADEON_DEBUG=vp and post the output. Thanks.
Comment 12 Pavel Ondračka 2010-08-10 01:16:37 UTC
Created attachment 37757 [details]
output with RADEON_DEBUG=vp, with vs-if-loop.patch

(In reply to comment #11)
> Created an attachment (id=37755) [details]
> Implement vertex shader loops and branches
> 
> Here is an updated patch, can you try again with RADEON_DEBUG=vp and post the
> output. Thanks.

Your patch is definitely move in a right direction, the big black triangle is gone, units now have right colors and there are first signs of terrain (cliffs). 
However there are some strange artifacts, maybe shadows, the big slowdown is still present and terrain is still mostly black. I'll attach new screenshot.
Comment 13 Pavel Ondračka 2010-08-10 01:17:33 UTC
Created attachment 37758 [details]
screenshot with vs-if-loop.patch
Comment 14 Pavel Ondračka 2010-08-11 03:29:05 UTC
Good news, with latest mesa when I disable use of GLSL in Wine, everything is rendered 100% correctly and there is no visible drop of framerate. However when using GLSL (default Wine settings) problems still remains.
Comment 15 Felipe Contreras 2010-08-21 12:58:16 UTC
(In reply to comment #14)
> Good news, with latest mesa when I disable use of GLSL in Wine, everything is
> rendered 100% correctly and there is no visible drop of framerate. However when
> using GLSL (default Wine settings) problems still remains.

And you also need to patch Wine? (bug #29137)
Comment 16 Pavel Ondračka 2010-08-23 06:01:16 UTC
With glsl2 merged into master things are looking much better now, terrain is rendered properly and most of units and buildings too, however there are some effects which are wrong and some effects are too big. I wasn't able to test much because the big slowdown is still present and it's not easy to play game at 1-3 fps. Any more logs and/or screenshots needed?
Comment 17 Pavel Ondračka 2010-09-23 00:11:03 UTC
This bug is fixed with latest mesa master, there is one small regression in non GLSL codepath, I'll open a new bug as soon as I finish bisecting.
Comment 18 Hannes 2011-02-16 18:08:51 UTC
I experience issues very similar to those described here, although I run ver up2date gallium:

root@archmain /h/hannes# yaourt -Qss  mesa
radeon/lib32-mesa-full 20110206-1 (lib32)
    Mesa OpenGL library
radeon/lib32-mesa-full-gallium 20110206-1 (lib32)
    Mesa OpenGL library
radeon/mesa-demos-git 20110107-1
    The mesa demos (glxinfo, glxgears, ...), built from the git master branch.
radeon/mesa-full 20110206-1
    Full Mesa 3D graphics library with all its components, built from the git master branch.
radeon/mesa-full-gallium 20110206-1
    Full Mesa 3D graphics library with all its components, built from the git master branch.

The menus and textures are really broken, and the game keeps on spitting out:

err:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glDrawElements @ ../../../wine/dlls/wined3d/drawprim.c / 43

and:


fixme:d3d_surface:surface_load_ds_location Not supported with fixed up depth stencil.


I have also attached screenshots. Is this the same issue, should I reopen or should I report as new bug?

Thanks for your help!
Comment 19 Hannes 2011-02-16 18:11:52 UTC
Here's the attachment:
http://soulrebel.in-berlin.de/pub/screens_and_logs.tar.xz
Comment 20 Hannes 2011-02-16 18:13:58 UTC
Sorry for all the noise, I forgot to mention that I set "UseGLSL" to disabled, but it didn't change anything.

Thanks for your help-
Comment 21 Marek Olšák 2011-02-16 18:18:52 UTC
Hannes, it seems to be a bug in Wine.
Comment 22 Hannes 2011-02-27 05:22:57 UTC
(In reply to comment #21)
> Hannes, it seems to be a bug in Wine.

Actually I have now tried Doom3-Demo (native) and it has very similar issues (the menu interface is completely white with slightly visible interface elements appearing on mouse over, sound works).

Doom3 give no errors on console. I didnt manage to start a game, because I don't know how to navigate through the menus...

-> I really think this is a driver issue! Can I reopen? Do you need further information?

Thanks for your help.
Comment 23 Marek Olšák 2011-02-27 16:58:01 UTC
Please file a new bug instead.
Comment 24 Hannes 2011-02-27 17:15:31 UTC
Ah, I did not realise the Arch Mesa-packages lack s3tc support. I have installed that now and get other (seemingly better but still strange behaviour).

Directly after installing the lib, both SC2 and Doom3 bootet up correctly with some minor drawing issues in the menus (90% correct i would say, compared to the 2% before). Both games had in-game drawing issues that were severe, (flickering lines, squares and other patterns on random textures…

After a restart I now have this:
- Doom3 works ok, with some minor drawing issues in-game (mostly related to shadows), but playable
- SC2 shows loading screen and then crashes giving this (a a few hundred times):

Please report at bugs.freedesktop.org
Mesa 7.11-devel implementation error: Unexpected texture format in radeon_update_wrapper()

The above error was also printed the one time after install where I actually started SC2 with some serious issues. Finally it prints:

fixme:win:EnumDisplayDevicesW ((null),0,0x4346d68,0x00000000), stub!
fixme:mmdevapi:AEV_GetMute stub
fixme:d3d:query_init Event query: Unimplemented, but pretending to be supported.
fixme:winhttp:WinHttpGetIEProxyConfigForCurrentUser returning no proxy used
fixme:imm:ImmReleaseContext (0x40022, 0x13c9c8): stub
drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.

And dmesg shows:

[drm:r100_cs_track_check] *ERROR* [drm] Buffer too small for z buffer (need 4096000 have 3502080) !
[drm:r100_cs_track_check] *ERROR* [drm] zbuffer (1280 4 0 800)
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

Should I open an extra report for this?

Thanks for your help.
Comment 25 Marek Olšák 2011-02-28 02:52:49 UTC
(In reply to comment #24)
> Please report at bugs.freedesktop.org
> Mesa 7.11-devel implementation error: Unexpected texture format in
> radeon_update_wrapper()

This is the r300 classic driver, not the r300 gallium driver. The classic driver is unmaintained, I recommend using the gallium driver.
Comment 26 Hannes 2011-03-02 07:35:44 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > Please report at bugs.freedesktop.org
> > Mesa 7.11-devel implementation error: Unexpected texture format in
> > radeon_update_wrapper()
> 
> This is the r300 classic driver, not the r300 gallium driver. The classic
> driver is unmaintained, I recommend using the gallium driver.

I am pretty sure I am using gallium:

hannes@archmain ~> glxinfo | grep OpenGL
r300: DRM version: 2.8.0, Name: ATI R480, ID: 0x5d52, GB: 4, Z: 1
r300: GART size: 509 MB, VRAM size: 256 MB
r300: AA compression: NO, Z compression: NO, HiZ: NO
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI R480
OpenGL version string: 2.1 Mesa 7.11-devel
OpenGL shading language version string: 1.20
OpenGL extensions:

I also updated to a current kernel with drm-next for radeon:

hannes@archmain ~> uname -a
Linux archmain 2.6.38-rc6-43687-g16d5286-dirty #1 SMP PREEMPT Sat Feb 26 17:32:37 CET 2011 x86_64 AMD Phenom(tm) II X4 945 Processor AuthenticAMD GNU/Linux

Same issues, same error.

I still have the feeling that I am hijacking this thread, should I open another one or would you be willing to answer private mail, so we can narrow the issue down?


Thanks for your help!
Comment 27 Marek Olšák 2011-03-02 07:40:05 UTC
There is no way for a gallium driver to end up in radeon_update_wrapper.
Comment 28 Henri Verbeet 2011-03-02 09:33:09 UTC
(In reply to comment #26)
> I am pretty sure I am using gallium:
> 
> hannes@archmain ~> glxinfo | grep OpenGL
> r300: DRM version: 2.8.0, Name: ATI R480, ID: 0x5d52, GB: 4, Z: 1
> r300: GART size: 509 MB, VRAM size: 256 MB
> r300: AA compression: NO, Z compression: NO, HiZ: NO
> OpenGL vendor string: X.Org R300 Project
> OpenGL renderer string: Gallium 0.4 on ATI R480
> OpenGL version string: 2.1 Mesa 7.11-devel
> OpenGL shading language version string: 1.20
> OpenGL extensions:
> 
> I also updated to a current kernel with drm-next for radeon:
> 
> hannes@archmain ~> uname -a
> Linux archmain 2.6.38-rc6-43687-g16d5286-dirty #1 SMP PREEMPT Sat Feb 26
> 17:32:37 CET 2011 x86_64 AMD Phenom(tm) II X4 945 Processor AuthenticAMD
> GNU/Linux
> 
Note that Starcraft 2 is a 32-bit application, and needs 32-bit drivers. Use something like the following:

WINEDEBUG="-all,+wgl" wine StarCraft\ II.exe 2>&1 | head

to see what Wine actually ends up using.
Comment 29 Hannes 2011-03-04 18:16:56 UTC
Thanks for your help.

Indeed there was an issue, where the LIBGL_DRIVERS_PATH was adjusted and it was correct(pointing at gallium) for 64bit, but wrong for 32bit. Since all the diagnosis apps like glxinfo ran natively they didnt realise... oh well.

After having changed that I can run SC2 and playable framerates! There are still some display issues if activate certain options and I get similar issues with doom3 when certain options are set, but I will debug that at a later point in time and file a seperate bug report for that.

Thanks for your work on the new driver architecture, I feel its really going forward :)
Comment 30 Hannes 2011-03-04 18:49:38 UTC
Hm, just reading through the output of wine after running the game, I get exactly the same error as reported here orginally:

"r300 VP: Compiler error:
Vertex program has too many instructions
Using a dummy shader instead."

Also it should be noted that I did set "UseGLSL" to "disabled" in Wine's registry. 

As I said previously, the Game works ok, so its not a critical issue to me, but if performance could be increased or especially some the stuff activated that makes the graphics worthwhile it would be great.

I created a log with RADEON_DEBUG=vp set, you can find it here:
http://soulrebel.in-berlin.de/pub/sc2_output_debug.xz

Thanks for your help!

P.S: strange coincidences, first I think I have the issue, that it turns out I did it wrong, then it turns out, I actually do get the same error…
Comment 31 Marek Olšák 2011-03-05 04:19:41 UTC
(In reply to comment #30)
> Hm, just reading through the output of wine after running the game, I get
> exactly the same error as reported here orginally:
> 
> "r300 VP: Compiler error:
> Vertex program has too many instructions
> Using a dummy shader instead."
> 
> Also it should be noted that I did set "UseGLSL" to "disabled" in Wine's
> registry. 
> 
> As I said previously, the Game works ok, so its not a critical issue to me, but
> if performance could be increased or especially some the stuff activated that
> makes the graphics worthwhile it would be great.
> 
> I created a log with RADEON_DEBUG=vp set, you can find it here:
> http://soulrebel.in-berlin.de/pub/sc2_output_debug.xz

The error message only shows on r300-r400. There is a lot of scalar operations, I guess it could be fixed by implementing Dual-Op (pair) instruction scheduling for vertex shaders.


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.