Trotz der Fortschritte haben moderne GPUs immer noch feste Rasterizer. Sehr anpassbar, mit programmierbaren Shadern, aber dennoch nicht vollständig programmierbar.

Warum das?

Warum können GPUs nicht einfach massiv parallele Geräte mit universellen Recheneinheiten sein, bei denen Rasterizer nur eine vom Benutzer bereitgestellte Software für dieses Gerät ist?

Ist die Leistung einer Hardware mit festen Funktionen so günstig, dass ein solcher Ansatz nicht durchführbar ist?

Kurz gesagt, Leistungsgründe sind, warum sie nicht programmierbar sind.

Geschichte und Markt

In der Vergangenheit gab es separate Kerne für Vertex- und Fragment-Prozessoren, um aufgeblähte FPU-Designs zu vermeiden. Es gab einige mathematische Operationen, die Sie beispielsweise nur in Fragment-Shader-Code ausführen konnten (da sie meist nur für Fragment-Shader relevant waren). Dies würde zu schwerwiegenden Hardware-Engpässen bei Anwendungen führen, bei denen das Potenzial der einzelnen Kerntypen nicht ausgeschöpft wird.

Als programmierbare Shader immer beliebter wurden, wurden universelle Einheiten eingeführt. Immer mehr Stufen der Grafik-Pipeline wurden in Hardware implementiert, um die Skalierung zu erleichtern. In dieser Zeit wurde auch GPGPU immer beliebter, sodass die Anbieter einige dieser Funktionen einbauen mussten. Es bleibt jedoch zu beachten, dass der Großteil der Einnahmen aus GPUs immer noch Videospiele waren, sodass dies die Leistung nicht beeinträchtigen konnte.

Schließlich entschied sich ein großer Player, Intel, in programmierbare Rasterizer mit ihrer Larrabee-Architektur zu investieren . Dieses Projekt sollte wegweisend sein, aber die Leistung war anscheinend weniger als gewünscht . Es wurde heruntergefahren und Teile davon wurden für Xeon Phi-Prozessoren geborgen. Es ist jedoch erwähnenswert, dass die anderen Anbieter dies nicht implementiert haben.

Versuche an Software Rasterizers

Es gab einige Versuche zur Rasterung durch Software, aber alle scheinen Probleme mit der Leistung zu haben.

Eine bemerkenswerte Anstrengung war ein Versuch von Nvidia im Jahr 2011 in diesem Papier . Dies wurde kurz vor der Kündigung von Larrabee veröffentlicht, daher ist es sehr wahrscheinlich, dass dies eine Reaktion darauf war. Unabhängig davon gibt es einige Leistungsangaben, von denen die meisten eine um ein Vielfaches langsamere Leistung als Hardware-Rasterizer aufweisen.

Technische Probleme mit der Software-Rasterisierung

In der Nvidia-Veröffentlichung wurden viele Probleme angesprochen. Hier sind jedoch einige der wichtigsten Probleme mit Software-Rastern:

Große Probleme

• Interpolation: Die Hardware-Implementierung generiert Interpolationsgleichungen in spezialisierter Hardware. Dies ist für den Software-Renderer langsam, da dies im Fragment-Shader durchgeführt werden musste.

• Anti-Aliasing: Es gab auch Leistungsprobleme beim Anti-Aliasing (speziell beim Speicher). Informationen zu den Subpixel-Samples müssen auf dem Chip gespeichert werden, was nicht ausreicht, um dies zu speichern. Julien Guertault wies darauf hin, dass der Textur-Cache / Cache mit Software möglicherweise langsamer ist. MSAA hat hier sicherlich Probleme, da es den Cache (die Nicht-Textur-Caches) überläuft und außerhalb des Chips in den Speicher gelangt. Rasterizer komprimieren Daten, die in diesem Speicher gespeichert sind, was hier auch für die Leistung hilfreich ist.

• Stromverbrauch: Simon F wies darauf hin, dass der Stromverbrauch geringer sein würde. In dem Artikel wurde erwähnt, dass benutzerdefinierte ALUs in Rastern enthalten sind (was den Stromverbrauch reduzieren würde), und dies wäre sinnvoll, da Fragment- und Vertex-Verarbeitungseinheiten in der Vergangenheit benutzerdefinierte Befehlssätze verwendeten (also wahrscheinlich auch benutzerdefinierte ALUs). Dies wäre sicherlich ein Engpass in vielen Systemen (z. B. mobil), obwohl dies Auswirkungen über die Leistung hinaus hat.

Zusammenfassung

TL; DR: Es gibt zu viele Ineffizienzen, die beim Rendern von Software nicht behoben werden können, und diese Dinge summieren sich. Es gibt auch viele größere Einschränkungen, insbesondere wenn Sie sich mit VRAM-Bandbreite, Synchronisationsproblemen und zusätzlichen Berechnungen befassen.