🚀 go-pugleaf

On Tuesday, September 17, 2019 at 8:10:06 PM UTC+2, M.M. wrote:
> Dziś zobaczyłem pierwszy w rankingu wydajności procesor AMD EPYC
> zawierający 64 rdzenie:
> 
> https://www.cpubenchmark.net/cpu.php?cpu=AMD+EPYC+7742&id=3547
> 
> 
> Mocno wyprzedził w rankingu zarówno najlepszy procesor Intela jak i
> dotychczasowy procesor AMD, aż trudno uwierzyć:
> 
> https://www.cpubenchmark.net/high_end_cpus.html

Intel od paru lat produkuje Xeona Phi, który ma 72 rdzenie
i może opalać 4 wątki / rdzeń = 288 wątków. Nie potrafię
znaleźć go w tym zestawieniu.

w.

On Tuesday, September 17, 2019 at 8:45:18 PM UTC+2, Wojciech Muła wrote:
> On Tuesday, September 17, 2019 at 8:10:06 PM UTC+2, M.M. wrote:
> > Dziś zobaczyłem pierwszy w rankingu wydajności procesor AMD EPYC
> > zawierający 64 rdzenie:
> > 
> > https://www.cpubenchmark.net/cpu.php?cpu=AMD+EPYC+7742&id=3547
> > 
> > 
> > Mocno wyprzedził w rankingu zarówno najlepszy procesor Intela jak i
> > dotychczasowy procesor AMD, aż trudno uwierzyć:
> > 
> > https://www.cpubenchmark.net/high_end_cpus.html
> 
> Intel od paru lat produkuje Xeona Phi, który ma 72 rdzenie
> i może opalać 4 wątki / rdzeń = 288 wątków. Nie potrafię
> znaleźć go w tym zestawieniu.
> 

Chyba tam nie ma ani koprocesorów a kart typu tesla, chyba są tylko
główne procesory, gpu, pamięci i dyski twarde. Xenon Phi jest bardzo
drogi, ale jest bardzo wygodny, normalnie aplikację dzieli się na
wątki i działa - albo i nie, jeśli wąskim gardłem będą transfery.

Ciekawe jak w praktyce wygląda przyspieszenie obliczeń na Tesli 
względem Xenon Phi. I ciekawe czy w ogole warto inwestować w te drogie
rozwiązania, jak za 150usd można kupić: GeForce GTX 1650 - tania,
wydajna, a 10 takich kart z lekkim underclockingiem na niektórych
obliczeniach pobiera tylko 500 wat mocy. No ale na GPU trzeba się
nauczyć jakiegoś OpenCL albo CUDA.

Pozdrawiam

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)

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

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

oczywiscie to wyzej by nieladnie przesunelo, by ladnie przesunelo trzebby dodac troche ifow (ktorych nie che mi sie pisac bo wychodze z dumu) ale pogladowo wiadomo o co chodzi
(a o tym jak taka macierz kanalow mialaby traktowac ify bylo napisane wczesniej, kazdy z miliona kanalow musialby sprawdzic tego ifa ale to nie jest taka wielka srata jesli wezmiemy pod uwage prostote kodowania)

W dniu wtorek, 17 września 2019 21:15:49 UTC+2 użytkownik M.M. napisał:
> Ciekawe jak w praktyce wygląda przyspieszenie obliczeń na Tesli 
> względem Xenon Phi. I ciekawe czy w ogole warto inwestować w te drogie
> rozwiązania, jak za 150usd można kupić: GeForce GTX 1650 - tania,
> wydajna, a 10 takich kart z lekkim underclockingiem na niektórych
> obliczeniach pobiera tylko 500 wat mocy. No ale na GPU trzeba się
> nauczyć jakiegoś OpenCL albo CUDA.
Jak ktoś umie napisać sensownie równoległy kod to OpenCL/CUDA nie są
żadnym problemem. Owszem, to nie są jakieś przepiękne API, ale 
praktycznie każdy ostro sprzętowy kod w C wygląda równie źle;)
Do tego można się tego uczyć bezproblemowo na dowolnym komputerze
z jakąś sensowną kartą graficzną, odpalenie Hello World na CUDA
(domyślny program to bodajże jakieś równoległe dodawanie wektorów
czy tam sortowanie) zajmuje jakieś 15 minut, z czego 10 to rejestracja 
na stronie nvidii żeby ściągnać toolchain. To jest wręcz przerażająco
łatwe w porównaniu do dawnego oprogramowywania "grubych" platform
obliczeniowych gdzie potrzeba było komercyjnego kompilatora za grubą
kasę na uczelnianym klastrze i wczytywania się w dokumentację żeby
coś się w ogóle uruchomiło.

Pozdrawiam, 
-- 
Karol Piotrowski

