Ian Romanick wrote:
I don't have R100 specs handy, but here's what it took to implement cube mapsOn Mon, Oct 28, 2002 at 11:38:49AM -0700, Brian Paul wrote:Alan Hourihane wrote:I'm going to be merging the DRI cvs back into the XFree86 very soon. Anyone have any furthur patches to the DRI cvs before I do this ?I think I'll bring in my (minor) changes to the radeon kernel module from the mesa-4.1 branch. This might save people from having to upgrade their kernel module later when Mesa 4.1 is on the trunk and people want to use cube textures.Could you perhaps give a 30 second tour of how to enable support for these features in the R100 driver? My guess is that enabling these features (and NV_texture_rectangle) should be pretty much the same for R100 as R200. :)
in the R200 driver (R100 doesn't support NPOT textures, AFAIK):
Changed r200_tex_obj's image array from:
drmRadeonTexImage image[RADEON_MAX_TEXTURE_LEVELS];
to:
drmRadeonTexImage image[6][RADEON_MAX_TEXTURE_LEVELS];
and similarly for the dirty_images field to accomodate 6 sets of images.
When allocating memory for the tex object, allocate 6x the normal amount of
memory. I'm keeping the mipmaps for the 6 cube faces in one contiguous
block of memory (though the hardware doesn't require that).
I overhauled the r200SetTexImages() function. It basically computes x,y,
width,height parameters for blitting the image data to the card's memory.
The used to be pretty complicated so I simplified it (we use a fixed 1KB-wide
blit stride now). This was also done in anticipation of compressed textures.
The texture upload code now observes a 'face' parameter to indicate which
mipmap set (of the six) is to be uploaded.
As for register setup, there are 5 registers to specify the location (offset)
of the extra five sets of mipmaps. There are also additional register fields
to specify the width/height of each of the additional cube faces. OpenGL
requires the same image size for all cube faces but the R200 hardware doesn't.
There's a bit for enabling cube mapping too. These registers are replicated
for each texture unit.
Finally, there's texture coordinate generation. GL_NORMAL_MAP and
GL_REFLECTION_MAP are the important modes. These are done by the hardware's
TCL engine. One subtlety is swizzling/negating the texture coordinates.
This had me stuck for the better part of a day. After setting up the TCL
registers for those gen modes I found that I had to transpose the 3rd and
4th components of the texture coordinates using the texture matrix. For
reflection mode I also have to apply a negative scale to the matrix. There's
a left-hand/D3D vs right-hand/OpenGL register bit which I thought would solve
that, but it didn't seem to work. There may be a TCL option to do the swizzling, but I didn't find it. Not a big deal - the texture matrix solution is
essentially free. I had to do the same thing for 3D textures.
One caveat: the glTexCoord3 functions aren't implemented yet - I'll leave
that fun job to Keith. Since cubemaps usually use texgen, this isn't
a big deal right now. 3D textures are disabled for now for that reason.
-Brian
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
