Jakie są zalety i wady HLSL vs GLSL vs cg? [Zamknięte]

Jakie są zalety / wady trzech?

coderanger ma rację, że HLSL jest ukierunkowane na DirectX, GLSL na OpenGL i CG są dostępne z obydwoma interfejsami.

Istnieją jednak inne kwestie do rozważenia (informacje na forum OGRE):

• CG nie pozwoli ci korzystać z najnowszych funkcji GLSL (nie jestem pewien co do HLSL). Jest to środek, więc nie będziesz w stanie w pełni wykorzystać funkcji GLSL, tylko wspólnej, dopóki Shader Model 3.0 (zrozumiał AFAI).
• CG jest tworzony przez NVidię, która optymalizuje go pod kątem kart, ale wydaje się, że nie wykonuje dużo pracy dla kart ATI ... niektórzy ludzie zgłaszają, że mogą występować problemy z kartami ATI używającymi CG.
• OpenGL wydaje się być nieco wolniejszy niż DirectX na platformach Windows. To naprawdę zależy od tego, co robisz i powód, dla którego znalazłeś to źródło w implementacjach sterowników, ale dobrze jest wiedzieć, zanim wybierzesz interfejs API i powiązany język modułu cieniującego. Jednak OpenGL jest jedynym interfejsem dostępnym na wszystkich platformach (win / mac / unix / niektóre konsole). Więc wiedząc, że używanie wyłącznie GLSL może być lepszym wyborem dla nie-Microsoftowej gry międzyplatformowej.
• Sterowniki NVidia w Linuksie wydają się być bardziej stabilne niż sterowniki ATI, dzięki czemu CG jest bardziej interesujący, jeśli chcesz mieć pewność, że działa on dobrze na Linuksie (to wszystkie zgłoszone informacje, musisz sprawdzić szczegóły)

Więc jeśli nie używasz najnowszych funkcji shadera, CG wydaje się dobrym wyborem. GLSL wydaje się lepszy, jeśli wybierasz się na OpenGL. HLSL, jeśli korzystasz wyłącznie z platform Microsoft.

Teraz najpierw opracowanie w HLSL dla Windows do korzystania z DirectX, a następnie konwersja do GLSL dla Linuksa i Maca może być lepszym rozwiązaniem, aby mieć pewność co do wydajności i mieć większy zestaw funkcji modułu cieniującego. Może to jednak być dużo pracy (sam tego nie zrobiłem, więc nie mogę powiedzieć). Silnik graficzny OGRE (i inne silniki) pozwala na użycie dowolnego API (DirectX lub OpenGL lub innych), więc to pomaga, ale nadal istnieje kod modułu cieniującego do konwersji, jeśli pójdziesz tą drogą.

To wszystkie informacje, które zebrałem, wybierając język shaderów (jeszcze nie podjąłem decyzji).

Aktualizacja: Valve dokonało konwersji jednej ze swoich gier na OpenGL i nie znalazło sposobu, aby wersja DirectX była szybsza niż OGL . Pamiętaj więc, że stan implementacji sterownika, jakość interfejsu API itp. Zmieniają się co roku zbyt mocno, abyś mógł całkowicie polegać na surowej wydajności jako argumentie wyboru jednego lub drugiego. Mając to na uwadze, wybierz OpenGL / GLSL, aby uprościć swoje życie podczas pracy (lub mając plany lub nadzieje na pracę) na platformach innych niż Windows, użyj DirectX / HLSL, jeśli naprawdę chcesz korzystać tylko z platform Microsoft i skupić się, a może mieć jakieś dobre Interfejs API szybszy niż OpenGL (jest teraz cofany, więc nie licz na to); użyj CG, jeśli chcesz zapewnić obie możliwości użytkownikowi, ale jeśli masz do tego siłę roboczą (i narzędzia), użycie GLSL i HLSL może być również realnym rozwiązaniem.

Aktualizacja (2012): Należy zauważyć, że CG zostało przerwane i nie jest już wspierane ani aktywnie obsługiwane przez Nvidię. Nvidia zaleca wszystkim użytkownikom przejście na kombinację GLSL i HLSL lub nowszą bibliotekę, taką jak nvFX (na github). Wynika to z faktu, że utrzymanie zgodności funkcji między GLSL i HLSL było zbyt trudne.

Mogę tylko rozmawiać o CG kontra HLSL, ponieważ są to 2, których do tej pory używałem.

Cg to nie to samo co HLSL.

W Cg NVIDIA wykonała świetną robotę, tworząc bardzo czystą składnię shaderów. Jest bardzo podobny do HLSL.

Ale połączenie z D3D9 / D3D11 (kodem inicjującym, kodem kompilacji modułu cieniującego) jest znacznie czystsze na HLSL niż Cg. -1 Cg. Cg ma nieprzyjemny kod startowy, którego nie potrzebujesz nawet dla HLSL przez D3D.

W Cg musisz „cgGetNamedParameter” dla każdej uniform zmiennej modułu cieniującego, którą chcesz ustawić / zmodyfikować. I musisz zachować CGparameterodniesienie w kodzie dla tej zmiennej

// C++ code to interact with Cg shader variable (shader language independent)
CGparameter mvp = cgGetNamedParameter( vs, "modelViewProj" ); 
CG::getLastError("Getting modelViewProj parameter");  // check for errors
cgSetMatrixParameterdr( mvp, &modelViewProj._11 ) ;   // setting the matrix values

