- Haydi bakalim neymi bu:
===========================

Once upon  a  time, diye  balayalm...Burda  ok basit  de olsa  ufak   bi yaz
dizisi ile az  ok basit  bi demo framework  tarz bii  nasl hazrlanr  ondan
bahsetmeye alacam.  Burda anlatacam  eyin,  yuzyirmisekiz byte,  drt  k
v.b  tarz  demolara   pek  apply  edilemeyeceini   syleyebilirim.  Daha   ok
bahsetmek istediim  ey,  yapsal olarak  biraz  da flexible  bi  design  nasl
yaparz onun stne deineceim. 

ncelikle  bir  design'a  balamadan   nce  temel  yap  talarmza   bakalm.
Nelerlazm bize sonuta.  Dnelim bakalm.  Demo dediimiz  eyi standart  bir
oyunapplication v.s.  gibi eylerden  ayran taraf,  user interaction  ksmnn
hemenhemen hi  olmamas. Yani  'escape'  dndaki bir  tuu kontrol  eden  bir
demotrne henz rastlamadm  (ok enderdir, yok  space'e basarsn secret  music
gelirfalan  filan...)  Bu  yzden  o  adan  epey  bir  anslyz.  Yani   user
interactionyoksa  herey   daha  bi   kontrol   altnda  olur.   Aslnda   temel
yapacamz ey  birmzik/ses v.s.  eliinde sunacamz  grntsel  effectler
zinciri tarznda,o  anki yaptmz  makinada yaplmas  gerekten zor  olup  ve
grsel olarak  dasanatsal  bi  taraf  olan bi  yapdr.  Yani  aslnda...  Film
ekiyoruz...  Balarve  bir  sre  sonra   da  biter.  Hi  bir  ey   farkllk
gstermez.  ok  enterasanekillerde   hazrlanm  bariz  randomize   effectler
dnda her  altrdmzda ayn  saliselerde ayn  grntleri grr..  ayn
sesleri duyarz. O  zamanburdan una  gelebiliriz ki, en  salam olmas  gereken
yerimiz,  bizim  timing  control'umuz  diyebiliriz.  Yani  istediimiz  eyleri,
istediimiz  anlarda  yapmamz  salayan  bir   yap.  Bunu  yle  bir   design
etmeliyiz ki, ufack bir deiiklik yapmak bize pahalya patlamamal. 