W dniu czwartek, 19 września 2019 04:55:42 UTC+2 użytkownik krop...@gmail.com napisał:
> W dniu wtorek, 17 września 2019 21:15:49 UTC+2 użytkownik M.M. napisał:
> > Ciekawe jak w praktyce wygląda przyspieszenie obliczeń na Tesli 
> > względem Xenon Phi. I ciekawe czy w ogole warto inwestować w te drogie
> > rozwiązania, jak za 150usd można kupić: GeForce GTX 1650 - tania,
> > wydajna, a 10 takich kart z lekkim underclockingiem na niektórych
> > obliczeniach pobiera tylko 500 wat mocy. No ale na GPU trzeba się
> > nauczyć jakiegoś OpenCL albo CUDA.
> Jak ktoś umie napisać sensownie równoległy kod to OpenCL/CUDA nie są
> żadnym problemem. Owszem, to nie są jakieś przepiękne API, ale 
> praktycznie każdy ostro sprzętowy kod w C wygląda równie źle;)
> Do tego można się tego uczyć bezproblemowo na dowolnym komputerze
> z jakąś sensowną kartą graficzną, odpalenie Hello World na CUDA
> (domyślny program to bodajże jakieś równoległe dodawanie wektorów
> czy tam sortowanie) zajmuje jakieś 15 minut, z czego 10 to rejestracja 
> na stronie nvidii żeby ściągnać toolchain. To jest wręcz przerażająco
> łatwe w porównaniu do dawnego oprogramowywania "grubych" platform
> obliczeniowych gdzie potrzeba było komercyjnego kompilatora za grubą
> kasę na uczelnianym klastrze i wczytywania się w dokumentację żeby
> coś się w ogóle uruchomiło.
> 
ktos tu przemilczal pare istotnych rzeczy i o tyle moim zdaniem pieprzy glupoty

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

On Thursday, September 19, 2019 at 4:55:42 AM UTC+2, krop...@gmail.com wrote:
> W dniu wtorek, 17 września 2019 21:15:49 UTC+2 użytkownik M.M. napisał:
> > Ciekawe jak w praktyce wygląda przyspieszenie obliczeń na Tesli 
> > względem Xenon Phi. I ciekawe czy w ogole warto inwestować w te drogie
> > rozwiązania, jak za 150usd można kupić: GeForce GTX 1650 - tania,
> > wydajna, a 10 takich kart z lekkim underclockingiem na niektórych
> > obliczeniach pobiera tylko 500 wat mocy. No ale na GPU trzeba się
> > nauczyć jakiegoś OpenCL albo CUDA.
> Jak ktoś umie napisać sensownie równoległy kod to OpenCL/CUDA nie są
> żadnym problemem. Owszem, to nie są jakieś przepiękne API, ale 
> praktycznie każdy ostro sprzętowy kod w C wygląda równie źle;)
> Do tego można się tego uczyć bezproblemowo na dowolnym komputerze
> z jakąś sensowną kartą graficzną, odpalenie Hello World na CUDA
> (domyślny program to bodajże jakieś równoległe dodawanie wektorów
> czy tam sortowanie) zajmuje jakieś 15 minut, z czego 10 to rejestracja 
> na stronie nvidii żeby ściągnać toolchain. To jest wręcz przerażająco
> łatwe w porównaniu do dawnego oprogramowywania "grubych" platform
> obliczeniowych gdzie potrzeba było komercyjnego kompilatora za grubą
> kasę na uczelnianym klastrze i wczytywania się w dokumentację żeby
> coś się w ogóle uruchomiło.
> 
> Pozdrawiam, 
> -- 
> Karol Piotrowski

Możesz polecić jakiś praktyczny tutorial od podstaw OpenCLa dla kogoś, kto wie 
co to C++ i programowanie rownoległe na CPU, ale z GPU nie miał nigdy 
do czynienia?

Pozdrawiam

W dniu czwartek, 19 września 2019 21:12:40 UTC+2 użytkownik fir napisał:
> 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

z poczatku mysllem ze na takiej matrycy mozna by puszczac kody ktore by robily to samo defakto ten sam zsynchronizowany kod w asmie z tym ze ew niektore by wylaczaly sie czasowo na niektroych branczach

ale jak sie zastanowic to np kod rasteryzacji na ekranie (trojkatow '2d+depth' z tablicy) raczej by tak nie poszedl bo trojkaty maja rozne rozmiary wiec ich wenetrzne peteli krecilyby sie inaczej,
wyglada na to wiec ze trzbaby to odzielnie przmyslec

co prawda jest opcja puscic to inaczej np rasteryzacje  takich trojkatow puscic tak ze kazdy kanal renderuje jeden piksel na
ekranie i kazdy po prostu leci po tablicy trojkatow i zmienia kolor na ten ktory napotkal jest najblizej (takie cos by szlo chyba rowno)

troche cizeko powiedziac jkby to bylo bo chyab jest to troche nowatorska a przynajmniej szeroko chyba niezbyt popularna koncepcja

