Bug 35434 - [RADEON:KMS:R600G] etqw: broken ground textures
[RADEON:KMS:R600G] etqw: broken ground textures
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600
git
All Linux (All)
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-18 14:06 UTC by Brian Paterni
Modified: 2011-06-18 10:35 UTC (History)
2 users (show)

See Also:


Attachments
patch (1.97 KB, patch)
2011-06-15 20:13 UTC, Vadim Girlin
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Paterni 2011-03-18 14:06:13 UTC
A few pictures of what I'm seeing are attached.

Environment:
Linux kernel (Linus' current git with s3tc support)
libdrm, xf86-video-ati, mesa @ current git

RV770 [Radeon HD 4850]
[   153.910] (II) RADEON(0): KMS Color Tiling: enabled
[   153.910] (II) RADEON(0): KMS Pageflipping: enabled
[   153.910] (II) RADEON(0): SwapBuffers wait for vsync: enabled
Comment 1 Brian Paterni 2011-03-18 14:17:22 UTC
correction:
Images [1] and [2] are located elsewhere due to bug tracker attachment limitation.

[1] http://imgur.com/k8NNA    # bad ground textures example
[2] http://imgur.com/fDkmc    # junk example
Comment 2 Andy Furniss 2011-03-18 15:18:40 UTC
(In reply to comment #0)
> A few pictures of what I'm seeing are attached.
> 
> Environment:
> Linux kernel (Linus' current git with s3tc support)
> libdrm, xf86-video-ati, mesa @ current git
> 
> RV770 [Radeon HD 4850]
> [   153.910] (II) RADEON(0): KMS Color Tiling: enabled
> [   153.910] (II) RADEON(0): KMS Pageflipping: enabled
> [   153.910] (II) RADEON(0): SwapBuffers wait for vsync: enabled

I also see the corrupted ground on both rv670 and rv790.

Running d-r-t kernel I haven't seen any other corruption yet.

Starting in spectator mode the ground is OK until moving around, when patches/strips become corrupted.
It is possible for corrupted ground to become normal again when viewed from a different place.

I have tested with the above settings disabled and with various in game settings - it makes no difference.
Comment 3 Benjamin Bellec 2011-03-30 10:41:14 UTC
I also have corrupted textures. Buildings textures doesn't have problem, only the ground textures.

RV770 / 2.6.39-rc1 / F15 updated
Comment 4 Benjamin Bellec 2011-04-02 09:26:44 UTC
I must add that in my case the "artefact textures" (as [2] screenshot example from Brian) is different when modifying the etqw config files.
etqw has a "useNormalCompression" parameters which can take "0", "1" or "2" :

[flag] - Enables/Disables the creation of compressed DDS textures for normal maps.

    0 - Prevents engine from creating compressed DDS textures for normal maps.
    1 - Allows engine to create 256 color compressed DDS textures for normal maps.
    2 - Allows engine to create rxgb compressed DDS textures for normal maps.

The default is "2". The "1" flag have same behaviour ingame. But when settign to "0" the "artefact textures" are not grey, yellow or char but it's ingame textures artefact (I can see bushs or players artefacts for example).
Comment 5 Brian Paterni 2011-04-09 10:24:52 UTC
(In reply to comment #4)
> I must add that in my case the "artefact textures" (as [2] screenshot example
> from Brian) is different when modifying the etqw config files.
> etqw has a "useNormalCompression" parameters which can take "0", "1" or "2" :
> 
> [flag] - Enables/Disables the creation of compressed DDS textures for normal
> maps.
> 
>     0 - Prevents engine from creating compressed DDS textures for normal maps.
>     1 - Allows engine to create 256 color compressed DDS textures for normal
> maps.
>     2 - Allows engine to create rxgb compressed DDS textures for normal maps.
> 
> The default is "2". The "1" flag have same behaviour ingame. But when settign
> to "0" the "artefact textures" are not grey, yellow or char but it's ingame
> textures artefact (I can see bushs or players artefacts for example).

I haven't necessarily played around with 'useNormalCompression' myself, however I have some good news that the artifact textures seem to be fixed with current git (git-ee67889). I'm not sure what commit exactly, but it appears to be fixed as I was able to play an hour on slipgate without any artifacts appearing. Though there are times where the game will freeze for a short time < 1 second mostly and then continue. (Perhaps this is due to the alsa buffer overflow recent id games seem to be experiencing?)

Ground textures still appear to be broken but other than that, quake wars is quite playable I think.
Comment 6 Benjamin Bellec 2011-04-10 13:57:46 UTC
With current git I still have these artifacts. But each times I run a 3D applications I have these errors :
EE r600_pipe.c:431 r600_get_param - r600: unknown param 45

For instance :
$ glxinfo | grep "OpenGL version string"
EE r600_pipe.c:431 r600_get_param - r600: unknown param 45
OpenGL version string: 2.1 Mesa 7.11-devel (git-a26121f)

Perhaps it's related ? Or should I open another bug ?
Comment 7 Brian Paterni 2011-04-10 14:56:50 UTC
I'm getting this 'unknown param 45' error as well, though it doesn't /seem/ to be related to this bug; I recall being able to run quake wars prior to the error appearing regularly. So a separate bug report may be necessary.

Looking at src/gallium/drivers/r600/r600_pipe.c though, it looks like r600_get_param() is not handling PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL which has been mapped to '45'. However I'm unsure of what exactly needs to be done for r600g to support it.
Comment 8 Benjamin Bellec 2011-04-18 17:19:15 UTC
Here is a screencast of these textures problems. The first part show especially the texture corruption, and the second part the artifacts.

http://dl.free.fr/hUqycZ1Qo     etqw-bugzilla-35434.ogv
Comment 9 Benjamin Bellec 2011-05-02 14:09:29 UTC
At the end of the video, you can see that land textures and sky textures are inverted.
Comment 10 Benjamin Bellec 2011-05-23 13:12:37 UTC
In fact, I have these 2 issues also with gallium-swrast.
Comment 11 Sven Arvidsson 2011-05-24 12:30:03 UTC
(In reply to comment #10)
> In fact, I have these 2 issues also with gallium-swrast.

I just tried ETQW with llvmpipe and it's rendering correctly.

Can you confirm that you're getting software rendering? Check the renderer string in glxinfo, and double check by setting LIBGL_DEBUG=verbose and check which driver is loaded.

If nothing else, the game should be very slow, even with a fast CPU, 4-5 fps and a loading time of several minutes...
Comment 12 Benjamin Bellec 2011-05-24 13:10:52 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > In fact, I have these 2 issues also with gallium-swrast.
> 
> I just tried ETQW with llvmpipe and it's rendering correctly.
> 
> Can you confirm that you're getting software rendering? Check the renderer
> string in glxinfo, and double check by setting LIBGL_DEBUG=verbose and check
> which driver is loaded.
> 
> If nothing else, the game should be very slow, even with a fast CPU, 4-5 fps
> and a loading time of several minutes...

Shame on me!
ETQW has loaded r600_dri.so from /usr/local/dri (my former dri install) when I deleted it from /usr/dri ! So I believed I was on llvmpipe (Gnome 3 was in fallback-mode, and glxinfo said that too).

You are right, ETQW is too slow to move the mouse.
Comment 13 Sven Arvidsson 2011-05-24 13:12:43 UTC
(In reply to comment #12)
> 
> You are right, ETQW is too slow to move the mouse.

Yeah, that sounds about right for software rendering :)
Comment 14 Benjamin Bellec 2011-06-01 12:02:31 UTC
I don't know really why, but I have no more artefacts.

There is now only broken textures.

FYI :
(II) RADEON(0): KMS Color Tiling: disabled
(II) RADEON(0): KMS Pageflipping: enabled
(II) RADEON(0): SwapBuffers wait for vsync: enabled
Comment 15 Vadim Girlin 2011-06-15 20:13:00 UTC
Created attachment 48019 [details] [review]
patch

Does this patch help?
Comment 16 Brian Paterni 2011-06-15 21:43:42 UTC
(In reply to comment #15)
> Created an attachment (id=48019) [details]
> patch
> 
> Does this patch help?

It does, broken ground textures do seem to be rendering correctly now for me! :)

Although, it looks like some more problems have popped up since I last tested quake wars:

1) screen artifacts (image [2] originally cited in this bug) apparently have not been fixed within r600g/mesa as I had assumed. I only managed to work around the issue by setting r_useIndexBuffers=1 (game variable). Artifacts are still present when r_useIndexBuffers=0 (which is default)

2) water in-game is no longer rendered correctly, now only black blobs appear where water should be.

3) Some game scenery is not being rendered (some trees in refinery is all I've noticed so far)

**Note: I tested ETQW both before and after applying your patch, Vadim, and I can say that your patch is *not* the cause of regressions 2 & 3

I will try and bisect 2 & 3 at some point in the future. It's a little too late for me to do it tonight yet.
Comment 17 Vadim Girlin 2011-06-15 22:28:20 UTC
(In reply to comment #16)
> 2) water in-game is no longer rendered correctly, now only black blobs appear
> where water should be.

I hope the patch from bug 38280 will fix it.
Comment 18 Andy Furniss 2011-06-16 04:46:36 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > Created an attachment (id=48019) [details] [details]
> > patch
> > 
> > Does this patch help?
> 
> It does, broken ground textures do seem to be rendering correctly now for me!
> :)

+1 working for me also - thanks Vadim.

> 
> Although, it looks like some more problems have popped up since I last tested
> quake wars:
> 
> 1) screen artifacts (image [2] originally cited in this bug) apparently have
> not been fixed within r600g/mesa as I had assumed. I only managed to work
> around the issue by setting r_useIndexBuffers=1 (game variable). Artifacts are
> still present when r_useIndexBuffers=0 (which is default)

r_useIndexBuffers=0 has always been problematic for me.

I don't think it's default for everyone - on my two current boxes it's 1 and I haven't changed it.

IIRC from long ago before r500 had accel, using fglrx if the game ever got started in compiz (with LIBGL_ALWAYS_INDIRECT=1) then it would set it to 0 which would stick and break rendering even when running with no compiz/direct. 

> 
> 2) water in-game is no longer rendered correctly, now only black blobs appear
> where water should be.
> 
> 3) Some game scenery is not being rendered (some trees in refinery is all I've
> noticed so far)

