Nvidia cuda

[Nowi]

NVIDIA CUDA

 

http://www.nvidia.pl/object/cuda_what_is_pl.html

 

może mi ktoś coś więcej o tym powiedziec jest już jakieś zastosowanie tego języka w 3dstudio max ??

[Master Kiełbaster]

nie ma żadnego i raczej nieprędko będzie

[Nowi]

A wiesz może czy Ati wypuściło coś takiego i czy to coś jakiś cudem można uzywac w kartach z czipsetem od "amd"

[Hynol]

Jak na razie nie.

 

Master - czemu nie? To znaczy "cuda" po stronie renderera powinny się pojawić, ale nie widzę problemu żeby karta wzięła na siebie całą masę obliczeń... Jak na razie testowałem sobie kompresję video i wyglada to świetnie.

[Nowi]

Kurcze szkoda, coś mi się wydaje jak to wyjdzie w pełni stabilne :) i Vray będzie to obsługiwał będzie chyba trzeba zmienic kartę bo coś mi się nie wydaję aby Ati prędko to wprowadziło :)

[sanki]

ati CUDA też ma implementować (podobno) a dodatkowo zamierza implementować OpenCL ale praktyczne tego wykorzystanie w programach to pewnie dopiero za jakiś czas, na razie z CUDA chyba tylko Gelato będzie korzystać jeżeli o grafikę komputerową chodzi, ale pewności nie mam

Edytowane 23 Wrzesień 2008 przez sanki

[Master Kiełbaster]

ati ma jakieś swoje close to metal.

 

Master - czemu nie?

 

póki co karty są zbyt prymitywne by coś poza kompresją policzyć, do tego dochodzi mała pamięć i niska przepustowość PCI która zabija całą wydajność. poza tym w 3ds nie pojawią się cuda bo się w nim nic nie pojawia poza nowym numerkiem :P

[arev]

Nie odbierajcie tego co napiszę za pewnik, ale czytałem na forum nVidii wypowiedź jakiegoś programisty (nawet Polak, zdaje się, że pracownik jakiejś wyższej uczelni), w której stwierdził, że o ile tylko program ma możliwość wczytywania pluginów to możliwym jest przerzucenie jego obliczeń z CPU na GPU. Wprawdzie jednostki obliczeniowe GeForce'ów mają tylko dokładność double (CPU ma long-double), ale w sumie nie wiem czy taki Vray, czy Mental potrzebują tego "longa" jeśli nie to coś ciekawego może jednak z tego zakwitnąć. A przepustowość szyny PCI-E miałbym gdzieś o ile chociaż trochę przyspieszyłoby to rendering. Nikt nie oczekuje, że MLT będzie liczyć się w czasie rzeczywistym. Poza tym, jak już się czepiać szczegółów to pamięci DDR2 mają 6.4 GB/s przy taktowaniu 800 MHz, więc szybciej wymiana danych z procesorem nie będzie się odbywać, a szyna PCI-E w wersji 1.1 ma 8 GB/s, przy czym wewnętrzne połączenie GPU GDDR2/3/5 jest dużo szybsze (wysokie częstotliwości pamięci w kartach) niż CPU DDR2/3.

[sanki]

Master Kiełbaster - AMD zadecydowało że zarzucają close to metal na rzecz OpenCL http://en.wikipedia.org/wiki/OpenCL

[Master Kiełbaster]

Łączna liczba jednostek SP(streaming multiprocessors) wynosi więc 240, a TF 80. Z punktu widzenia wykonywania obliczeń podwójnej precyzji (stosowanych przy GPGPU), możemy wyróżnić jeszcze 30 jednostek SP potrafiących wykonać owe obliczenia.

czyli obecnie gpu nie obsługuje w pełni nawet podwójnej precyzji :(

[dokturpotfor]

w hardwarze nowe chipy (gt200, r700) obsluguja double, w softwarze

mozesz sobie pisac nawet i siedemnastokrotna precyzje :). Problem byl

kiedys kiedy double precision musialo byc robione na poziomie:

 

a) shadera

b) kompilatora shadera

c) drivera

 

klopoty z przenoszeniem oprogramowania takiego jak raytracer nie jest w

precyzji czy wydajnosci tylko w architekturze problemu. aby wykorzystac

dobrze moc gpu nalezy... hmm... pisac w paradygmacie SIMD (single

instruction multiple data) lub bardzo ograniczonym MIMD, co to oznacza?

W uproszczeniu... aby wykorzystac na raz wszystkie 'procesorki' karty

graficznej (ktorych liczba juz idzie w setki) musza one wykonywac w

danej chwili dokladnie to samo (niemal co do instrukcji jezyka maszynowego,

tutaj dokladnie to samo to jest takie hardcorowe 'dokladnie to samo': jesli

procesorki chca pracowac naraz to albo wszystkie wykonuja np x + y = z,

albo czesc wykonuje z + y = z, a czesc ktora np chce zrobic x = sqrt(y)

musi odpuscic kolejke). Dla przykladu, jest jakis tam pseudoshaderowy

programik:

 

bleble = dot ( normal, oko )

kolor = bleble * textura[u,v];

alpha = 1 - bleble;

 

i teraz jak idzie 16 prockow na raz, kazdy ma parametry innego pixela jako

dane wejsciowe (normal, oko, u, v, jakas przypisana teksture). procki

wykonuja instrukcja po instrukcji: najpierw kazdy oblicza iloczyn skalarny

wektora do swiatla i oka, pozniej kazdy przypisuje to do zmiennej ble ble

pozniej kazdy wyciaga kolor z tekstury w punkcie (u,v), pozniej kazdy