W dniu piątek, 20 września 2019 15:00:16 UTC+2 użytkownik M.M. napisał:
> On Thursday, September 19, 2019 at 4:55:42 AM UTC+2, krop...@gmail.com wrote:
> > W dniu wtorek, 17 września 2019 21:15:49 UTC+2 użytkownik M.M. napisał:
> > > Ciekawe jak w praktyce wygląda przyspieszenie obliczeń na Tesli 
> > > względem Xenon Phi. I ciekawe czy w ogole warto inwestować w te drogie
> > > rozwiązania, jak za 150usd można kupić: GeForce GTX 1650 - tania,
> > > wydajna, a 10 takich kart z lekkim underclockingiem na niektórych
> > > obliczeniach pobiera tylko 500 wat mocy. No ale na GPU trzeba się
> > > nauczyć jakiegoś OpenCL albo CUDA.
> > Jak ktoś umie napisać sensownie równoległy kod to OpenCL/CUDA nie są
> > żadnym problemem. Owszem, to nie są jakieś przepiękne API, ale 
> > praktycznie każdy ostro sprzętowy kod w C wygląda równie źle;)
> > Do tego można się tego uczyć bezproblemowo na dowolnym komputerze
> > z jakąś sensowną kartą graficzną, odpalenie Hello World na CUDA
> > (domyślny program to bodajże jakieś równoległe dodawanie wektorów
> > czy tam sortowanie) zajmuje jakieś 15 minut, z czego 10 to rejestracja 
> > na stronie nvidii żeby ściągnać toolchain. To jest wręcz przerażająco
> > łatwe w porównaniu do dawnego oprogramowywania "grubych" platform
> > obliczeniowych gdzie potrzeba było komercyjnego kompilatora za grubą
> > kasę na uczelnianym klastrze i wczytywania się w dokumentację żeby
> > coś się w ogóle uruchomiło.
> > 
> > Pozdrawiam, 
> > -- 
> > Karol Piotrowski
> 
> Możesz polecić jakiś praktyczny tutorial od podstaw OpenCLa dla kogoś, kto wie 
> co to C++ i programowanie rownoległe na CPU, ale z GPU nie miał nigdy 
> do czynienia?
> 
> Pozdrawiam

moge wkleic jakies moje stare notatki/proby z opencl (z 2015, nie pamietam czy to ostatnia wersja ale pamietam ze to dzialalo, i wersja opencl renderowania madelbrota byla najszybsza, pisalem o tym na grupie wiec jest o tym gdzies watek w 2015)


ale szczerze mowiac nie wiem czy polecalbym sie tym zajmowac, jesli ktos chce zbierac odznaki programistycznego skauta i wpisac opencl do cv to na pewno 
- w innym wypadku chyba nie


#include "fist.h"
////////////////////////////////////////////////////////////////////////////////

//#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
//#include <string.h>
#include <math.h>
//#include <unistd.h>
//#include <sys/types.h>
//#include <sys/stat.h>
//#include <OpenCL/opencl.h>
//#include "clew.c"
#include "clew.h"
int clewInit(const char* path);

////////////////////////////////////////////////////////////////////////////////

// Use a static data size for simplicity
//
//const int DATA_SIZE = 130*1024;

const int OCL_INPUT_DATA_SIZE = 1*1024;
const int OCL_OUTPUT_DATA_SIZE =  256*256;
const int OCL_PROCESSING_RANGE =  256*256;

//int   DATA_SIZE = DATA_SIZE_MAX/10;

////////////////////////////////////////////////////////////////////////////////

// Simple compute kernel which computes the square of an input array
//
// const char *KernelSource = "\n" \
// "__kernel void square(                                                       \n" \
// "   __global float* input,                                              \n" \
// "   __global float* output,                                             \n" \
// "   const unsigned int count)                                           \n" \
// "{                                                                      \n" \
// "   int i = get_global_id(0);                                           \n" \
// "   if(i < count)                                                       \n" \
// "       output[i] = input[i] * input[i];                                \n" \
// "}                                                                      \n" \
// "\n";

// const char *KernelSource = "\n" \
// "__kernel void square(                                                       \n" \
// "   __global int* input,                                              \n" \
// "   __global int* output,                                             \n" \
// "   const unsigned int count)                                           \n" \
// "{                                                                      \n" \
// "   int i = get_global_id(0);                                           \n" \
// "   if(i < count)                                                       \n" \
// "       output[i] = i+input[i] *2   ;                                \n" \
// "}                                                                      \n" \
// "\n";