Fixed in master now.
Comment 19 Sven Arvidsson 2011-06-16 04:49:46 UTC
(In reply to comment #15)
> Created an attachment (id=48019) [details]
> patch
> 
> Does this patch help?

Yep, textures are fine now! Thanks for working on this :)

I still have two glitches in ETQW, the globe in the menu and the characters in
the team select menu, described in bug 36917. It would be great if someone
could comment on whether this is specific to Evergreen or not.
Comment 20 Benjamin Bellec 2011-06-16 13:34:31 UTC
@Vadim
Thanks, your patch fix the textures.

@Brian
You are right, r_useIndexBuffers=0 is still problematic. I thought this was solved, but in fact I have perhaps just modified my settings in etqw so that my file config is now set to r_useIndexBuffers=1.

I tested resetting to 1, now instead of "artefacts" my screen freezes and shakes... I know now exactly where this is reproductible. For example, in "area 22" map, start with Strogg (soldier), you will land on the right of the Strogg base, then just turn left (looking to the Cyclope), and there is artefact (or now freeze&shake). I noted that watching the Cyclope on this map always results in this behavior.
Comment 21 Benjamin Bellec 2011-06-16 13:35:37 UTC
Sorry, I meant "I tested resetting to 0".
Comment 22 Sven Arvidsson 2011-06-18 07:13:41 UTC
(In reply to comment #20)
> I tested resetting to 1, now instead of "artefacts" my screen freezes and
> shakes... I know now exactly where this is reproductible. For example, in "area
> 22" map, start with Strogg (soldier), you will land on the right of the Strogg
> base, then just turn left (looking to the Cyclope), and there is artefact (or
> now freeze&shake). I noted that watching the Cyclope on this map always results
> in this behavior.

The patch has been merged to master now, so this bug can be closed.

As for the artefacts, it's probably better to open a new bug so this could be tracked separately. I have tried earlier versions of r600g and as far as I can tell this is not a regression.
Comment 23 Brian Paterni 2011-06-18 08:49:48 UTC
(In reply to comment #22)
> The patch has been merged to master now, so this bug can be closed.

Indeed it has. Thanks again for your work Vadim. This stuff is witchcraft to me :)

> As for the artefacts, it's probably better to open a new bug so this could be
> tracked separately. I have tried earlier versions of r600g and as far as I can
> tell this is not a regression.

I don't think it is either. I've been testing etqw since the introduction of the s3tc patches (whenever that was, a kernels ago is my estimate) which had made quake wars playable and the artifacts were present back then as well.
Comment 24 Sven Arvidsson 2011-06-18 10:35:16 UTC
The problem with the artefacts is filed as bug 38452.