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

Once upon  a  time, diye  başlayalım...Burda  çok basit  de olsa  ufak   bi yazı
dizisi ile az  çok basit  bi demo framework  tarzı bişi  nasıl hazırlanır  ondan
bahsetmeye çalışacağım.  Burda anlatacağım  şeyin,  yuzyirmisekiz byte,  dört  k
v.b  tarzı  demolara   pek  apply  edilemeyeceğini   söyleyebilirim.  Daha   çok
bahsetmek istediğim  şey,  yapısal olarak  biraz  da flexible  bi  design  nasıl
yaparız onun üstüne değineceğim. 

Öncelikle  bir  design'a  başlamadan   önce  temel  yapı  taşlarımıza   bakalım.
Nelerlazım bize sonuçta.  Düşünelim bakalım.  Demo dediğimiz  şeyi standart  bir
oyunapplication v.s.  gibi şeylerden  ayıran tarafı,  user interaction  kısmının
hemenhemen hiç  olmaması. Yani  'escape'  dışındaki bir  tuşu kontrol  eden  bir
demotürüne henüz rastlamadım  (çok enderdir, yok  space'e basarsın secret  music
gelirfalan  filan...)  Bu  yüzden  o  açıdan  epey  bir  şanslıyız.  Yani   user
interactionyoksa  herşey   daha  bi   kontrol   altında  olur.   Aslında   temel
yapacağımız şey  birmüzik/ses v.s.  eşliğinde sunacağımız  görüntüsel  effectler
zinciri tarzında,o  anki yaptığımız  makinada yapılması  gerçekten zor  olup  ve
görsel olarak  dasanatsal  bi  tarafı  olan bi  yapıdır.  Yani  aslında...  Film
çekiyoruz...  Başlarve  bir  süre  sonra   da  biter.  Hiç  bir  şey   farklılık
göstermez.  Çok  enterasanşekillerde   hazırlanmış  bariz  randomize   effectler
dışında her  çalıştırdığımızda aynı  saliselerde aynı  görüntüleri görür..  aynı
sesleri duyarız. O  zamanburdan şuna  gelebiliriz ki, en  sağlam olması  gereken
yerimiz,  bizim  timing  control'umuz  diyebiliriz.  Yani  istediğimiz  şeyleri,
istediğimiz  anlarda  yapmamızı  sağlayan  bir   yapı.  Bunu  öyle  bir   design
etmeliyiz ki, ufacık bir değişiklik yapmak bize pahalıya patlamamalı. 