const char *KernelSource = "\n" \
// "__kernel void square(                                                       \n" \
// "   __global int* input,                                              \n" \
// "   __global int* output,                                             \n" \
// "   const unsigned int count)                                           \n" \
// "{                                                                      \n" \
// "   int i = get_global_id(0);                                           \n" \
// "   if(i < count)       \n" \
// "   {   int x = i%550; int y=i/550;                                                       \n" \
// "       output[i] = x+input[i] +y   ;                                \n" \
// "   }        \n" \
// "}                                                                      \n" \
// "\n";
"__kernel void square(                                                \n" \
"   __global int* input,                                              \n" \
"   __global int* output,                                             \n" \
"   const unsigned int count)                                         \n" \
"{                                                                    \n" \
"   int i = get_global_id(0);                                         \n" \
"   if(i < count)                                 \n" \
"   {                                             \n" \
"   int x = i%256;                  \n" \
" //  if(x>=256) return;                  \n" \
"   int y = i/256;                   \n" \
" //  if(y>=256) return;                  \n" \
"    float cRe = -0.5 + -1.5 + x/256.*3.;                 \n" \
"    float cIm =  0.0 + -1.5 + y/256.*3.;                  \n" \
"   float re = 0;    \n" \
"   float im = 0;     \n" \
"   int n = 0;     \n" \
"   for( n=0; n<=1000; n++)   {   \n" \
"     if( re * re + im * im > 4.0 )  { output[256*y+x] = n + 256*n + 256*256*n; return;}   \n" \
"     float re_n = re * re - im * im + cRe;      \n" \
"     float im_n = 2 * re * im       + cIm;      \n" \
"     re = re_n;          \n" \
"     im = im_n;          \n" \
"     }                   \n" \
"   output[256*y+x] = 250<<8;   \n" \
"   }                     \n" \
"}                         \n" \
"\n";

    int data[OCL_INPUT_DATA_SIZE];              // original data set given to device
    int results[OCL_OUTPUT_DATA_SIZE];           // results returned from device

// void SetupInputData()
// {
//     // Fill our data set with random float values
//     //
//     int i = 0;
//     unsigned int count = DATA_SIZE;
//     for(i = 0; i < count; i++)
//         data[i] = rand() / (float)RAND_MAX;
// }
////////////////////////////////////////////////////////////////////////////////
    int err;                            // error code returned from api calls
    unsigned int correct;               // number of correct results returned

    size_t global;                      // global domain size for our calculation
    size_t local;                       // local domain size for our calculation

    cl_device_id device_id;             // compute device id
    cl_context context;                 // compute context
    cl_command_queue commands;          // compute command queue
    cl_program program;                 // compute program
    cl_kernel kernel;                   // compute kernel

    cl_mem input;                       // device memory used for the input array
    cl_mem output;                      // device memory used for the output array

int SetupCL()
{
  static int initialised =0;
  if(initialised) return 0;
  initialised=1;

    clewInit("OpenCl.dll");

    int writeCLInfo();

  //  writeCLInfo();




  //////// platform
   static cl_platform_id platform_id[10] = {0};
   cl_uint no_of_platforms_found = 0;

   int ret = clGetPlatformIDs(10, platform_id, &no_of_platforms_found);
 //  if(ret == CL_SUCCESS ) ERROR_("clGetPlatformIDs success") ;
  // alert(" %d platforms found\n",no_of_platforms_found ) ;

   // Connect to a compute device
   //
    int gpu = 1;
    err = clGetDeviceIDs(platform_id[0], gpu ? CL_DEVICE_TYPE_GPU : CL_DEVICE_TYPE_CPU, 1, &device_id, NULL);
    if (err != CL_SUCCESS)
    {
        ERROR_("Error: Failed to create a device group!\n");
        return EXIT_FAILURE;
    }

    // Create a compute context
    //
    context = clCreateContext(0, 1, &device_id, NULL, NULL, &err);
    if (!context)
    {
        ERROR_("Error: Failed to create a compute context!\n");
        return EXIT_FAILURE;
    }

    // Create a command commands
    //
    commands = clCreateCommandQueue(context, device_id, 0, &err);
    if (!commands)
    {
        ERROR_("Error: Failed to create a command commands!\n");
        return EXIT_FAILURE;
    }

    // Create the compute program from the source buffer
    //
    program = clCreateProgramWithSource(context, 1, (const char **) & KernelSource, NULL, &err);
    if (!program)
    {
        ERROR_("Error: Failed to create compute program!\n");
        return EXIT_FAILURE;
    }

    // Build the program executable
    //
    err = clBuildProgram(program, 0, NULL, NULL, NULL, NULL);
    if (err != CL_SUCCESS)
    {
        size_t len;
        char buffer[2048];

        ERROR_("Error: Failed to build program executable!\n");
        clGetProgramBuildInfo(program, device_id, CL_PROGRAM_BUILD_LOG, sizeof(buffer), buffer, &len);
        ERROR__("%s\n", buffer);
        exit(1);
    }

    // Create the compute kernel in the program we wish to run
    //
    kernel = clCreateKernel(program, "square", &err);
    if (!kernel || err != CL_SUCCESS)
    {
        ERROR_("Error: Failed to create compute kernel! \n");
        exit(1);
    }

    // Create the input and output arrays in device memory for our calculation
    //
    if(OCL_INPUT_DATA_SIZE>0)
     input  = clCreateBuffer(context,  CL_MEM_READ_ONLY,  sizeof(float) * OCL_INPUT_DATA_SIZE, NULL, NULL);

    output = clCreateBuffer(context, CL_MEM_WRITE_ONLY, sizeof(float) * OCL_OUTPUT_DATA_SIZE, NULL, NULL);

    if (!input || !output)
    {
        ERROR_("Error: Failed to allocate device memory!\n");
        exit(1);
    }

    ////////////////////////



    // Set the arguments to our compute kernel
    //
    err = 0;
    int count = OCL_PROCESSING_RANGE;

    err  = clSetKernelArg(kernel, 0, sizeof(cl_mem), &input);
    err |= clSetKernelArg(kernel, 1, sizeof(cl_mem), &output);
    err |= clSetKernelArg(kernel, 2, sizeof(unsigned int), &count);

    if (err != CL_SUCCESS)
    {
        ERROR__("Error: Failed to set kernel arguments! %d\n", err);
        exit(1);
    }


    // Get the maximum work group size for executing the kernel on the device
    //
    err = clGetKernelWorkGroupInfo(kernel, device_id, CL_KERNEL_WORK_GROUP_SIZE, sizeof(local), &local, NULL);
    if (err != CL_SUCCESS)
    {
        ERROR__("Error: Failed to retrieve kernel work group info! %d\n", err);
        exit(1);
    }

    return 0;
}

