🚀 go-pugleaf

"biki" <biki@viper.pl> wrote in message 
news:962A8E53Ebikikillerradomnet@193.110.122.97...
> zna sie kto dobrze na watkach w windozie?
> konkretnie chodzi mi o synchronizacje.
> chce sobie zrobic rendering i occlusion culling na osobnych watkach
> i troche mi sie to kwasi bo nie umiem posynchronizowac?
> konkretnie jest tak.
>
> glowny watek uruchamia watek cullera ktory sobie liczy widocznosc sceny
> i widoczne obiekty wrzuca do listy (na koniec)
> glowny program zaraz po tym wywolaniu zaczyna sprawdzac czy cos sie
> pojawilo na liscie i jesli tak to to renderuje. no i mam kwas..
>
>
> tak wyglada procka watku.
> robi swoje a potem sygnalizuje ze skonczyla
>
> DWORD  WINAPI _ThreadFunc(LPVOID  param) {
> culler *cull;
>  cull=(culler*)param;
>  cull->OcclusionCulling();
>  cull->culling_in_progress=0;
> }
>
> tu ustawiam flage zeruje liste i odpalam watek
> void culler::ThreadedOcclusionCulling(void) {
>  culling_in_progress=1;
>  items=NULL; tail=NULL;
>  othread=CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)_ThreadFunc,this,0,
> &thread_id);
> }
>
> tu pobieram pierwszy element na liscie
> jesli jeszcze nie ma to czekam az sie pojawi albo culler skonczy prace
> i zwracam nowy obiekt ktory sie pojawil albo null
>
> node *culler::GetFirstNode(void){
>  while (items==NULL) {
>    if (culling_in_progress==0) return NULL;

Sleep(0); // zeby wymusic uspienie tego a obudzic culling (lub cos tam 
innego)

ale i tak generujesz sobie waiting condition
bo jak z innego watku wywolujesz GetFirstNode(...)
to tamten czeka i czeka, i czeka na wynik i zrzera czekaniem czas procka 
ciagle sprawdzajac warunek we while'u

>  }
>  temp_node=items;
>  return temp_node;
> }
>
> tu pobieram kolejny obiekt podobnie synchronizujac z cullerem
>
> node *culler::GetNextNode(void) {
>  while (temp_node->next==NULL) {
>    if (culling_in_progress==0) return NULL;

Sleep(0);


>  }
>  temp_node=temp_node->next;
>  return temp_node;
> }
>
>
> no i kicha polega na tym ze jak miedzy odpaleniem watku a pobraniem
> pierwszego obiektu wyniku mija dlugi czas jest ok
> ale jak chce to robic w pelni rownolegle to efekt jest taki jakby culler
> skonczyl prace a na liscie nic nie bylo.
>
> moze ktorys pomoc??

na pierwszy rzut oka wyglada oki, poza tym wspomnianym waiting condition
moze kompilator chce zabardzo pooptymalizowac ? daj
volatile bool culling_in_progress; jesli jeszcze nie masz

-- 
MX 

tak zrobilem i dziala bez zarzutu. :))

> chce sobie zrobic rendering i occlusion culling na osobnych watkach
> i troche mi sie to kwasi bo nie umiem posynchronizowac?
> konkretnie jest tak.

Takie mało pytanko z mojej strony, jest sens stosowania takiego 
"wątkowania" w przypadku aplikacji nieinteraktywnej typu demo ? :)

Tzn. co mi to da? Jeden wątek Render, ok, drugi cull, ale czy na tym 
jest jakiś wzrost wydajności/przepustowości ?  Chodzi o procki HT ?


-- 
Venire

tylko chcialem poeksperymentowac. okazuje sie ze na moim sprzecie dopalki 
nie daje zadnej. a spodziewalem sie choc odrobiny. bo kiedy akcelerator 
sobie rysuje watek przygotowuje kolejne dane rownolegle.. ale moze zrobilem 
jakis banalny blad w rozumowaniu. nic to. na bledach czlowiek sie uczy.

"venire" <venire@o2.pl> wrote in message 
news:d2h9t7$qgk$1@inews.gazeta.pl...
>> chce sobie zrobic rendering i occlusion culling na osobnych watkach
>> i troche mi sie to kwasi bo nie umiem posynchronizowac?
>> konkretnie jest tak.
>
> Takie mało pytanko z mojej strony, jest sens stosowania takiego 
> "wątkowania" w przypadku aplikacji nieinteraktywnej typu demo ? :)
>
> Tzn. co mi to da? Jeden wątek Render, ok, drugi cull, ale czy na tym jest 
> jakiś wzrost wydajności/przepustowości ?  Chodzi o procki HT ?

w tym konkretnym wypadku wzrostu wydajnosci akurat bym sie nie spodziewal
gdyby to dzialalo troche inaczej to moze.

np. gdyby culler przygotowywal dane dla nastepnej klatki
a renderer bral sobie z listy przygotowanej juz w poprzedniej klatce i 
procesowal obecna klatke
(w sesie ustawianie shaderow, textur, DrawPrimitive itp.)
to powinno to dac jakis tam zauwazalny skok wydajnosci na prockach z HT

-- 
mx 

> bo kiedy akcelerator sobie rysuje watek przygotowuje kolejne dane 
> rownolegle.. ale moze zrobilem
> jakis banalny blad w rozumowaniu. nic to. na bledach czlowiek sie uczy.

A to moze testnij "klasyczna" prace rownolegla GPU i CPU. Jest kilka 
newralgicznych punktow gdzie mozna to uzyc. Jednym z nich jest np Present z 
dx-a lub swapbuffers z ogl. Normalnie wyglada to tak ze Present czeka na 
karte graficzna (i tu podkreslam, ze to nie prawda ze to present powoduje 
rendering klatki z kolejki (bo czasem takie stwierdzenia sie pojawiaja :) ).

Ten czas mozna zagospodarowac - jak rendering trwa dluzej to daje to 
znakomite efekty.

Przyklad:

Robilem test aplikacji 3d pracujacej przy ok 20 FPS. NvPerfHud pokazal duzy 
czas spedzony w driverku (co jest ok - Present czeka na karte). Ten czas 
wynosil iles tam msec (nie pamietam ile).

Teraz tuz przed wywolaniem Present wstawilem zwykly kodzik mocno obciazajacy 
CPU - taki zeby wykonywal sie okolo tych msec podanych przez nvperf-a.

Wyniczek:

NvPerfHud pokazal zmiane - juz nie sterownik blokowal, a aplikacja. 
Natomiast wykres czasu dla ramki sie nie zmienil - wciaz bylo 20 FPS. 
Zwiekszenie obciazenia kodu CPU przed present o kilka msec - ale 
przekraczajacych wyniki z nvperf-a zwiekszylo dokladnie o tyle msec czas 
trwania ramki (przeciazenie przez CPU). (ofkoz danie tego kodu CPU >>po<< 
Present udezylo natychmiast w FPS).


Sorry za wywod jezeli to nie na temat (niewyspany jestem :D). Ale moze 
testnij umieszczenie tych obliczen wlasnie w czasie jak juz nie ma nic do 
roboty a sterownyk tylko czeka na karte ?. Jest wiecej takich miejsc - np 
locki, obsluga rtargetow itp.


Pozdr.
       st3tc

hmm.. warto sie z tym pobawic.. dzieki.