-
11. Data: 2011-11-03 06:26:12
Temat: Re: na 4rech procesorach
Od: " " <f...@N...gazeta.pl>
Wiktor S. <wswiktor&poczta,fm@no.spam> napisał(a):
> > czy takie pisania do zwyklej tablicy (kazdy watek do swojej czesci)
> > tez trzeba synchronizowac? byloby to glupie i niedobre
>
> jeśli każdy do osobnego obszaru, oraz jeżeli jeden wątek nie będzie w
> trakcie renderowania odczytywał wyników pracy innego wątku, to
> synchronizacji nie trzeba.
>
>
ok, no to moze napisze to nawet pozniej i spytam w necie czy ktos mi
to na 4procesorowym kompie przetestuje -mam nadzieje ze zadziala od razu
bo takie testowanie z przerwami to nie jest wygodna rzecz
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
-
12. Data: 2011-11-03 07:23:58
Temat: Re: na 4rech procesorach
Od: " " <f...@N...gazeta.pl>
Robert Winkler <n...@n...org> napisał(a):
> > nie wiem co nazywasz pamiecia ekranu, ale ja renderuje
> > do zwyklej tablicy bajtow (konkretnie jest to wskaznik jaki
> > zwraca funkcja createDibSection, ale jest to raczej zwykla tablica
> > ramu tyle ze zaalokowana wewnetrznie przez winde, pozniej dopiero
> > to sie blituje do pamieci video);
>
> Nie podajesz źródeł więc skąd mamy wiedzieć
> że robisz to z wykorzystaniem bitmapy utworzonej poza ekranem.
> Załóz project na przykład na github i wrzuć źródła.
>
> > czy takie pisania do zwyklej tablicy (kazdy watek do swojej czesci)
> > tez trzeba synchronizowac? byloby to glupie i niedobre
>
> Jesli jestes absolutnie pewiem ze jakiś fragment bitmapy
> nie będzie znajdował się jednocześnie w cache dróch różnych rdzeni
> (procesorów)
> to nie potrzebujesz synchronizacji.
> Nie jest to jednak pewne, cache nie pracuje na poziomie pojedyńczych
komórek
> pamięci
> ale kilkunasto bajtowych linii.
> (w niektórych procesorach to nawet 512 bajtów, nie jest to jednak żaden
> procesor rodziny x86)
>
> btw.
> Skoro renderujesz to do bitmapy stworzonej poza pamięcią ekranu
> to co za problem stworzyć 4 niezależne bitmapy,
> po jednaj dla kazdego wątku.
> Każda z nich zawierała by fragment całości (1/4 wysokości)
> po zakończeniu wszystkich wątków przepisałbyś je BitBlt-em
> do jednej bitmapy, podając odpowiedno parametr Y gdzie ma być ona skpiowana.
>
> Widziałeś jak wygląda raytracing na maszynie z 80-ma równoległymi wątkami?
> (4 Xeony po 10 rdzeni każdy plus HT żeby podwoić liczbe wątków)
> http://www.youtube.com/watch?v=zbokPe4_-mY
///////
co do zrodel :
podawalem kluczowe kawalki zrodel co prawda w roznych
postach rozrzuconych na grupach (podzial kodu na pliki, jak
wyglada u mnie glowna petla, jak wygladaja same blity tez
(to akurat dawniej), jak uzywam query performance countera
do mierzenia czasu, jak ogolnie wyglada moja filozofia
agentowa, sam kawalek obliczania koloru (toporny i nieladny
co prawda) itd...) podam zreszta jeszcze na pewno inne kawalki
w miare mojego nimi zainteresowania (bo zarowno jak jestem
z czegos niezadowolony jak i zadowolony to lubie to
porozwazac i omowic w poscie);
Nie za bardzo chce podac cale zrodla gotowe do skompilowania
po prostu kliknieciem bo tak jak tomasz biskup kiedys
powiedzial: nie chce by ktos to pogarszal i przerabial na
niepodobajace mi sie sposoby (nie mowie ze moje zrodla sa
specjalnie dobre - takie sobie); Ogolnie jak ktos jest
zainteresowany to moge powiedziec jak cos robie i nawet
przekleic (nawet wypracowane) kawalki kodu ale ten ktos
niech lepiej pozniej swoj program napisze po swojemu. :}
i najlpeiej przylaczy sie do dyskusji i wniesie cos od
siebie do zagadnienia;
////////
co do meritum:
moge zrobic czetery pixelbufory i blitowac 4 razy ale
jest to mz troche nienaturalne; kawalki sa rozlaczne
wiec z normalnymi konfliktami nie powinno byc
problemu; czy ta bitmapa/pixelbufor jest alokowana do
jak wyrownanego adresu to nie wiem... sama ta bitmapa
jest wyrownana w poziomie do 4 pixeli (kazdy pixel
4 bajty) wiec o ile poczatek jest wyrownany do 16B lub
lepiej to kawalki tez sa wyrownane do 16B (jest jakis
sposob by wyrownywac to co jest alokowane przez malloc
np? pamietam z jednej ksiazki ze kriss kasperski wyrownywał
kiedys do 4096 (granicy sttrony czy cos takiego) i chyba
dawala to duze przyspieszenia; nie wiem jak z tym 'zachodzeniem
cacheow' i na czym to mialoby polegac - mz jak jeden watek
przelacza milion razy na sekunde komorke 0x11111111
a drugi 0x11111112 (nawet w tej samej lini cache) to chyba
nie powinno byc problemow z przeklamaniami - choc pewnie
moglyby byc opoznienia; Co do samego pisania do pamieci
ekranu to nie wiem czy jest to mozliwe - raczej nie;
ta pamiec nie jest zwyklym ramem (nie wiem wogole jaka nazwa
tu jest adekwatna VRAM?) i nie wiem czy mozna dostac wskaznik
do niej raczej nie - zaluje ze nie wiem jak komunikowac
sie z karta na poziomie drivera; na poziomie obslugi drivera
to jest na pewno jakies api a na poziomie wnetrza samego
drivera to nie wiem jak ta komunikacja miedzy CPU+RAM a GPU+VRAM
idzie czy przez jakis 'dzielony ram' czy przez te asemblerowe
'out'
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
-
13. Data: 2011-11-04 02:32:30
Temat: Re: na 4rech procesorach
Od: "Wiktor S." <wswiktor&poczta,fm@no.spam>
> Jesli jestes absolutnie pewiem ze jakiś fragment bitmapy
> nie będzie znajdował się jednocześnie w cache dróch różnych rdzeni
> (procesorów)
> to nie potrzebujesz synchronizacji.
twierdzisz że jeżeli do tablicy jest tylko ZAPIS, a potem i tak czekamy na
wszystkie wątki,
to nadal trzeba synchronizować dostęp?
to by była tragedia...
--
Azarien