Here is a patch that will enable the 3rd texture unit in the Radeon R100/RV200 driver. I have tested it using multiarb on a Radeon "classic" DDR and a Radeon M6 (AGP developer board). There are a few issues that I came across that should be resolved before applying.
- How should we calculate the maximum texture size? I changed to code based
on some older discussions on the matter. The problem was that the old
method could over-commit texture memory. My impression is that the driver
/must/ avoid the situation where there isn't enough memory to load all the
textures required for a given pass. If AGP texturing is enabled (that
patch should be ready tomorrow *grin*), should AGP size be taken into
consideration? As long as all the textures of a given size can fit
somewhere, it should be acceptable (though not optimal).
- Do we really need the &3 in radeon_vtxfmt_c.c:
static void radeon_MultiTexCoord1fARB( GLenum target, GLfloat s )
{
- GLfloat *dest = vb.texcoordptr[(target - GL_TEXTURE0_ARB)&1];
+ GLfloat *dest = vb.texcoordptr[(target - GL_TEXTURE0_ARB)&3];
dest[0] = s;
dest[1] = 0;
}
If we don't need the mask, then the AND instructions should be removed
from the assembly stubs in radeon_vtxtmp_x86.S as well.
- In radeon_vtxfmt_x86.c in radeon_makeX86MultiTextureCoord2fvARB and
radeon_makeX86MultiTextureCoord2fARB, is the if-statement that masks
'key' a fast path specifically for the case where texture unit 0 & 1
are enabled? Does it need to be expanded for the 3rd unit? Looking at
the code in radeon_vtxtmp_x86.S, this just doesn't seem right.
By the end of this week I hope to have two more Radeon patches (one to fix
one of the crashes on non-TCL hw, and one to enable AGP textures). I've
finally gotten back to cleaning up my old texture manager patch, so I hope
to get that out RSN as well.
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
dri-radeon-3rd-tmu.patch.gz
Description: application/gunzip
