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