Bug 35434

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

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

I also have corrupted textures. Buildings textures doesn't have problem, only the ground textures.

RV770 / 2.6.39-rc1 / F15 updated

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

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

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 ?

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.

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

At the end of the video, you can see that land textures and sky textures are inverted.

In fact, I have these 2 issues also with gallium-swrast.

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

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

(In reply to comment #12)
> 
> You are right, ETQW is too slow to move the mouse.

Yeah, that sounds about right for software rendering :)

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

Created attachment 48019 [details] [review]
patch

Does this patch help?

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

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

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

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

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

Sorry, I meant "I tested resetting to 0".

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

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

The problem with the artefacts is filed as bug 38452.