Bug 2241 - implement GL_ARB_texture_cube_map in radeon driver
implement GL_ARB_texture_cube_map in radeon driver
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R100
x86 (IA32) Linux (All)
: high enhancement
Assigned To: Default DRI bug account
Depends on: 2195
  Show dependency treegraph
Reported: 2005-01-08 16:44 UTC by Andreas Stenglein
Modified: 2009-08-24 12:22 UTC (History)
1 user (show)

See Also:

drm_radeon_cube_20050108.diff.txt (10.66 KB, patch)
2005-01-08 16:46 UTC, Andreas Stenglein
Details | Splinter Review
mesa_radeon_cubemap_20050108.diff.txt (89.86 KB, patch)
2005-01-08 16:54 UTC, Andreas Stenglein
Details | Splinter Review
mesa_radeon_cubemap_20050227.diff (87.43 KB, patch)
2005-02-27 10:13 UTC, Andreas Stenglein
Details | Splinter Review
mesa_radeon_cubemap_20050228.diff (86.34 KB, patch)
2005-02-27 16:56 UTC, Roland Scheidegger
Details | Splinter Review
mesa_radeon_cubemap_20050605_3.diff.txt (61.17 KB, patch)
2005-06-05 12:05 UTC, Andreas Stenglein
Details | Splinter Review
mesa_radeon_cubemap_3tmu_20050903.diff.txt (85.16 KB, patch)
2005-09-03 12:51 UTC, Andreas Stenglein
Details | Splinter Review
mesa_radeon_cubemap_3tmu_20051008.diff.txt (76.29 KB, patch)
2005-10-08 09:46 UTC, Andreas Stenglein
Details | Splinter Review
new cube map patch (17.94 KB, patch)
2005-10-13 16:21 UTC, Roland Scheidegger
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Stenglein 2005-01-08 16:44:44 UTC
Add support for Cubemaps.
Comment 1 Andreas Stenglein 2005-01-08 16:46:57 UTC
Created attachment 1643 [details] [review]

Patch for radeon kernelmodule.
Comment 2 Andreas Stenglein 2005-01-08 16:54:34 UTC
Created attachment 1644 [details] [review]

experimental support for GL_ARB_texture_cube_map for radeon mesa driver.

+ cubemap demo works
+ http://frustum.org/3d/index.php?demo=8 works

- mipmap is broken/omitted
- texgen is a tcl fallback
- TexCoord3 is a vfmt fallback
- contains lots dead code
Comment 3 Roland Scheidegger 2005-02-10 14:06:36 UTC
I have applied the drm part to cvs (together with a texture micro tiling so they
can have the same drm minor number), together with the corresponding sanity code
pieces. I'm afraid, the rest is a bit too much for me to review/commit,
especially since I don't have too much time testing on r100. It would definitely
be nice to have though.
Comment 4 Andreas Stenglein 2005-02-27 10:13:58 UTC
Created attachment 1981 [details] [review]

patch against current mesa cvs.
unfortunately textures are broken, might be some interaction with the
texture-tiling patches. I might check that (much) later...

thanks for committing the drm part.
Comment 5 Roland Scheidegger 2005-02-27 16:56:36 UTC
Created attachment 1986 [details] [review]

There was indeed some interaction with tiling, exactly the same as was with
r200. The fixed BLIT_WIDTH y coord hack won't work. New fix, very quick testing
shows the inner sphere is correct, but the outer box is completely wrong,
unless sw tcl is used.
btw I'm not sure why cube maps would be limited to 512x512, though if there
were bugs with larger maps before, this was likely because of the same y coord
hack (which could cause the y coord to exceed the limit of the blitter, the
r200 driver had a workaround for that, though this is now gone with tiling
since it's no longer needed).
Comment 6 Andreas Stenglein 2005-03-20 05:30:51 UTC
ut2003_demo shows at least two problems with this patch:
- missing textures (citadel and antalus ground texture)
- z fighting in citadel "danger balls", maybe because of tcl/texgen fallback
Comment 7 Andreas Stenglein 2005-06-05 12:05:01 UTC
Created attachment 2830 [details] [review]

patch against current Mesa CVS HEAD
Comment 8 Andreas Stenglein 2005-06-12 12:23:16 UTC
Created attachment 2881 [details]

cubemap demo works, even if using new packets and maos_arrays.
projtex (still) works.
ut2003_demo antalus looks ok, at least better than before ;)
ut2003_demo citadel looks ok in sw-tnl mode only.

