Dlaczego dzisiaj miałbyś używać renderowania programowego zamiast renderowania sprzętowego?


13

Zakładam, że w przeciwieństwie do renderowania procesora lub oprogramowania?

Czy generalnie nie wszystkie obecne renderowanie byłoby oparte na GPU, skoro korzystasz z OpenGL lub Direct X?

Czy ktoś może podać mi jakieś informacje tutaj, nie może znaleźć żadnych odpowiednich odpowiedzi?

Odpowiedzi:


7

Jak już wyraźnie wiesz, czym jest rendering GPU ... pozwól, że odpowiem na to, o co pytasz.

Renderowanie sprzętowe tradycyjnie nosi znamiona bycia bardzo złożonym. Było to w dużej mierze spowodowane zaprojektowaniem interfejsów programowania aplikacji (API), które nie były dobrze dostosowane do ukrywania złożoności; to znaczy, krzywa uczenia się była stroma. Częściowo wynika to również ze zrozumienia, że ​​pisanie aplikacji 3D - dla których te interfejsy API są ściśle dostosowane - jest o wiele bardziej skomplikowane niż pisanie aplikacji 2D. Jeśli chodzi o złożoność interfejsu, mam na myśli interfejsy takie jak OpenGL i DirectX. Jeśli chodzi o 3D kontra 2D, mam na myśli matematykę i geometrię, które służą do tworzenia scen 3D, a nie prostotę, z jaką niedoświadczony umysł może podejść do problemów 2D.

Jednak w ostatnich latach nie tylko materiały edukacyjne stały się znacznie bardziej dostępne, ale także wiele bibliotek, które zawierają podstawowe złożoności tych interfejsów, stały się dostępne i obniżyły bariery wejścia. Wszystko to przełożyło się na cykl zwiększonego zainteresowania, który był już obecny ze względu na rosnące znaczenie wizualizacji, zgrabnych interfejsów użytkownika i wydajności na urządzeniach o niskiej mocy.

Renderowanie programowe i renderowanie 2D było więc dobrym punktem wyjścia dla osób, które były nowe w grafice i / lub chciały stworzyć produkt, w którym renderowanie nie zajęło zbyt wiele czasu w projekcie. Przynajmniej w odniesieniu do 2D to nadal obowiązuje; technologia w dużej mierze pokryła lukę we wprowadzaniu renderowania 2D do GPU.


20

Jest tu kilka naprawdę dobrych odpowiedzi, więc tylko je uzupełnij.

Główną siłą napędową renderowania oprogramowania jest zdolność. Zostało to poruszone w jednej z odpowiedzi, ale zamierzam przedstawić przeciwny punkt: renderowanie programowe może być w rzeczywistości bardziej wydajne niż renderowanie sprzętowe, nie mniej.

Ze sprzętem jesteś ogólnie ograniczony do możliwości samego sprzętu, chociaż OpenGL dla jednego jest w stanie emulować oprogramowanie wielu rzeczy, które mogą nie istnieć w sprzęcie. Oznacza to, że jeśli spróbujesz użyć Funkcji X, ale sprzęt jej nie obsługuje, nastąpi jedna z dwóch rzeczy: albo wrócisz do emulacji oprogramowania (typowy scenariusz OpenGL), albo nie dostaniesz się do w ogóle go używaj (typowy scenariusz D3D).

Dzięki renderowaniu oprogramowania możesz sam napisać kod. Możesz manipulować rzeczami i mieć pełną kontrolę nad tym, co dzieje się aż do poziomu pikseli. Aby dać przykład wybuchu z przeszłości, Quake zaimplementował w oprogramowaniu programy cieniujące piksele w 1996 roku, w czasie, gdy karty 3D (wtedy nie były nazywane „GPU”) ledwie rasteryzowały kilkadziesiąt teksturowanych trójkątów.

Dotyczy to również obecnych układów GPU, ale nadal istnieją znaczne części potoku graficznego, które są udostępniane jako stała funkcjonalność (lub nawet w ogóle nie są ujawniane).

Renderowanie oprogramowania można lepiej skalować. Dopiero stosunkowo niedawno widzieliśmy, że konfiguracje wielu GPU stają się naprawdę wykonalne, ale oprogramowanie może skalować się na wiele rdzeni procesora na wielu serwerach. Możesz mieć dedykowane do tego całe farmy serwerów, a profesjonalne farmy renderujące nadal będą korzystać z renderowania programowego.

Oprogramowanie może ujawniać różne paradygmaty renderowania. Obecny sprzęt jest bardzo skoncentrowany wokół paradygmatu trójkąt / wierzchołek / fragment / rasteryzacja; chodzi o wybranie jednej rzeczy i zoptymalizowanie jej, aż zacznie krzyczeć o litość. Procesory graficzne są nadal złym wyborem, np. Do śledzenia promieni, które jest częściej wdrażane w oprogramowaniu.

