Bug 29363

Created attachment 37528 [details]
screenshot

Can you run the program again with the environment variable RADEON_DEBUG=vp and post the output.

Created attachment 37530 [details]
output with RADEON_DEBUG=vp

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 on attachment 37618 [details] [review]
Implement vertex shader loops

This patch has a mistake, another one is one the way.

Created attachment 37619 [details] [review]
Implement vertex shader loops v2

This patch should be better.

(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

Created attachment 37644 [details] [review]
Implement vertex shader loops v3

Here is a modified patch that should apply cleanly to master.

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.

Created attachment 37650 [details]
screenshot

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.

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.

Created attachment 37758 [details]
screenshot with vs-if-loop.patch

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.

(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)

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?

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.

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!

Here's the attachment:
http://soulrebel.in-berlin.de/pub/screens_and_logs.tar.xz

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-

Hannes, it seems to be a bug in Wine.

(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.

Please file a new bug instead.

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.

(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.

(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!

There is no way for a gallium driver to end up in radeon_update_wrapper.

(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.

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 :)

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…

(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.