I don't know if the change is a real fix or only partially working:
ut2003_demo seems to send 3 texcoords when 2d texturing and so a 0 was written
to the q-coord.
Could this (submitting 3 texcoords) be the trigger for a tcl-fallback in the
radeon driver?

Is ctx->Texture.Unit[x]._ReallyEnabled up to date when radeonSetVertexFormat()
is called ?
Comment 9 Andreas Stenglein 2005-06-21 05:51:07 UTC
Created attachment 2935 [details] [review]

with this patch it is also possible to use the 3rd TMU when configured with
driconf. (default: use only 2 TMUs)

ut2003_demo citadel looks now ok with hw-tcl.
Unfortunately sometimes false textures are being used.
Comment 10 Andreas Stenglein 2005-09-03 12:51:11 UTC
Created attachment 3164 [details] [review]
Comment 11 Roland Scheidegger 2005-09-19 15:22:47 UTC
(In reply to comment #10)
> mesa_radeon_cubemap_3tmu_20050903.diff.txt
Just a sidenote, ut2k3 emits 3 coords because it uses projective texturing (for
instance antalus map tree shadows), it will simply use the texture matrix to
swap r and q coords (saves some vertex size that way). Thus you can't simply
only submit 2 coords in that case, the code is quite broken I think wrt emitting
tex coords in that area. I'm not quite sure how the coord selection works, on
r200 there is an explicit selection if you want to use the 3rd or 4th texture
coordinate for the texture AGU, which isn't present on r100 it seems. I'd
suspect it just always uses coord number 3, and unlike the r200, it looks like
you can't even submit all 4 coords, which makes this probably hard to work for
all cases (actually, impossible for hw tcl). Maybe if an app uses 3 coords for a
2d texture, just assume it will later use the texture matrix to calculate a q
coord. The texture matrix would probably need some adjustments to take this into
account (e.g. 3rd and 4th line need to be swapped if my math is correct, so that
the final q coord output is the 3rd coord. Actually, I think the current code is
broken when 4 coords are supplied too, since when you submit the 4th coord as
the 3rd, you'd need to swap columns 3 and 4 of texmat I think, followed by
swapping lines 3 and 4 to get the 4th coord out as the 3rd - not doing any
swapping at all will only work for "simple" matrices.
There are more problems with texmat, as far as I can tell the argument order is
reversed when doing the _math_matrix_mul_matrix in update_texturematrix (this
was fixed in r200, should be the same in radeon).
I think the swapping needed for texture matrix is probably the reason that q
coord texgen is not supported currently.
Comment 12 Andreas Stenglein 2005-10-08 09:46:14 UTC
Created attachment 3515 [details] [review]

here is another update, I changed the emit code in radeon_swtcl.d a bit to emit
the q-coord always if more than 2 texture-coords are available.
Since Roland added texgen for q-coord, cubemap demo also works with hw-tcl.
Unfortunately ut2003_demo looks better with tcl_mode=0, especially the
reflections on water.
Comment 13 Roland Scheidegger 2005-10-13 07:43:13 UTC
(In reply to comment #12)
> Created an attachment (id=3515) [edit]
> mesa_radeon_cubemap_3tmu_20051008.diff.txt
> here is another update, I changed the emit code in radeon_swtcl.d a bit to emit
> the q-coord always if more than 2 texture-coords are available.
I've commited the 3tmu part of it (with some changes).
As for cube maps, I don't think you can make mipmaps work. ATI's windows driver
does not expose mip/aniso filtering for 3d and cube maps according to dx caps
viewer. Don't know if this is a chip bug or rather a limitation (in the first
case it could potentially work with rv100/rv200, I've got a r100).
I think though it would be easy to prevent the mipmaps from being uploaded and
wasting texture memory (e.g. skip the driCalculateTextureFirstLastLevel
calculation in radeonSetTexImages).

> Since Roland added texgen for q-coord, cubemap demo also works with hw-tcl.
> Unfortunately ut2003_demo looks better with tcl_mode=0, especially the
> reflections on water.
Is something else apart from the water wrong? I've never had much luck with the
water reflections (texgen, if it worked before that would have been because of a
tcl fallback), the r200 couldn't handle it neither (both dri driver and fglrx).
It should be noted the same reflections with ut2k4 work just fine (with r200,
dri driver) so ut2k3 is probably doing something strange there.
Some errors in ut2k3 are also because the game needs 4 texture units sometimes
(for instance the quad damage, should look the same though with sw tcl).
Comment 14 Roland Scheidegger 2005-10-13 16:15:09 UTC
I've looked at the cube map part and some things don't quite work well. In
particular, 3 tmus and cube maps don't mix too well. Apparently, we're hitting
some hardware limitations there. For instance, if you run ut2k3 with 3 tmus, it
will look very wrong, and after that you're stuck with completely broken mipmaps
until you reboot! I've hunted this down, it's because the
TXFORMAT_CUBIC_MAP_ENABLE bit is still set, and if this unit is not enabled, it
will never get unset - this breaks mipmapping on either unit 0 or 1 (or both,
dunno), despite that the unit isn't actually enabled. That could obviously be
fixed, but I'd bet it doesn't work if the unit is enabled neither...
I'm wondering if the 3tmu patch was actually correct, can the radeon do
trilinear filtering simultaneously on all units? And if not, on which units can
it do filtering involving mipmaps simultaneously? And what about trilinear on
some units + cube mapping on others?
Comment 15 Roland Scheidegger 2005-10-13 16:21:27 UTC
Created attachment 3556 [details] [review]
new cube map patch

newer version of the patch, I've dropped all the non-working vtxfmt changes for
now. maos_arrays and maos_verts path could need some adjustments I think
(potentially lots of unnecessary matrix uploads when the texture target is a
cube map). And apparently something needs to be done about the interaction with
other tex units / mipmapping...
Comment 16 Roland Scheidegger 2005-10-15 16:55:18 UTC
commited to cvs. I wasn't sure if the cubic_map_enable bit on unit 2 MUST be
unset if the unit is disabled on other than original r100 chips (looks like a
chip bug to me), but the workaround is probably not really degrading
performance. No vtxfmt code was commited, too many "this doesn't work
correctly...". I think as a first step it would be useful to get "standard"
vtxfmt working without the fancy codegen. That's true for r200 too, btw - while
the code there is indeed simpler (no texture coord swapping hacks needed) and
already handles (multi)texcoord3x, it doesn't handle texturing with projected
coords neither.
I'm not sure optimizing the one-by-one vertex emit path is worth it though, apps
interested in performance will use something else (drawArrays for instance) anyway.
Comment 17 Andreas Stenglein 2005-10-21 11:50:44 UTC
Thanks for finishing this!
Comment 18 Erik Andren 2006-05-10 06:26:18 UTC
Roland, ok to close this one?
Comment 19 Roland Scheidegger 2006-05-10 09:20:10 UTC
(In reply to comment #18)
> Roland, ok to close this one?
Yes, that's ok. vtxfmt has other fallbacks too and I'm not going to touch it
just for that - noone is interested in immediate mode performance anyway.
Comment 20 ajax at nwnk dot net 2009-08-24 12:22:58 UTC
Mass version move, cvs -> git