Bugzilla – Bug 4799
radeon driver should support 3d texture maps without raster fallback
Last modified: 2010-03-27 04:27:06 UTC
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
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:
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:
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
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...