So is ATI's aniso method rip-mapping or not?

noko said:
Can the LOD be adjusted with the Radeon8500?

Sure it can, but the drivers slider for LOD has been broken for quite some time. I was coding a little yesterday and was trying to reduce some shimmering when bumpmapping (due to normal vectors not being exactly length 1 after filtering) by adjusting the LOD a little. I noticed that LOD wouldn't want to work on texture 0 when doing multitexturing. When doing single texturing it worked just fine, and when doing multitexturing it would work perfectly fine on texture 1 too, but not texture 0. I think this and the broken LOD slider may be related. I'll mail ATi about it.
 
Humus
Sure it can, but the drivers slider for LOD has been broken for quite some time.

So if a game has a LOD adjustment you can adjust LOD, right? So in SeriousSam SE then the LOD can be change, is that true? That is if you know. Thanks for the reply Humus.

This isn't right as far as I see it, I adjust LOD on my GF3 to get rid of texture aliasing in games. Looks like I will think twice before going ATI route if this basic driver feature is non-funtional. Reverend has definitely educated me on what to look for in texture aliasing and I don't think I could go back to a bad rendering card that has servere texture aliasing. Especially when it is preventable by a simple adjustment.
 
DaveBaumann said:
Galilee,

An ‘algorithmic choice’ does not mean it’s a driver thing – it an algorithmic hardware design choice. All 3D chips are, is a bunch of silicon that’s very fast at working out specific mathematical algorithms.

Yes I know, but the designer do algorithm coices both in the hardware (choice of topology) and in the software. Even though ATI chose to disable trilinear when doing anisotrophic filtering, does not automatically mean it's a hardware limitation. It probably is, but not necessarily....

....
....
I think ;)
 
noko said:
Humus
Sure it can, but the drivers slider for LOD has been broken for quite some time.

So if a game has a LOD adjustment you can adjust LOD, right? So in SeriousSam SE then the LOD can be change, is that true?

Yes, unless the app is affected by the same bug as I experienced.
 
Galilee said:
DaveBaumann said:
Galilee,

An ‘algorithmic choice’ does not mean it’s a driver thing – it an algorithmic hardware design choice. All 3D chips are, is a bunch of silicon that’s very fast at working out specific mathematical algorithms.

Yes I know, but the designer do algorithm coices both in the hardware (choice of topology) and in the software. Even though ATI chose to disable trilinear when doing anisotrophic filtering, does not automatically mean it's a hardware limitation. It probably is, but not necessarily....

....
....
I think ;)

They've confirmed that it's a hardware restriction on a couple of occasions.
 
noko said:
Maybe the R300 8 pipes will address this issue with two pipes, each pipe is rendering from one mip-map blending the multiple bilinear filtered textures in the frame buffer, hence a very fast hardware anisotropic filtered method using trilinear filtered samples. Who knows???

Trilinear wouldnt fix what people notice most with the 8500s aniso though.

I turned on the coloured mip maps in q3 today and many of the apparent mip boundries were completely independant of the colours. I assume this is where the 8500 changes the filter window and this is more noticable than the mip boundries (which are generally too far out at 16x to see).
 
noko said:
Maybe the R300 8 pipes will address this issue with two pipes, each pipe is rendering from one mip-map blending the multiple bilinear filtered textures in the frame buffer, hence a very fast hardware anisotropic filtered method using trilinear filtered samples. Who knows???

Sure, but you're still using two pipes. Even if R300 does have 8 pipes, then using 2 for each pixel will halve performance with Anisotropic filtering. The extra pipes will make it faster compared to today's cards, but the performance hit will be 50%, something we don't want.
 
Mintmaster,

Wouldn't that only be the case if the 8 pipes was totally being used and not idle that a 50% performance hit would happen? Yet in most cases wouldn't memory bandwidth limit texture rendering if each pipe was doing a separate pixel meaning many of the 8 pipes would be stalled. I really don't know but I doubt in most cases that this would incur a 50% performance hit unless you are doing a very limited test or condition. Plus this is only an idea which is probably not represented by any real hardware anyways.
 
If R300 implements multisampling, then yes, the performance hit could be devastating.

MS AA doesn't hit bandwidth as much as SS AA... so the pipelines should keep busy with it at least the majority of the time.
 
Back
Top