procedural graphic

[devreci]

bişey ilgimi çekti 4kb procedural graphic yapılırken hep ekran kartı kullanılmış ray tracing kullanıyor ise (raytrace dışında üçgen çizerek iyi bişey yaplamaz ?) neden cpu kullanılmıyor. mesela sadece bir win oluşturulacak ve
setpixel ile 3dsmax render sistemi gibi yukarıdan aşağıya tarayacak. win  oluşturmak  ve setpixel  dot, cross , lerp  sıkıştırılmış hali 100 byte bile almayacak

ben dx8.0 dan sonrasını bilmiyorum acaba direcx 10- 11 bunlarda çarpışma , raytrace ile ilgili yeni fonksiyonlarmı eklendi direk heseplıyormu ekran katı .
ki gördüğüm kadarıyla öyle değil ? bilgisi olan varmı ?

[skate]

istersen cpu kullanırsın ancak 4k'ya sığdırmak açısından shaderlar daha avantajlı olur. sonuçta vertex shader, pixel shader, geometry shader gibi birçok shaderın yaptığı işi kendi kodunla yapmak daha çok yer harcayacaktır.

[devreci]

@skate:
öyle ama shaderi sonuçda biz yazacağız bugün baya bi araştırdım
mesela dx11 de raytracingi kolaytıracak herhangi bir fonksiyon yok mesela ray triangle testini yine biz yazmak zorundayız. yani ekran kartı bizim işimizi kolaylaştırmıyor.

ekran kartında doğru dürüst asm instructionları yok mesela cpuda flaglar var 200 küsür instructin var dinamik hafıza kontrolü var.

hemde her bilgisayarda çalışacaktır.mesela benim yeni sayılacak laptopumda
birçok demo çalışmıyor çükü ekran kartım intel. mecburen arkadaşın bilgisayarından bakıyorum.

[Ragnor]

mesele birazda şu, polygon'larla elde edeceğin grafik asla raytracing ile elde edebileceğin kadar iyi olamaz ve artık sonunda donanımlarımız raytracing kullanmaya izin verecek kadar güçlendi. cpu yerine gpu kullanılmasının sebebi ise sanırım 4k'ya sığdırmak için falan. yoksa okuduğuma göre cpu ile çok daha sağlam ray tracing yapılabilir durumdaymış pc'lerde. tabii bunlar yanlışta olabilir, çok iyi bilmediğim konular bunlar ama ahkam kesmemi engellemiyor anlayacağın

[skate]

ekran kartları bu yöne kayıyor son yıllarda. geçen sene yazdığım bir yazım vardı bu konuda hatırlarsanız.
 
http://emir.akaydin.com/?p=98
 
şu anda cpu gpu war daha tam başlamadı, yakında işler iyice kızışacak. ama 4k için shader kullanımının avantajlı olduğu birçok durum var. olay sadece ray tracing değil çünkü.

[nightlord]