Tamam timing  olay  bir yana,  bunun  dnda  neler gerekiyor.  Temel  bi  gfx
libtasarm !?  ...Hmm tam  olarak deil.  nk neticede  'standard'n  dnda
bireyler  yapacamz  iin  bize   uygun  bir  library  oluturulabilinir   mi
bilemiyorum. Tpk  AI library'leri  gibi dnn.  Her oyunda  kullanilabilecek
bir AIlibrary'si yazmak  mmkn m !?  Hayr deil. Neticede  AI dediimiz  ey,
fake'lerden  ibaret,  oyununa  gre  yapacan  fake,  veya  izleyecein  yntem
deiir.Ancak tabi  ki baz  belli  bal yaplar  var...  rnein bir  AI  iin
bakarsak,ne bileyim ben bir path finding nemli yap talarndan  biri.  (Haaala
anlamdeilim  niye  path   finding'i  AI  sayarlar...   o  ayr  konu).   Yani
yapacamz eyin iine bunu koyabiliriz.. Ama general bii  yapmak  imkansz...
Ayns demogfx lib'i iin  de geerli. Ne koyabiliriz  ki iine... ok basit  ve
genel eyleri  !?  Nedir bu...  Bir  gurup tridi  objeyi ok  rahat  bi  ekilde
ekrana istedigimiz ader'la  basabilecek bir  yap !?  Yoksa procedural  texture
hazrlaypo texture'u  ekrana basan  bi yap  !? Yoksa  3-5 pass'de  hazrlanm
3-5 textureu  alp  onlara screen  space  effect ile  post-processing  yapan  bi
yap!? Yoksahepsi  mi  !? Yani  yok  bunun  tam cevab.  Mkemmelini  de  yapmak
imkansz. ki  gnsonra  aklnza "yaa  hadi  burda da  bezierlerden  4.  derece
fractal biii  izdirip arkasnda  da radiosity  hodo hodosu"  yapiim  dediiniz
anda o library'den tek bir function armyot durumunda bulacaksnz kendinizi.
Ama, bi ok  eyi kolaylatrabilmemizi salayan bi  yap yapmak elbette mmkn.
Buna deineceiz.

Baka  neyimiz  var   bunlarn  yani  sra??..Mzik!..   Evet  mzik  veya   ses
effectleri. Burda yaplacak  abart miktarda birey  yok akas. Genel  olarak
seseffect'leri  ok  kullanlmaz.  Yani  ya  direk  mziin  iine  gmldr  o
effectlerya da... Yoktur..  O yzden  demo'muz balad  andan itibaren  sadece
'play' diyip, arkasndan hereyi kendi haline brakmak herzaman en  gzel  zm
gibidir.

Temel   bi    bakta    bu       component    yeterli   gibi    gzkse    de
(timing/gfx/music)bunlarn yan sra  arka planda olup  da bizim iimizi  cidden
ok feci  anlamdakolaylatran  bi  ka yap  daha  vardr.  Bunlarn  arasnda,
memory  manager,   resource   manager  (texture,sound,me..vs.   gibi   eylerin
yuklenme mekanizmasve demo tarafndan eriebilirlii..) ve en  nemlisi  thread
manager  librarysi.Biliyosunuz  artk  gnmzde   bir  adet  CPU  diye   birey
kalmad. Bir  adet CPUbile  olsa  sistemde bir  de GPU  diye  bi kavram  var  ki
bunlardan maximum performans  elde etmek  istiyosak bunlarn  senkronizasyonunu
ok ok ok iyi bi ekilde salamak zorundayz. ki...  Gnmzde  hemen hemen bi
ok kiide artkya dual-pentium ya da en azndan  hyper-thread  pentium ayarnda
aletler var. Kalkip da CPU'nun %50'sini kullanan ve GPU ile sync  olmayan  (yani
GPU  calrken   CPU  bekler   veya  CPU   calrken  GPU   bekler)  bi   yap
hazrladmzdamakinadan  alacamz  performans  kafadan  te  birine  der.
te burdakisync olaylar iin kesinlikle bir thread manager,  task  managervari
bir yapkesinlikle arttr.  Bi taraftan  CPU'nun biri  bi procedural  texture'u
hazrlarken (ki..aslnda  GPU'da da  mmkn) dier  taraftan dier  CPU  meleri
sortederken GPU'da  bi onceki  frame'i present  etmek iin,  bi nceki  frame'in
sortedilmi  me'lerini   izebiliyo  olmal.   Bunu  ok   rahat  bir   ortamda
salayamadmz bir durumda  ortalk 1 -  plk gibi olur, 2  - ciddi  anlamda
bir performans ak salayamayz.

- Tamam guzeldir, nedir yani imdi bu bahsettiklerimiz:
========================================================

zetle yle basit bir ekil izelim ascii miz ile:

   thread/task manager    resource manager
                                |           |--> audio render
timer -----> demo flow -- demo core engine -|                  (AV layer)
                                |           |--> video render
                          memory manager
                          
Her  bi   component   aslnda  kendi   bana   bile  kitap   olabilecek   kadar
detayl.Fakat demo  durumunda  bu  detaylar  mmkn  olduunca  atabiliriz.  Ve
iimizeyarayan kadar  stne  konuup  bi  design  kartabiliriz.  Hangisinden
anlatmayabalayacam ben de  bilmiyom ama, yle  basite bi timer'dan  girelim
bakalmnerelere  gidiyor  durum.  Tabi  bunu  design  ederken  her  zaman  diger
component'largzmzn  nnde   bulundurmalyz  ki,   sonuta   karacamz
design dzgnbir yap  olsun ve  istediimiz deiiklii  parmak klatana  kadar
yapabilelim.

- Let the time flow:
====================

Evet timer. GetTickCount(), GetPerformanceCounter(), Gettime(),  ... Bunlar  bo
eyler. Yani nemli  olan time'i  nasl aldmz  deil. Hi  de bir  nemiyok.
ki gn sonra  function'n ad belki  de "GiveMeTheTimeMothaFucker()"  olabilir.
Dediim gibi hi bi nemi  yok. nemli olan burada  bu time olayn nasolup  da
sisteme entegre  edeceiz.  Bunun  stne  deineceiz.  Demonun  ak  tamamen
time'a baldr. Belli  bir zaman geldiinde  belli eyler yaplmas  istenilir.
Bunun design'n yaparken  bir baka istediimiz  husus, rahat debug  edebilmek.
Yani  belki   de   istiyoruz  ki   btn   demo...  Aslnda   yava    alsn.
Normalzamann  ne  biliim  ben  9.3562   de  birinde.  nk  o  zaman  belki de
grlmeyen bir bug' yakalayabiliriz. 

Ayn yap  oyunlarda da  ok sk  kullanlr. Rahat  debug edebilme,  'constant'
fpssalamak, gerektiinde  baka  bi  virtual  timer  ile  deitirmek,  kafadan
40.saniyeden balatabilmek...v.s.  timeline gibi  dnn.  nasl ki  ben  35.ci
saniyeden film  playlesin diyosam  demo'da da  bunu diyebilmeliyim.  ve her  ey
ona greduzgun bir ekilde akmali.

Tabi btn bunlarn dnda en nemli sorun (ki bi ok kiinin  dikkat  etmedii
mevzu...) Constant frame rate. Nasl olur da salanr. ? Braktm  defoyu  bugn
bi ok profesyonel  oyun bile  adam gibi  salayabilmi durumda  deil bunu.  Bi
pixel ilerletirsin  adam/arabay/yarat...frame  rate 75fps'den  35'e  der.
... "u-uh..  No!..  Bad design"..  Eee  napacaz  !? Hah  zm  bulduk!..  Btn
olayi35 fps'ye setleyelim o  zaman. O zaman dmez.  Yani btn demo'ya  bakalm
en dk ka  fps oluyo ona  bakalm. Ona setleriz btn  ak.. Yooo  dostuuum
yooo zaman cpu  o 75fps yapabildii  yerde bo  kalyor mu olacak  ?! Yok  byle
biii."unused system resource" exception frlatlr suratna!  Madem  ki 2 cpu 1
gpu'muzvar dibine  kadar  kullanp.  Mmkn olduunca  da  constant  frame  rate
nasl salanr.bunu  kasmak gerekmektedir.  (bu arada  design temelini  2 cpu  1
gpu mu gibi varsayyorum.  u an iin  sizde byle bi  sistem olmasa da  bundan
sonra byle olacak bu  i.. Hatta yaknda  4/8 cpu 2/4  gpu olmas an  meselesi.
(sl cards, multiplecpu boards...etc.. Fiyatlar her geen gn dyor)

O zaman nasl yaklamalyz  olaya. Oyunlarda ok  sik kullanlan bir  yontemden
bahsetmek istiyorum  burda. Bu  yntemin bir  dezavantaj var.  Her ey  totalde
bir frame geriden takip  ediyor. Yani u  an hesaplanan bir  frame var fakat  u
an izilmekte (audio/video) olan frame aslnda bi nceki frame. Basit  bi  delay
zetle. Oyunda insanlar  bunun kurtardn sylyor  (50 fps hesabimiz varsa 20
ms  lik  bi  delayden  bahsediyoruz)..   Demo  da  hayli  hayli  kurtarr.   Ama
flexibleve constant time control ok nemli bi konu.

lk vermemiz gereken  karar  demomuzun  ka  fps  olacana  karar  vermek. "eee
abicim varsn  gitsin  1000 fps...sper  ite  baksana okuz  gibi hzl..."  yav
kime ne  canim  kardeim  1000  fps ne...  Ayni  frame'i  1000  kere  hesaplayp
basmann kime  ne  faydas  var""olur mu  ya  bak  760 fps  idi...  1000  fps'ye
kardm..."bo laflar bunlar.  Basit bi filme  bakalm sinemada grdmz  bir
film  24   fps.televizyonda  grdmz   sahneler   25  fps'dir.   (50fps   ama
interlaced) bunun  byle  yaplmasnn sebebi  insan  gznn onun  tesinde  ki
frame'leri aslnda  karyor  olmas.  Yani  arka arkaya  akan  30  frame'e  bi
saniye de  bakarsanz  aslnda  gz biyolojik  sebeplerden  bu  frame'lerin  6-7
tanesini karr. Orda yle bi resim grdnz bile bilmezsiniz. O  yzden  bu
fps'yi insanin nasl  algladna yakn  bir ekilde  semek kesinlikle  makine
acsndan  ve  dzgn  resource  kullanm   asndan  en  gzel  seim   olur.
Oyunlarda bu biraz daha yksek tutulur.. rnein 50-60fps oyun iin  yeterli  bi
fps'dir. Normal film  fps'sinden biraz  daha yksek olmasnn  sebebi ortada  bi
user-interaction'in olmasndan  kaynaklanyor.  Yani tam  frame'in  banda  bir
hareket yaptnz anda  onun etkisini40ms sonra  ekranda grmek biraz  delay'li
olabiliyor (25fps = 40ms per frame)ama 20ms'lik bi delay akas ok  da  belli
olmuyor.. (yani  50  fps)  ama  bata  da  dediimiz  gibi  demo  olaynda  user
interaction yok. Herey kontrolmz  altnda her turlu  fake'e az. O  yzden
birazck daha dk fps hedeflemek akas bize koymaz.

Bi  ikinci  husus   bu  hedef  fps   yi  seerken,  (hani   demitim  ya   dier
componentlara da  bakmak  lazm)  gfx  lib'imizi de  gz  nnde  tutmak  lazm.
Ekranmzn  tarama  frekans  da  ok  nemli.  Yani  ekran  update   hzmzn
monitor'un refreshrate'inin  rational bi  kat olmas  ok nemli  rnein  60hz
tarayan bi monitorde kalkp da 47fps lik bir rakam oluturmak biraz  zor.  Yani
ekran  update'imiz  monitor  ile  sync  deilse  eer,  monitor  n  tabancas
ekrann ortalarnda  bir yerde  ise,  biz ekrann  st ksmini  update  ilemine
giriyor  olabiliriz. Sonra update hz monitor iin tabancasn yakalad  anda
da monitor  tabancasnn  alt  ksmndaki yerleri  update  ediyor  oluruz  (tabi
tabanca durmuyor o  da devam ediyo  yrmeye)o zaman monitor  st ksmi  birinci
frame'den tabancann  alt ksmn  da ikinci  frame'den gstermeye  balar..  Ve
ortada byle bi  izgi gibi birey  grmeye balarz. Bu da  ayn  nceki gibi..
"u-uh.. No  ...  Olmaz"  gibi  bir  durum. Yani  yle  bi  ayarlamalyz  ki  ya
monitorun refresh  hznda bir  fps seelim  ya da  onun bi  kat (yani  integer
kat.. Ama  inverse.. 1/2  1/3 1/4  gibi)diyelim aacamz  ekran 75  hz'lik  o
zaman 75  fps  seebiliriz.  Bu  da  bize  frame  bana  13.33333ms  gibi  bii
brakr. Baktk  bu sre  yeterli deil  bizim iin(ki  aslnda 75fps  de  fazla
hani...) O zaman 37.5fps  gibi bi fps seebiliriz.  26.6666 ms ayryoruz u  an
frame bana ve her  iki taramada bir frame  update geiyoruz. 37.5 fps  oluyor.
Ama.. Yok kardeim.  Ben byle  ondalk istemiyorum diyosak  o zaman..  60hz'lik
bi ekranda 2  framede bir update  ile 30fps'lik bir grnt  veya.. 80hz'lik  bi
ekranda 2 framede  bir update ile  40 fps'lik  bir grnt (ki  bu durumda  25ms
kalyo frame  bana).  rnek  olarak  40fps'yi hedef  seelim  diyelim  ki.  Bu
durumda bizim  hedefimiz ekranmz  her  25ms'de bir  update etmek  olucak.  Ve
monitor refresh problemini  halletmek iin  de 80hz'lik  bir mode  ap her  iki
taramada bir update ekicez.  (bu demek degil  ki monitor taramayacak...tabi  ki
o  framebuffer'da  ne  varsa  onu   tarayacak.  Biz  sadece  her  25ms'debir   o
framebuffer'i update edecez o kadar.)

imdi izleyeceimiz yntem u ekilde:
Bizim bir  timeline'imiz  var  di  mi  ?  Yani  sfrnc  ms'de  balayp  yle
giden...

0-------------25------------50-----------75---------100----------125-----------
  1.frame          2.frame      3.frame     4.frame      5.frame       ....
  
Hah aynen byle.. Programmz  balar (demo!) Ve biz  normal bir ekilde yapyor
olsaydk, timer'dan  her  25  ms'de  bir  'update'  event'i  yaratp  ekranmz
update ediyo olurduk. Yani.. 0.ci ms'deyiz.  Hesaplayacaklarmz  hesaplyoruz,
o srada tabii ki  time akyo durmuyo time..  Oluyo diyelim 15ms.. Sonra  cpu'ya
diyoruz ki "alo hadi  yaptk biz yapacamz  sen iyisi mi  iz!. Cpu hali  ile
gpu'ya signal yolluyo  "bak insanlar bekliyo  izim gerekiyo u  an hadi  gster
kendini"  diye.  Gpu'da  hart  izmeye  balyor.  Ancak!  Biz  eer   monitor
taramas ile  kendimizi  sync  etmek  istiyorsak,  yle  durumlar  olabiliyor..
(1.frame'i zoomluyorum.)

                                1. Frame total usage
Time 
0------------5-------------10---------------15------------20-----------25


       _____________________________________________
Cpu   |            cpuwork                          |_______cpuidle____________
                                                    

                                                    __________________
Gpu   _____________gpuidle_________________________|   gpuwork        |_waitvbl


Burada gsterdiim standart  bi cpu ve  gpu graph'i. Biraz  kt design  edilmi
bi  oyunun  veya  demonun  alma  ekli.  Cpu  ve  gpu'ya  farkl   zamanlarda
eriilerek, birbirlerinin paralel almas engellenmi  ve  olabilecek  minimum
performans  alnm.  te  btn  bunlar  engellemek  iin  insanlar   eitli
yntemler bulmu. nk hedef grafik:


                                1. Frame total usage
Time 
0------------5-------------10---------------15------------20-----------25


       ________________________________________________________________________
Cpu   |
                                                    

                  _____________________________________________________________
Gpu   ___________|

Buna yakn  biii  olmal.  Bu tabe  imkansz.  Yani  kimse bu  kadar  iyi  sync
yapamaz.ama elimizden  geleni ardna  koymamalyz  ve  ona  gre  dnmeliyiz.

imdi bunun iin  nasl bi timing  teknii kullanacamza bakalm  ncelikle...
Bu teknik iin  2 adet timer  varm gibi dnyoruz.  Birincisi gerek  timer,
ki bu  sistemden  gidip gerek  time  value'sunu alan  birim.  kincisine  sanal
timer diyebiliriz.  Bu  da  aslnda  sistemin  kullanaca  timer.  imdi  btn
programmz bu  noktada azck  task oriented  dnyoruz. Sistem  standard'n
birazck dna  kyor. Buna  daha sonradan  u task/thread  manager  ksmnda
baya bi deineceim.

imdi.. Programmz aslnda bi  nevi iki timer'i da  kullanyor. Ana olan  btn
olaylar  gerek  timer'i  kullanyor..  Ancak  hesaplama  izme  gibi   ksmlar
virtual timeri.
yle   oluyor.    Hep   beraber   time'la    birlikte   ilerleyerek    bakalm.
0.ms -> balyoruuuuuuuuuuuuuuuuuuz...
4.ms -> diyelim aha bu noktada ekrana  bi cube gelmesi gerekiyor. Hemen  o  kb
          getiren task'i  (dikkat!!!!!! - execute  etmiyoruz)..  Gereken  task'i
                         bi   queue'ya   atyoruz.   Daha   almad    kodumuz
13.ms ->  aha  burda da  diyelim  o  srada bi  texture  hesaplanmas  gerekiyor
diyelim
        (tamamen  uyduruyorum  bunlar) o texture'u da hesaplamyoruz.  Ve direk
        queue'ya atlyor.

Taam diyelim ilk frame'de  bunlar oluyor. Gerek  zaman.. Gerekten ilerledi  ve
bu tip ilemlerin olacan grd. Ve bunlar bi ekil queue'da  topland.  Sonra
real-timer bakyo ki..  25.ms oldu..  .hah ite  bu noktada  artk frame  update
olmas gerekiyor. nk bu  frame iin yaplmas  gereken i listesi  belirlendi
ve  artk  frame  update  gerekiyor.  Ama  geldik  frame'in  sonuna  henz  bii
yaplm  deil  evet...   Bu  ilemlerin   yaplna  aslnda   bu  frame   de
balayacaz...pekiiiii... Ne zaman gsterecez... Cevap: bi sonraki  frame..  Yani
tamamen bi  frame delay  yiyoruz. (halbuki  bu frame'de  gstermemiz  gerekirdi)
ama salad avantaj: o frame'i izmeye baladmz andan itibaren  bir  frame
oluturulmas gereken ileri aslnda  bi nevi sort ettik.  Ve 25.ci ms'de u  an
cpu biliyo nelerin yaplmasn 1.frame'i izerken.. Arka arkaya  onlar  execute
ediyor. (hi bi  stop yok cpu'da..  Hali ile gpu'da da  (zati frakl  thread'ler
de  calyor  ekran   update  gibi   olaylar..  Buna  da   deineceim  u   an
kurcalamasn ortal)..) Cpu  direk olarak full  g execute ediyor  ve hi  bi
wait yemiyor. Ve ayni  anda gpu'da full g  tm drawing olaylarna balyor  ve
hi   bi    wait    yemiyo    taaaaaaaaaa    ki..    leri    bitene    kadar..
Yani gerek  ikinci frame'in  (yani bizim  aslnda birinci  frame) balang  ve
biti
Grafiine bakacak olursak eer:

                                2. Frame total usage
Time 
25------------30------------35--------------40------------45-----------50


       ______________________________
Cpu   |                             |__________________________________________
                                                    

          __________________________________________________
Gpu   ___|                                                  |__________________


ekline  uygun  bi  yap  kar.  Cpu  balad  almaya.  Biraz  yapt   iini
(ncelikle gpu  iin  gerekenleri  falan..) Sonra  dan  gpu'da  balad  izmeye
yaplanlar... Ve  ayni  anda biri  hazrlananlar  izerken dieri  de  gereken
dier ilemleri  yapmaya devam  ediyor. Ve  %90 ihtimalle  cpu iini  daha  nce
bitiriyor.  Ve  gpu  azck  daha   izmeye  devam  ediyor.  Eee.  Hani   boluk
kalmayacakt... Hah ite kalmayacak.. Demek ki kotu biii yapmz.  Yani  bizim
program u an  haaaaaaaala resource  kaldrabilecek durumda..  (tabi bu  arada..
Bu 2.frame'deyken..  Bizim 2.ci  frame iin  gereken task'larda  bi yandan  demo
flow tarafnda queue'ya push'lanmaya devam..diyelim buframe'de hodo  hodo  noise
hesaplanmas gerekiyor.  Execution  yok.. Sadece  basit  bi push  ilemi  olduu
iin sistemi zati kullanmyor. O hodo hodo noise aslnda 3.cu  frame'de  execute
edilecek. Yukardaki rneimizde aslnda belki de o hodo hodo  noise'u bu  framee
tayabilirdik.. Grdmz  gibi haaaaaala  imkanmz var  o ilemleri  yapacak
gpu ve cpu belli bi ksmda bo.. Ama artk o boluun nerede olaca  ne  zaman
olaca tamamen  kontrolmz altnda.  Yk arlatrp  hafifletmek  elimizde.
rnein belki bi  rotation ilemi  (varsayalm 40000,40000,40000  lik bi  volume
texture'u byle  sinus hodo  cosinus biii  yapyoz... Ama  dnmesi biraz  yava
olmas bizim  iin  ok da  problem  deil. O  zaman  bunu biz  2  frame'de  bir
dndrelim. Ve  gene ayni  ekilde buna  benzer gene  ok zaman  yiyebilecek  bi
baka process'de  var diyelim  o da  gene ayn  ekilde 2  frame'de bir  alsa
problem olmayacak. O zaman bunlar hesaplayacak tasklarmz bu  tip  frame'lere
blersek kesinlikle ok daha performansl sonular alabiliriz..  Bunlara  sras
ile task a ...ve task b diyelim.

Time  0------------25------------50--------------75------------100----------125
         1.frame         2.frame        3.frame         4.frame         5.frame
          
     push task-a    process task-a process task-b process task-a process task-a
                    push task-b    push task-a    push task-b 
                      
Gibi bi  grnt  kacak. Yani  belki  baz frame'lerde  tam  istediimiz  gibi
gzkmeyecek yani hem  task a'nin o  saniye'de ki hali  ve hem de  task b'nin  o
saniyede ki  hali...ama..bi  nevi  process'lere blm  scheduling  sistemi  bunu
ykten kurtaracak. Obur turlu yaptmzda belki de 40fps'lik  olaymz  aslnda
20fps olacakt..  Yani olay  bi nevi  workcompression gibi  duunun.  (bilenler
iin.. Pal grnt  gibi.. Odd felds  - even felds... Her  frame'de sadece  ya
odd field'slar gnderilir..  Ya da even...  Ancak ve ancak ikisi  bir olunca  bi
frame olur.. Ama  birinci frame'in  odd'u geldiinde..  Aslnda ikinci  frame'in
even'i olabilir  elimizde.  Ek  bi  bilgi olarak  yuv  encoding  de  benzeri  bi
prensiple alr.)

Bu sistemin  getirdii  baka  bi  avantaj  ise,  birden  ok  cpu'muzun  olduu
durumlar iin  geerli. Yani  elimizde her  zaman execute  edilmesi beklenen  bi
group task  var.  Ve bunlarn  execution'ini  biz aslnda  birbirinden  bamsz
olarak deiik processorlere yaptrabiliriz. Hali ile

                                2. Frame total usage
Time 
25------------30------------35--------------40------------45-----------50


        ___________
Cpu1   |           |___________________________________________________________
        ___________
Cpu2   |           |___________________________________________________________
                                                    
         __________________________________________________
Gpu   ___|                                                  |__________________

  
Haline dntrebiliriz.  Bu da  aslnda  bizim iin  ilemciye ok  daha  fazla
yklene bileceimiz  manasna  geliyor. Neticede  her  task bi  i  yapyor.  Ve
tasklar birbirinden tamamen  bamsz. Ve  eer hangi sra  ile yapldklar  da
nem tamyosa o zaman bi task/thread manager gibi bi birim vastas  ile  eit
miktarda cpu'lara bltrle  bilinir. (tam  eit olmaz tabii  ki ama..  Olduu
kadar)... Bunun nasl olacana o birimi incelerken deineceim. Ama  ok  basit
mantn anlatmam  gerekirse  iki  thread olduunu  dnn  ve   bunlarn wait
state'de olduunu  dnn.  Ve ortada  bi  queue  var. Eer  queue'ya  yeni  bi
task/mesaj  biii  gelirse  bunlardan  biri  uyanyor  ve  queue'dan  onu   alp
execute'a balyor..  Sonra bi  adet  daha gelirse  ikincisi de  uyaniyor.  V.s.
Eger birisi  iini  bitirirse  tekrar  wait  state'e  gelmeden  queue'ya  tekrar
bakyor ve eer queue'da daha bi ka adet task daha varsa gene  onlardan  birini
alp execute mode'una giriyor.  Neyse fazla kafa  kartrmadan bunu daha  sonra
anlatiim.

Neyse umarm bu timer konusu ve sync olaylar hakknda bi bilgi verip  temel  bi
designin  nasl  olmas  gerektii  konusunda  aydnlatabilmiimdir.  Bu  yazya
devam  edeceim   kaldm  yerden   imdi   dier  konulara   dallanrsam   ok
uzayabilecei inancndaym.  Bir  sonraki yazmda  task/thread  manager  ksmna
deinmeyi dnyorum.  Daha ilerci  blmlerde ise  memory manager  /  resource
manager ve temel  eyleri yapan bir  gfx lib'i nasl  yapmalyz eklinde  devam
edeceim  ilk  designimza.  'Lord  of   the  demos'  adl  yaz  dizisi   devam
edecektir.


ciao!

[b]~sensei/rt - csermen@gmail.com[/b] 