W dniu środa, 18 września 2019 15:46:02 UTC+2 użytkownik fir napisał:
> W dniu środa, 18 września 2019 15:29:03 UTC+2 użytkownik fir napisał:
> > zalezy co rozumiec za rdzen/sprzetowy watek
> >
> > w swiecie gpu mowia o ile wiem o tzw kanalach, jeden kanal przypada na jednego
floata (przypadajacego niezaleznie do obrobki)
> >
> > o tyle powstaje koncepcja zbudowania czegios w rodzaju komputacyjnej macierzy
> > (powiedzmy 1024x1024 floato) zdolnej np do zaladowania megabajta floatow w jednym
cyklu dodania do niej drugiego miliona floatow w drugim cyklu i zapisania tego
spowrotem w trzecim czy piatym
> >
> > taka komputacyjna macierz wydaje mi sie dobrym pomyslem, pisalem juz o tym choc
nie jestem epwien czy na tej grupie.. (np o tym jak to zintegrowac z c)
> >
> > sporo czesc kodow np rysowanie zbioru mandelbrota (ale i zapewne wiele innych )
daloby sie puscic na tej tablicy prawie bez zmian z milionowym przyspieszeniem (o ile
sprzet mialby milion kanalow)
> >
> > jakies inne przykladowe kody typu jakis kontrast czy usrednienie pikseli itd (mam
na mysli takie kody w ktorych kanal "czyta" wartisci np z 8-miu przylagajacych
kanalow) tez chyab dobrze by szly bo jako ze wszystko jesli liczone w jednym
kroku/cyklu to nei trzeba sie chyba martwic konfliktami w dostepach do pamieci, nie
trzeba nic synchronizowac (choc moze to zalezy od przypadku trzebby przesledzic jakie
algorytmy/kody dobrze wykonuja sie na takiej solidnej tablicy
> >
> > (solina nazywam ja bo kazdy taki kanal nie ma niezlaleznego instruction
pointer...alternatywna bylaby jakas inna tablica gdzie kazdy z milionow kanalow
mialby swoje ip, ale bylby to jakis inny rodzaj tablicy)
> >
> > gdyby mi sie chcialo to bym sie pozastanawial jak rozne algorytmy wpisuja sie ten
schemat, ale ostatnio cos slabo z motywacja - nad pewnymi drobnymi rzeczami mozna sie
jednak zastanowic
> >
> > np smieszne wydalo mi sie zastanowienie jak dzialalby na tym jakis raytracer/kod
z duzymi ifami, bo byloby to wyglada smieszne:
> >
> > zalozmy ze taki kod mialby postac w stylu
> >
> > if(a)
> > {
> > if(b)
> > {
> >
> > }
> > }
> >
> > if(c)
> > {
> >
> > }
> >
> > gdzie te ify sa 'duze'
> >
> > wyglada na to ze taka macierz komputacyjna musialaby wchodzic w kazdy (scislej
prwie kazdy) if poniewaz jakas czesc watkow mialaby byc dla nich liczona, resztka
kanalow by w tym czasie sobie robila nic, alebo nic uzytecznego
> > po wyjsciu z ifa inne watki by wchodzily w inny if a inne by lezaly odlogiem -
> > slowem taki kod zawsze by wlazl w prawie wszystkie ify i tak by wygladal
pojedynczy przebieg (akurat w przypadku raytracerow gdy odbicia promieni sie liczy do
kilku odbic w glab itd to by moglo nieco zwolnic ale i tak bylby spory zysk na
prostocie)
> > *(choc w tych niektorych raytracerach nie tylko liczy sie zalamane odbicia ale
jeszcze np przy odbiciu wprowadza sie cala nowa petle by zeskanowac swiatlo z
otoczenia dla roznych katow, wtedy jeden taki kanal by byl zatrudniony dla liczenia
calej petli i mamy klasyczne zmulando, wiec moze w tym wypadku dynamiczna tablica
kanalow z osobnymi ip sprawdzalaby sie lepiej, ale ja i tak pozostaje chyab pewnym
fanem tej solidnej prostej tablicy 'wykonawczej' (choc tej drugiej pewnie tez)
> >
> > nie wiem jednak czy chce mi sie to rozwazac bo jest to dla nie troche malo
praktyczne (bardziej praktyczne to mogloby byc dla intela/amd/nvidia ;c)
>
> skladnie w c w ekstremalnym uproszczeniu
> w jaki mozna by to wyrazic to cos w stylu
>
> for(1000) {}
>
> for(1000,1000) {}
>
> gdzie zamiast for moze byc tez jakies inne slowo np moze 'map' o ile tu pasuje
> (ciezko mi ocenic czy apsuje) lub jakies inne, podaje for dla uproszczenia
>
> liczba w for podaje ile watkow ma to liczyc, a numer watku jest domyslnie zapodany
w i, jesli podac dwie liczby to i,j a jesli 3 to i,j,k
>
>
> for(1024,1024)
> {
> tab[i+j*1024] = tab[(i+1)+j*1024];
> }
>
> //przesuwa tablice 1 MB pixeli w lewo na milionie kanalow na raz


mozna by sie zastanowic jak rozne algorytmy/kody by sie zachowywaly/jak by sie je
pisalo w takim ujeciu na owa tablice komputacyjna/macierz obliczeniowa, ale nie wiem
czy mi sie chce

na przyklad kod rasteryzera (czyli wazna rzecz): w pierwszej fazie po prostu bierzesz
trojkaty z tablicy trojkatow i mnozysz przez maciez modelu i macierz kamery,
wyrzucasz te ktore sa poza polem widzenia - w wyniku dostajesz np tablice trojkatow
2d+depth, to sie paralelizuje chyba idealnie

dalszy proces jednak juz jest gorszy bo trzeba wypelniac framebufor i tu juz tak
prosto nie jest, chopc ew mozna by nad tym sie zastanowic