Bug 8056

Summary: s3tc broken in ut2004
Product: Mesa Reporter: Simon <Simon80>
Component: Drivers/DRI/r300Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high CC: ghepeu, glisse, saschasommer, tehfoo, xeros
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: screenshot of the problem
the big CopyTexSubImage2D hack
Screenshot showing gearbox running accelerated
xorg.conf
Mesa part1 of tiling.
DRM tile part
Mesa part 2 of tiling
Mesa part 3 of tiling
New drm patch
R300 tiling mesa part
R300 tiling mesa part v2
DRM tile part rebased to current git.
MESA r300 tiling.

Description Simon 2006-08-29 00:14:58 UTC
I'm surprised there's no bug for this issue already, since it is mentioned on
the wiki, so I hope I'm not missing something.  I compiled mesa with
USE_EXTERNAL_DXTN_LIB=1 and installed the external compression library, such
that now I have GL_S3_s3tc and GL_EXT_texture_compression_s3tc listed in
glxinfo.  Now when I test Unreal Tournament 2004, it is significantly faster
than before I did this (though still unplayable), but a lot of textures have
severe display problems.

Some r300 output while running ut2004 that may be relevant:

 $ ut2004 dm-rankin?spectatoronly=1?numbots=12?quickstart=1?attractcam=1
-benchmark -seconds=20
-exec=/usr/local/games/ut2004/Benchmark/Stuff/botmatchexec.txt
center pointWARNING: ALC_EXT_capture is subject to change!
libGL warning: 3D driver claims to not support visual 0x4b
Mesa: CPU vendor: AuthenticAMD
Mesa: CPU name: Mobile AMD Athlon(tm) 64 Processor 3400+
Mesa: MMX cpu detected.
Mesa: 3DNow! cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
Failing back to sw-tcl
*********************************WARN_ONCE*********************************
File r300_state.c function r300_setup_rs_unit line 1326
fragprog wants coords for tex0, vp doesn't provide them!
***************************************************************************
*********************************WARN_ONCE*********************************
File r300_texstate.c function r300SetTexImages line 273
DXT 3/5 suffers from multitexturing problems!
***************************************************************************
CTRL-C before main loop ... forcing exit.
Comment 1 Simon 2006-08-29 00:16:46 UTC
Created attachment 6732 [details]
screenshot of the problem
Comment 2 Rune Petersen 2006-08-29 02:36:51 UTC
The dansing textures are caused by:
DXT 3/5 suffers from multitexturing problems!
In other words do not use s3tc unless you have to.


The slowness:
"Failing back to sw-tcl"
This bug was introduced some days ago, and was fixed yesterday, please update.

Performance tip:
Set "UseVBO" option to "True"
in ~/.ut2004/System/UT2004.ini


Question:
What card do you have?
What options are anabled for your card in xorg.conf?
Comment 3 Aapo Tahkola 2006-08-29 08:20:25 UTC
Created attachment 6739 [details] [review]
the big CopyTexSubImage2D hack

Only works with 24 bit color tiled resolution with a width of 1280.
Testing only!
Comment 4 Aapo Tahkola 2006-08-29 08:23:28 UTC
Created attachment 6740 [details]
Screenshot showing gearbox running accelerated

gearbox window must be positioned like that to get clip rectanges right for the
blit operation.
Comment 5 Aapo Tahkola 2006-08-29 08:32:26 UTC
The problem with DXT 3/5 textures has been described here:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg27996.html

Current problem with r300_meta_bitblt boils down to lines 350 and 396.
Accoring to debug info in r300_cmdbuf.c, clip rects are set to correct values,
yet it crashes the machine.
Comment 6 Simon 2006-08-29 09:42:00 UTC
sorry about the summary, by the way, I forgot to finish it before committing the
bug yesterday
Comment 7 Simon 2006-08-29 14:52:00 UTC
Created attachment 6743 [details]
xorg.conf

