Sayfa 23

Tamam diyelim ilk frame'de bunlar oluyor. Gerçek zaman.. Gerçekten ilerledi ve bu tip işlemlerin olacağını gördü. Ve bunlar bir şekil queue'da toplandı. Sonra real-timer bakıyor 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 bir şey yapılmış değil evet... Bu işlemlerin yapılışına aslında bu frame de başlayacağız... Pekiiiii... Ne zaman göstereceğiz... Cevap: bir sonraki frame.. Yani tamamen bir 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 bir nevi sort ettik. Ve 25.ci ms'de şu an cpu biliyor nelerin yapılmasını 1.frame'i çizerken.. Arka arkaya onları execute ediyor. (hiç bir stop yok cpu'da.. Hali ile gpu'da da (zati farklı thread'lerde çalışıyor ekran update gibi olaylar.. Buna da değineceğim şu an kurcalamasın ortalığı)..) Cpu direkt olarak full güç execute ediyor ve hiç bir wait yemiyor. Ve aynı anda gpu'da full güç tüm drawing olaylarına başlıyor ve hiç bir wait yemiyor 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 bir yapı çıkar. Cpu başladı çalışmaya. Biraz yaptı işini (öncelikle gpu için gerekenleri falan..) Sonradan gpu'da başladı çizmeye yapılanları... Ve aynı 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 kötü bir şey 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'lar da bir yandan demo flow tarafında queue'ya push'lanmaya devam.. diyelim bu frame'de hodo hodo noise hesaplanması gerekiyor. Execution yok.. Sadece basit bir push işlemi olduğu için sistemi zati kullanmıyor. O hodo hodo noise aslında 3.cü frame'de execute edilecek. Yukarıdaki örneğimizde aslında belki de o hodo hodo noise'u bu frame'e taşıyabilirdik.. Gördüğümüz gibi haaaaaala imkanımız var o işlemleri yapacak gpu ve cpu belli bir 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 bir rotation işlemi (varsayalım 40000,40000,40000'lik bir volume texture'u böyle sinus hodo cosinus bir şey yapıyoruz... 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 aynı şekilde buna benzer gene çok zaman yiyebilecek bir 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