Yeni Kayıt
Konudaki Resimler
önceki
< Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 30 Nisan 2013; 17:25:42 > |
Hızlı 
Bildirim
Yeni Benchmark Programı - Cuda RayTracer (2. sayfa)
Sıcak Fırsatlarda Tıklananlar
Editörün Seçtiği Fırsatlar
Daha Fazla 
Bu Konudaki Kullanıcılar:
Daha Az 
2 Misafir - 2 Masaüstü
Giriş
Mesaj
-
-
quote:
Orijinalden alıntı: Tugrul_512bit
quote:
Orijinalden alıntı: hanibal187
quote:
Orijinalden alıntı: Tugrul_512bit
quote:
Orijinalden alıntı: hanibal187
quote:
Orijinalden alıntı: Tugrul_512bit
Kernel programı çok uzun değilse opencl sürümünü çıkartabilirim
tabi paylaşmak istersen. Oyun grafik motoru olarak sadece jmonkey engine kullandım ve şu anda unity öğreniyorum.
uzun ve kötü bir durumda aslında
zamanında cpu için yazdığımda bir sürü özelliği vardı depth of field, aa, soft shadows, reflection, refraction, texture vs vs... 5500 satır civarında ve çok fazla tekrar comment out içeriyor şu anki versiyonu 
kodu temizlediğim zaman atayım sana güzel olur opencl versiyonu.
Dediğim gibi optix kullanmak daha mantıklı aslında sıfırdan yazınca ne kadar uğraşırsan uğraş optix gibi temiz ve hızlı olmuyor (optix de cudaya bağımlısın gerçi)
5500 satırsa boşver Ben çarpışma simülasyonnu yapmıştım 200-250 satır bile yoktur(kernel). Demekki raytracingde bir ton hesap var. Çok üşengecim de 
Peki hesapları yaptırırken thread sayısı kaça çıkıyor ve kaçar kaçar gidiyor? Threadler tek boyutlu mu yoksa 2-3 boyutlu mu?
şu an blok başına 32 thread kullanıyorum (en iyi sonucu onda veriyor halbuki 4 warp destekliyor ama kod şişkin olduğundan dolayı register sizelarını geçiyor, bide shared memory ile uğraşmadım çok fazla memory pass vardı) tek gpuda blok sayısı olarakta 1024x1024 pixel ekran için 2-dimension block var -> GridDim dim3(1024, 1024/32, 1). Aynı anda benim kartta 14smx X 32 thread çalışıyor.
Fermi'de hızlı çalışmasıda blok başına 32 threadden kaynaklanıyor :D 480'de 15SM ve 580'de 16SM olunca haliyle bizim 14SMX'i geçiyor
Belki titanda kernelin başlama süresi biraz fazladır yani bir başladımı çok fazla işlem yapması gerekiyordur o süreyi telafi etmesi için. Kernel toplamda kaç hesaplamayı yaptırıyor paralel olarak? Atıyorum 10000 işlem yaptırıyorsa gtx480 şipşak başlayıp biter ama titanın bir hazırlık süresi vardır ve 10 katı işlemi aynı sürede yapar belki.
Boş kernel ile denedin mi hiç? Ya da sadece basit toplama işlemi yapan bir kernel ile?
o da var tabi, 600 serisinde 2 clock sürüyor bir aritmetik operasyonu tamamlaması, 500 de ise tek clock program çok kısa sürdüğünden o kazanımı göremiyoruz.
Büyük inputlar için reduction yapmıştım 1milyondan - 256 milyona kadar o zaman 4 warp kullanınca fark ortaya çıkıyor bu scenede çok az input var kalabalıklaştırmak lazım
-
quote:
Orijinalden alıntı: hanibal187
quote:
Orijinalden alıntı: Tugrul_512bit
quote:
Orijinalden alıntı: hanibal187
quote:
Orijinalden alıntı: Tugrul_512bit
quote:
Orijinalden alıntı: hanibal187
quote:
Orijinalden alıntı: Tugrul_512bit
Kernel programı çok uzun değilse opencl sürümünü çıkartabilirim tabi paylaşmak istersen. Oyun grafik motoru olarak sadece jmonkey engine kullandım ve şu anda unity öğreniyorum.
uzun ve kötü bir durumda aslında zamanında cpu için yazdığımda bir sürü özelliği vardı depth of field, aa, soft shadows, reflection, refraction, texture vs vs... 5500 satır civarında ve çok fazla tekrar comment out içeriyor şu anki versiyonu kodu temizlediğim zaman atayım sana güzel olur opencl versiyonu.
Dediğim gibi optix kullanmak daha mantıklı aslında sıfırdan yazınca ne kadar uğraşırsan uğraş optix gibi temiz ve hızlı olmuyor (optix de cudaya bağımlısın gerçi)
5500 satırsa boşver Ben çarpışma simülasyonnu yapmıştım 200-250 satır bile yoktur(kernel). Demekki raytracingde bir ton hesap var. Çok üşengecim de
Peki hesapları yaptırırken thread sayısı kaça çıkıyor ve kaçar kaçar gidiyor? Threadler tek boyutlu mu yoksa 2-3 boyutlu mu?
şu an blok başına 32 thread kullanıyorum (en iyi sonucu onda veriyor halbuki 4 warp destekliyor ama kod şişkin olduğundan dolayı register sizelarını geçiyor, bide shared memory ile uğraşmadım çok fazla memory pass vardı) tek gpuda blok sayısı olarakta 1024x1024 pixel ekran için 2-dimension block var -> GridDim dim3(1024, 1024/32, 1). Aynı anda benim kartta 14smx X 32 thread çalışıyor.
Fermi'de hızlı çalışmasıda blok başına 32 threadden kaynaklanıyor :D 480'de 15SM ve 580'de 16SM olunca haliyle bizim 14SMX'i geçiyor
Belki titanda kernelin başlama süresi biraz fazladır yani bir başladımı çok fazla işlem yapması gerekiyordur o süreyi telafi etmesi için. Kernel toplamda kaç hesaplamayı yaptırıyor paralel olarak? Atıyorum 10000 işlem yaptırıyorsa gtx480 şipşak başlayıp biter ama titanın bir hazırlık süresi vardır ve 10 katı işlemi aynı sürede yapar belki.
Boş kernel ile denedin mi hiç? Ya da sadece basit toplama işlemi yapan bir kernel ile?
o da var tabi, 600 serisinde 2 clock sürüyor bir aritmetik operasyonu tamamlaması, 500 de ise tek clock program çok kısa sürdüğünden o kazanımı göremiyoruz.
Büyük inputlar için reduction yapmıştım 1milyondan - 256 milyona kadar o zaman 4 warp kullanınca fark ortaya çıkıyor bu scenede çok az input var kalabalıklaştırmak lazım
Benim çarpışma simülasyonunda 128k parçacık kullanmıştım. Bağ sayısı da 2.6 Milyon idi. Ancak bu şekilde işlemci darboğazını ve açılış-kapanış gecikmesini telafi edebilmiştim hd7870 ile.
-
quote:
Orijinalden alıntı: Tugrul_512bit
Benim çarpışma simülasyonunda 128k parçacık kullanmıştım. Bağ sayısı da 2.6 Milyon idi. Ancak bu şekilde işlemci darboğazını ve açılış-kapanış gecikmesini telafi edebilmiştim hd7870 ile.
Tabi çarpışma testinde data büyük olunca memory copy süresi bütün programı egale ediyor neredeyse, speed-up cpuya göre o kadar iyi olmalıki o kısmı amortize edebilsin. Ne yazıkki şimdilik memory copy işlemlerine yapılacak birşey yok ha raytracingde 1 kere gpu ya atıp onu kernel sonunda texturea bağlayıp göstertebilirsin ama elde yine main memory->gpu memory oluyor. Onun için artık nvidianın 2 sonraki roadmapte volta'da görünen stackted dram olayı çözecektir. Gerçi maxwelldeki virtual memoryide merak etmiyor değilim memory copy işlemleri büyük ihtimalle implicit olabilir.
< Bu mesaj bu kişi tarafından değiştirildi hanibal187 -- 30 Nisan 2013; 17:53:34 >
-
quote:
Orijinalden alıntı: hanibal187
quote:
Orijinalden alıntı: Tugrul_512bit
Benim çarpışma simülasyonunda 128k parçacık kullanmıştım. Bağ sayısı da 2.6 Milyon idi. Ancak bu şekilde işlemci darboğazını ve açılış-kapanış gecikmesini telafi edebilmiştim hd7870 ile.
Tabi çarpışma testinde data büyük olunca memory copy süresi bütün programı egale ediyor neredeyse, speed-up cpuya göre o kadar iyi olmalıki o kısmı amortize edebilsin. Ne yazıkki şimdilik memory copy işlemlerine yapılacak birşey yok ha raytracingde 1 kere gpu ya atıp onu kernel sonunda texturea bağlayıp göstertebilirsin ama elde yine main memory->gpu memory oluyor. Onun için artık nvidianın 2 sonraki roadmapte volta'da görünen stackted dram olayı çözecektir. Gerçi maxwelldeki virtual memoryide merak etmiyor değilim memory copy işlemleri büyük ihtimalle implicit olabilir.
Valla GCN için memory copy olarak bir tek "global broadcast" biliyorum yani bir parçacığın X konumunu tek komut ve tek cycle ile tüm çekirdeklere dağıtabiliyorsun. 2 milyondan fazla bağ hesabını bu şekilde yaptırıyorum. Ana bellekten sadece 128k adet parçacığın konumu geliyor sonra bunlar 26 kere broadcast donanımsal desteğiyle hesap için yollanıyor. Evet buna rağmen ana belleğin hızına çok bağımlı bir olay. O kadar kare alma kuvvet alma ve trigonometrik hesaplar var gene de bellek yetişemiyor çekirdeklere. Broadcast da olmasa zaten hesap hiç yapılamayacak
Kartın 3Tflops gideri var ama sadece 1.6Tflopsunu kullanabiliyorum bu yolla. 3TFlops için prime95 teki gibi olduğu yerde boş boş çarpma işlemi yaptırmak lazım.
< Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 30 Nisan 2013; 18:05:16 >
-
I5 3570k 4Ghz (neden yukarıya çıkarmayıp bıraktıysam onu da anlamadım 4.5 e çekip öyle deneyeyim.)
Gtx 570 (Standart gtx 570 def.) Score:3722
Gtx 570 (Elimdeki kartın asıl def. hızı 823 ) Score: 4155
Gtx 570 (O.c 925) Score:4690
Gtx 570 (O.c 950) Score:4779
Kart olarak Evga Gtx 570 Classified kullanıyorum.
-
quote:
Orijinalden alıntı: kaan0101
oraya nvidialarda gelecek
edit
660ti stock 2492
kaan hocam kartı satmadın mı
-
arkadaşları skor yanıltmasın kartlar 1ghz de iken bu puanları alıyor.
ek bir bilgi sunayım adobe cs6 after effect yazılımı ile raytrace bench testinde gtx 680 yaklaşık 6dk Titan 4:40 gibi bir zamanlama ile bitiriyor ben gtx 580slı ile aynı testi 3dk gibi bir zamanlama ile bitiriyorum test hayli kastırıcı ve gpu+memory controlcüleri de zorlayan bir test.
burda ki etken nedir bilemiyorum çok fazla teknik bilgim yok fakat kepler mimarisinde ki sanal çekirdek olayı yüzünden diye düşünüyorum .
gtx 580 de 512 cuda varsa sadece bu çekirdekler işlemlerde döngü yapıyor ama sanal çekirdekler yazılımların tam desteğini almadıklarından tıkanma yapıyor diye bir mantık yürütmüştüm ne kadar doğru bilemiyorum tabi
bir de cuda çekirdek hızlarının 600 serisinde hayli düşük olması da etken olabilir mi ?
< Bu mesaj bu kişi tarafından değiştirildi arbiter -- 30 Nisan 2013; 20:40:09 >
-
default hızlarda alınmıştır
tek thread CPU
tek GPU
-
quote:
Orijinalden alıntı: arbiter
arkadaşları skor yanıltmasın kartlar 1ghz de iken bu puanları alıyor.
ek bir bilgi sunayım adobe cs6 after effect yazılımı ile raytrace bench testinde gtx 680 yaklaşık 6dk Titan 4:40 gibi bir zamanlama ile bitiriyor ben gtx 580slı ile aynı testi 3dk gibi bir zamanlama ile bitiriyorum test hayli kastırıcı ve gpu+memory controlcüleri de zorlayan bir test.
burda ki etken nedir bilemiyorum çok fazla teknik bilgim yok fakat kepler mimarisinde ki sanal çekirdek olayı yüzünden diye düşünüyorum .
gtx 580 de 512 cuda varsa sadece bu çekirdekler işlemlerde döngü yapıyor ama sanal çekirdekler yazılımların tam desteğini almadıklarından tıkanma yapıyor diye bir mantık yürütmüştüm ne kadar doğru bilemiyorum tabi
bir de cuda çekirdek hızlarının 600 serisinde hayli düşük olması da etken olabilir mi ?
Aslında bir sürü etken var ama en basitinden, 600 serisindeki intruction per clock cycle 500 serisine göre az bunu daha fazla core sayısı ile kapatıyorlar ; 580'de sm içinde 32 core varken 680'de smx içinde 192 core var hızlanma 6 kat olması gerekirken bu 2-3 kat civarında oluyor (bu sayede hem daha az enerji tüketiyor hemde daha yüksek performans veriyor, son dediğinde haklısın, basitçe hızları daha yavaş) ve programda kullanılan objeler az olunca clock cycle'ı daha hızlı olan 500 serisi avantajlı oluyor.
Scene'i bir hayli kalabalık yapmam lazımki (10-15 sn civarında ki gpular asıl gücünü gösterebilsin) fazla core sayısından yararlansın şu an zaten gördüğünüz üzere kernel time cuda hesaplama süresini gösteriyor ve oldukça hızlı (0.01-0.02 sn ).
-
quote:
Orijinalden alıntı: kankatree
kaan hocam kartı satmadın mı
kartı gönderdim dostum bugün arkadaşın eline geçmiş
hafta sonu almıştım o skoru
-
bende bir sorun cıktı heralde dedim neyse sevimdim bir sorun olmadıgına kaan hocam tekrar hayırlı olsun
-
quote:
Orijinalden alıntı: kankatree
bende bir sorun cıktı heralde dedim neyse sevimdim bir sorun olmadıgına kaan hocam tekrar hayırlı olsun
sağolasın dostum alan arkadaş sıfır kart almış gibi oldu iyide bir karttı 1330 da stabil çalışıyordu -
Bende çalışmadı ekran kartı Nvidia işletim sistemi Win 8 pro X64
Seçenekler çıkar çıkmaz arka plana geçiyor o ekranda 1 ve 2 ye bassamda
artık çalışmıyor bekliyor
-
Takipyeyim hayirli ugurlu olsun insaallah
< Bu ileti mobil sürüm kullanılarak atıldı > -
@Tugrul_512bit Boş iş dedğin prime mersen projesinin parçası, kodları son derece optimize ve neyi neden yaptığını çok iyi bilen insanlar var. Yaptığın işler için app profilerı kullan faydasını görbilirsin.
Keplerde sanal çekirdek faln diye bişey yok, daha çok cuda core / çekirdeği daha düşük frekansda işletiyor. Kodun farklı mimarilere göre optimize edilmesi ayarlanması gerekiyor ki en yüksek verimde çalışsın. Occupancy calculator faln gibi şeyler ile hangi gpu'yu max oranda kullanırsın, boşta kalmayacak şekilde ayarlarsın o tarz şeylere bakıyorsun. GPU'daki birimleri en yüksek oranda çalıştırmaya çalışmak için o mimariye özel şeyler dışında (thread/blok/register vs dışında), donanım bazı şeyleri senin istediğinden farkı organize edebilir. Bu da daha kullanıma yol açabilir (occupancy denen şeye). Bunu değişken optimizasyonu ile düzeltemiyorsak, farklı gpularda belki daha iyi çalışabilecek farklı kod kullanmamız gerekir. Bunun için de gpu-dispatcher gibi bişey yazmamız gerekir ki farklı mimarilerde (burda konu gpu olduğundan farklı gpularda) farklı kod dalları işletilebilsin ki onda en iyi çalışabilecek kod devamyolu kullanılsın. Küçük işlerde bunlar bi yere kadar yapılır belki ama uzun uzadıya kimse o kadar uğraşmaz, farklı donanım için daha iyi çalışacak farklı kod yazma olayı peşinde. Tek bi kod yazıp hepsinde en uygun çalışmasın sağlayacak bişey yok kısaca (1 code to rule all ).
Ayrıca Fermide, komutlar işlenirken donanım üstünde bağımlılık kontrolü falan gibi şeyler yapılıyor, ona göre çalıştırılacak komutlar organize ediliyor (register vs. warp durumu gibi, kullanılmaya hazır olup olmadığı yeni warpların işletilebilecek kaynakları gibi). CPU'daki front end'in, komutları çözen kısmın karmaşık olması gibi analoji/benzetme yapabilirz burda (analoji daha basit hale getirmiyor o ayrı). Keplerde ise bu compiler destekli olarak çalışıyor, oluşacak değişkenlikler önceden bilindiğinden önlenebildiğinden, donanım üstünde bu tarz kontrol devreleri çıkartılmış oluyor. Bi nevi compiler değişkenler / bağımlılıklar kontrolünü yapıyor (bi açıdan da Vliw'e benziyor bu, compiler tarafından asiste edildiği için). Elde donanımın yaptığı işin azaltılarak compiler desteği ile yapılması sağlanmış bi donanım kalıyor, bu da doğal olarak güç tüketimi vs. gibi şeylere yansıyor(yine analoji olacaksa eğer CPU'nun front-end'inin hafifletilmesi gibi. farklı uzunlukta olabilen komutlar ve değişkenleri inceleyip bunların birbirlerine olan bağımlılıklarına göre sınıflandırmak zorunda olan donanım yapısını değiştirip yazılım / compiler ile bi nevi sabit uzunlukta komut / değişken paketleri şeklinde işlemesini sağlıyorsun. Compiler önceden oluşacak gelişme / değişen şeyleri bildiği için ve bunları hint / önbilgi / ipucu olarak donanıma verdiği için, donanım 2saat bunlar arasındaki gecikme / değişkenlik / bağımlılıkları incelemek zorunda kalmıyor, yine Vliw'e benzer şeyler bunlar ). Sonuçta elde hafiflemiş donanım / komut işleme yapısı + azaltılmış güç tüketimi kalıyor.
Bunların hepsi kodu ve gpu'daki birimlerin kullanımını etkileyebilecek şeyler.
Bunu yüksek seviyede basite indirgemek gerekirse, yeni komutları işlemek için oluşan gecikmeyi(latency'i) maskeleyebilmek için bütün birimleri sürekli meşgul etmek gerekiyor (yukarda utilizaition ile anlatılan o, warpın yeni bi komut işletebilmek için harcadığı / beklediği zaman), şu latency hiding denilen olay için.
Burda esas mesele, Keplerde bu latency hiding olayı için (boşa harcanan zaman / kaynak olmaması için), Fermi'ye göre 4-8 kat daha fazla oranda birimlerin mutlaka meşgul olması komut işliyor olması gerekiyor. Kepler, Compute Capability 2.1 olan GPU'lar için (gf104 114 vs.) 4 kat daha fazla işlem yapmalı meşgul olmalı ki extradan gecikmeler düşük performansa yol açmasın. Aynı zmanda Compute Capability 2.0 olan GPU'lara göre (gf100 110 faln yani) 8 kat daha fazla işlem yapabilmeli ki yine bu gecikme maskelenebilsin. Bunun için, hiç o kadar uğraşmamış olmama rağmen yerine göre farklı kodlama gerekmesi lazım.
Yine diğer yandan, Nvidia mimarilerinde warp scheduler denen çalıştırılmaya hazır warpları yönlendiren yapılar var. Bunlar dispatcher unit denen şeyler ile komutları cuda corelar / çekirdekler üstünde çalıştırılması sağlanıyor.
Aralarında şöyle uyduruk bi oran kurarsak :
Compute capability 2.0
gf100 >> SM başına 32 cc >> 2 Warp Scheduler >> 2 dispatcher : warp/dispatcher başına 16 cc
compute capability 2.1
gf114 >> SM başına 48 cc >> 2 warp scheduler >> 4 dispatcher : Warp grubu başına 24 cc ve dispatcher başına 12 cc
İşin başında 4 issue / 4 komut işleyebilir gibi geliyor. Ama Burda Warp Scheduler aynı anda 2 farklı Warp seçebilir. dispatcher unitler ise ancak aynı warp içinden komut işleyebilir.
Compute capability 3
gk104 >> Sm başına 192 cc >> 4 warp scheduler >> 8 dispatcher : Warp grubu başına 48 cc ve dispatcher başına 24 cc
Burda yine 8 komut işlenebilir gibi geliyor. Ama yine Warp Scheduler aynı anda 4 farklı warp grubu hazırlablir. Dispatcher unitler ise yine aynı warp'dan 2 çifti seçip işleyebilir.
Burda olan başka birşey daha var, her nesil sonrasında granulitede artış varmış gibi gözükürken, olası bağımlılık branch vs. gibi şeyler sonucunda mesela 1 warp stall edildiği zaman boşa harcanan kaynaklar daha fazla oluyor. Çünkü o tarz bi granulite yok. Kontrol birimlerinin başına düşen cc miktarı arttıkça, aslında fine-grain kontrol imkanı azalmaya başlıyor(stall vs. gibi durumlarda dedğim gibi daha büyük miktarda kullanılmış kaynak çöpe gidiyor). Compute bazlı işlem yaparken Keplerin falso yiyebilmesinde bu tarz şeylerin de etkileri var. Mesela stall yeme ihtimali iki farklı mimari arasında %1 vs. %0.5 olsun. Bu stall yeme durumundaki performansa olumsuz etkisi önceki mimarilerde mesela %5 olurken Keplerde bu %10'ları geçebiliyor. Bu yüzden profiler desteği ile kodun faln çok daha iyi incelenmesi, bi yerde büyük kayıplar oluşturabilen küçük aksaklıkların daha çok irdelenmesi gerekiyor. Çünkü bu tarz ufak bi aksaklık önceki mimarilerde daha az kayba yol açabilirken Keplerde olumsuz etkisi daha fazla, bu yüzden üstünde daha fazla düşülmeye ihtiyacı var.
-
3970x @4.8 Ghz
Titan @ 1202 / 1500
CPU: 115
GPU: 3660
-
FX8150 1400MHz : 18 puan 4300MHz: 58 puan.
HD7870: 115207 puan !!!! Çalışıyor ama görüntü yok. Sanırım hata veriyor ama haberim yok :)
Ip işlemleri
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