mnozy go przez bleble, pozniej kazdy przypisuje go do swojej zmiennej kolor

pozniej kazdy oblicza roznice 1 - bleble, i wynik przypisuje do zmiennej alpha

 

procedura jest prosta kolejna i instrukcja, wszyscy ja wykonuja, nastepna

instrukcja itd..

 

a co sie dzieje kiedy pojawia sie kod ktory jest bardziej skomplikowany,

np ma jakies skoki warunkowe (czyli sie slangowo 'branch-uje').

 

bleble = dot (normal, oko)

if (bleble > 0.5) {

kolor = tekstura[u,v]

alpha = 1 - bleble;

} else {

kolor = noise2d (u, v)

alpha = 0.5 * bleble;

}

cosdalej...

 

i co sie teraz dzieje ? jak w poprzednim przykladzie: procki wszystkie najpierw

obliczaja iloczyn skalarny normal * oko, pozniej wszystkie zapisuja to do

zmiennej bleble, pozniej wszystkie sprawdzaja warunek czy bleble jest

wieksze od 0.5... i pozniej... no wlasnie... dla czesci warunek jest spelniony

a dla czesci nie... i co sie dzieje ? czesc procesorkow (np zalozmy bez

straty ogolnosci ze dla bleble>0.5) idzie dalej wykonujac instrukcje

tekstura[u,v], nastepnie ta grupka przypisze wartosc do zmiennej kolor,

i 1- bleble do zmiennej alpha. dopiero wtedy pozostale procesory beda

mogly sie zajac druga alternatywa klauzula instrukcji 'if/else'. kiedy ta grupa

skonczy (a poprzednia sie teraz nudzi...) dopiero wtedy obie beda mogly

kontynuowac razem i robic 'cosdalej...'

 

i teraz wyobrazcie sobie takie procesorki ktore maja bardzo maly stos (rzedu

kilobajtow), maja niewiele kodu (bo rozmiar kodu takze jest rzedu kilobajtow)

nie maja bezposredniego dostepu do pamieci (poza ograniczonym samplerem

tekstur, ale tylko w okreslonych miejscach! ), nie maja wszystkich tych

bajerow co duze CPU ( out of order execution, pipelining, cache ) ale za to

potrafia wykonywac jednoczesnie ta sama instrukcje na 160 (r700) zestawach

danych - w oczywisty sposob to wymaga diametralnie innego podejscia

do pisania oprogramowania. logika takiego offlinowego renderingu jest bardzo

nieodpowiednia dla GPU:

 

a) jest tam duzo rekurencji: np: aby obliczyc swiatlo z punktu trafienia

promieniem w kulke, oblicz swiatlo z punktu trafienia promieniem odbitym od

kulki, swiatlo rozproszone (czyli z X promieni losowych w roznych kierunkach)

i swiatlo zalamane z promienia zgodnie z zasada zalamania swiatla, oczywiscie

te promienie znow sie odbijaja, rozpraszaja i zalamuja. Taki mechanizm pojawia

sie bardzo czesto: photon mapping, raytracing, occlusion, sss w mniej

lub bardziej podobnym schemacie.

 

b) kod jest duzy skomplikowany i logika wielokrotnie sie rozgalezia

 

c) obliczenia nie sa spojne pamieciowo... duze CPU ma dostep do RAM'u...

wiec (+/- koszt nietrafien w cache) koszt sciagniecia czegokolwiek z pamieci

jest +/- taki sam. Np jesli promien odbity laduje gdzies po drugiej stronie

sceny (a akurat jej geometria jest zapisana gdzies zupelnie daleko w RAMIE)

to nie ma problemu zeby CPU sobie to odczytalo. na gpu program ma dostep

do bardzo ograniczonego lokalnego obszaru pamieci

 

Problemem nie jest wydajnosc czy prostota gpu problemem jest to ze trzeba

od nowa nauczyc sie programowac :) i przepisac oprogramowanie od nowa.

podejrzewam ze pierwsze pluginy GPU do mentala beda polegac na:

a) znalezieniu jakiej krytycznej sekcji w kodzie (jakas czesto wykonywana,

nierekurencyjna funkcja - albo rekurencyjna ale zostanie zastapiona przez

funkcje z 'lazy evaluation' - ktora wykonuje duzo obliczen numerycznych),

np jakies obliczanie materialu, albo przeciecia promienia z geometria itd...

b) wywolania tej funkcji beda gromadzone do jakiegos duzego bufora

c) i w taki sposob wyslane do GPU, zeby szybko przemielil 'zakolejkowane'

obliczenia

 

obecnie tak sie dzieje z fizyka i np przetwarzaniem sygnalu/kodowaniem

wideo (o ktorym wspominal Hynol). bo tam duzo jest takiej rabanki

numerycznej: mnozenie wielkich macierzy, rozklady macierzy, szybka

transformata fourierrea, ktore akurat maja te zajebiste wlasnosci ze:

sie nie branchuja, wykonuja kubek w kubek te same operacjie na kazdym

strumieniu i korzystaja z pamieci w bardzo regularny/lokalny sposob.

 

to tyla...

 

PS: troche was oklamalem dla efektu edukacyjnego mowiac ze instrukcja w

instrukcje kod wykonywany przez strumienie gpu musi byc taki sam. w

hardwarze i sterownikach ATI i NVIDIA zaszyli pare trickow ktore pozwalaja

w delikatny sposob robic rozne rzeczy na roznych strumieniach, (np mnozenie

z dodawaniem ) ale ograniczenie ze na bardzo niskim poziomie strumienie

musza pracowac tak samo jest w ogolnosci prawdziwe.

[arev]

Bardzo ciekawe i miłe w czytaniu, dzięki.