It's a Radeon Mobility 9600.  My xorg.conf is attached.  It might be notable
that I'm using AIGLX (but not compiz).	I was experimenting with different
settings in the Device section yesterday.  Other than GARTSize, I copied the
other options from the wiki.  Other than FW support causing a black screen on
startup, and GARTSize changing memory consumption, none of the options cause
problems.  I took benchmarks with each change I made, but they don't indicate
much, ut2004 was the only useful benchmark, and the results are flaky because
of my cpu being throttled, so the benchmarks aren't terribly useful.  q3a and
glxgears indicate that page flip is beneficial, but ut2004 doesn't seem to.  I
should test again with UseVBO=True and my cpu fixed to one speed if I want
better results from ut2004.
Comment 8 Simon 2006-08-31 03:34:44 UTC
> The slowness:
> "Failing back to sw-tcl"
> This bug was introduced some days ago, and was fixed yesterday, please update.

Any slowness in question goes beyond this one issue - the r300 driver is much
slower than fglrx, which is yet slower than the windows driver.  UT2004 is a
game that I should theoretically have no problems playing on my hardware with
all of the settings cranked up - when it first came out I was playing it on a
Mobility Radeon 9000 IGP in windows.  I haven't tried running it on r300 with
the settings all at a bare minimum, but I have them mostly at "normal", which
isn't unreasonable either.  So my point here, I guess, is that there's a huge
performance issue with the driver at present, since I can't even get playable
framerates, but it's out of the scope of this bug.
Comment 9 Rune Petersen 2006-08-31 04:57:46 UTC
It is common knowledge that r300 is slow, but UT 2004 is playable provided you
set UseVBO=True. This should give a 3x speedup.
Comment 10 Simon 2006-09-11 17:55:33 UTC
(In reply to comment #9)
> It is common knowledge that r300 is slow, but UT 2004 is playable provided you
> set UseVBO=True. This should give a 3x speedup.

I've changed that, it seems to make a big difference if s3tc is enabled, but
still not playable.  I have a somewhat serious interest in working on r300
though, and I've been trying to reproduce the texture corruption issue with my
own simple opengl commands.  So far, I have a spinning cube with a texture on
the sides, and I have r300 warning my about the multitexturing problems, but the
texture still looks fine.  I'm going to find out about how to use multitexturing
and add to my code till I hopefully reproduce the problem.  Anyone have any
advice for me?
Comment 11 Aapo Tahkola 2006-09-11 21:27:32 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > It is common knowledge that r300 is slow, but UT 2004 is playable provided you
> > set UseVBO=True. This should give a 3x speedup.
> 
> I've changed that, it seems to make a big difference if s3tc is enabled, but
> still not playable.  I have a somewhat serious interest in working on r300
> though, and I've been trying to reproduce the texture corruption issue with my
> own simple opengl commands.  So far, I have a spinning cube with a texture on
> the sides, and I have r300 warning my about the multitexturing problems, but the
> texture still looks fine.  I'm going to find out about how to use multitexturing
> and add to my code till I hopefully reproduce the problem.  Anyone have any
> advice for me?

http://www.rasterburn.org/~aet/multiarb1.c

Comment 12 Simon 2006-09-12 20:56:00 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > It is common knowledge that r300 is slow, but UT 2004 is playable provided you
> > > set UseVBO=True. This should give a 3x speedup.
> > 
> > I've changed that, it seems to make a big difference if s3tc is enabled, but
> > still not playable.  I have a somewhat serious interest in working on r300
> > though, and I've been trying to reproduce the texture corruption issue with my
> > own simple opengl commands.  So far, I have a spinning cube with a texture on
> > the sides, and I have r300 warning my about the multitexturing problems, but the
> > texture still looks fine.  I'm going to find out about how to use multitexturing
> > and add to my code till I hopefully reproduce the problem.  Anyone have any
> > advice for me?
> 
> http://www.rasterburn.org/~aet/multiarb1.c
> 
> 

Ok, I reproduced the issue like so:

RCS file: /cvs/mesa/Mesa/progs/demos/multiarb.c,v
retrieving revision 1.15
diff -u -r1.15 multiarb.c
--- multiarb.c  9 Jan 2005 17:39:06 -0000       1.15
+++ multiarb.c  13 Sep 2006 03:50:57 -0000
@@ -256,13 +256,13 @@
       glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);

       if (i == 0) {
-         if (!LoadRGBMipmaps(TEXTURE_1_FILE, GL_RGB)) {
+         if (!LoadRGBMipmaps(TEXTURE_1_FILE, GL_COMPRESSED_RGBA_S3TC_DXT3_EXT)) {
             printf("Error: couldn't load texture image\n");
             exit(1);
          }
       }
       else if (i == 1) {
-         if (!LoadRGBMipmaps(TEXTURE_2_FILE, GL_RGB)) {
+         if (!LoadRGBMipmaps(TEXTURE_2_FILE, GL_COMPRESSED_RGBA_S3TC_DXT3_EXT)) {
             printf("Error: couldn't load texture image\n");
             exit(1);
          }

When you right click on the demo window and enable some of the checkered
textures, they should be messed up if you have changed the format as above.  I
had gotten multitexturing working yesterday, but I think the problems only
happen when mixing the compressed textures with uncompressed ones?
Comment 13 Simon 2006-09-14 16:51:40 UTC
Can I get some tips for what I can do to debug this?  I want to learn more, but
I don't know where to start.  Thanks..
Comment 14 Simon 2006-09-14 17:49:05 UTC
Oh, I forgot about comment #5, so I guess I have somewhere to start. Any more
advice is still welcome though.
Comment 15 Peter Zubaj 2007-06-26 11:08:35 UTC
Created attachment 10460 [details] [review]
Mesa part1 of tiling.
Comment 16 Peter Zubaj 2007-06-26 11:09:20 UTC
Created attachment 10461 [details] [review]
DRM tile part
Comment 17 Peter Zubaj 2007-06-26 11:09:57 UTC
Created attachment 10462 [details] [review]
Mesa part 2 of tiling
Comment 18 Peter Zubaj 2007-06-26 11:11:06 UTC
Created attachment 10463 [details] [review]
Mesa part 3 of tiling
Comment 19 Peter Zubaj 2007-06-26 11:13:42 UTC
Patches implementing micro tiling on r300, if someone wants play with them. 
Comment 20 Adam K Kirchhoff 2007-07-14 07:55:41 UTC
I'm curious if anyone else has tested them?  They appear to work fine here, with ut2004 and doom3.  Any chance we'd see them merged into the mesa tree?  
Comment 21 Oliver McFadden 2007-07-14 08:22:42 UTC
I did some testing and saw texture corruption. I think these patches need a lot more testing and possibly some improvements.  It would really help if the patches were against Git, too, although I can apply the chunks that fail manually it is a pain. 
Comment 22 Rune Petersen 2007-07-14 15:32:28 UTC
Oliver may I suggest a branch for experimenting with the tiling patches?

might make it easier for people to participate... just a thought.

(oh and nice job you have been doing on the driver)
Comment 23 Oliver McFadden 2007-07-14 18:26:09 UTC
I don't have any objection to creating a branch for these patches; in fact, this is probably a very good idea. They defiantly still need some work before merging, though.  I will have to get some tips on pushing a branch to the fd.o Git repo though, I've never done that before. :-) 
Comment 24 Simon 2007-07-14 23:35:18 UTC
(In reply to comment #23)
> I will have to get some tips on pushing a branch to the fd.o
> Git repo though, I've never done that before. :-) 

You might find http://www.freedesktop.org/wiki/Infrastructure/git useful.
Comment 25 Andrew Randrianasulu 2007-08-28 17:56:47 UTC
Created attachment 11317 [details] [review]
New drm patch

simple conversion after DRM_ERR removal. Compile and runtime tested. (only on rv280, but all radeons use this one module [radeon.ko] anyway ....)
Comment 26 Peter Zubaj 2007-09-08 10:29:09 UTC
Created attachment 11472 [details] [review]
R300 tiling mesa part

Macro, micro tiling should work.
Comment 27 Rune Petersen 2007-09-09 04:16:46 UTC
Have you tried it with Nexiuz?

I fixed up the patches some time ago, but some games like Nexiuz failed to load.
I didn't have time to investigate....
Comment 28 Peter Zubaj 2007-09-09 07:03:26 UTC
For me nexuiz from Fedora 7 with new patch works ok.

Small fix for small mipmap textures:

diff --git a/src/mesa/drivers/dri/r300/r300_texstate.c b/src/mesa/drivers/dri/r300/r300_texstate.c
index ad31e76..9c4fff9 100644
--- a/src/mesa/drivers/dri/r300/r300_texstate.c
+++ b/src/mesa/drivers/dri/r300/r300_texstate.c
@@ -345,7 +345,7 @@ static void r300SetTexImages(r300ContextPtr rmesa,
 		t->image[0][i].dst_offset = curOffset;
 
 		/* set blit pitch - used for pitch texture register too */		
-		t->image[0][i].dst_pitch = MAX2(t->image[0][i].width * t->transfer_size, 16);
+		t->image[0][i].dst_pitch = MAX2(t->image[0][i].width * t->transfer_size, ((i == 0) ? 16 : 8));
 
 		if (RADEON_DEBUG & DEBUG_TEXTURE)
 			fprintf(stderr,
Comment 29 Rune Petersen 2007-09-28 06:47:23 UTC
I have done some light testing.

- No regressions with non-s3tc textures
- minor texturing bugs with s3tc:
    - Quake 3 (dm1): there is a strange effect on the stairs when viewed from a distance
    - UT 2004 demo: the CTF flag looks wrong.

My only reservation with this patch is that changes code paths used for non-s3tc textures as well.
In other words it might break currently working games on some cards.

So if we could get this patch tested by a few more testers I would be more confident getting this patch committed. The s3tc bugs we can always fix later.

I tested it on my R420 (X800)
Comment 30 Oliver McFadden 2007-09-28 12:08:37 UTC
I tested the new patches with my code a while ago, and the texture corruption problems seem to be fixed... I had the patches sitting in a local repo for a while, and forgot to mention it here.  I think this could get committed soon, but I would like to get rid of all the #if 0/commented-out code before committing. Peter is probably the best person for the job, since he wrote the patch. :-) 
Comment 31 Simon 2007-09-29 03:21:04 UTC
I tried applying the last three non-obsolete patches to the latest mesa and libdrm from git.  glxgears seems to work fine, but when I run quake3 or ut2004, they both pop up a window briefly before exiting prematurely, and the following is what gets printed last:

*********************************WARN_ONCE*********************************
File r300_state.c function r300SetupTextures line 1308
macro tiling enabled!
***************************************************************************
*********************************WARN_ONCE*********************************
File r300_state.c function r300SetupTextures line 1312
micro tiling enabled!
***************************************************************************
drmRadeonCmdBuffer: -22

Without the patches applied, this doesn't happen.
Comment 32 Oliver McFadden 2007-09-29 06:30:33 UTC
You're still using (part of) the old DRM then; it isn't enough to just install libdrm, you need to install both libdrm and the kernel modules. 
Comment 33 Peter Zubaj 2007-09-29 13:36:20 UTC
I will try to test quake 3 and ut2004. I think, there is still some problem in doom3 too (I don't know if this is problem of my patches or r300 driver itself). I will check, if untiled non s3tc textures can be used with tiled s3tc textures in multitexturing. If yes, then old code can be used for non s3tc textures and new for s3tc. If not, then old code should be used with old drm or if s3tc is not enabled and new in all other cases.
Comment 34 Rune Petersen 2007-09-30 01:57:57 UTC
I believe the code is correct; I just fear it might hit some hardware quirks/bugs/feature and break things.

On the other hand we are 3 who have tested it without any problems so far.
Comment 35 Michel Dänzer 2007-10-01 01:23:59 UTC
(In reply to comment #32)
> You're still using (part of) the old DRM then; it isn't enough to just install
> libdrm, you need to install both libdrm and the kernel modules. 

The Mesa code should handle an old DRM more gracefully though.
Comment 36 Simon 2007-10-01 17:06:27 UTC
I can't test with the latest drm, because it fails to compile with:

linux-core/drm_compat.c:190: error: static declaration of ‘vm_insert_pfn’ follows non-static declaration
include/linux/mm.h:1126: error: previous declaration of ‘vm_insert_pfn’ was here

I'm compiling it against the latest kernel in Ubuntu 7.04, see http://packages.ubuntu.com/feisty/devel/linux-headers-2.6.20-16
Comment 37 Peter Zubaj 2007-10-03 12:22:43 UTC
>     - UT 2004 demo: the CTF flag looks wrong.
> 

Looks like this is caused by wrong storing of cube mipmap textures in my patch. I store them:
 - one face - all mipmaps
 - second face - all mipmaps
  ...

and it should be
 - one mipmap level - all faces
 - second mipmap level - all faces
  ...
Comment 38 Peter Zubaj 2007-10-07 10:37:02 UTC
Created attachment 11931 [details] [review]
R300 tiling mesa part v2

New version, should fix
    - Quake 3 (dm1): there is a strange effect on the stairs when viewed from a
distance
    - UT 2004 demo: the CTF flag looks wrong.

I hope, it will not add new problem.

Still, check for old drm part is needed and upload code in r300_texmem.c is ugly.
Comment 39 Rune Petersen 2007-10-13 16:27:00 UTC
I have done some more testing:

- I can't find any texturing issue with s3tc enabled now.
- I have found no regressions caused bu this patch with non-s2tc games/apps.

So it would appear that all that is needed is the cleanup and version checking and we are good to go.

At least I am a happy camper ( Call of Duty much nicer now =)
Comment 40 Sascha Sommer 2008-01-03 10:55:54 UTC
Will this eventually be commited someday or what is goint to happen with these patches?

s3tc multitexturing would be nice to have imho.
Comment 41 Giacomo Perale 2008-03-02 06:11:17 UTC
what's the current status of these patches? can they go in or is there some problem not reported here?

if they just stay in bugzilla eventually they'll bit rot...
Comment 42 Markus Amsler 2008-04-07 15:54:25 UTC
Created attachment 15746 [details] [review]
DRM tile part rebased to current git.
Comment 43 Markus Amsler 2008-04-07 15:59:25 UTC
Created attachment 15747 [details] [review]
MESA r300 tiling.

I just rebased the drm/mesa patches, I'm not familiar with this texturing stuff. They look a bit hackish/unfinished, but let me game Wow with enabled s3tc without any problems.
Comment 44 Adam Jackson 2009-08-24 12:24:14 UTC
Mass version move, cvs -> git
Comment 45 Tomasz Czapiewski 2009-12-25 13:10:57 UTC
Are these patches in master already or need more testing to be merged?
Comment 46 almos 2011-03-26 08:45:09 UTC
I think this issue has been solved in r300g. At least I see no corruption with rv350 and mesa 7.10.

The UseVBO=True hack is not enabled by default for a good reason: it misrenders the skybox, foliage and a few lightmaps. This is the game's issue, and not specific to mesa. The speed difference it makes is negligible with nvidia blob, and with current r300g it gives around +50% performance instead of the 3x increase reported earlier.

I'm closing this bug, feel free to reopen, if desired.
Comment 47 Matt Turner 2011-03-26 10:58:18 UTC
(In reply to comment #46)
> The UseVBO=True hack

Hack? I used this years ago with the classic r300 driver and don't remember it misrendering anything. Do you have a link or something that explains why it's a hack?
Comment 48 Michel Dänzer 2011-03-27 04:30:13 UTC
(In reply to comment #47)
> (In reply to comment #46)
> > The UseVBO=True hack
> 
> Hack? I used this years ago with the classic r300 driver and don't remember it
> misrendering anything. Do you have a link or something that explains why it's a
> hack?

It's right there in the parts you didn't quote:

(In reply to comment #46)
> The UseVBO=True hack is not enabled by default for a good reason: it misrenders
> the skybox, foliage and a few lightmaps. This is the game's issue, [...]

Basically, it appears that the UseVBO path was abandoned at some point during the development of the game.
Comment 49 almos 2011-05-10 16:25:16 UTC
(In reply to comment #47)
> (In reply to comment #46)
> > The UseVBO=True hack
> 
> Hack? I used this years ago with the classic r300 driver and don't remember it
> misrendering anything. Do you have a link or something that explains why it's a
> hack?

See e.g. this:
https://bugs.freedesktop.org/show_bug.cgi?id=28994

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.