Andreas Stenglein wrote:
I tried to get the 3rd TMU working on radeon, and with this patch it works at least without hw-TCL for multiarb.c from Mesa/demos. (RADEON_TCL_FORCE_DISABLE=1)
With hw-TCL the 3rd texture is visible, but isnt rotating.
The patch also includes some code for the kernelmodule for cube-textures on radeon, and some comments where I dont know what to do. You can switch off the 3rd TMU with export RADEON_NO_3RD_TMU=1
It would be nice if someone with knowledge about TCL could have a look at it.
Which programs/demos/games could/should be tested as they make use of the 3rd texture unit?
As another data point, I have attached my very old patch to enable the 3rd TMU on Radeon. IIRC, it worked w/HW TCL, vtxfmt, & codegen. It is now quite outdated. There were a couple of reasons I did not commit any of this.
1. A lot of it (i.e., calculate_max_texture_levels) would be superseded by the texmem branch (which has now been merged to the trunk).
2. Enabling the 3rd TMU can drastically reduce the maximum available texture size on some memory configurations. This is even more significant on the R200 which has 6 TMUs.
3. There are some problems with some fast-pathing in the vtxfmt code. The code assumes that the allowable range for 'target' (see radeon_vtxfmt_c.c, line 542) is a power of two. If an app calls glMultiTexCoord2fv with a target of 3 (assuming the mask value is changed from 1 to 3), the driver will explode.
4. A similar problem to #3 exists with the codegen path. The fast paths selected in radeon_makeX86MultiTexCoord2fvARB (see radeon_vtxfmt_x86.c, line 354) and friends may not be expandable to the 3 (or 6 for R200) TMU cases.
At worst a test can be used in this code. If there's no sane way to avoid it, we have to do it & that's that.
The first issue is a non-issue now. My original intention, before discovering the second issue, was to "merge" the patch after merging the texmem branch. It turns out that it took much longer to make the branch mergable than initiallly anticipated.
I think we're going to have to wrestle with the second issue at some point. When the next round of texmem work is complete, we won't be able to predict apriori how big the largest texture set can be. Even now, I find it unlikely that on an R200 there would be 6 2048x2048 cube maps (the worst case) bound at any time. This renders the current calculation somewhat bogus to begin with. It seems that the existing closed-source drivers just advertise the hardware maximum in all cases.
If the hardware maximum is advertised, then an app could bind a set of textures that can't fit in memory at once. The driver would then have to fallback to software. I believe the open-source drivers used to function this way, but doing so caused problems with Quake2. I'm really not sure what the right sollution is.
Correct - and in fact they still should function this way if the situation somehow arises that the bound textures can't all be uploaded.
Keith
------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
