Programmierbare Texturfilterung auf den ALUs

[boxleitnerb]

Manchmal liest man ja, dass die ALUs die Aufgaben der TMUs/TFUs übernehmen könnten, was dann auch programmierbar wäre. Welche Vor- und Nachteile hätte das tendenziell bzgl. Platzverbrauch auf dem Die, Performance und Verbrauch?

Man könnte dann per Treiber mehr Einfluss nehmen, z.B. das Problem von Nvidia mit negativem LOD und SGSSAA lösen statt auf eine zukünftige Hardware zu warten. Der Trend geht doch eh weg von Fixed Function Units, warum nicht auch bei den TMUs (oder gar ROPs?) ?

[Godmode]

Manchmal liest man ja, dass die ALUs die Aufgaben der TMUs/TFUs übernehmen könnten, was dann auch programmierbar wäre. Welche Vor- und Nachteile hätte das tendenziell bzgl. Platzverbrauch auf dem Die, Performance und Verbrauch?

Man könnte dann per Treiber mehr Einfluss nehmen, z.B. das Problem von Nvidia mit negativem LOD und SGSSAA lösen statt auf eine zukünftige Hardware zu warten. Der Trend geht doch eh weg von Fixed Function Units, warum nicht auch bei den TMUs (oder gar ROPs?) ?

Ich glaube das Problem ist, dass in Hardware gegossene Einheiten um einen Faktor schneller sind, als wenn das die ALUs machen. Aber irgendwann wird die Zeit sicher reif dafür sein. Es gab dazu schon mal einen Thread dazu, den ich aber nicht mehr finde.

[Coda]

Man bräuchte immer noch spezielle Instructions dafür (vor allem um die Line of Anisotropy auszurechnen), sonst ist es zu langsam. Außerdem ist ein Problem, dass die Anzahl der Samples stark schwankt, was die ALUs mit der hohen Branch-Granularität (mindestens 32 Pixel) nicht so sehr mögen.

Dazu kommt dass die Texture-Fetches dann nicht mehr Out-Of-Order laufen können. Man müsste sich da was anderes einfallen lassen.