Tamam timing  olayı  bir yana,  bunun  dışında  neler gerekiyor.  Temel  bi  gfx
libtasarımı !?  ...Hmm tam  olarak değil.  Çünkü neticede  'standard'ın  dışında
birşeyler  yapacağımız  için  bize   uygun  bir  library  oluşturulabilinir   mi
bilemiyorum. Tıpkı  AI library'leri  gibi düşünün.  Her oyunda  kullanilabilecek
bir AIlibrary'si yazmak  mümkün mü !?  Hayır değil. Neticede  AI dediğimiz  şey,
fake'lerden  ibaret,  oyununa  göre  yapacağın  fake,  veya  izleyeceğin  yöntem
değişir.Ancak tabi  ki bazı  belli  başlı yapılar  var...  Örneğin bir  AI  için
bakarsak,ne bileyim ben bir path finding önemli yapı taşlarından  biri.  (Haaala
anlamışdeğilim  niye  path   finding'i  AI  sayarlar...   o  ayrı  konu).   Yani
yapacağımız şeyin içine bunu koyabiliriz.. Ama general bişi  yapmak  imkansız...
Aynısı demogfx lib'i için  de geçerli. Ne koyabiliriz  ki içine... Ç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
hazırlayıpo texture'u  ekrana basan  bi yapı  !? Yoksa  3-5 pass'de  hazırlanmış
3-5 textureu  alıp  onlara screen  space  effect ile  post-processing  yapan  bi
yapı!? Yoksahepsi  mi  !? Yani  yok  bunun  tam cevabı.  Mükemmelini  de  yapmak
imkansız. İki  günsonra  aklınıza "yaa  hadi  burda da  bezierlerden  4.  derece
fractal bişii  çizdirip arkasında  da radiosity  hodo hodosu"  yapiim  dediğiniz
anda o library'den tek bir function çağırmıyot durumunda bulacaksınız kendinizi.
Ama, bi çok  şeyi kolaylaştırabilmemizi sağlayan bi  yapı yapmak elbette mümkün.
Buna değineceğiz.

Başka  neyimiz  var   bunların  yani  sıra??..Müzik!..   Evet  müzik  veya   ses
effectleri. Burda yapılacak  abartı miktarda birşey  yok açıkçası. Genel  olarak
seseffect'leri  çok  kullanılmaz.  Yani  ya  direk  müziğin  içine  gömülüdür  o
effectlerya da... Yoktur..  O yüzden  demo'muz başladığı  andan itibaren  sadece
'play' diyip, arkasından herşeyi kendi haline bırakmak herzaman en  güzel  çözüm
gibidir.

Temel   bi    bakışta    bu   üç    component    yeterli   gibi    gözükse    de
(timing/gfx/music)bunların yanı sıra  arka planda olup  da bizim işimizi  cidden
çok feci  anlamdakolaylaştıran  bi  kaç yapı  daha  vardır.  Bunların  arasında,
memory  manager,   resource   manager  (texture,sound,meş..vs.   gibi   şeylerin
yuklenme mekanizmasıve demo tarafından erişebilirliği..) ve en  önemlisi  thread
manager  librarysi.Biliyosunuz  artık  günümüzde   bir  adet  CPU  diye   birşey
kalmadı. Bir  adet CPUbile  olsa  sistemde bir  de GPU  diye  bi kavram  var  ki
bunlardan maximum performansı  elde etmek  istiyosak bunların  senkronizasyonunu
çok çok çok iyi bi şekilde sağlamak zorundayız. ki...  Günümüzde  hemen hemen bi
çok kişide artıkya dual-pentium ya da en azından  hyper-thread  pentium ayarında
aletler var. Kalkip da CPU'nun %50'sini kullanan ve GPU ile sync  olmayan  (yani
GPU  calışırken   CPU  bekler   veya  CPU   calışırken  GPU   bekler)  bi   yapı
hazırladığımızdamakinadan  alacağımız  performans  kafadan  üçte  birine  düşer.
İşte burdakisync olayları için kesinlikle bir thread manager,  task  managervari
bir yapıkesinlikle şarttır.  Bi taraftan  CPU'nun biri  bi procedural  texture'u
hazırlarken (ki..aslında  GPU'da da  mümkün) diğer  taraftan diğer  CPU  meşleri
sortederken GPU'da  bi onceki  frame'i present  etmek için,  bi önceki  frame'in
sortedilmiş  meş'lerini   çizebiliyo  olmalı.   Bunu  çok   rahat  bir   ortamda
sağlayamadığımız bir durumda  ortalık 1 -  çöplük gibi olur, 2  - ciddi  anlamda
bir performans akışı sağlayamayız.

- 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   aslında  kendi   başına   bile  kitap   olabilecek   kadar
detaylı.Fakat demo  durumunda  bu  detayları  mümkün  olduğunca  atabiliriz.  Ve
işimizeyarayan kadarı  üstüne  konuşup  bi  design  çıkartabiliriz.  Hangisinden
anlatmayabaşlayacağım ben de  bilmiyom ama, şöyle  basitçe bi timer'dan  girelim
bakalımnerelere  gidiyor  durum.  Tabi  bunu  design  ederken  her  zaman  diger
component'larıgözümüzün  önünde   bulundurmalıyız  ki,   sonuçta   çıkaracağımız
design düzgünbir yapı  olsun ve  istediğimiz deişikliği  parmak şıklatana  kadar
yapabilelim.

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

Evet timer. GetTickCount(), GetPerformanceCounter(), Gettime(),  ... Bunlar  boş
şeyler. Yani önemli  olan time'i  nasıl aldığımız  değil. Hiç  de bir  önemiyok.
İki gün sonra  function'ın adı belki  de "GiveMeTheTimeMothaFucker()"  olabilir.
Dediğim gibi hiç bi önemi  yok. Önemli olan burada  bu time olayını nasıolup  da
sisteme entegre  edeceğiz.  Bunun  üstüne  değineceğiz.  Demonun  akışı  tamamen
time'a bağlıdır. Belli  bir zaman geldiğinde  belli şeyler yapılması  istenilir.
Bunun design'ını yaparken  bir başka istediğimiz  husus, rahat debug  edebilmek.
Yani  belki   de   istiyoruz  ki   bütün   demo...  Aslında   yavaş    çalışsın.
Normalzamanın  ne  biliim  ben  9.3562   de  birinde.  Çünkü  o  zaman  belki de
görülmeyen bir bug'ı yakalayabiliriz. 

Aynı yapı  oyunlarda da  çok sık  kullanılır. Rahat  debug edebilme,  'constant'
fpssağlamak, gerektiğinde  başka  bi  virtual  timer  ile  değiştirmek,  kafadan
40.saniyeden başlatabilmek...v.s.  timeline gibi  düşünün.  nasıl ki  ben  35.ci
saniyeden film  playlesin diyosam  demo'da da  bunu diyebilmeliyim.  ve her  şey
ona göreduzgun bir şekilde akmali.

Tabi bütün bunların dışında en önemli sorun (ki bi çok kişinin  dikkat  etmediği
mevzu...) Constant frame rate. Nasıl olur da sağlanır. ? Bıraktım  defoyu  bugün
bi çok profesyonel  oyun bile  adam gibi  sağlayabilmiş durumda  değil bunu.  Bi
pixel ilerletirsin  adamı/arabayı/yaratığı...frame  rate 75fps'den  35'e  düşer.
... "u-uh..  No!..  Bad design"..  Eee  napacaz  !? Hah  çözüm  bulduk!..  Bütün
olayi35 fps'ye setleyelim o  zaman. O zaman düşmez.  Yani bütün demo'ya  bakalım
en düşük kaç  fps oluyo ona  bakalım. Ona setleriz bütün  akışı.. Yooo  dostuuum
yooo zaman cpu  o 75fps yapabildiği  yerde boş  kalıyor mu olacak  ?! Yok  böyle
bişii."unused system resource" exception fırlatılır suratına!  Madem  ki 2 cpu 1
gpu'muzvar dibine  kadar  kullanıp.  Mümkün olduğunca  da  constant  frame  rate
nasıl sağlanır.bunu  kasmak gerekmektedir.  (bu arada  design temelini  2 cpu  1
gpu muş gibi varsayıyorum.  Şu an için  sizde böyle bi  sistem olmasa da  bundan
sonra böyle olacak bu  iş.. Hatta yakında  4/8 cpu 2/4  gpu olması an  meselesi.
(slı cards, multiplecpu boards...etc.. Fiyatları her geçen gün düşüyor)

O zaman nasıl yaklaşmalıyız  olaya. Oyunlarda çok  sik kullanılan bir  yontemden
bahsetmek istiyorum  burda. Bu  yöntemin 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 aslında bi önceki frame. Basit  bi  delay
özetle. Oyunda insanlar  bunun kurtardığını söylüyor  (50 fps hesabimiz varsa 20
ms  lik  bi  delayden  bahsediyoruz)..   Demo  da  hayli  hayli  kurtarır.   Ama
flexibleve constant time control çok önemli bi konu.

İlk vermemiz gereken  karar  demomuzun  kaç  fps  olacağına  karar  vermek. "eee
abicim varsın  gitsin  1000 fps...süper  işte  baksana okuz  gibi hızlı..."  yav
kime ne  canim  kardeşim  1000  fps ne...  Ayni  frame'i  1000  kere  hesaplayıp
basmanın kime  ne  faydası  var""olur mu  ya  bak  760 fps  idi...  1000  fps'ye
çıkardım..."boş laflar bunlar.  Basit bi filme  bakalım sinemada gördüğümüz  bir
film  24   fps.televizyonda  gördüğümüz   sahneler   25  fps'dir.   (50fps   ama
interlaced) bunun  böyle  yapılmasının sebebi  insan  gözünün onun  ötesinde  ki
frame'leri aslında  kaçırıyor  olması.  Yani  arka arkaya  akan  30  frame'e  bi
saniye de  bakarsanız  aslında  göz biyolojik  sebeplerden  bu  frame'lerin  6-7
tanesini kaçırır. Orda öyle bi resim gördüğünüzü bile bilmezsiniz. O  yüzden  bu
fps'yi insanin nasıl  algıladığına yakın  bir şekilde  seçmek kesinlikle  makine
acısından  ve  düzgün  resource  kullanımı   açısından  en  güzel  seçim   olur.
Oyunlarda bu biraz daha yüksek tutulur.. Örneğin 50-60fps oyun için  yeterli  bi
fps'dir. Normal film  fps'sinden biraz  daha yüksek olmasının  sebebi ortada  bi
user-interaction'in olmasından  kaynaklanıyor.  Yani tam  frame'in  başında  bir
hareket yaptığınız anda  onun etkisini40ms sonra  ekranda görmek biraz  delay'li
olabiliyor (25fps = 40ms per frame)ama 20ms'lik bi delay açıkçası çok  da  belli
olmuyor.. (yani  50  fps)  ama  başta  da  dediğimiz  gibi  demo  olayında  user
interaction yok. Herşey kontrolümüz  altında her turlu  fake'e açığız. O  yüzden
birazcık daha düşük fps hedeflemek açıkçası bize koymaz.

Bi  ikinci  husus   bu  hedef  fps   yi  seçerken,  (hani   demiştim  ya   diğer
componentlara da  bakmak  lazım)  gfx  lib'imizi de  göz  önünde  tutmak  lazım.
Ekranımızın  tarama  frekansı  da  çok  önemli.  Yani  ekran  update   hızımızın
monitor'un refreshrate'inin  rational bi  katı olması  çok önemli  örneğin  60hz
tarayan bi monitorde kalkıp da 47fps lik bir rakamı oluşturmak biraz  zor.  Yani
ekran  update'imiz  monitor  ile  sync  değilse  eğer,  monitor  ışın  tabancası
ekranın ortalarında  bir yerde  ise,  biz ekranın  üst kısmini  update  işlemine
giriyor  olabiliriz. Sonra update hızı monitor işin tabancasını yakaladığı  anda
da monitor  tabancasının  alt  kısmındaki yerleri  update  ediyor  oluruz  (tabi
tabanca durmuyor o  da devam ediyo  yürümeye)o zaman monitor  üst kısmi  birinci
frame'den tabancanın  alt kısmını  da ikinci  frame'den göstermeye  başlar..  Ve
ortada böyle bi  çizgi gibi birşey  görmeye başlarız. Bu da  aynı  önceki gibi..
"u-uh.. No  ...  Olmaz"  gibi  bir  durum. Yani  öyle  bi  ayarlamalıyız  ki  ya
monitorun refresh  hızında bir  fps seçelim  ya da  onun bi  katı (yani  integer
katı.. Ama  inverse.. 1/2  1/3 1/4  gibi)diyelim açacağımız  ekran 75  hz'lik  o
zaman 75  fps  seçebiliriz.  Bu  da  bize  frame  başına  13.33333ms  gibi  bişi
bırakır. Baktık  bu süre  yeterli değil  bizim için(ki  aslında 75fps  de  fazla
hani...) O zaman 37.5fps  gibi bi fps seçebiliriz.  26.6666 ms ayırıyoruz şu  an
frame başına ve her  iki taramada bir frame  update geçiyoruz. 37.5 fps  oluyor.
Ama.. Yok kardeşim.  Ben böyle  ondalık istemiyorum diyosak  o zaman..  60hz'lik
bi ekranda 2  framede bir update  ile 30fps'lik bir görüntü  veya.. 80hz'lik  bi
ekranda 2 framede  bir update ile  40 fps'lik  bir görüntü (ki  bu durumda  25ms
kalıyo frame  başına).  Örnek  olarak  40fps'yi hedef  seçelim  diyelim  ki.  Bu
durumda bizim  hedefimiz ekranımızı  her  25ms'de bir  update etmek  olucak.  Ve
monitor refresh problemini  halletmek için  de 80hz'lik  bir mode  açıp 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 izleyeceğimiz yöntem şu şekilde:
Bizim bir  timeline'imiz  var  di  mi  ?  Yani  sıfırıncı  ms'de  başlayıp  öyle
giden...

0-------------25------------50-----------75---------100----------125-----------
  1.frame          2.frame      3.frame     4.frame      5.frame       ....
  
Hah aynen böyle.. Programımız  başlar (demo!) Ve biz  normal bir şekilde yapıyor
olsaydık, timer'dan  her  25  ms'de  bir  'update'  event'i  yaratıp  ekranımızı
update ediyo olurduk. Yani.. 0.ci ms'deyiz.  Hesaplayacaklarımızı  hesaplıyoruz,
o sırada tabii ki  time akıyo durmuyo time..  Oluyo diyelim 15ms.. Sonra  cpu'ya
diyoruz ki "alo hadi  yaptık biz yapacağımızı  sen iyisi mi  çiz!. Cpu hali  ile
gpu'ya signal yolluyo  "bak insanlar bekliyo  çizim gerekiyo şu  an hadi  göster
kendini"  diye.  Gpu'da  haşırt  çizmeye  başlıyor.  Ancak!  Biz  eğer   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 gösterdiğim standart  bi cpu ve  gpu graph'i. Biraz  kötü design  edilmiş
bi  oyunun  veya  demonun  çalışma  şekli.  Cpu  ve  gpu'ya  farklı   zamanlarda
erişilerek, birbirlerinin paralel çalışması engellenmiş  ve  olabilecek  minimum
performans  alınmış.  İşte  bütün  bunları  engellemek  için  insanlar   çeşitli
yöntemler bulmuş. Çünkü hedef grafik:


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


       ________________________________________________________________________
Cpu   |
                                                    

                  _____________________________________________________________
Gpu   ___________|

Buna yakın  bişii  olmalı.  Bu tabe  imkansız.  Yani  kimse bu  kadar  iyi  sync
yapamaz.ama elimizden  geleni ardına  koymamalıyız  ve  ona  göre  düşünmeliyiz.

Şimdi bunun için  nasıl bi timing  tekniği kullanacağımıza bakalım  öncelikle...
Bu teknik için  2 adet timer  varmış gibi düşünüyoruz.  Birincisi gerçek  timer,
ki bu  sistemden  gidip gerçek  time  value'sunu alan  birim.  İkincisine  sanal
timer diyebiliriz.  Bu  da  aslında  sistemin  kullanacağı  timer.  Şimdi  bütün
programımızı bu  noktada azıcık  task oriented  düşünüyoruz. Sistem  standard'ın
birazcık dışına  çıkıyor. Buna  daha sonradan  şu task/thread  manager  kısmında
baya bi değineceğim.

Şimdi.. Programımız aslında bi  nevi iki timer'i da  kullanıyor. Ana olan  bütün
olaylar  gerçek  timer'i  kullanıyor..  Ancak  hesaplama  çizme  gibi   kısımlar
virtual timeri.
Şöyle   oluyor.    Hep   beraber   time'la    birlikte   ilerleyerek    bakalım.
0.ms -> başlyıoruuuuuuuuuuuuuuuuuuz...
4.ms -> diyelim aha bu noktada ekrana  bi cube gelmesi gerekiyor. Hemen  o  kübü
          getiren task'i  (dikkat!!!!!! - execute  etmiyoruz)..  Gereken  task'i
                         bi   queue'ya   atıyoruz.   Daha   çalışmadı    kodumuz
13.ms ->  aha  burda da  diyelim  o  sırada bi  texture  hesaplanması  gerekiyor
diyelim
        (tamamen  uyduruyorum  bunları) o texture'u da hesaplamıyoruz.  Ve direk
        queue'ya atılıyor.

Taam diyelim ilk frame'de  bunlar oluyor. Gerçek  zaman.. Gerçekten ilerledi  ve
bu tip işlemlerin olacağını gördü. Ve bunlar bi şekil queue'da  toplandı.  Sonra
real-timer bakıyo ki..  25.ms oldu..  .hah işte  bu noktada  artık frame  update
olması gerekiyor. Çünkü bu  frame için yapılması  gereken iş listesi  belirlendi
ve  artık  frame  update  gerekiyor.  Ama  geldik  frame'in  sonuna  henüz  bişi
yapılmış  değil  evet...   Bu  işlemlerin   yapılışına  aslında   bu  frame   de
başlayacaz...pekiiiii... Ne zaman gösterecez... Cevap: bi sonraki  frame..  Yani
tamamen bi  frame delay  yiyoruz. (halbuki  bu frame'de  göstermemiz  gerekirdi)
ama sağladığı avantaj: o frame'i çizmeye başladığımız andan itibaren  bir  frame
oluşturulması gereken işleri aslında  bi nevi sort ettik.  Ve 25.ci ms'de şu  an
cpu biliyo nelerin yapılmasını 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  calışıyor  ekran   update  gibi   olaylar..  Buna  da   değineceğim  şu   an
kurcalamasın ortalığı)..) Cpu  direk olarak full  güç execute ediyor  ve hiç  bi
wait yemiyor. Ve ayni  anda gpu'da full güç  tüm drawing olaylarına başlıyor  ve
hiç   bi    wait    yemiyo    taaaaaaaaaa    ki..    İşleri    bitene    kadar..
Yani gerçek  ikinci frame'in  (yani bizim  aslında birinci  frame) başlangıç  ve
bitiş
Grafiğine bakacak olursak eğer:

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


       ______________________________
