Füllrate: Unterschied zwischen den Versionen
K |
Wilson (Diskussion | Beiträge) K |
||
| Zeile 16: | Zeile 16: | ||
Wenn viele Rendering Passes, die recht komplex sind, notwendig sind, so kann man auch im ersten Rendering Pass die gesamte Szene nur in den Tiefenbuffer zeichnen (diese Technik wird beispielsweise in Quake 3 verwendet). Bei den nächsten Passes werden dadurch alle nicht sichtbaren Fragmente sofort durch den Tiefentest verworfen. | Wenn viele Rendering Passes, die recht komplex sind, notwendig sind, so kann man auch im ersten Rendering Pass die gesamte Szene nur in den Tiefenbuffer zeichnen (diese Technik wird beispielsweise in Quake 3 verwendet). Bei den nächsten Passes werden dadurch alle nicht sichtbaren Fragmente sofort durch den Tiefentest verworfen. | ||
| − | Einige Dinge, die ''' | + | Einige Dinge, die '''keinen''' oder nur wenig Einfluss auf die Füllrate nehmen: |
*[[LOD|Level of Detail]] | *[[LOD|Level of Detail]] | ||
*[[Vertex]] [[Shader]] | *[[Vertex]] [[Shader]] | ||
*[[Frustum Culling]] | *[[Frustum Culling]] | ||
*Texturgröße, sofern genug Videospeicher vorhanden ist und [[MipMaps]] verwendet wird. | *Texturgröße, sofern genug Videospeicher vorhanden ist und [[MipMaps]] verwendet wird. | ||
Version vom 17. August 2008, 20:48 Uhr
Die Füllrate einer Grafikkarte beschreibt die Fragmente, die je Sekunde berechnet werden können. Da der Aufwand für diese Berechnungen jedoch sehr unterschiedlich sein kann, sind diese Angaben mit Vorsicht zu geniesen, denn meistens werden die Angaben für sehr primitive Rendereinstellungen gemacht (untexturiert, kein Fragment Shader, ...).
Der Begriff Füllratengebunden bezieht sich darauf, dass die Anzahl der Fragmente, die berechnet werden können, im Normalfall der ausschlaggebende Punkt für die Framerate ist. Dies ist natürlich nicht auf allen Grafikkarten gleich, jedoch sind die Verhältnisse zwischen Vertexanzahl und Fragmentanzahl, die je Sekunde gezeichnet werden können, meistens doch recht ähnlich.
Um zu testen, ob eine Applikation füllratengebunden ist, reicht es aus, die Applikation mit niedrigerer Auflösung laufen zu lassen und zu schauen, ob sich an der Geschwindigkeit Unterschiede bemerkbar machen.
Einige Möglichkeiten, um die Füllrate zu schonen (und somit füllratengebundene Applikationen zu beschleunigen), sind:
- Auflösung verringern
- Objekte von vorne nach hinten zeichnen, um Gebrauch vom Tiefentest zu machen, welcher Fragmente recht früh verwirft
- Gebrauch vom Alphatest machen, um Fragmente mit einem sehr niedrigem Alpha-Wert sehr früh zu verwerfen
- Die Rendereinstellungen je Fragment herabsetzen, also weniger Texturen, kürzerer Fragment Shader, ...
- Die Szene weniger oft rendern (weniger Rendering Passes)
- Occlusion Culling
- Mipmapping bei Texturen, um die Lokalität der Texturzugriffe zu erhöhen
- Bilineare Filterung (anstatt linear, trilinear oder anisotropes Filtern)
Wenn viele Rendering Passes, die recht komplex sind, notwendig sind, so kann man auch im ersten Rendering Pass die gesamte Szene nur in den Tiefenbuffer zeichnen (diese Technik wird beispielsweise in Quake 3 verwendet). Bei den nächsten Passes werden dadurch alle nicht sichtbaren Fragmente sofort durch den Tiefentest verworfen.
Einige Dinge, die keinen oder nur wenig Einfluss auf die Füllrate nehmen:
- Level of Detail
- Vertex Shader
- Frustum Culling
- Texturgröße, sofern genug Videospeicher vorhanden ist und MipMaps verwendet wird.