///////////////////

int RunOpenCLtask()
{
  //    DATA_SIZE = frame_size_x*frame_size_y/4;

//     SetupInputData();

   if(0)
     for(int i = 0; i < OCL_INPUT_DATA_SIZE; i++)
     {
         data[i] = frame_bitmap[i] ;
     }


    // Write our data set into the input array in device memory
    //
   if(OCL_INPUT_DATA_SIZE>0)
   {
    err = clEnqueueWriteBuffer(commands, input, CL_TRUE, 0, sizeof(float) * OCL_INPUT_DATA_SIZE, data, 0, NULL, NULL);

    if (err != CL_SUCCESS)
         ERROR_EXIT("Error: Failed to write to source array!\n");
   }



    // Execute the kernel over the entire range of our 1d input data set
    // using the maximum number of work group items for this device
    //
    global = OCL_PROCESSING_RANGE;

    err = clEnqueueNDRangeKernel(commands, kernel, 1, NULL, &global, &local, 0, NULL, NULL);
    if (err)
         ERROR_EXIT("Error: Failed to execute kernel!\n");

    // Wait for the command commands to get serviced before reading back results
    //
    clFinish(commands);

    // Read back the results from the device to verify the output
    //
    err = clEnqueueReadBuffer( commands, output, CL_TRUE, 0, sizeof(float) * OCL_OUTPUT_DATA_SIZE, results, 0, NULL, NULL );
    if (err != CL_SUCCESS)
    {
        ERROR__("Error: Failed to read output array! %d\n", err);
        exit(1);
    }

    if(1)
     for(int i = 0; i < OCL_OUTPUT_DATA_SIZE; i++)
     {
         int x = i%256;
         int y = i/256;
         frame_bitmap[y*550+x] = results[i];
     }

    // Validate our results
    //
//     correct = 0;
//     for(int i = 0; i < count; i++)
//     {
//         if(results[i] - data[i] * data[i]<0.001)
//             correct++;
//     }
//
//     for(int i=0; i<1024; i++)
//     {
//         printf("data %f square %f \n", data[i], data[i]*data[i]);
//         printf("result %f \n", results[i]);
//     }


    // Print a brief summary detailing the results
    //
//    printf("Computed '%d/%d' correct values!\n", correct, count);
 //   alert("Computed '%d/%d' correct values!\n", correct, count);

}

void ShutdownOpenCl()
{
   // Shutdown and cleanup
    //
    clReleaseMemObject(input);
    clReleaseMemObject(output);
    clReleaseProgram(program);
    clReleaseKernel(kernel);
    clReleaseCommandQueue(commands);
    clReleaseContext(context);

}

int writeCLInfo()
{



  int i, j;
  char* value;
  size_t valueSize;
  cl_uint platformCount;
  cl_platform_id* platforms;
  cl_uint deviceCount;
  cl_device_id* devices;
  cl_uint maxComputeUnits;



  // get all platforms

  clGetPlatformIDs(0, NULL, &platformCount);

  platforms = (cl_platform_id*) malloc(sizeof(cl_platform_id) * platformCount);

  clGetPlatformIDs(platformCount, platforms, NULL);



  for (i = 0; i < platformCount; i++) {



      // get all devices

      clGetDeviceIDs(platforms[i], CL_DEVICE_TYPE_ALL, 0, NULL, &deviceCount);

      devices = (cl_device_id*) malloc(sizeof(cl_device_id) * deviceCount);

      clGetDeviceIDs(platforms[i], CL_DEVICE_TYPE_ALL, deviceCount, devices, NULL);



      // for each device print critical attributes

      for (j = 0; j < deviceCount; j++) {



          // print device name

          clGetDeviceInfo(devices[j], CL_DEVICE_NAME, 0, NULL, &valueSize);

          value = (char*) malloc(valueSize);

          clGetDeviceInfo(devices[j], CL_DEVICE_NAME, valueSize, value, NULL);

          printf("%d. Device: %s\n", j+1, value);

          free(value);



          // print hardware device version

          clGetDeviceInfo(devices[j], CL_DEVICE_VERSION, 0, NULL, &valueSize);

          value = (char*) malloc(valueSize);

          clGetDeviceInfo(devices[j], CL_DEVICE_VERSION, valueSize, value, NULL);

          printf(" %d.%d Hardware version: %s\n", j+1, 1, value);

          free(value);



          // print software driver version

          clGetDeviceInfo(devices[j], CL_DRIVER_VERSION, 0, NULL, &valueSize);

          value = (char*) malloc(valueSize);

          clGetDeviceInfo(devices[j], CL_DRIVER_VERSION, valueSize, value, NULL);

          printf(" %d.%d Software version: %s\n", j+1, 2, value);

          free(value);



          // print c version supported by compiler for device

          clGetDeviceInfo(devices[j], CL_DEVICE_OPENCL_C_VERSION, 0, NULL, &valueSize);

          value = (char*) malloc(valueSize);

          clGetDeviceInfo(devices[j], CL_DEVICE_OPENCL_C_VERSION, valueSize, value, NULL);

          printf(" %d.%d OpenCL C version: %s\n", j+1, 3, value);

          free(value);



          // print parallel compute units

          clGetDeviceInfo(devices[j], CL_DEVICE_MAX_COMPUTE_UNITS,

                  sizeof(maxComputeUnits), &maxComputeUnits, NULL);

          printf(" %d.%d Parallel compute units: %d\n", j+1, 4, maxComputeUnits);



      }



      free(devices);



  }



  free(platforms);

    return 0;
}    

