W dniu poniedziałek, 14 grudnia 2015 01:55:26 UTC+1 użytkownik ACMM-033 napisał:
> Użytkownik "Przemysław Ryk" <przemyslaw.ryk@gmail.com> napisał w wiadomości
> news:nr3qxtq75v0g$.dlg@maverick.przemekryk.no-ip.info...
> > Dnia Sun, 13 Dec 2015 23:55:58 +0000, 2late napisał(a):
> >
> >>>> A po zlozeniu tego kompa, jakiego softu uzyles do kompresji video za
> >>>> pomoca
> >>>> CUDA?
> >>>
> >>> Adobe Premiere Pro. Photoshop te nie miał problemów z użyciem CUDA.
> >>
> >> A uzycie CPU podczas kompresji 100%.
> >
> > Akurat jednakowoż nie. :D
>
> Tak sobie myślę, skoro każdy ułamek mocy do obliczeń jest cenny, to czyż nie
> szybciej by było (może niewiele, ale zawsze coś...?), aby oba procki, ten
> graficzny, i ten podstawowy, liczyły, co trzeba? Jakby mi "cudak" liczył np.
> BOINC, czy cokolwiek innego (podobno można), to by mi szybciej wyniki
> wypluwał. Np. zamiast co 2 godziny, to co 10 minut? Myślę... myślę...
> jeszcze o tym poczytam, mam kartę z cudakiem, to chociaż bym wykorzystał, by
> się nie nudziła.
>
o gpu nie mowi sie procek, szczena opada od takich wyrazen
gpu to system ktorego czescia jest uklad słabych procków (jeden taki procek by
za wiele nie 'policzyl')
tak samo co to jest cudak?
cuda (cudak?) nie 'liczy' bo cuda to interfejs (i to raczej drugorzędny w
stosunku do opencl)
(cuda i open cl maja mw tyle do gpu co do gpu maja odpowiednio directx i
opengl) wiec gadanie cudak mi policzy mw brzmi tak samo sensownie jak
direktiksiak mi to policzy (direktuksiak zreszta o ile wiem tez moze to
policzyc aside cuda i opencl)]
(liczą procki na gpu wygonujace kod w tzw 'warpach' - jeden warp to cos w
rodzaju strumienia/przebiegu procesora ktory wykonuje kod na rejestrach
analogicznych do sse w zwyklym procesorze; kazdy taki warp sklada sie z pewnej
ilosci skalarnych kanałow, same te warpy są pogrupowane w grupy i dla
programisty o ile pamietam
logiczna jednostką na ktora pisze sie kody
są wlasnie 'logiczne' grupy warpów, wszystkim zarządza ukryty manager ktory
tlumaczy te logiczne grupy na konkretnie fizyczne zasoby (tym samym niestety
takie godowanie przypomina roche interpreter, nie do konca mi sie to podoba)
[od dosyc niedawna ucze sie kodowania kerneli w opencl tak ze nie koniecznie
moge to jasno przedstawic, i niektre moje wypowiedzi co do tych logicznych grup
moga byc nieco niescisle, jednakowoz sporo materialow na te tematy jest
dostepnych w necie - zgadza sie ze troche zagmatwanych w czytaniu ]
przy okazji moge wspomniec ze nie ma co sie tak napalac na konkretne wyniki
typu sialalalala wrzuce to na cudaka procka i cudak pip pip bruku bryk mi to
policzusi
10 minutusiow zamiast dwu godzinusiuw hop hop** bo najpierw trzeba kod
zakodowac, (co nie jest takie hop siup tralalala, programistow ktorzy ogarniaja
kodowanie na gpu nie jest tak duzo do tego na gpu uruchamia sie specyficzne
kody), pozniej musi sie on wykonac na konkretnym sprzecie (z czym moga byc
wieksze albo mniejsze problemy), a na koniec musi byc jakas przyzwoita
wydajnosc o co tez nie jest latwo.. czysty hardware gpu ma wiekszy potencjal
nic cpu bo ma wieksza ogolna 'przepsutowosc' (mam na mysli ilosc danych jaka
mozna przetwozyc na sekunde) ale tez nie jest to jak na dzis przepsutowosc
wieksza setki razy a jedynie kilka (mowiac ostrozniej) do kilkunastu razy
(mowiac optymistyczniej).. do tego tą czysta przepustowosc da sie osiagnac zle
zalezy kiedy.. te moje oszacowania 10x byly raczej optymistyczne (zalezy jaka
karte porownywac z jakim prockiem i dla jakich kodow) ale mialem na mysli mw to
ze z grubsza o takim czynniku moze to byc mowa, na tyle na ile sie na tym znam
(jako srednio zaawansowany koder i poczatkujacy w opencl)
** z drugiej strony kodowanie na gpu moza przydac sie do o wielo wiecej rzeczy
niz takie batchowe obliczenia i przetwazanie,
naprawde moze sie to przydac w wiekszosci sytuacji gdy kod przetwaza duzy
strumien danych na sekunde, czyli wlasciwie w wiekszosci przypakow gdy
obciazenie procesora dochodzi do 99% (czy tam stu) i wisi
|