Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > pl.comp.programming > #33116

Re: Kiedy będzie milion rdzeni?

Newsgroups pl.comp.programming
Date 2019-09-22 03:11 -0700
References <d22e4ca1-bc54-4f21-a8ed-f35f79ba2937@googlegroups.com> <298b5ab7-c4d6-4042-abe7-274d84e79bc7@googlegroups.com> <669e4acc-5c14-415e-b4ee-fb81bf042fd4@googlegroups.com> <efe683a2-19a1-4134-8a97-2fb4b9bfe040@googlegroups.com>
Message-ID <c22b56c2-a2ca-44fe-b006-e9e3f059b502@googlegroups.com> (permalink)
Subject Re: Kiedy będzie milion rdzeni?
From fir <profesor.fir@gmail.com>

Show all headers | View raw


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

Back to pl.comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Kiedy będzie milion rdzeni? "M.M." <mmarszik@gmail.com> - 2019-09-17 11:10 -0700
  Re: Kiedy będzie milion rdzeni? Wojciech Muła <wojtek.mula@gmail.com> - 2019-09-17 11:45 -0700
    Re: Kiedy będzie milion rdzeni? "M.M." <mmarszik@gmail.com> - 2019-09-17 12:15 -0700
      Re: Kiedy będzie milion rdzeni? kropelka@gmail.com - 2019-09-18 19:55 -0700
        Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-19 02:00 -0700
        Re: Kiedy będzie milion rdzeni? "M.M." <mmarszik@gmail.com> - 2019-09-20 06:00 -0700
          Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-22 03:33 -0700
            Re: Kiedy będzie milion rdzeni? "M.M." <mmarszik@gmail.com> - 2019-09-22 08:19 -0700
              Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-22 08:52 -0700
                Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-22 09:09 -0700
                Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-22 12:05 -0700
              Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-26 10:26 -0700
                Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-26 10:29 -0700
  Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-18 06:29 -0700
    Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-18 06:46 -0700
      Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-18 06:50 -0700
      Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-19 12:12 -0700
        Re: Kiedy będzie milion rdzeni? fir <profesor.fir@gmail.com> - 2019-09-22 03:11 -0700
  Re: Kiedy będzie milion rdzeni? godek.maciek@gmail.com - 2019-10-17 02:03 -0700

csiph-web