On Sunday, September 22, 2019 at 12:33:24 PM UTC+2, fir wrote:

> moge wkleic jakies moje stare notatki/proby z opencl (z 2015, nie pamietam czy to ostatnia wersja ale pamietam ze to dzialalo, i wersja opencl renderowania madelbrota byla najszybsza, pisalem o tym na grupie wiec jest o tym gdzies watek w 2015)

Zapewne przeoczyłem, dopiero niedawno interesuję się OpenCl'em, a i tak
minimalnie. Dzięki za kod.


 
> ale szczerze mowiac nie wiem czy polecalbym sie tym zajmowac, jesli ktos chce zbierac odznaki programistycznego skauta i wpisac opencl do cv to na pewno 
> - w innym wypadku chyba nie

Ostatnio oglądałem tutorial, facio mówi, że uzyskali przyspieszenie 360
razy w OpenCL względem jakiegoś rozwiązania w Matlabie. Chyba więc warto?

To chyba ten tutorial:
https://www.youtube.com/watch?v=VPboVYvSCjI

Pozdrawiam

W dniu niedziela, 22 września 2019 17:19:18 UTC+2 użytkownik M.M. napisał:
> On Sunday, September 22, 2019 at 12:33:24 PM UTC+2, fir wrote:
> 
> > moge wkleic jakies moje stare notatki/proby z opencl (z 2015, nie pamietam czy to ostatnia wersja ale pamietam ze to dzialalo, i wersja opencl renderowania madelbrota byla najszybsza, pisalem o tym na grupie wiec jest o tym gdzies watek w 2015)
> 
> Zapewne przeoczyłem, dopiero niedawno interesuję się OpenCl'em, a i tak
> minimalnie. Dzięki za kod.
> 
> 
>  
> > ale szczerze mowiac nie wiem czy polecalbym sie tym zajmowac, jesli ktos chce zbierac odznaki programistycznego skauta i wpisac opencl do cv to na pewno 
> > - w innym wypadku chyba nie
> 
> Ostatnio oglądałem tutorial, facio mówi, że uzyskali przyspieszenie 360
> razy w OpenCL względem jakiegoś rozwiązania w Matlabie. Chyba więc warto?
> 