Cpu   |                             |__________________________________________
                                                    

          __________________________________________________
Gpu   ___|                                                  |__________________


Şekline  uygun  bi  yapı  çıkar.  Cpu  başladı  çalışmaya.  Biraz  yaptı   işini
(öncelikle gpu  için  gerekenleri  falan..) Sonra  dan  gpu'da  başladı  çizmeye
yapılanları... Ve  ayni  anda biri  hazırlananları  çizerken diğeri  de  gereken
diğer işlemleri  yapmaya devam  ediyor. Ve  %90 ihtimalle  cpu işini  daha  önce
bitiriyor.  Ve  gpu  azıcık  daha   çizmeye  devam  ediyor.  Eee.  Hani   boşluk
kalmayacaktı... Hah işte kalmayacak.. Demek ki kotu bişii yapmışız.  Yani  bizim
program şu an  haaaaaaaala resource  kaldırabilecek durumda..  (tabi bu  arada..
Bu 2.frame'deyken..  Bizim 2.ci  frame için  gereken task'larda  bi yandan  demo
flow tarafında queue'ya push'lanmaya devam..diyelim buframe'de hodo  hodo  noise
hesaplanması gerekiyor.  Execution  yok.. Sadece  basit  bi push  işlemi  olduğu
için sistemi zati kullanmıyor. O hodo hodo noise aslında 3.cu  frame'de  execute
edilecek. Yukardaki örneğimizde aslında belki de o hodo hodo  noise'u bu  framee
taşıyabilirdik.. Gördüğümüz  gibi haaaaaala  imkanımız var  o işlemleri  yapacak
gpu ve cpu belli bi kısımda boş.. Ama artık o boşluğun nerede olacağı  ne  zaman
olacağı tamamen  kontrolümüz altında.  Yükü ağırlaştırıp  hafifletmek  elimizde.
Örneğin belki bi  rotation işlemi  (varsayalım 40000,40000,40000  lik bi  volume
texture'u böyle  sinus hodo  cosinus bişii  yapıyoz... Ama  dönmesi biraz  yavaş
olması bizim  için  çok da  problem  değil. O  zaman  bunu biz  2  frame'de  bir
döndürelim. Ve  gene ayni  şekilde buna  benzer gene  çok zaman  yiyebilecek  bi
başka process'de  var diyelim  o da  gene aynı  şekilde 2  frame'de bir  çalışsa
problem olmayacak. O zaman bunları hesaplayacak tasklarımızı bu  tip  frame'lere
bölersek kesinlikle çok daha performanslı sonuçlar alabiliriz..  Bunlara  sırası
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  görüntü  çıkacak. Yani  belki  bazı frame'lerde  tam  istediğimiz  gibi
gözükmeyecek 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 bölüm  scheduling  sistemi  bunu
yükten kurtaracak. Obur turlu yaptığımızda belki de 40fps'lik  olayımız  aslında
20fps olacaktı..  Yani olayı  bi nevi  workcompression gibi  duşunun.  (bilenler
için.. Pal görüntü  gibi.. Odd fıelds  - even fıelds... Her  frame'de sadece  ya
odd field'slar gönderilir..  Ya da even...  Ancak ve ancak ikisi  bir olunca  bi
frame olur.. Ama  birinci frame'in  odd'u geldiğinde..  Aslında ikinci  frame'in
even'i olabilir  elimizde.  Ek  bi  bilgi olarak  yuv  encoding  de  benzeri  bi
prensiple çalışır.)

Bu sistemin  getirdiği  başka  bi  avantaj  ise,  birden  çok  cpu'muzun  olduğu
durumlar için  geçerli. Yani  elimizde her  zaman execute  edilmesi beklenen  bi
group task  var.  Ve bunların  execution'ini  biz aslında  birbirinden  bağımsız
olarak değişik processorlere yaptırabiliriz. Hali ile

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


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

  
Haline dönüştürebiliriz.  Bu da  aslında  bizim için  işlemciye çok  daha  fazla
yüklene bileceğimiz  manasına  geliyor. Neticede  her  task bi  iş  yapıyor.  Ve
tasklar birbirinden tamamen  bağımsız. Ve  eğer hangi sıra  ile yapıldıkları  da
önem taşımıyosa o zaman bi task/thread manager gibi bi birim vasıtası  ile  eşit
miktarda cpu'lara bölüştürüle  bilinir. (tam  eşit olmaz tabii  ki ama..  Olduğu
kadar)... Bunun nasıl olacağına o birimi incelerken değineceğim. Ama  çok  basit
mantığını anlatmam  gerekirse  iki  thread olduğunu  düşünün  ve   bunların wait
state'de olduğunu  düşünün.  Ve ortada  bi  queue  var. Eğer  queue'ya  yeni  bi
task/mesaj  bişii  gelirse  bunlardan  biri  uyanıyor  ve  queue'dan  onu   alıp
execute'a başlıyor..  Sonra bi  adet  daha gelirse  ikincisi de  uyaniyor.  V.s.
Eger birisi  işini  bitirirse  tekrar  wait  state'e  gelmeden  queue'ya  tekrar
bakıyor ve eğer queue'da daha bi kaç adet task daha varsa gene  onlardan  birini
alıp execute mode'una giriyor.  Neyse fazla kafa  karıştırmadan bunu daha  sonra
anlatiim.

Neyse umarım bu timer konusu ve sync olayları hakkında bi bilgi verip  temel  bi
designin  nasıl  olması  gerektiği  konusunda  aydınlatabilmişimdir.  Bu  yazıya
devam  edeceğim   kaldığım  yerden   şimdi   diğer  konulara   dallanırsam   çok
uzayabileceği inancındayım.  Bir  sonraki yazımda  task/thread  manager  kısmına
değinmeyi düşünüyorum.  Daha ilerci  bölümlerde ise  memory manager  /  resource
manager ve temel  şeyleri yapan bir  gfx lib'i nasıl  yapmalıyız şeklinde  devam
edeceğim  ilk  designimıza.  'Lord  of   the  demos'  adlı  yazı  dizisi   devam
edecektir.


ciao!

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