4k da gpu tercih edilmesinin 3 sebebi var:
- gpu pipeline uzerindeki pekcok fixed function (yani programlanabilir olmayan) unitelerin yeteneklerini hic kod yazmadan kullanabilmek (ornegin rasterizer'in herseyi pikseller arasinda bedava interpole etmesi, texture lookupta bilinear filtering, anisotropic filterin, fog, alpha blending vs. gibi goruntu kalitesine cok etki eden ozellikler)
- programlanabilir unitelerde bir shader kodu komutunun genel olarak bir cpu komutundan daha cok is yapabilmesi. Ornegin, iki matrisi tek shader satirinda zart diye carpabilirsin, bir instruction'da linear interpolation yapabilirsin.
- raytracing'de ve raymarchingde kullanilan bazi ekstra matematiksel trikler var, piksel shader'da kolay yapilan, bunlar hakkinda iq'nun sitesine bak orada bi presentasyon var.
 
sonuc olarak sunu da unutmamak lazim. Su anda artik PC 4K'lardan beklenen goruntu kalitesi (cozunurluk, renk sayisi, post processin vs acisindan) cok ileri bir noktaya geldi. 256b'larda kullanilan dos grafik modlari bugun pc scenerlarini kolay kolay tatmin etmez.

[Decipher]

Ben kendi adima neden GPU tercih ettigimi belirteyim:

• Nightlord'un da dedigi gibi GPU bircok detayi hazir olarak onume sunuyor. Per vertex valuelarin per fragment interpolationi gibi.
• CPU kodu cok gelismis ve cidden kaliteli bir matematik kutuphanesi buil-in olarak gelmiyor. Bunlari kendim kodlamak zorundayim CPU-only yapiyorsam.
  
• GPU pipelinelari paralel, CPU'dan cok daha hizli ve flexible bir sekilde calculation yapabilir.
• Son olarak ise, senin dedigin "GPU raytracing - raymarching kolaylastiracak hicbir sey vermiyor." sozu tamamen yanlis. Shader dillerinin sagladigi built-in vektor turleri, operator swizzling hatta ve hatta refract() ve reflect() gibi fonksiyonlar, ya da high-level bir programming language altinda supplement edilmis matematiksel operatorler bu isi cok cok kolaylastiriyor. Bugun GPU'da GLSL ile adaptive distance-field based sphere-tracer yazmak 15 satir GLSL koduyken esdeger kod C'de ~100 satira kadar cikabilir (iyimser estimate hatta bu). Cunku onlarca matematik fonksiyonunu kendin kodlaman lazim (sansliysan bir kismi intrinsic olacaktir ama intrinsicler bigger code generate edebilir [tabii 4k'da bu kick-in etmez buyuk ihtimalle]).

[skate]

tüm bu yazılanları özetleyelim şimdi. bkz: ilk cevabım

[devreci]

evet haklısınız, özellikle tex coordun ve tex filterin hesaplanması sorun olur eğer yüksek seviyeli shader dillerde hazır libraryler bulunuyorsa ve bunu tek fonksiyon ile çağırabiliyorsak cpuda uğraşmak mantıksız.

ama skatenin gelecek , ragnorun evimize kadar geldi yorunlarına katılmıyorum
iste hesap bi oyunu düşünelim tamamı raytrace

(1024*768)   *  (10.000.000)   *  (60) =471.859.200.000.000
  (pixel)   *  (ücgenler,light) *  (fps) =470 trilyon

saniyede 470 trilyon hesaplama en iyi ihtimalle yani gpu clock'u bir saniyede 470 Thz puls verecek. Yani görülür ışığın frekansı kadar. 1 cm bakır tel en fazla 25-40 Ghz iletebiliyor eğer altın ve -273 derece soğululmuışsa 80-100 Ghz arası. zaten cpu genişliğini kücülterek frekansı arttırmaya calışıyorlar çünkü anahtarlama transistörler en fazla 5-6 ghz çalışıyor.

yani önümümzdeki yüzbin yıl boyunca tamamı raytrace oyun göremeyeceğiz.

ama bi seçenek daha var mesela ekranın her 10X10 bölümünden sorumlu ayrı ayrı
çekirdek gpular olursa olur heralde 1000 çekirdekli filan. her çekirdeğin 200 watt elektrik tükettiğini düşünürsek 200000watt elektrik çekmesi sorunu
olacaktır sadece =D

şok şok ! ben yanlış hesapladım galiba :S

[skate]

@devreci: abi o nasıl hesap öyle, ışını ışık kaynağından mı atıyorsun nedir? bak ben 2005'de Almanya CeBIT'de çok da monster olmayan bir setupta fake birşey kullanmadan 3-5 FPS civarı çalışan ray trace engine gördüm ki çok detaylıydı. şimdiye 30-50 FPS'leri rahat bulur hale gelmiştir bile o. Ama öyle ekrandaki pixel başına hesap yapmayacaksın. Ray Grouping diye bir yöntem bulmuşlardı mesela. Birçok paralel ray'i gruplayıp işlemlerin sayısını düşürüyordu v.s. Özetle her frame başlangıcında precalculationlar yapmak kadar basit yöntemlerle fake birşey olmaksızın realtime ray tracing mümkün ve böyle oyunlar şu anda bile var. Ama donanım desteklemedikçe end user'a sunulmuyor. Özeti budur. Önümüzdeki yüzbin yılı bekleme 5-10 sene önceye git göreceksin

[spritus]

ben de konuyu merak edip youtube'dan search ettim ve şu videoyu buldum:

[ame]http://www.youtube.com/watch?v=J5QJ-cG4ZBU[/ame]

[skate]

bu güzel ama oldukça ham bir örnek. bundan çok daha iyisini zaten scene demolarında izliyoruz. benim bahsettiğim 5 yıl önce 3-5 FPS olan sahnede onbinlerce-yüzbinlerce yüzey falan vardı. bir araba yarışı oyunu gibi birşeydi. arabayı dıştan görüyorsun, etrafta pist, binalar v.s. var. arabanın içine girip kokpitten de görebiliyorsun v.s. ortada oyun yok ama bir oyunda kullanılırsa ne kadar detaylı olabilir bunu gösteren bir simülasyondu. kalite benim dibimi düşürmüştü.
 
edit: benim izlediğimde çevredeki binalar v.s. çok daha kaliteliydi ancak şu tür birşey izlemiştim.
 
[youtube]zKqZKXwop5E[/youtube]

[devreci]

teşekkürler ama güzel değiller , gerçekçi değiller . bi max renderi kalitesi varmı ? gerçek olup olmadığı anlaşılamıyor vrayda  render 30dk da hesaplanıyormuş duyduğum kadarıyla

raytrace quake4 müş

[ame]http://www.youtube.com/watch?v=DsCgJhoAm0c[/ame]