Bug 8056

Created attachment 6732 [details]
screenshot of the problem

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?

Created attachment 6739 [details] [review]
the big CopyTexSubImage2D hack

Only works with 24 bit color tiled resolution with a width of 1280.
Testing only!

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.

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.

sorry about the summary, by the way, I forgot to finish it before committing the
bug yesterday

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.

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

It is common knowledge that r300 is slow, but UT 2004 is playable provided you
set UseVBO=True. This should give a 3x speedup.

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

(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

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

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

Oh, I forgot about comment #5, so I guess I have somewhere to start. Any more
advice is still welcome though.

Created attachment 10460 [details] [review]
Mesa part1 of tiling.

Created attachment 10461 [details] [review]
DRM tile part

Created attachment 10462 [details] [review]
Mesa part 2 of tiling

Created attachment 10463 [details] [review]
Mesa part 3 of tiling

Patches implementing micro tiling on r300, if someone wants play with them. 

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?  

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. 

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)

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

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

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

Created attachment 11472 [details] [review]
R300 tiling mesa part

Macro, micro tiling should work.

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

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,

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)

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

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.

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. 

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.

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.

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

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

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

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.

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

Will this eventually be commited someday or what is goint to happen with these patches?

s3tc multitexturing would be nice to have imho.

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

Created attachment 15746 [details] [review]
DRM tile part rebased to current git.

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.

Mass version move, cvs -> git

Are these patches in master already or need more testing to be merged?

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.

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

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

(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