[GPU] Optimale Cache-Nutzung bei Texturzugriffen

[Schrompf]

Moin,

ich habe ein Shader-Programm, das pro Pixel aus x verschiedenen Rechteck-Bereichen ein- und derselben Textur lesen muss. Mit x == 8 oder höher. Die Einzel-Zugriffe sind relativ zu den Nachbarpixeln schön kontinuierlich, aber die Texturzugriffe innerhalb einer Ausführung des Shaderprogramms sind quer über die ganze Textur gestreut.

Meine Frage nun: könnte es sich lohnen, die selbe Textur an x Sampler Stages zu binden und jeden Texturzugriff über seine spezifische Sampler Stage durchzuführen? Falls jede Stage ihren eigenen Cache hat, könnte man damit die Cache-Lokalität drastisch verbessern. Die Whitepaper zu den aktuellen GPU-Architekturen lesen sich aber so, als hätte ein Threadblock nur einen einzigen L1-Cache, wodurch das ganze Manöver eh für die Katz wäre.

Ausprobieren kann ich das Ganze leider nicht so einfach, weil ich hier auf meinem Rechner immer CPU-limitiert bin. Ich wäre an euren Gedanken und Ideen interessiert, ob und wie ich das auch auf kleineren oder Laptop-GPUs optimieren könnte.

[dot]

Zumindest bei NVIDIA hast du einen Texture Cache pro Multiprozessor. Ich würde mal vermuten, dass es keinen Unterschied machen wird, insbesondere da du mit x = 8 und 4 Byte pro Pixel wunderbar in eine 32 Byte Cache Line passt (Kompression mal außen vor)...

Aber who knows...es wäre wohl auf jeden Fall ein interessantes Experiment... ;)

Wer weiß, wie das Ganze bei Intel oder gar auf mobilen GPUs ausschaut, möglicherweise könnte es dort was bringen. NVIDIA Flaggschiff Desktop GPUs sind vielleicht nicht die Art von Architektur, auf der man seine Überlegungen aufbauen sollte, wenn man für eigentlich die kleinen Geschwister optimieren will, die potentiell grundlegend anders arbeiten...

Edit: Ach, das x = 8 bezog sich auf die Anzahl der Rechtecke; dachte du holst 8 Samples pro Rechteck...wie genau samplest du denn innerhalb dieser Rechtecke?

[Schrompf]

Es ist eine Art Texturatlas, bestehend aus 8+ Quadraten von jeweils 200 bis 400 Pixeln Größe auf einer gemeinsamen Textur. Und im FragmentShader lese ich einen Texel aus jedem der 8+ Quadrate entlang der projezierten Primitive. Ich wende quasi 8+ separate ShadowMaps an, die Texturzugriffe pro Quadrat sind also schön kontinuierlich.

[dot]

Ok, ich würde mal vermuten, dass es nix bringen wird; aber sicher weiß man es natürlich immer erst, wenn man es ausprobiert hat... :P

[B.G.Michi]

Sowas halte ich für riskant. Ich bin sicher kein Experte aber da klingt schon ziemlich Hersteller- und Architekturspezifisch. Angenommen du holst 10% auf einer speziellen GPU raus, sobald du auf die nächste Architektur schaust oder der Hersteller im Treiber was rumspielt, fliegt dir die Optimierung um die Ohren und du bist bei -20%...

[Alexander Kornrumpf]

Kannst du die Textur so speichern dass das Zugriffsmuster kontinuierlich wird?

[Schrompf]

Nein. Wie gesagt, es sind ein Rudel Shadow Maps, die ich für die Nachverarbeitung auf einem Texturatlas gesammelt habe. Die kann man nicht einfach so interleaven.

Aber ich hätte alle auf einzelnen Texturen lassen können. Wär ne ziemliche Verschwendung gewesen, für jedes einzelne Licht die Maximalgröße zu reservieren, aber dafür hat man dann ein hübsches Array an Texturen. Und solange die Sampler reichen, kann man aus denen dann immer hübsch kontinuierlich cache-freundlich lesen.

[dot]

Kannst du die Textur so speichern dass das Zugriffsmuster kontinuierlich wird?

Das hätte vermutlich sogar negative Auswirkungen auf die Performance, da Texturen auf der Grafikkarte bereits so im Speicher ausgelegt werden, dass lokal benachbarte Texel auch an nicht weit voneinander entfernten Speicheradressen liegen (http://en.wikipedia.org/wiki/Z-order_curve). ;)

[Krishty]

Sowas halte ich für riskant. Ich bin sicher kein Experte aber da klingt schon ziemlich Hersteller- und Architekturspezifisch. Angenommen du holst 10% auf einer speziellen GPU raus, sobald du auf die nächste Architektur schaust oder der Hersteller im Treiber was rumspielt, fliegt dir die Optimierung um die Ohren und du bist bei -20%...

Die nächste Architektur bringt aber dafür 50 % mehr Rechenleistung, da gleicht es sich dann aus.

Im Kern ist es aber richtig: Man sollte immer auf AMD und Nvidia parallel testen; sonst ist es irgendwann auf der einen Architektur zehn Mal langsamer. Kommentar aus meinem FFT-Glare-Quelltext:

  has proven to be slightly faster (5 %) on AMD GPUs, it also takes thrice the time to compile and performs 13.8 % worse on Nvidia GPUs.