Oczywiście, jeśli chodzi o bezpośrednie porównanie jabłek z jabłkami, GPU pokona oprogramowanie każdego dnia tygodnia - pod warunkiem, że porównamy obszary, w których GPU są silniejsze. Ale to nie znaczy, że są silniejsze w każdej dziedzinie. Mimo to i na potrzeby tej witryny SE korzystanie ze sprzętu jest na ogół dobrym rozwiązaniem, ale należy pamiętać, że istnieją przypadki użycia, w których oprogramowanie jest również opłacalne.


8
+1 za „renderowanie programowe może być bardziej wydajne niż renderowanie sprzętowe, nie mniej”.
concept3d

10

Renderowanie sprzętowe lub GPU polega na renderowaniu obrazu za pomocą procesora graficznego (zwanego także kartą graficzną). Przeciwieństwem jest renderowanie programowe przy użyciu procesora.

Renderowanie oprogramowania jest zwykle używane jako awaryjne, gdy nie ma dostępnego (odpowiedniego) procesora graficznego. Ponieważ jednak procesor graficzny jest o rząd wielkości szybszy, renderowanie oprogramowania prawie nigdy nie jest przydatne, ponieważ procesor zwykle nie będzie w stanie renderować obrazów w czasie rzeczywistym. Renderowanie programowe jest przydatne, gdy potrzebna jest wysoka precyzja, jeśli do renderowania obrazu wymagane są bardzo skomplikowane formuły. Ponieważ procesory mają bardziej ogólny cel niż procesory graficzne, dzięki czemu mają więcej możliwości. Jednak ten argument staje się coraz mniej aktualny, ponieważ obecnie procesory graficzne mogą obsługiwać coraz bardziej złożone zadania i nie są już ograniczone jedynie do 32-bitowych liczb zmiennoprzecinkowych do reprezentowania liczb.


2

Myślę, że to naprawdę dobre pytanie.

Mogę sobie wyobrazić:

  • VRAM jest bardziej ograniczony niż ogólna pamięć RAM. W przypadku renderowania GPU - każda tekstura jest większym problemem. W pamięci RAM możesz przechowywać średnio około 4 do 8 razy więcej danych niż w VRAM. Oczywiście ten scenariusz zakłada, że ​​nie ma systemu, który byłby odpowiedzialny za zwolnienie / wypchnięcie nieużywanych / wymaganych tekstur z / do RAM / VRAM

  • Jeśli chodzi o wielowątkowość, praca z renderowaniem oprogramowania jest o wiele łatwiejsza - nie ma potrzeby udostępniania kontekstów

  • Jeśli wykonujesz grafikę 2D - zwykle większość frameworków przeprowadza implementację Dirty Rectangles Evaluation - co rozwiązuje wiele problemów z wydajnością.

Renderowanie przy użyciu OGL / D3D daje jednak znacznie większą wydajność i możliwości. Shadery potrafią robić naprawdę niesamowite rzeczy, które są prawie niemożliwe przy renderowaniu oprogramowania.

Ale techniki, takie jak blitting, używanie colorkeys, mają swoje własne odczucia, jakbyś był na poziomie podstawowym, pochodzącym ze świata grafiki komputerowej.

Myślę, że przynajmniej dobrze jest wiedzieć o renderowaniu oprogramowania. To naprawdę bardzo ekscytujący świat, nie wspominając o tym, że jest on źródłem wszystkiego, co widzimy dzisiaj.


1
Do uruchomienia shaderów nie potrzebujesz akceleracji sprzętowej. System OS X 10.9 jest dostarczany z funkcją pełnego wdrożenia oprogramowania GL4. Wydajność jest niewiarygodnie dobra do renderowania oprogramowania; nie chodzi o to, że można realistycznie grać w wyrafinowane gry (szczerze mówiąc, procesory graficzne, z którymi Apple dostarcza swoje produkty), ale jest o wiele bardziej praktyczne niż używanie czegoś takiego jak rasterizer odniesienia Direct3D. W rzeczywistości jest to coś, za pomocą którego można wysłać działające oprogramowanie.
Andon M. Coleman,

@ AndonM.Coleman Nie wszyscy używają Apple i nie znam programów renderujących, które obsługują shadery w Linuksie i Windowsie.
luke1985

1
Nie o to mi chodziło. Istnieją implementacje OpenGL, w których w pełni funkcjonalne moduły cieniujące działają całkowicie na procesorze. Fakt, że Apple jest deweloperem, jest w dużej mierze nieistotny. Twoja odpowiedź sprawiała wrażenie, jakbyś myślał, że musisz mieć procesor graficzny, aby uruchomić nowoczesne shadery w OpenGL.
Andon M. Coleman

@ AndonM.Coleman I to prawie poprawne, ponieważ w 80% przypadków musisz.
luke1985

2
Shadery można łatwo wdrożyć za pomocą renderowania programowego, w rzeczywistości nawet Tomb Raider 1 i Quake 1 miały shadery pikseli. Jest dokładnie odwrotnie, procesor daje o wiele większą kontrolę niż ograniczenie potoku wierzchołków / fragmentów obecnych układów GPU.
lama12345,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.