Are IHVs going to eventually get rid of trilinear filtering?

[K.I.L.E.R]

IHVs seem to be heading in that direction.

When I refer to trilinear filtering, I'm refering to TF being properly done and not in the pseudo state it is in on the X800 and NV30+.

 

[Xmas]

I don't think they will take it out of the hardware, since you need it at least as a fallback, and the same units are required for 3D textures. But it is possible that they will keep on not providing full TF all of the time via the drivers.

 

[Ostsol]

Perhaps filtering will eventually become programmable.

 

[arjan de lumens]

You can do full programmable filtering today, it's just an order of magnitude slower than fixed-function filtering. For partially programmable filtering, PS3.0 IIRC allows you to set the LOD level to use for a texture lookup, which can be used to implement brilinear filtering.

 

[vb]

First, Trilinear is not in hardware. when you ask for trilinear all (recent) cards are doing twice bilinear from next mip map levels.

IMHO trilinear is an old answer to a crude problem: mip-mapping. I think mip-mapping and filtering should be left to hardware/driver, and the app should only supply the base texture + filtering hints. By now IHV's should have come with a better answer to filtering than trilinear.

PS: And no, bilinear, in any sort of percent, is not the answer.

 

[GraphixViolence]

Re: Are IHVs going to eventually get rid of trilinear filter

When I refer to trilinear filtering, I'm refering to TF being properly done and not in the pseudo state it is in on the X800 and NV30+.

Trilinear filtering is just a variation on bilinear filtering designed to hide mipmap boundary artifacts by sampling from multiple mip levels per pixel. So these "pseudo states" you're talking about are still trilinear filtering as long as they accomplish this goal. The only difference between implementations is how efficiently they can accomplish it, and how well the artifacts are removed.

 

[Exxtreme]

Re: Are IHVs going to eventually get rid of trilinear filter

IHVs seem to be heading in that direction.

When I refer to trilinear filtering, I'm refering to TF being properly done and not in the pseudo state it is in on the X800 and NV30+.

True. I'm not buying high-end-hardware to get worse filter quality than on a GF3. I want the best image quality as possible. If it doesn't run fast enough, i can use the sliders in the driver panel to reduce the quality. But i want have the choice. I don't need the IHV for this. Hopefully the IHV's will give me a chance to disable the "optimisations" in future products.

 

[Dave Baumann]

A wieghted mipmap blend would probably be better than Trilinear.

 

[ERP]

The fundamental problem here is that dev's don't explicitly request the filtering that they want. Used selectively Aniso is very cheap on pretty much any hardware since NV20. A lot of textures just don't need it.

Because Dev's don't explicitly select filtering based on texture usage, IHV's have added overides to their the control panel so the features get used. This is basically a sledge hammer solution and it is always going to be expensive, so they have to find ways to limit the impact. Unfortunately that seems to mean lower quality filtering in general.

This is unfortunately a viscious circle, as a dev why should I spend the time setting the right filtering level when the user is just going to override it anyway?

 

[arjan de lumens]

A wieghted mipmap blend would probably be better than Trilinear.

Aren't they the same thing, or am I missing something important here

 

[Hellbinder]

I say screw mipmaps... Lets just have the base textures at full resolution on everything. 8)

 

[jvd]

I understand from reading the other thread that tri is ideal for most things but not all.

With that knoweldge I still don't have the whole picture.

Is bilinear the best for those other cases or is there something better for it ?

If there is something best for those cases that is no bilinear perhaps we should find that and move to it and have mix of that and tri for the best image quality.

Perhaps that new filtering / tri and bi for the cases where each is best suited.

Having used an x800pro i can't see an image diffrence over my 9700pro.
If ati and nvidia can adopt that then I don't see a problem with the mix.

However the lvl of quality from the nv3x version is not acceptable as while playing you can notice a diffrence.

 

[no_way]

Because Dev's don't explicitly select filtering based on texture usage, IHV's have added overides to their the control panel so the features get used.

