Ian Romanick wrote:
There's a number of test routines in the src/math/m_debug_*.c files. I think that would be the place to add more if needed.Felix Kühling wrote:On Tue, 28 Jan 2003 13:10:41 -0800 Ian Romanick <[EMAIL PROTECTED]> wrote:Felix Kühling wrote:The patch moves the load operations back to the front of the loop as in the G3TN_norm_w_lengths case.
Good catch. It looks like this went into the Mesa tree back in October of 2001...over a year ago! It looks like Andres Lewycky gave Brian some bad patches. :(
Yeah, but until November 2002 (DRI trunk) there was a comment in 3dnow.c that the 3dnow-normal code is broken and it was not used.D'oh!I realize that AMD recommends reading memory backwards, but would a quick-fix be to just use the 3Dnow! prefetch instructions?
The prefetch instructions used are and must be 3DNow instructions. On Intel Prefetch was introduced with the SSE extension on the PentiumIII. They're not available on older Athlons and K6's. Anyway, all that prefetching looks odd to me. In the first transform loop in _mesa_3dnow_transform_normalize_normals memory is prefetched which is never read but only written. This is obviously useless. Then in the normalize loop the memory which was written before is prefetched again. I think this is not necessary. The array is small enough to be still in the cache.
I believe that prefetchw tells the processor to warm up the cache line because it's going to be written soon. I think the prefetching in the first loop is probably correct. The prefetchw of (%eax) might need to be before the add. I'd have to benchmark it. I'm not sure if I have a 3dnow capable box around anymore. If I do, it will be an old K6-III. :)
I'll see if I can clean this up a bit. On the mesa-4-0-4 branch this code is disabled anyway, so there is not really a hurry to apply my stupid little patch. About this reading backward thing, where is that documented. I have an AMD Athlon optimization guide from February 2002 which doesn't mention it.
I've seen a reference posted to dri-devel a couple times. Here's a couple references the Dieter posted on 09-Jan-2003:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103548024914815&w=2
http://208.15.46.63/events/gdc2002.htm
I'm not sure if this applies to the K6 family or just to Athlons. I suspect it may only apply to Athlons, but we may have to test it.
Since these functions are globally exported, it might be worth it to write a quick test that calls the various _transform_normalize_normals functions to make sure that they all produces the same (or close enough) results.
And: _transform_normalize_normals_no_rot _transform_rescale_normals_no_rot _transform_rescale_normals _transform_normals_no_rot _transform_normals _normalize_normals _rescale_normals These should be tested too, while we're at it.Agreed. Brian: If such tests do get written, where should they live in the tree?
-Brian
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
