Teknoloji Haberleri
Aşağı Git
Tüm Forumlar
Donanım / Hardware
Dahili Bileşenler
Ekran kartı
Yeni Benchmark Programı - Cuda RayTracer
Bu konudaki kullanıcılar: 1 misafir, 1 mobil kullanıcı
37
Cevap 1489
Tıklama 0
Öne Çıkarma
Cevap 1489
Tıklama 0
Öne Çıkarma
-
Cevap: Yeni Benchmark Programı - Cuda RayTracer (2. sayfa)
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  |
tabi paylaşmak istersen. Oyun grafik motoru olarak sadece jmonkey engine kullandım ve şu anda unity öğreniyorum. 
Bu mesaja 2 cevap geldi.
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. |
Bu mesaja 1 cevap geldi.
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 >
Bu mesaja 1 cevap geldi.
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 < Resime gitmek için tıklayın > Gtx 570 (Elimdeki kartın asıl def. hızı 823 ) Score: 4155 < Resime gitmek için tıklayın > Gtx 570 (O.c 925) Score:4690 < Resime gitmek için tıklayın > Gtx 570 (O.c 950) Score:4779 < Resime gitmek için tıklayın > Kart olarak Evga Gtx 570 Classified kullanıyorum. |
kaan hocam kartı satmadın mı  |
Bu mesaja 2 cevap geldi.
|
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 >
Bu mesaja 2 cevap geldi.
|
default hızlarda alınmıştır tek thread CPU < Resime gitmek için tıklayın > tek GPU < Resime gitmek için tıklayın > |
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 ). |
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 |
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @kaan0101
sağolasın dostum alan arkadaş sıfır kart almış gibi oldu iyide bir karttı 1330 da stabil çalışıyordu |
Bu mesaja 1 cevap geldi.
|
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ı > Bu mesaja 1 cevap geldi.
|
@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. |
Bu mesaja 1 cevap geldi.
|
3970x @4.8 Ghz Titan @ 1202 / 1500 CPU: 115 GPU: 3660 < Resime gitmek için tıklayın > |
Bu mesaja 1 cevap geldi.
|
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 :) |
DH Mobil uygulaması ile devam edin.
Mobil tarayıcınız ile mümkün olanların yanı sıra, birçok yeni ve faydalı özelliğe erişin.
Gizle ve güncelleme çıkana kadar tekrar gösterme.
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?
< Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 30 Nisan 2013; 17:25:42 >
Bu mesaja 1 cevap geldi. Cevapları Gizle