Why not correct the problem from the side where its occuring, i.e educate developers and provide appropriate tools for them to fix those simple problems ?
If you are going to do an awfully clever algorithm to detect whether a certain texture needs trilinear, AF, bicubic filtering or certain kind of texture compression, or god forbid, it would be altogether smarter to replace the entire texture with a simple high-performing procedural shader it would be alot more efficient to do it on content generation side, than to try futz with stuff at runtime and second-guess the developers intentions.

 

[ERP]

Because Dev's don't explicitly select filtering based on texture usage, IHV's have added overides to their the control panel so the features get used.

Why not correct the problem from the side where its occuring, i.e educate developers and provide appropriate tools for them to fix those simple problems ?
If you are going to do an awfully clever algorithm to detect whether a certain texture needs trilinear, AF, bicubic filtering or certain kind of texture compression, or god forbid, it would be altogether smarter to replace the entire texture with a simple high-performing procedural shader it would be alot more efficient to do it on content generation side, than to try futz with stuff at runtime and second-guess the developers intentions.

Like I said it's a vicious circle, it takes a considerable amount of time and effort to sort through content and make appropriate quality decisions, because users simply override the settings anyway, why bother?

In console development we do it because we have a fixed platform and walking the quality/performance line is a focus of development.

In the PC space, it takes time for new hardware features to get used in software and IHV's want to expose it to users as soon as possible, but in this case that defeats devs using the feature....

I don't know that there is a solution at this point.

 

[Hyp-X]

I think mip-mapping and filtering should be left to hardware/driver, and the app should only supply the base texture + filtering hints.

I strongly disagree.
The driver will never guess what should the mipmaps look like when the texture contains custom data.
Even simple normal map mipmaps are non-trivial.

 

[vb]

I think mip-mapping and filtering should be left to hardware/driver, and the app should only supply the base texture + filtering hints.

I strongly disagree.
The driver will never guess what should the mipmaps look like when the texture contains custom data.
Even simple normal map mipmaps are non-trivial.

You can always ask for point sampling and/or supply textures in sets. but on "classic" textures the driver/hardware should be able to choose what is appropriate for the hardware implementation.

 

[Laa-Yosh]

Hyp-X: So no rest for you after the gold master?

Congratulations by the way!

 

[nutball]

I think mip-mapping and filtering should be left to hardware/driver, and the app should only supply the base texture + filtering hints.

I strongly disagree.
The driver will never guess what should the mipmaps look like when the texture contains custom data.
Even simple normal map mipmaps are non-trivial.

You can always ask for point sampling and/or supply textures in sets. but on "classic" textures the driver/hardware should be able to choose what is appropriate for the hardware implementation.

You could leave it to the driver. Or you could leave it to the app.

Or, you could leave it to the end-users. Or are they too stupid to know what they want?

 

[no_way]

Like I said it's a vicious circle, it takes a considerable amount of time and effort to sort through content and make appropriate quality decisions

Thats why i suggested that IHVs could deploy tools to help in this process if they really want to help so badly. The decision made at content generation side will be qualitatively better, because you have _context of intended usage available_ and human can assist in cases where the decisions are hard for software to make. I.e. : the texture is used as lightmap, ok, we dont compress it but we do use bilinear filtering.

In the PC space, it takes time for new hardware features to get used in software and IHV's want to expose it to users as soon as possible, but in this case that defeats devs using the feature....

Oh, in many cases im quite sure its not the end users they are so concerned about, its the benchmarkers.

 

[vb]

You could leave it to the driver. Or you could leave it to the app.

Or, you could leave it to the end-users. Or are they too stupid to know what they want?

Yeah, I can imagine next Serious Sam game advanced options

20th page

Light map generated around tree 578 from light 39h:

Filtering: Point/Bi/Tri
Aniso level 1/2/4/8/16
mip mapping on/off
Lod bias -7..........+7
Bi optimisations on/off
Tri optimisations on/off
aniso opt on/off

........

Light map generated around tree 578 from light 39e:

..........