Texturatlas vs. Array-Textur: Wie unterschiedlich werden sie von CPU und GPU behandelt und wie wirkt sich das auf die Leistung aus?

Unity 5.4 (derzeit in der Beta) wird eine mit Spannung erwartete Funktion (seit 2013) enthalten, nämlich Array-Texturen - genauso vergeblich wie OpenGLs ArrayTexture . Nachdem ich etwas über Arrays-Texturen und Textur-Atlanten gelesen habe, kann ich die technischen Unterschiede bei der Verwendung durch CPUs und GPUs immer noch nicht ganz verstehen.

Um genauer zu sein, möchte ich um eine Erklärung zu den Hauptunterschieden bitten, wie Texturatlas und Texturarrays von CPU und GPU behandelt werden und vor allem, wie sich solche Unterschiede auf die Leistung und die Speicherbehandlung auswirken können (z wie Textur-Arrays leistungsfähiger sein können als Textur-Atlanten usw.).

Wenn technische Details zur Implementierung von Unity aufgrund der unglücklichen geschlossenen Ressourcen fehlen, würde ich mich über eine Antwort bezüglich OpenGL.s ArrayTexture freuen.

textures rendering texture-atlas

— ASteer
quelle

Ich bin nicht überrascht, dass Sie keinen technischen Vergleich gefunden haben, da beide implementierungsabhängig sind (mehr für Arrays).

— Wondra

Es wird Ihnen schwer fallen, Informationen darüber zu erhalten, wie die Interna der Unity-Engine funktionieren, da es sich um eine geschlossene Blackbox handelt. Das einzige, was Sie tun können, ist, jeden Fall zu profilieren und sich einen Vergleich der CPU- und GPU-Nutzung zu verschaffen. Um zu verstehen, wie es funktioniert, müsste ein Unity-Techniker eingreifen oder sein Quellcode geöffnet oder durchgesickert sein.

— Jgallant

@ Jon Fair genug, aber eigentlich war ich mehr an einer motorunabhängigen Antwort interessiert. Wenn es so unterschiedlich ist, kann ich die Frage aktualisieren, um beispielsweise über OpenGLs ArrayTexture

— ASteer

Wie in den obigen Kommentaren erwähnt, hängt die Leistung von der Implementierung, Ihrer speziellen Hardware und dem, was Sie mit den Texturen versuchen, ab. Die einzig verlässliche Antwort besteht darin, jede Alternative zu profilieren.

Es gibt jedoch einige Unterschiede in Bezug auf die Verwendung der einzelnen Optionen, die konsistent gelten:

Ein großer Unterschied besteht darin, dass bei Array-Texturen jede Textur separat behandelt wird, um beispielsweise Texturkoordinaten zu verpacken oder Mipmapping durchzuführen.

Dies vermeidet häufige Probleme mit Texturatlanten, bei denen zwischen benachbarten Texturmustern eine Polsterung hinzugefügt werden muss, um zu verhindern, dass Proben an ihren Rändern zusammenbluten, insbesondere in tieferen Mip-Levels.

Dies bedeutet auch, dass Sie, wenn Sie möchten, dass Ihre Texturen gekachelt werden, die Textur-Sampling-Hardware verwenden können, um dies genau wie bei einer Vanille-Textur zu tun. Bei Atlanten müssen wir normalerweise die Kachelberechnung in unserem Fragment-Shader durchführen, da der Sampler nur Texturkoordinaten über den gesamten Atlas umwickelt / spiegelt / klemmt / umrandet, nicht einzelne Kacheln darin.

Die Haupteinschränkung bei Array-Texturen besteht darin, dass alle ihre Texturen die gleiche Auflösung und Anzahl von Mip-Levels haben müssen. Wenn Sie versuchen, Texturen mit sehr unterschiedlichen Auflösungsanforderungen zu stapeln (z. B. Speichern von Geländekacheln, deren LoD mit der Entfernung in einer virtuellen Textur abnimmt ), möchten Sie möglicherweise stattdessen die Flexibilität eines Atlas.

— DMGregory
quelle

Danke, genau danach habe ich gesucht. Ich meine, keine Antwort darauf, was schneller und weniger speicherintensiv ist - da diese natürlich von der Implementierung abhängen. Trotzdem war ich mir sicher, dass einige Hinweise auf die Funktionsweise jedes Einzelfalls nützlich sein könnten, um ihre üblichen Best- und Worst-Fit-Szenarien zu verstehen. Ihre Antwort hat mir dabei tatsächlich geholfen.

— ASteer

Ein weiterer Nachteil von Array-Texturen: Sie sind begrenzt durch GL_MAX_ARRAY_TEXTURE_LAYERS. Auf meiner semi-modernen GPU ist dies 2048. Wenn Sie also Tonnen winziger Texturen möchten, ist diese Grenze möglicherweise zu niedrig.

— JWD