Zdaje sie ze keidys juz pisalem ze nazwa zawodu "programista" powinan byc podzielona na co najmniej z 5  bardziej szczegolowych okreslen, np Tworca (tago albo tamtego, z zaznaczeniem ze taki tworca zajmuje sie tworzeniem czyli wymyslaniem jak to ma wygladac), Optymalizator (ktos kto optymalizuje juz napisany  kod) i ew kilka innych np Teoretyk Programowanie (w szczegolnosci jezyka C albo jakichstam systemow) (cos czym sam sie sp[oro zajmowalem) i ew jeszcze pare innych (niezbyt jasne czy mozna np wprowadzic jakichstam projektanotow i implementatorow/klepaczy, Klepacza pewnie tak ale nie jestem pewien czy projektanta bo ja zwykle jak klepalem to projekt sie zmienial za to byc moze da sie wydzielic pojecie jakiegos Ogarniacza/Pomcnika

pytanie jest czy warto byc poprostu az tyle optymalizatorem a tym samym o tyle mniej tworca (sam mam sporo talentu do bycia teoretykiem ale tez odrebne pytanie ile warto w to inwestowac)

W dniu niedziela, 22 września 2019 17:52:23 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 22 września 2019 17:19:18 UTC+2 użytkownik M.M. napisał:
> > On Sunday, September 22, 2019 at 12:33:24 PM UTC+2, fir wrote:
> > 
> > > moge wkleic jakies moje stare notatki/proby z opencl (z 2015, nie pamietam czy to ostatnia wersja ale pamietam ze to dzialalo, i wersja opencl renderowania madelbrota byla najszybsza, pisalem o tym na grupie wiec jest o tym gdzies watek w 2015)
> > 
> > Zapewne przeoczyłem, dopiero niedawno interesuję się OpenCl'em, a i tak
> > minimalnie. Dzięki za kod.
> > 
> > 
> >  
> > > ale szczerze mowiac nie wiem czy polecalbym sie tym zajmowac, jesli ktos chce zbierac odznaki programistycznego skauta i wpisac opencl do cv to na pewno 
> > > - w innym wypadku chyba nie
> > 
> > Ostatnio oglądałem tutorial, facio mówi, że uzyskali przyspieszenie 360
> > razy w OpenCL względem jakiegoś rozwiązania w Matlabie. Chyba więc warto?
> > 
> 
> Zdaje sie ze keidys juz pisalem ze nazwa zawodu "programista" powinan byc podzielona na co najmniej z 5  bardziej szczegolowych okreslen, np Tworca (tago albo tamtego, z zaznaczeniem ze taki tworca zajmuje sie tworzeniem czyli wymyslaniem jak to ma wygladac), Optymalizator (ktos kto optymalizuje juz napisany  kod) i ew kilka innych np Teoretyk Programowanie (w szczegolnosci jezyka C albo jakichstam systemow) (cos czym sam sie sp[oro zajmowalem) i ew jeszcze pare innych (niezbyt jasne czy mozna np wprowadzic jakichstam projektanotow i implementatorow/klepaczy, Klepacza pewnie tak ale nie jestem pewien czy projektanta bo ja zwykle jak klepalem to projekt sie zmienial za to byc moze da sie wydzielic pojecie jakiegos Ogarniacza/Pomcnika

(czyli testera/pisacza dokumentacji, robicza archiwow, utrzymywacza stronki itd)

z kolei wspominajas o Tworcy nie mam na mysli tzw Designera co bardziej pewne polaczenie Designera z prototypistą (dosyc ciezka robota, znam z zycia)

Z kolei zamiast projektanta ew mozna by wprowadzic moze Konceptualiste jest to tez mega ciezka robota z pogranicza Klepacza i Tworcy i polaga ona na wykonceptualizowaniu pewnych rozwiazan ktore pozniej z jednej strony mozna kodowac i prototypowac po stronie kodu a z drugiej widzialnie 'Designowac' i prototypowac po stronie widzialnej

dla mnie nadrzednym problemem jest w co inwestowac ile czasu by zdolac cos oryginalnego wykodowac, ze powtorze szypko

1. Tworca
2. Konceptualista
3. Klepacz
4. Pomocnik

5. Optymalizator
6. Teoretyk

dwu ostatnich mozna od biedy wywalic a newet i tego 3ciego od konca moze tez

(o tyle dla mnie, jesli jakies dzialo mialoby byc moim celem te opencl spada z listy priorytetow)

> 
> pytanie jest czy warto byc poprostu az tyle optymalizatorem a tym samym o tyle mniej tworca (sam mam sporo talentu do bycia teoretykiem ale tez odrebne pytanie ile warto w to inwestowac)

W dniu niedziela, 22 września 2019 18:09:03 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 22 września 2019 17:52:23 UTC+2 użytkownik fir napisał:
> > W dniu niedziela, 22 września 2019 17:19:18 UTC+2 użytkownik M.M. napisał:
> > > On Sunday, September 22, 2019 at 12:33:24 PM UTC+2, fir wrote:
> > > 
> > > > moge wkleic jakies moje stare notatki/proby z opencl (z 2015, nie pamietam czy to ostatnia wersja ale pamietam ze to dzialalo, i wersja opencl renderowania madelbrota byla najszybsza, pisalem o tym na grupie wiec jest o tym gdzies watek w 2015)
> > > 
> > > Zapewne przeoczyłem, dopiero niedawno interesuję się OpenCl'em, a i tak
> > > minimalnie. Dzięki za kod.
> > > 
> > > 
> > >  
> > > > ale szczerze mowiac nie wiem czy polecalbym sie tym zajmowac, jesli ktos chce zbierac odznaki programistycznego skauta i wpisac opencl do cv to na pewno 
> > > > - w innym wypadku chyba nie
> > > 
> > > Ostatnio oglądałem tutorial, facio mówi, że uzyskali przyspieszenie 360
> > > razy w OpenCL względem jakiegoś rozwiązania w Matlabie. Chyba więc warto?
> > > 
> > 
> > Zdaje sie ze keidys juz pisalem ze nazwa zawodu "programista" powinan byc podzielona na co najmniej z 5  bardziej szczegolowych okreslen, np Tworca (tago albo tamtego, z zaznaczeniem ze taki tworca zajmuje sie tworzeniem czyli wymyslaniem jak to ma wygladac), Optymalizator (ktos kto optymalizuje juz napisany  kod) i ew kilka innych np Teoretyk Programowanie (w szczegolnosci jezyka C albo jakichstam systemow) (cos czym sam sie sp[oro zajmowalem) i ew jeszcze pare innych (niezbyt jasne czy mozna np wprowadzic jakichstam projektanotow i implementatorow/klepaczy, Klepacza pewnie tak ale nie jestem pewien czy projektanta bo ja zwykle jak klepalem to projekt sie zmienial za to byc moze da sie wydzielic pojecie jakiegos Ogarniacza/Pomcnika
> 
> (czyli testera/pisacza dokumentacji, robicza archiwow, utrzymywacza stronki itd)
> 
> z kolei wspominajas o Tworcy nie mam na mysli tzw Designera co bardziej pewne polaczenie Designera z prototypistą (dosyc ciezka robota, znam z zycia)
> 
> Z kolei zamiast projektanta ew mozna by wprowadzic moze Konceptualiste jest to tez mega ciezka robota z pogranicza Klepacza i Tworcy i polaga ona na wykonceptualizowaniu pewnych rozwiazan ktore pozniej z jednej strony mozna kodowac i prototypowac po stronie kodu a z drugiej widzialnie 'Designowac' i prototypowac po stronie widzialnej
> 
> dla mnie nadrzednym problemem jest w co inwestowac ile czasu by zdolac cos oryginalnego wykodowac, ze powtorze szypko
> 
> 1. Tworca
> 2. Konceptualista
> 3. Klepacz
> 4. Pomocnik
> 
> 5. Optymalizator
> 6. Teoretyk
> 

emo mi przypomniala ze trzbby dodac chyba jeszcze funkcje powiedzmy Ucznia - kogos kto np czyta tutoriale i sie uczy, (np api) ale nie wiem czy nie dodac jej do pomocnika (bo tego pomocnika widze troche jak takiego googlatora - tak naprawde ta funkcje mozna by wydzielic tez w odrebna osobe, ktorej mozna by mowidz - znajdz mi to a to w dokumentacji/google i podaj mi jak np zrobic to a to (np przelaczyc okna na fullscreen itd - taka robota nie jest moim zdaniem w gesti Klepacza ktory i tak ma duzo do roboty)


> dwu ostatnich mozna od biedy wywalic a newet i tego 3ciego od konca moze tez
> 
> (o tyle dla mnie, jesli jakies dzialo mialoby byc moim celem te opencl spada z listy priorytetow)
> 
> > 
> > pytanie jest czy warto byc poprostu az tyle optymalizatorem a tym samym o tyle mniej tworca (sam mam sporo talentu do bycia teoretykiem ale tez odrebne pytanie ile warto w to inwestowac)

W dniu niedziela, 22 września 2019 17:19:18 UTC+2 użytkownik M.M. napisał:
> On Sunday, September 22, 2019 at 12:33:24 PM UTC+2, fir wrote:
> 
> > moge wkleic jakies moje stare notatki/proby z opencl (z 2015, nie pamietam czy to ostatnia wersja ale pamietam ze to dzialalo, i wersja opencl renderowania madelbrota byla najszybsza, pisalem o tym na grupie wiec jest o tym gdzies watek w 2015)
> 
> Zapewne przeoczyłem, dopiero niedawno interesuję się OpenCl'em, a i tak
> minimalnie. Dzięki za kod.
> 
> 
ten kod to nic takiego wziete to jest z jakiegos tutoriala tyle ze costam przerobilem na swoje i sprawdzilem czy dziala

wymaga pewnie jedynie ze 2 godzin skupienia by odpalic i zrozumiec, 
zieaw, pytanie jednak czy warto to robic z powodow o ktorych pisalem oraz zniechecajace jest to ze nie jestem przekonany czy nie jest tak jak za dawnych czasow ze kod zoptymalizowany pod jedna karte nie bedzie zoptymalizowany pod druga (jesli wogole zdziala.. to jest troche zniechecajace i sgereuje byc moze ze mozna troche poczekac z zajmowaniem sie tym - no chyba ze ktos naprawde sie interesuje wlasnie tym

jest to i tak chyba ciekawsze niz android, za kttorego aj czuje ze pwnienem sie wziac gdybym mial wrocic do roboty ale cos nie moge sie zmusic (bo ciagle zasysa mnei w kierunku c ;c )

> (bo ciagle zasysa mnei w kierunku c ;c )

tzn jesli wogle mi sie chce myslec o programowaniu bo nie za specjalnie, straszne czasy nastaly :U

W dniu wtorek, 17 września 2019 20:10:06 UTC+2 użytkownik M.M. napisał:
> Dziś zobaczyłem pierwszy w rankingu wydajności procesor AMD EPYC
> zawierający 64 rdzenie:
> 
> https://www.cpubenchmark.net/cpu.php?cpu=AMD+EPYC+7742&id=3547
> 
> 
> Mocno wyprzedził w rankingu zarówno najlepszy procesor Intela jak i
> dotychczasowy procesor AMD, aż trudno uwierzyć:
> 
> https://www.cpubenchmark.net/high_end_cpus.html
> 
> Cena też nie jest mała, 7tys USD.
> 
> Pozdrawiam

Ostatnio jakaś firma zrobiła "czip" z 400000 rdzeni, więc całkiem niedaleko tytułowego miliona:

https://www.cerebras.net/

Tajemnica w tym, że jeden taki "czip" się robi z całego krzemowego wafla.