the radeon driver currently does not support 3d texture maps, causing a raster fallback. However, the hardware can do it, although with some limitations (not more than one volume texture + one other texture simultaneously, no mipmaps). I'll attach a patch which tries to address this, though I can't test it right now (other than it compiles). Mipmaps are simply ignored (same as is already done with cube maps, dunno, should there be a incredibly slow raster fallback instead, or behaviour depend on if auto-mipmapping was used, or even a driconf option?).
Created attachment 3577 [details] [review] patch for enabling 3d textures patch to enable 3d textures. If it doesn't work, one reason could be that texcoord routing for unit 2 might need adjustments (e.g. the RADEON_TXFORMAT_ST_ROUTE_STQ bits), dunno. There could be other things wrong too :-).
I've just added a page to the DRI wiki on the subject of handling mipmaps on hardware that doesn't do mipmapping: http://dri.freedesktop.org/wiki/HardwareWithoutMipmaps
This patch does not work. I don't have time to investigate this right now, but results don't seem to be very different than when you'd treat the texture just as a 2d texture with stex3d. Not sure, but since apparently the 3rd texture unit is used to handle the depth dimension, it might maybe be necessary to route the 3rd (i.e. r) coordinate to the 3rd unit explicitly as the s coord of that unit (with the t coord set to 0), while only routing the two first coords (s,t) to the first unit?
There is some info in the IRC logs: http://dri.sourceforge.net/IRC-logs/20040510.txt
Created attachment 7064 [details] [review] new patch for enabling 3d textures New try for 3d textures, it now disables the perspective bit, as it just makes things worse. However, this still doesn't work. I'm now pretty sure that you indeed have to route the r coord manually as s coord to unit 2, and setup won't do that for you. (With this patch, you can see that r tex coord is not set up, just start multiarb demo (with unit 2 enabled) and you can see that the output of stex3d will change according to redraws of multiarb, and permanently change after multiarb has been closed.). If TXFORMAT_2 is initialized to use RADEON_TXFORMAT_ST_ROUTE_STQ0 (instead of STQ2) then you no longer have that problem, but it looks to me like the interpolator of unit 2 for the r coord will simply use the s coord (as a result s and r coord are always identical), which is obviously wrong. So, unless I'm missing some setup bits to change that, this makes 3d textures practically unimplementable. You could hack up tex gen / tex matrix stuff on unit 2 more or less easily in tcl mode, but I don't think the swtcl code could handle that easily. And noone really seemed to have missed that feature too hard, so you can see where this is heading...
I hope nobody minds fielding newbie questions - can one of you explain what 3D texture maps are, and what they get used for? I understand 2D texture maps already, I think, but I'm not sure what is meant by 3D, the gl man page for glTexCoordxx is really terse, and searching online hasn't totally clarified it for me.
I'll send a brief explanation to your email address, Simon.
Mass version move, cvs -> git
I am nearly certain that this got handled by the radeon-rewrite adventure; I distinctly remember Dave certifying that 3D textures work on r100. If not, go ahead and re-open...
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.