W HLSL jest to znacznie czystsze - tylko jedna linia i nie musisz utrzymywać tej CGparameterzmiennej.

// D3D9 C++ code to interact with HLSL shader variable
DX_CHECK( id3dxEffect->SetMatrix("modelViewProj", &mvp._11 ), "Set matrix" ) ;

Powyżej DX_CHECKjest tylko prosta funkcja, która sprawdza HRESULT, który jest zwracany z SetMatrixpołączenia. Powyższy kod to d3d9 . D3D10 i 11 są oczywiście o wiele bardziej bolesne (ponieważ nie ma obiektu ID3DX11Effect).

Zanim zacząłem używać HLSL, patrzyłem na ten kod i byłem zazdrosny .

Chociaż NVIDIA starali się zrobić wspólny interfejs dla CG między OpenGL / D3D, praktycznie jej nie w ten sposób, i masz cgGL*, cgD3D9, cgD3D10,cgD3D11 grupy funkcyjne do czynienia z. Tak więc całość działa dla OpenGL i D3D !! roszczenie idzie tylko do tej pory. Nadal musisz wszystko zawinąć w #ifdefgrupy typu OpenGL / D3D , aby działało na różnych platformach. -2 Cg.

Ponadto miałem ostatnio złe doświadczenia z kartami Cg / ATI, co, jestem pewien, nie jest moim złym. (Ktoś inny to wypróbował?). Myślę, że może być prawdą, że NVIDIA nie testuje całkowicie kart ATI, jak twierdzi Klaim. Lub że ATI nie testuje na Cg. Tak czy inaczej, istnieje rozbieżność i konflikt interesów. -3 Cg.

W sumie wolałem Cg. Jego kod shaderów składnia i nazewnictwo jest czysty, słodki, i schludny. Szkoda, że ​​ma te inne problemy.

Moje bardzo podstawowe rozumienie jest takie, że HLSL jest tylko dla DirectX, a GLSL jest tylko dla OpenGL. Cg jest w zasadzie tym samym językiem co HLSL, ale można go używać zarówno z DirectX, jak i OpenGL (choć za pomocą innego kodu środowiska wykonawczego).

Kolejną istotną różnicą między HLSL i GLSL (nie znam CG, więc nie mogę za to mówić) jest to, że dzięki HLSL Microsoft zapewnia kompilator modułu cieniującego jako część środowiska uruchomieniowego D3D, podczas gdy z GLSL twój dostawca sprzętu zapewnia go jako część ich kierowca.

Ma to zalety i wady po obu stronach.

Za pomocą metody GLSL sprzedawca może dostroić kompilator do możliwości swojego sprzętu. Najlepiej znają swój sprzęt, wiedzą, co robić, a czego nie. Z drugiej strony wadą jest to, że - w świecie, w którym jest wielu dostawców sprzętu - masz sytuację, w której mogą występować niespójności między kompilatorami modułów cieniujących, a dostawca ma również całkowicie wolne prawo do popsucia.

Metodą HLSL Microsoft kontroluje kompilator. Wszyscy mają stałą bazę techniczną, a jeśli moduł cieniujący z powodzeniem kompiluje się w jednym miejscu, można zasadnie założyć, że kompiluje się wszędzie. Ten sam moduł cieniujący będzie generował takie same skompilowane dane wyjściowe niezależnie od dostawcy (wszystkie inne rzeczy są oczywiście takie same). Z drugiej strony kompilator HLSL musi być „działający konsekwentnie na wszystkim”, więc nie jest w stanie wyciągnąć żadnych specjalnych sztuczek specyficznych dla dostawcy, aby wydobyć kilka ostatnich kropel soku ze zbiornika.

Jeśli wydaje mi się, że preferuję widok HLSL na świat, to dlatego, że tak. Byłem wcześniej gryziony przez bardzo niespójne zachowanie na różnych platformach, aw jednym przypadku nawet musiałem rzucić ładunek GLSL z powrotem do ARB ASM, aby uzyskać linię bazową, która działała. Kompilator GLSL firmy NVIDIA może być tutaj postrzegany jako szczególnie znany - zaakceptuje nawet składnię i słowa kluczowe HLSL, co oznacza, że ​​jeśli nie będziesz ostrożny, będziesz mógł stworzyć shadery, które będą działać tylko na NVIDIA i nic więcej. Tam jest dżungla.

Używam obu, zacząłem od glsl i przeniosłem się do hlsl tylko dlatego, że projekt tego wymaga. Biorąc pod uwagę wybór, jest cały czas glsl. glsl wydaje się bardzo śliski, a hlsl wydaje się, że wyszedł z ławki hobby inżyniera.

Możesz także przyjrzeć się RTSS (Run Time Shader System), który jest również dostarczany z Ogre. Jest dość nowy, ale w zasadzie piszesz shadery w kodzie, a nie w plikach zewnętrznych. Nie wdrożyłem go jeszcze, ale zdecydowanie planuję użyć tego, gdy przyjdzie czas.

Oto ogromna seria samouczków na wiki Ogre, jak pisać shadery. http://www.ogre3d.org/tikiwiki/JaJDoo+Shader+Guide

Jeśli chodzi o twoje pierwotne pytanie, jak powiedział Praetor, tak naprawdę nie jest to kwestia zalet / wad, to kwestia tego, jakiego systemu renderowania chcesz użyć. Ponieważ używanie DX / OpenGL z Ogre to tylko kwestia załadowania wtyczki, najprawdopodobniej będziesz chciał użyć formatu .cg.