Bug 960 - rendering error - random textures used
Summary: rendering error - random textures used
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r200 (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-31 19:05 UTC by Nicholas Miell
Modified: 2004-10-21 23:21 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Montage of flipscreen3d screenshots (245.92 KB, image/jpeg)
2004-07-31 19:05 UTC, Nicholas Miell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicholas Miell 2004-07-31 19:05:04 UTC
Attached is a montage of screenshots taken at one second intervals while the
flipscreen3d screensaver is running (with the --no-rotate option).

As you can see, it starts with a screenshot of the desktop (as expected), but as
it scales that texture, other textures from previous runs of flipscreen3d are
mixed in. (Yes, previous runs. Earlier, I had an instance where flipscreen3d was
using Neverball textures.)

This is with an ATI FireGL 8800, Xorg 6.7.0 (xorg-x11-6.7.0-5), on FC2/AMD64.
Comment 1 Nicholas Miell 2004-07-31 19:05:59 UTC
Created attachment 551 [details]
Montage of flipscreen3d screenshots

This is a rather low quality JPEG, if anyone wants the 11 MB original for some
reason, let me know.
Comment 2 Roland Scheidegger 2004-08-03 12:58:57 UTC
What's the xscreensaver version?
Also, how much ram does your FGL 8800 have, how much is useable for textures
(look in the Xorg log file), and what does glxinfo -l say about maximum texture
size, and what resolution are you running at?
Obviously, the mip-mapped textures do not get created (or uploaded) for some reason.
When I try that screensaver (4.16) with 1280x1024, I get
flipscreen3d: error mipmapping 2048x1024 texture: (unknown)
flipscreen3d: turning on -wireframe. Works fine in lower resolutions.
flipscreen3d uses gluBuild2DMipmaps to scale the picture and build the mipmaps,
looks like it rounds up 1280 to 2048 (I thought it would round down to 1024, but
that's another topic).
That said, I hacked the maximum supported texture size to 2048 instead of the
1024 which is normally calculated for my 64MB card, and I saw exactly the
symptoms you describe. Looks like there might be a problem with mipmapping of
large textures, since I can't see a reason why that shouldn't work (a single
2048x1024 texture with mipmaps should only consume about 12MB of ram or so,
which fits very well within the texture ram of my card).
Comment 3 Ian Romanick 2004-08-03 13:18:23 UTC
You might try disabling GL_SGIS_generate_mipmap in either the app or the driver.
 This sounds like it could be related to Mesa bug #887386.  That bug was
partially fixed (at least for 16-bit textures), but I have still seen problems
with that extension in some non-publicly availble apps.

I think the issue may be releated to the driver not correctly uploading the
generated mipmap levels when the base map is changed.  It seems to work find the
first time, but if glTexSubImage2D or glTexImage2D is called again, the maps
start to show problems.  I tried to write a simple test case to expose this
problem, but I could not make it happen under controlled circumstances.  I'm
assuming that flipscreen3d is open-source, so that should provide a starting
point for a test case.

http://sourceforge.net/tracker/index.php?func=detail&aid=887386&group_id=3&atid=100003
Comment 4 Roland Scheidegger 2004-08-03 13:40:40 UTC
flipscreen3d does not use auto-mipmapping, gluBuild2DMipmaps builds all mipmaps
itself using gluScaleImage (at least the documentation I've found says that).
flipscreen3d is part of xscreensaver and can be downloaded here:
http://www.jwz.org/xscreensaver/download.html
It's a nice 525-line program, unfortunately I failed attaching a debugger to it
(the problem does not happen when flipscreen3d -window is used (as the window is
too small), and starting it manually with flipscreen3d -root just crashes here.
And when starting it from within xscreensaver there are some forks and whatnot
going on :-().
Comment 5 Nicholas Miell 2004-08-03 13:57:35 UTC
(In reply to comment #2)
> What's the xscreensaver version?
> Also, how much ram does your FGL 8800 have, how much is useable for textures
> (look in the Xorg log file), and what does glxinfo -l say about maximum texture
> size, and what resolution are you running at?

xscreensaver 4.16

the FGL 8800 has 128MB,

Xorg.0.log says:

(II) RADEON(0): Using 5 MB for GART textures
(II) RADEON(0): Will use 100352 kb for textures at offset 0x1e00000,

glxinfo -l says:
    GL_MAX_TEXTURE_SIZE = 2048
    GL_MAX_3D_TEXTURE_SIZE = 128
    GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 1024
    GL_MAX_RECTANGLE_TEXTURE_SIZE_NV = 4096

resolution is 1280x1024

(In reply to comment #4)
> It's a nice 525-line program, unfortunately I failed attaching a debugger to it
> (the problem does not happen when flipscreen3d -window is used (as the window is
> too small), and starting it manually with flipscreen3d -root just crashes here.
> And when starting it from within xscreensaver there are some forks and whatnot
> going on :-().

try 'flipscreen3d -geometry 1280x1024' (this reproduces the bug for me)
Comment 6 Nicholas Miell 2004-08-03 14:06:54 UTC
as another datapoint, antspotlight and gleidescope also have similar texture
problems
Comment 7 Roland Scheidegger 2004-08-03 16:17:46 UTC
(In reply to comment #5)
> xscreensaver 4.16
> 
> the FGL 8800 has 128MB,
> glxinfo -l says:
>     GL_MAX_TEXTURE_SIZE = 2048
ok then looks like the problem only exists with really large textures.

> try 'flipscreen3d -geometry 1280x1024' (this reproduces the bug for me)
Yes that worked. The problem really seems to be caused by the overall size, not
the 2048 width of the created texture (since -geometry 1280x512 does not exhibit
any bugs). I've stepped through it with gdb, and you can also get all
interesting output with R200_DEBUG=texture - however, everything seems correct,
all 12 texture levels get uploaded with the correct parameters afaics. Hmm.
Comment 8 Ian Romanick 2004-08-04 10:08:23 UTC
Since I also have a 64MB card, I had to hack the driver to support 2048x2048
textures.  The interesting thing is that it works *fine* at 16-bit color, but
fails at 24-bit.  My guess is that it's uploading the texture levels, but just
not uploading them to the right place.
Comment 9 Ian Romanick 2004-08-04 11:56:45 UTC
I've done some more research into this bug.  I have a theory, but I'm not going
to be able to test it.  Texture uploads work by bliting a block of data from
main memory to either on-card or AGP memory.  This blit is always done as an I8
format texture that is 1024 bytes wide.  This change was made a long time ago to
pave the way for supporting compressed textures.  In any case, the texture stack
(i.e., the base map and all mipmaps) are treated as a single rectangle.  The
base level is uploaded by blitting to [0,0], and the mipmaps up uploaded by
blitting to some [x,y] that puts them at the correct byte offset in the texture.

In the case of a very large texture, the y value for some mipmaps is quite
large.  In the case of a 2048x1024x4-byte texture, the y value of the level-1
mipmap is 8192.  For a 2048x1024x2-byte texture it would only be 4096.  I
suspect there may be some blitter hardware limit that we're hitting here.

To test this, I put a hack in uploadSubImage.  Right before the LOCK_HARDWARE
call I put a block of code like:

if ( tmp.y > 4096 ) {
    tex.offset += tmp.y * 1024;
    tmp.y = 0;
}

That seems to fix the problem, though I'm not convinced that it's the right answer.
Comment 10 Eric Anholt 2004-08-04 12:10:47 UTC
The 2d coordinate space is -8192 to 8191, so that does seem like a genuine
issue, even if it's rare.
Comment 11 Michel Dänzer 2004-08-04 15:27:19 UTC
I think the best solution would be to always update the offset instead of
playing tricks with coordinates.
Comment 12 Dieter Nützel 2004-09-27 02:14:05 UTC
So what's up? 
 
Roland's findings (-geometry 1280x512 is OK) are true even with DRI/DRM CVS of today. 
I'll try with Ian's change, too. 
Comment 13 Dieter Nützel 2004-09-28 13:47:26 UTC
Latest DRI/DRM CVS (Mesa 6.2) with Ian's fix solved it. 
Comment 14 Dieter Nützel 2004-10-06 23:50:02 UTC
This one is badly needed for 'big' textures (xscreensaver 'flipscreen3d -geometry 1280x1024' 
and Celestia 'Earth' (image available). 
 
--- src/mesa/drivers/dri/r200/r200_texmem.c     2004-10-07 08:46:38.044333726 +0200 
+++ src/mesa/drivers/dri/r200/r200_texmem.c.Ian 2004-10-07 08:45:43.000000000 +0200 
@@ -382,6 +382,11 @@ 
    /* copy (x,y,width,height,data) */ 
    memcpy( &tmp, &t->image[face][hwlevel], sizeof(tmp) ); 
 
+if ( tmp.y > 4096 ) { 
+    tex.offset += tmp.y * 1024; 
+    tmp.y = 0; 
+} 
+ 
    LOCK_HARDWARE( rmesa ); 
    do { 
       ret = drmCommandWriteRead( rmesa->dri.fd, DRM_RADEON_TEXTURE, 
 
Comment 15 Ian Romanick 2004-10-07 09:41:35 UTC
Fix (finally) committed to Mesa CVS.  Sorry for taking so long to commit.  I
forgot about it. :(
Comment 16 Dieter Nützel 2004-10-21 12:19:19 UTC
I have to reopen (with latest Mesa/DRI/DRM CVS on XFree86).  
r200  
 
Your fix (in Mesa CVS) 
 
/* Adjust the base offset to account for the Y-offset.  This is done, 
    * instead of just letting the Y-offset automatically take care of it, 
    * because it is possible, for very large textures, for the Y-offset 
    * to exceede the [-8192,+8191] range. 
    */ 
   tex.offset += tmp.y * 1024; 
   tmp.y = 0; 
 
Do NOT work anylonger. 
 
flipscreen3d (big textures are broken, again):   
/opt/Mesa> /usr/X11R6/lib/xscreensaver/flipscreen3d -geometry 1280x1024   
flipscreen3d: error mipmapping 2048x1024 texture: (unknown)   
flipscreen3d: turning on -wireframe.   
   
=> Empty black flipping window.   
   
But this one works:   
/usr/X11R6/lib/xscreensaver/flipscreen3d   
/usr/X11R6/lib/xscreensaver/flipscreen3d -geometry 1024x1024   
/opt/Mesa> /usr/X11R6/lib/xscreensaver/flipscreen3d -geometry 1024x1025   
/opt/Mesa> /usr/X11R6/lib/xscreensaver/flipscreen3d -geometry 1024x1280   
/opt/Mesa> /usr/X11R6/lib/xscreensaver/flipscreen3d -geometry 1024x160   
/opt/Mesa> /usr/X11R6/lib/xscreensaver/flipscreen3d -geometry 1024x1600   
   
Badness starts here:   
/opt/Mesa> /usr/X11R6/lib/xscreensaver/flipscreen3d -geometry 1025x1024   
flipscreen3d: error mipmapping 2048x1024 texture: (unknown)   
flipscreen3d: turning on -wireframe.   
  
See https://freedesktop.org/bugzilla/show_bug.cgi?id=760, too.  
Comment 17 Ian Romanick 2004-10-21 13:02:19 UTC
What does 'glxinfo -l' show for the maximum texture size?  My guess, based on
the app reporting that it got a GL error, is that it's trying to use a texture
larger than the driver will let it use.  If that's the case, the app is broken.
Comment 18 Dieter Nützel 2004-10-21 14:18:00 UTC
Argh, 1024. Why this? 
 
   GL_MAX_TEXTURE_STACK_DEPTH = 10 
   GL_MAX_TEXTURE_SIZE = 1024 
   GL_MAX_TEXTURE_UNITS_ARB = 4 
   GL_MAX_TEXTURE_LOD_BIAS_EXT = 11 
   GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT = 16 
 
I've checked without your fix but. 
 
/opt/Mesa> /usr/X11R6/lib/xscreensaver/flipscreen3d -geometry 1025x1280 
flipscreen3d: error mipmapping 2048x1024 texture: (unknown) 
flipscreen3d: turning on -wireframe. 
 
I remember that there could be a fix for big textures are missing after S3TC merge. 
http://marc.theaimsgroup.com/?l=dri-devel&m=109737676015268&w=2 
http://marc.theaimsgroup.com/?l=dri-devel&m=109743615708955&w=2 
 
-Dieter 
Comment 19 Roland Scheidegger 2004-10-21 17:35:15 UTC
That fix unfortunately is a big ugly hack, which potentially causes really bad
behaviour (haven't looked exactly what happens when there's not enough video ram
to allocate all currently bound textures). Most apps will not hit such a
condition, but some might and this "solution" is unacceptable.
The behaviour you see with flipscreen3d is clearly an app bug.
It would be possible to announce larger texture sizes and deal with it if this
exceeds the available texture memory (for instance using gart texturing), but
currently the driver can't do that. 
Comment 20 Dieter Nützel 2004-10-22 11:48:57 UTC
But Roland's hack fixed it: 
 
    GL_MAX_TEXTURE_STACK_DEPTH = 10 
    GL_MAX_TEXTURE_SIZE = 2048 
    GL_MAX_3D_TEXTURE_SIZE = 64 
    GL_MAX_TEXTURE_UNITS_ARB = 4 
    GL_MAX_TEXTURE_LOD_BIAS_EXT = 11 
    GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT = 16 
 
--- src/mesa/drivers/dri/r200/r200_context.c.orig       2004-10-14 23:31:45.000000000 +0200 
+++ src/mesa/drivers/dri/r200/r200_context.c    2004-10-22 16:36:27.000000000 +0200 
@@ -351,6 +351,10 @@ 
                                 12, 
                                 GL_FALSE ); 
 
+/* adjust max texture size a bit. Hack, but I really want to use larger textures 
+   which will work just fine in 99.999999% of all cases, especially with texture compression... 
*/ 
+   if (ctx->Const.MaxTextureLevels < 12) ctx->Const.MaxTextureLevels += 1; 
+ 
    ctx->Const.MaxTextureMaxAnisotropy = 16.0; 
 
    /* No wide points. 
 
Comment 21 Eric Anholt 2004-10-22 15:24:24 UTC
Yes, this is an app bug.  However, it would be really neat if we made the
drivers smart enough to tell when too many textures are bound to fit in memory
and fall back, so that they could advertise sizes as large as the hardware can
actually render.  That would remove the desire for Roland's hack.
Comment 22 Ian Romanick 2004-10-22 16:21:11 UTC
A long time ago, the drivers used to do that.  The problem was that some games
(e.g., Quake2) would use textures with the maximum size and software fallbacks
would be hit.  With cards that have more than 2 textures unit (e.g., r200, i830,
etc.) this becomes an even bigger potential problem.  One option would be to
have a driconf option to select the behavior (advertise max hw size vs advertise
max safe size).

There maybe other options available as well.

Could someone that has fglrx drivers installed and working try a test program
that binds the maximum number of maximum sized textures and see what happens? 
With mipmaps a 2Kx2K textures is ~21MB.  If there is no AGP memory available, 6
of them would exhaust the memory on even a 128MB card.  Modifying multiarb to
use 2Kx2K textures would probably be the easiest thing to do.  It might also be
interesting to see what the Nvidia drivers do.


bug/show.html.tmpl processed on Jul 30, 2016 at 15:00:56.
(provided by the Example extension).