Şimdi Ara

AMD Mantle Hakkında Her Şey (4. sayfa)

Daha Fazla
Bu Konudaki Kullanıcılar: Daha Az
2 Misafir - 2 Masaüstü
5 sn
1.338
Cevap
19
Favori
63.958
Tıklama
Daha Fazla
İstatistik
  • Konu İstatistikleri Yükleniyor
5 oy
Öne Çıkar
Sayfa: önceki 23456
Sayfaya Git
Git
sonraki
Giriş
Mesaj
  • Teşekkürler hocam verdiğin bilgiler için Zero Limit hocamın dediği gibi, az çok neleri kastettiklerini ve neleri vaadedebileceklerini anlamış olduk
  • quote:

    Orijinalden alıntı: Rubisco

    Klavyene farene sağlık.
  • windows alt yapisini kullanarak pc de bir devrim beklemek fazla iyimser geliyor bana.devrim yapilacaksa once oyunlar icin ozellestirilmis bir isletim sistemi sart gibi.nasil ki creative windows alt yapisini kullanip tekel olmaya calistiginda ve belli bir muddet bunu basardiginda microsoft tarafindan alasagi edildiyse ayni durum mantle icin soz konusu olabilir.opel gl gelistirilebilseydi belki dx illetine bir alternatif uretilebilseydi belki simdi mantle diye bir konuyu konusmuyor olacaktik.soz konusu microsoft ise devlet icinde devlet olmaz diyecek her ne kadar basarili bir girisim olsa da buna izin vermeyecektir.
    rubisco'ya foruma kattiklarindan oturu tesekur ederim



    < Bu mesaj bu kişi tarafından değiştirildi -dehşet- -- 12 Kasım 2013; 2:14:03 >
    < Bu ileti m.bolumsonucanavari.com kullanılarak atıldı >
  • Bu konu çok güzel bilgilendirici yazılar içeriyor güncel kalmalı Rubisco aşmışsın dostum tebrik ve tşk. ederim.
  • Mantle render olayını hangi cpu ve gpu ile yapacaklar?hd 7000 series ve fx işlemci ile yaparlarsa müthiş olur True audio demosu olucak mi?

    < Bu ileti mobil sürüm kullanılarak atıldı >
  • quote:

    Orijinalden alıntı: NCR Trooper

    Mantle render olayını hangi cpu ve gpu ile yapacaklar?hd 7000 series ve fx işlemci ile yaparlarsa müthiş olur True audio demosu olucak mi?

    290x ile yaparlar reklam amacli hani dediler ya 290x bf4'te mantle oldugunda titanla dalga geciyor diye.bizim derdimiz 290x degil mantle yarar bir sey mi ogrenmek oldugu icin show seklinde degil de efendi 7000 bir kartta da farkini gosterselerdi daha iyi olurdu ama 290 280 7000 serisi hepsi core next mimari.islemci kaveri olacakmis.ayin 14'unde de kaveri'yi tanitacaklar.hem ekran karti 290x hem islemci farkli oldugu icin araliktaki bf4 mantle guncellemesi ve kullanici yorumlarindan tam net ortaya cikacak sanirsam bu mantle olayi.




  • quote:

    Orijinalden alıntı: -dehşet-

    windows alt yapisini kullanarak pc de bir devrim beklemek fazla iyimser geliyor bana.devrim yapilacaksa once oyunlar icin ozellestirilmis bir isletim sistemi sart gibi.nasil ki creative windows alt yapisini kullanip tekel olmaya calistiginda ve belli bir muddet bunu basardiginda microsoft tarafindan alasagi edildiyse ayni durum mantle icin soz konusu olabilir.opel gl gelistirilebilseydi belki dx illetine bir alternatif uretilebilseydi belki simdi mantle diye bir konuyu konusmuyor olacaktik.soz konusu microsoft ise devlet icinde devlet olmaz diyecek her ne kadar basarili bir girisim olsa da buna izin vermeyecektir.
    rubisco'ya foruma kattiklarindan oturu tesekur ederim

    C++ AMP Linux'e geliyor, bu da gece APU13'de açıklanıyor. MS--AMD arasında bi ilişki olmadığına kimse inanmaz bu vakitten sonra. O zman Mantle'ı da Ms'ye atılan kazık gibi bakmamak lazım. MS'ye rağmen bu işin içinde gibi durmuyor. Aksine Ms ile belli bi ilişkisi var gibi duruyor.




  • quote:

    Orijinalden alıntı: Rubisco

    quote:

    Orijinalden alıntı: -dehşet-

    windows alt yapisini kullanarak pc de bir devrim beklemek fazla iyimser geliyor bana.devrim yapilacaksa once oyunlar icin ozellestirilmis bir isletim sistemi sart gibi.nasil ki creative windows alt yapisini kullanip tekel olmaya calistiginda ve belli bir muddet bunu basardiginda microsoft tarafindan alasagi edildiyse ayni durum mantle icin soz konusu olabilir.opel gl gelistirilebilseydi belki dx illetine bir alternatif uretilebilseydi belki simdi mantle diye bir konuyu konusmuyor olacaktik.soz konusu microsoft ise devlet icinde devlet olmaz diyecek her ne kadar basarili bir girisim olsa da buna izin vermeyecektir.
    rubisco'ya foruma kattiklarindan oturu tesekur ederim

    C++ AMP Linux'e geliyor, bu da gece APU13'de açıklanıyor. MS--AMD arasında bi ilişki olmadığına kimse inanmaz bu vakitten sonra. O zman Mantle'ı da Ms'ye atılan kazık gibi bakmamak lazım. MS'ye rağmen bu işin içinde gibi durmuyor. Aksine Ms ile belli bi ilişkisi var gibi duruyor.

    Artık C++ AMP yardımıyla APU'nun hem normal çekirdeklerini hem gcn çekirdeklerini aynı şekilde kullanabilecek miyiz kolayca? Atıyorum SSE/AVX gibi optimizasyonları gcn üzerine aktarabilecek miyiz? Mesela skyrim sse optimizasyonunu gcn ye aktarabilen bir iş hattı var ise ne güzel olur değil mi?



    < Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 12 Kasım 2013; 15:27:31 >




  • quote:

    Orijinalden alıntı: Tugrul_512bit

    Artık C++ AMP yardımıyla APU'nun hem normal çekirdeklerini hem gcn çekirdeklerini aynı şekilde kullanabilecek miyiz kolayca? Atıyorum SSE/AVX gibi optimizasyonları gcn üzerine aktarabilecek miyiz? Mesela skyrim sse optimizasyonunu gcn ye aktarabilen bir iş hattı var ise ne güzel olur değil mi?

    HSA'nın amacı o ama zort diye olacak değil. Ona uygun kodlamayı tasarımı faln ypman grek. Onun için library faln var veya hazırlanıyor. Bolt'u faln o amaçla çıkardılar zaten. Orda ama ihtiyacın olan şeyin nerede nasıl neyle yapılması gereklilği de önemli. Eğer gecikmeden yüksek oranda etkilenmeye meyilli ise ve bunu engelleyemiyorsan, coherent bus / GCN / GPU'da kurtarmayabilir seni APU için. Skyrm SSE için doğru, eğer elleirnde imkan olsaydı belli hesaplamayı GPU'ya gecikmeden darbe almayacak kşekilde aktarabilselerde katkısı güzel olurdu. Önemli olan neyin nasıl implemente edildiği, donanımın sınırlarını bilmek, o sınırlar içine yapmak istediğin şeyi sığdırmaya çalışmk.
    Bi miktar hesaplama için SSE yerine GPU'ya çıkmak sana ilave yüzlerce cycle gecikmeye maloluyorsa, oyunda bu FPS düşüşü olarak geri geliyorsa ne anladım o işten o zman dersin rahatça. Critic path üstünde olmayan, GPU'daki bi sonucu işletebileceksen faydalı olmuş olacak.

    Elde bi library olsun, belli bi yere kadar SSE gibi kullanabileyim GPU'yu, APU üstünde bile olsa yeter dedirtebildikleri sürece çok ekmek yiyen çıkar bundan. Dedikleri gibi hesap sistemlerine faln verimli olarak entegre edilebilir bu. O noktadan sonra işte öbür tarafta dediğin / dediğim daha büyük APU / multi-soket coherent APU / HSA sistemler çoğalma eğilimine girer.




  • quote:

    Orijinalden alıntı: Rubisco

    quote:

    Orijinalden alıntı: Tugrul_512bit

    Artık C++ AMP yardımıyla APU'nun hem normal çekirdeklerini hem gcn çekirdeklerini aynı şekilde kullanabilecek miyiz kolayca? Atıyorum SSE/AVX gibi optimizasyonları gcn üzerine aktarabilecek miyiz? Mesela skyrim sse optimizasyonunu gcn ye aktarabilen bir iş hattı var ise ne güzel olur değil mi?

    HSA'nın amacı o ama zort diye olacak değil. Ona uygun kodlamayı tasarımı faln ypman grek. Onun için library faln var veya hazırlanıyor. Bolt'u faln o amaçla çıkardılar zaten. Orda ama ihtiyacın olan şeyin nerede nasıl neyle yapılması gereklilği de önemli. Eğer gecikmeden yüksek oranda etkilenmeye meyilli ise ve bunu engelleyemiyorsan, coherent bus / GCN / GPU'da kurtarmayabilir seni APU için. Skyrm SSE için doğru, eğer elleirnde imkan olsaydı belli hesaplamayı GPU'ya gecikmeden darbe almayacak kşekilde aktarabilselerde katkısı güzel olurdu. Önemli olan neyin nasıl implemente edildiği, donanımın sınırlarını bilmek, o sınırlar içine yapmak istediğin şeyi sığdırmaya çalışmk.
    Bi miktar hesaplama için SSE yerine GPU'ya çıkmak sana ilave yüzlerce cycle gecikmeye maloluyorsa, oyunda bu FPS düşüşü olarak geri geliyorsa ne anladım o işten o zman dersin rahatça. Critic path üstünde olmayan, GPU'daki bi sonucu işletebileceksen faydalı olmuş olacak.

    Elde bi library olsun, belli bi yere kadar SSE gibi kullanabileyim GPU'yu, APU üstünde bile olsa yeter dedirtebildikleri sürece çok ekmek yiyen çıkar bundan. Dedikleri gibi hesap sistemlerine faln verimli olarak entegre edilebilir bu. O noktadan sonra işte öbür tarafta dediğin / dediğim daha büyük APU / multi-soket coherent APU / HSA sistemler çoğalma eğilimine girer.

    Peki crossfire olayını artık tüm gcn kartlar-apu arasında yapmaya olanak sağlayabilir mi bu mantle?

    Mesela isteyen HD7730 ile 384 çekirdek daha ekleyerek ikiye katlasın, isteyen R9-290x 'i %5-%10 daha fazla performanslı kullansın. Tıpkı lucid-virtu-mvp yardımıyla intel HD kullanarak çerçeve düzenleme/atlama yapan anakartlar gibi.




  • ne oldu arkadaşlar mantle ve bf4 gösterimi?
    bunun dışında elimizde yeni bilgi var mı formattan takip edemedim
  • DICE'ın BF 4 Mantle sunumu yarınmış ama bugün şu saatlerde Mantle ile ilgili ayrı bir sunum olması gerekiyor ancak başka bir konu canlı yayınlanıyor.
  • Tugrul_512bit kullanıcısına yanıt
    Mantıklı olan öyle gözüküyor şu an. Burda önemli olan 2 şey var çıkış fiyatı ve zman içinde son kullanıcının eline geçerken ki 3-5 bi fiyat düşüşü. 7750 gddr5'e %50-75 aralığında katkı yaparsa eh işte ile kabul edilebilir arasında bi seviyeye getirmiş olur(7790/260x/560ti/6870 vs. gibi). En azından eski APU'lardaki gibi CF ile yine gidebileceğin yer kısıtlı olmaz.GCN kartlardaki CF ile ilgili her tür yenilikten faydalanacaklar. Daha az sorunla karşılaşılacak . Trinity + 7750 , vliw + GCN yapısı hemen hemen hiçbi getiri sağlamıyor .Bi yerlerde 7750 ddr3 ve 7750 gddr5'i cf edeni görmedim ama (7790/260x/560ti/6870/650ti) ile karşılaştırılacak seviyeye getirebilir performansı. Sadece %25 civarlarında bi katkısı olursa da 7770 civarında perf. verir.

    daha üst kartlar için özel bi kısıtlama getirmezler diye umuyorum. 3-5 ilave performasn Kaveri alacakların işine yarayabilir ilerde. Geriye maliyet ve olası alternatifleri karşılaştırmak kalıyor. Intelin dual core CPU'ları ile Kaveriyi karşılaştırmak sorun olaiblir. i3 ler belirgin oranda pahalı. Farklı kombinasyonları fiyatlar belirleyecek. Eğer Intel / AMD CPU + anakart + ekran kartı fiyatı, Kaveri + ekran kartına göre daha yüksek kalırsa veya performans pek rekabetçi olmaz ise kısmen AMD'ye ilave katkıda bulunabilir.

    i3 + h61 + 7770 >> 600tl >>7790 ile >> 650tl

    Kaveri sistem + CF için en ucuz ekran kartı heralde en az 50-100tl daha pahalıya mal olur. Gerisi 7770'e ne kadar fark koyacağına göre değişir artık. Bi yerlerde 7750 ddr3 CF karşılaştırmasına denk gelen olrsa fikir verebilir. Aradaki ilave fark ile i3 sisteme 7790 da alınabilir.

    O zman Kaveri'nin 7790'ı geçmesi lazım idare edecek ucuz bi i3 sisteme göre avantajlı olabilmesi için.




  • @Rubisco

    Peki hangi HD7790'u geçmesi gerek? Mantle optimizeli olanı mı yoksa şimdikini mi? Sanırım bu soru biraz garip oldu mantıksal olarak, kusura bakma. Hani hem draw-call sayısı arttırılacak mantle ile, hem de kaverinin yollama-alma gecikmesi olmayacak yani iki kere gecikmesiz olacak, i3+gtx650 ile bunlar var olacak.



    < Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 12 Kasım 2013; 20:51:42 >
  • E şimdikini tabi :// Mantle'ın farklı kombinasyonlara eşit davranmayabileceği gibi bi olasılığı da göz önünde bulundurmak lazım. Mantle tek karta çok yarar CF lik Kaveri+harici kartın kafasını karıştırırsa daha da zora girer iş.

    Ama CF'yi faln temel rutinlerini kendileri yazsa çok daha iş çıkartacğını söyleyenler var bi çok defa sağda solda yazdım. A.L faln dahil bu isimlere. Bu yüzden Mantle CF açısından da iyi bi verim verebilir(yukardakinin tersi durum). O zman belki 7790 ile karşılaştırılablir perf verip geçebilir de.

    7750 ddr3 CF testi görmüşlüğüm yok yada ddr3+gddr5 şeklnde, fikir verebilirdi olsa. CF gddr5 kabul edilebilir bi artışı var.
  • @Rubisco

    Aslında buna uygun sayılabilecek bir çeşit programlama türü vardı unuttum adını, bildiğim kadarını söyleyeyim:

    1)Çizimi yapılacak nesneler sıraya konulup parçalara ayrılır ve hesaplanacak fizik öğeleri de parçalara ayrılır.

    2)Daha sonra sistemdeki tüm hızlandırıcılar vb... için çalışabilirlik durumu algılanır. Uygun olanlara iş verilir. Kim işini çabuk bitirirse, sıradaki işi kapar.


    Simülasyon: 3dmark11 P-preset, combined.

    Sadece 1 adet çerçeveyi bitirmek için gerekli işlemler 15 adet çizim + 12 adet fizik olsun.

    Başla.

    kalan iş: 15 çizim + 12 fizik

    Aygıt durumu: HD7850= 5x, APU=2x

    Aygıtlara iş sağlanıyor: HD7850=3 çizim + 2 fizik, APU=1 çizim + 1 fizik
    kalan iş: 11 çizim + 10 fizik

    Aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    Aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    Aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)

    Aygıt durumu: APU=2x
    Aygıtlara iş sağlanıyor: APU=2 çizim
    kalan iş: 9çizim + 10 fizik

    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)

    Aygıt durumu: APU=2x
    Aygıtlara iş sağlanıyor: APU=2 fizik
    kalan iş: 9 çizim + 8 fizik

    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)

    Aygıt durumu: HD7850=5x, APU=2x
    Aygıtlara iş sağlanıyor: HD7850=2 çizim + 2 fizik, APU= 2 çizim
    kalan iş: 5 çizim + 6 fizik

    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)

    Aygıt durumu: APU=2x
    Aygıtlara iş sağlanıyor: APU= 2 çizim
    kalan iş: 3 çizim + 6 fizik

    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)

    Aygıt durumu: APU=2x
    Aygıtlara iş sağlanıyor: APU= 2 çizim
    kalan iş: 1 çizim + 6 fizik

    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)

    Aygıt durumu: HD7850=5x, APU=2x
    Aygıtlara iş sağlanıyor: HD7850=1 çizim + 4 fizik, APU= 2 fizik
    kalan iş: yok

    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)
    aygıt bekleniyor...(bu sırada CPU çekirdekleri de botları oynatıyor, oyun değişkenlerini hesaplıyor, sırayla yapılan bir işi yapıyor hatta fiziğe yardım ediyor)

    çerçeve çiziliyor

    başa dön.



    < Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 12 Kasım 2013; 22:15:39 >




  • AMD outlines HSA push
    http://www.fudzilla.com/home/item/33113-amd-outlines-hsa-push

    Updated software support

    .......AMD is promising to deliver an updated software developer kit, including :

    a GCC/HSA Linux compiler,
    PGI Accelerator compiler for C and C++,
    Open CL Math,
    math library ArrayFire 2.0 for Open CLE and CodeXL,
    a tool suite for Linux and Windows.

    Although some big names ( intel ve nvidia hemen akla geliyor) are still missing from the list of HSA supporters,
    the list itself is growing and it’s already impressive :
    ARM,
    Imagination,
    Qualcomm,
    Samsung,
    Mediatek,
    Texas Instruments,
    LG,
    Sony,
    Canonical,
    VIA,
    Marvel,
    Vivante
    and Broadcom are on board, to name a few. Intel and Nvidia are not.

    Oracle is expected to roll out a Java update to harness the full potential of HSA. Java Lambda expressions should allow developers to accelerate parallel projects on GPU cores by 2015.



    < Bu mesaj bu kişi tarafından değiştirildi cats.in.the.cradle -- 12 Kasım 2013; 22:30:24 >




  • Oracle açıkladı bugün HSA'ya katılacağını vs. En azından elle tutulur her yerde çalışabilir demo da yaptılar.

    @Tugrul_512bit Workerlar arası senkronizasyon hiçbi şart altında gerekmeyecek mi, gerekirse nasıl senkron edeceksin, main worker ile nasıl iletşim kuracaklar vs. vs. vs. tonla aydınlatman implemente etmen gereken şey var. Kurman gereken devasa bi framework var, bugün dünyada bunun altından kalkabilecek bişey yok. HSA bunu amaçlıyor ama yüksek seviyede. C# yada Java ile, yüksek seviyede yazdığın kodun, takr takr OpenCL kerneli yazmışsın gibi çalışmasını sağlatmak istiyor. Veya imkan varsa GPU değil DSP vs. üstünde.

    Belli bi Framework olmadan bunları birleştirmen çok çok zor çok karmaşık, çok fazla detayı kayıp parçası vs. si var. Birbirleri arasında bağımlılık olmaması lazım bahsettiğin gibi çalışması için, gerçek dünyada imkansız. Bağımlılıkları kıracak gelişmiş bi scheduler altyapısı lazım o da olamaz. Bağımlılıkları azaltabilirsin ama tamamen kıramazsın. Ondan sonra dönüp dolaşıp farklı threadler arasında senkronizasyon / iletişim / belli limit / bariyere ulaşınca senkronize olana kadr boş beklemek yerine başka işle uğraştırman lazım vs. vs.

    Yazdığın şeylerin parça parça farklı yerlerde yapılma durumu var veya yapılabiliyor. Ama baştan aşağı bütün sistem kaynaklarını dinamik oalrak kullanabilecek ve kullandırtabilecğeimiz tam bi yapı yok. CF benzeri işi mesela 12:3 oranında önceden bölersin. Sürekli dinamik olarak kalan işi yapabileceğin kadar kaynağın ve zmanın yok. Senin varsayımsal modelinde görev dağıtıcısının %100 olarak bağımsız iş yapabileceğine 1 kere dispatch ettikten sonra hiçbi threadin kendisine yakın olmayan gruptakiler ile veya daha yukarıdaki birimlerer ile ortak bi havuzda vs. iletişim kurmayacağı temel alıyorsun. Grafik için bunu yapamazsın, yapmak içn asla ama asla geri bildirimin olmaması gereken bi yapı kurman lazım. 1 kere dispatch ettikten sonra mümkün olduğu kadar sonuçların yerel olarak kullanılmasını istemen gerekir. harici karta sürekli emir yolla, APU'ya emir yolla, aralarındaki iletişim sorununu yok sayıyorsun yada önemsemiyorsun. dispatch ettikten sonra kendi kernellerini çalıştırsınlar ve anca yeni dispatchler ile bu çalışma yapısı değişsin demen lazım. Onu da her tür yapıya uyduramazsın sorun orda. N-body'e bi kısmını uydurursun, her bi parça sade etrafındaki parça ile etkileşir. Farklı kuvvet grupları / yerçekimini işin içine dahil ettiğin zaman dönüüp dolaşıp bağımlılıklar oluşur. Bağımlılığı dizayn aşamasında bi yere kadar kırmaya çalışırsın gerisi alt seviyede donanıma kalır (veya compiler altyapısına, daha öncesinde de kodlama alyapına).

    Problemi tamamen bağımsız parçalara ayırmadığın sürece VE düşük gecikme süreleriyle işleyemediğin sürece, her bi parçasını ne kadar hızlı işlediğinin önemi kalmıyor. Bugun Nandini (Oracle Java VP) tam bunun üstüne parmak bastı. Sen BigData ile uğraşmak istiyorsun, elinde Tesla'lar var, ama o dediğim noktalardan sonra bu artık BigData olmaktan çıkıyor, sadece FastData'ya iniyor. Yapabildiğin bunları yerel olarak hızlı işlemek. En temelde fundemental olarak ne bu amaca uygun farklı bi yazılım altyapın var ne debuna uygun donanım altyapın . Birbirleriyle iletişim kurma / konusunda sorun yaşayan donanımların var, bunlarda o BigData'yı FastData kavramına çeviriyor. Teslalar arasında mikrosaniye seviyesinde MPI iletişimi kurman, Teslalar için Melanox ile Infiniband altyapısı kurmaları, GPU'nun başka bi serverdaki GPU'ya mikrosaniye mertebesinde komut yollaması sadece FastData'da kalmana yol açıyor. Fundemental olarak temel olarak yazılım altyapın da buna uyugn değil, portatif de değil, başka sistemlerle uyumlu değil. Dönüp dolaşıp en baştaki limitlere takılıyorsun. Nvidia boşuna bi tarafını yırtmıyor CPU'dan kurtulalım diye (sırf Xeon'dan kurtulup cebini doldurmak için değil anı zmanda tam unified bi CPU--GPU altyapısı kuramadığı için, bunu geliştirmek için işletim sistemini çalıştırmak bi yandan da GPU/Tesla'yı sürmek için yeterli donanım altyapısı için dünya kadar başka şey istediği için vs. vs. ). Echelon peşinden boşuna koşmuyorlar. O zamana kadar altından kalkabilecek şeyleri yok, yapabildikleri FastData olarak işlemek. Temel olarak olaya bakış açısında değişim getiremiyorlar.

    Bu da bizi en baştaki sorunumuza geri götürüyor. Eğer Kaveri tarzı bi APU'nun devasa versiyonlarını yapamazsak farklı sistemler arasındaki iletişim yükleri bize bela olur. İş dönüp dolaşıp bizim problemin çözümü aşamasında tasarımını yaparken, problemi çok çok yüksek oranda bağımsız parçalara indirgememiz gerekiyor. Bnu yaparken de elimizdeki donanıma bakıyoruz. Bu şekilde parçalarsak ne kadar verimle işleyebilriim duvara toslamadan önce vs. diye.

    Oyun kısmına geri dönersek(hiç o kısmına girmedim dikkat edersen, çoğunlukla GPGPU / HPC üstünden gittim), 3d render kısmında driver altyapısının nasıl işlediğine vs. sine bi miktar bakarsan bi sürü user moddan kernel moda geçiş olduğnu driverın gidip GPU'ya bişey koyduğunu, sonra GPU'nun geri dönüp bana bişey koyuldu bunu aldım işledim sana bunu geri bildiriyorum dediğini vs. vs. bunun da tonla başka kımı var. Şu an oyun için yaygın Dx var. GL bunu parmak şıklatalım, şık, bütün dertlemizin çözümü noktasına indirimeyiz. Mantle tarzı zımbırtılar da bi yere kadar. Farklı donanım birimleri arasında iletişim kurmamız, geri bildirim almamız vs. gerekiyor, birbirleri arasında bağımlılıklar oluyor. Bunları kıramıyorsun, conditional jump vs. gibi şeyler yerine GPU'lar bi maske ekliyor pipeline'a. Bunun üstünden bi bracnh açıyor, iki farklı durumu da işliyor. Bu tarz kısımlar işin alt seviye kısmına giriyor. Alt seviyede komutların işlemesi , GPU birimlerinin iletişimi vs. CPU'dan çok çok farklı değil. Bi sürü branch, yerine göre prediction, yerine göre önden yollanmış hint vs. vs. tonla şey var. Alt seviyede komutlar arasında iletişim, senkronizayon, yeni veri yüklenmesi, geri bildirim yapılması, sonuçların bi yere yazılması vs. yine tonla şey var. Ama burda donanım seviyesinde bu bağımlılıklar ile yapılacak işlerle faln uğraşıyorsun. Yüksek seviyede, Dx komutlarına faln gedlğin zaman HLSL ile, veya GL için GLSL ile shader üstünden yapacakların için yine limitlerin var yine duvara toslayacağın yer var. Harici GPU'ya Vec4 yolla, dahili APU'ya Vec2 yolla, işle de. Bunun için de geri bildirim vs. gerektirmeyen yolla-ve-unut tarzı bi driver altyapın faln olmalı. APU'ya yolladğın işler için GPU'ya yolladığın işler için, en sonunda bi yerde bunların sonuçlarının birleştirilmesi vs. si gerkli.

    Hep dönüp dolaşıp aynı yerlerde tıkanıp duruyoruz.




  • @Rubisco

    Anladım, diyorsunki alınacak çok yol var. İşi paylaşacak şeyler birbirlerine çok yakın olmalı ki sonuçları birleştirilip tekrar dağıtılırken senkronizasyon sorunu azalsın. Yani APU içindeki CPU ile GPU birbirlerine çok yakınlar ama harici kart çok uzak. Harici GPU yerine daha büyük APU çok daha verimli ya da f/p olabilir diyorsun ya da harici iki kart olacak ve crossfire/sli yapılacaklar ve APU bambaşka bağımsız bir işle uğraşacak.

    Haklısın, oyun uzayını küplere bölüp her küp içindeki cisimleri farklı bir işlem biriminde(çarpışma noktaları, kırılma, parçalanma yani kütleçekimi olmasın) yaptırabiliriz o zaman çünkü bir küp içindeki tahtalar kırılırken diğer küplerin içindeki tahtalar ile etkileşmiyorlar.

    Javanın(8?) yapacağı katkı paralel-stream olayı mı olacak? Demosunu indirebiliyor muyuz? Şu anda sadece map-reduce, min,max gibi işlerde kullanılabiliyor sanırım. Yoksa aparapi olayı javaya entegre mi edilecek?

    Her oyun/benchmark başında bir ön-benchmark ile en zorlu işi hangi parçaya vermek daha iyi olur o bulunsa mesela elimizde APU+HD7730-cf var , ön benchmark sonucuna göre render işlemini CF'ye vermek uygun görülmüş olsun. Tamamen bağımsız olan yapay zeka, gaz akışı hesabı, kırılan kutular, ses yankıları hesabı gibi şeyler de APU'da hesaplanacağı ortaya çıksın ön-benchmark yardımıyla. Yoksa her olasılığı, tüm kart kombinasyonlarını sürücüye koymak hatta overclocklu durumları hesaba katıp önceden tanımlanmış yük hesabı yapmak zor olmaz mı? Belki eleman apuya öyle bir oc çekecek ki HD7850 yi sollayacak ama oyun bunu algılayamayacak ve darboğaz meydana gelecek, güç boşa gidecek.



    < Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 13 Kasım 2013; 0:59:11 >




  • quote:

    Orijinalden alıntı: Tugrul_512bit


    Her oyun/benchmark başında bir ön-benchmark ile en zorlu işi hangi parçaya vermek daha iyi olur o bulunsa mesela elimizde APU+HD7730-cf var , ön benchmark sonucuna göre render işlemini CF'ye vermek uygun görülmüş olsun. Tamamen bağımsız olan yapay zeka, gaz akışı hesabı, kırılan kutular, ses yankıları hesabı gibi şeyler de APU'da hesaplanacağı ortaya çıksın ön-benchmark yardımıyla. Yoksa her olasılığı, tüm kart kombinasyonlarını sürücüye koymak hatta overclocklu durumları hesaba katıp önceden tanımlanmış yük hesabı yapmak zor olmaz mı? Belki eleman apuya öyle bir oc çekecek ki HD7850 yi sollayacak ama oyun bunu algılayamayacak ve darboğaz meydana gelecek, güç boşa gidecek.






    Aparapinin Javaya entegre hali gibi ama temiz bi syntax vs. ile. Demo belki sonradan çıkartırlar public yaparlar. Bi sürü session var hepsi dıraşı kapalı ve derya gibi şeyler var.

    Oyunlar öyle yapılmıyor işte. Oyun dediğin şey için de dünya kadar durumu göze alman gerekiyor. Yetiştirmeye çalışılırken zar zor yetiştiriliyor artık, yıllar öncesi gibi değil. Yıllar önce PC Gamer "oyunlar artık beta haliyle satışa çıkıyor, kullanıcılar bugları temizliyor" gibisinden yazı yazmıştı. Şimdiki durum onun aşmış hali. Düzgün sorunsuz oyunlar da var ama çok oyunda öyle veya böyle sorunlar dizisi var. Saha testi son kullanıcı ile beraber bi tür geniş alanlı test olarak yürüyor. Beta meta olayları zaten farklı bi konumda artık feedback almak için.

    İş böyle olunca, desteklemen gereken bi sürü cpu gpu mimarisi ve versiyonu olunca, olabildiğince hepsinde iyi çalışan bişey çıkartmaya çalışıyorlar. ****da bu dertlerin hiçbiri yok. SAbit platformun güzelliği orada, bodoslama istediğin kadar uç noktalara gidebilirsn. Pc için, bahsettiğin APU + CF küçük bi kullanıcı kısmınını oluşturuyor. Buna itiraz oalrak notebooklara, Intel'in işlemcisinin dahil olduğu Intel işlemci + harici GPU gibi durumları öne sürebilirsin. Bu seferde oyun geliştricisine, envai çeşit AMD Intel APU + harici GPU için bi render altyapısı kurdurtman lazım. bunu da driver dışından yapman lazım. Kimse bunu yapamaz.

    AMD APU kısmına geri dönersek, bu tarz şeyler için baskı oluşturacak kadar geniş bi kullanıcı kitlesine ve yaygınlığa sahip değil. O yüzden kısım kısım mantıklı olsa da kimse onlarla uğraşmaz. Özellikle de geridönüşünün kısıtlı olduğu şeyler için. Onun yerine bugun olan şey, kullanmaya çalıştığın motora veya render altyapısına göre sistem kaynaklarını tahmin etmek. Çünkü çok çeşitli kullanıcı kitlesi var, bunların bi ton donanımı var. Sade APU CF için ise az sayıda kullanıcı var. Dönüp dolaşıp önceden bi yerde örneğini verdiğim ARM gillerden neden konsol çipi olmuyor olayı gibi noktaya geliyoruz. Geliştrici olarak küçük bi kullanıcı kısmına, varolan driver altyapısının tanımadığı ayrıcalığı tanıtmak istiyorsun. Driver altyapısı uygun olrsa Dx API üsütnden kurtarmaz uğraşmam dersin. Mantle için belki olur, detaylarını bilmioz mantle'ın çünkü.

    Geliştrici önceki paragrafta, belli miktar varsayımda bulunuyor ona göre sistem kaynaklarını dağıtıyor. Mesela 4 thread üstünde kuruyor sitemini. 1 tane ana thread CPU kullanımında 1. çekirdeğin %95 seviyeleirnde meşgul ediyor. Render için de bu thread kullanılıyor. 2. 3 4. threadler diğer işlere yarıyor. Sonuçta elinde 4 çekirdekli işlemciyi %95 %13 %5 %12 oranlarında kullanan bi oyun çıkıyor. 6 8 çekirekli işlemciye koyduğun zman bunu yine saçma sapan dağılımlar kalıyor elinde. Hatta belki çok çekirdeği kullanmaya çalıştığından dolayı oluşan overhead performansı bile düşürüyor.

    Sistem kaynaklarını tamamen dinamik ve verimli kullandırmtak için çok şeye ihtiyacın var. Bench 'e göre latency / throughput da test eder ona göre latency critic işleri hangisi iyi ise ona througput critic işleri diğerlerine atar. Oc li örnek verdin mesela, süper bi latency elde etti, ana render threadini ayrı bi çekirdeğe atar sürekli GPU'ya yüksek oranda dispatch edilmesini faln amaçlar. Olabilir bunlar ama çok çok çalışma ister, geri dönüşü soru işareti ama. AMD APU'lar %50 pazar payına sahip olsaydı, millet yatar kalkar bunlardan yağ çıkarmanın yollarına bakardı. Şimdiki pazar payı ile olası geliştirme zamanına değmez, uğraşmayız derler o kadar iş ile. Bunlara ayıracaklar zaman vs. için, daha iyi bi render kodu sıkıştırma kodu vs. bi ton başka şeyler uğraşırız diyebilirler ve haklılar. Arz talep eldeki imkanlar meselesi hep. ARM'dan konsol yap, koy MP32 GPU'yu. Hani nerde gerçek hayatta uygulaması var mı 1 Tflop'u geçen PowerVR? Kim lisansını alıp geliştirme işini gözü yiyor? Napıyorlar o yüzden, anca varolanla yetiniyorlar varolan tasarımları kullanıp konsol çakması bişeyler yapıyorlar. burda da durum aynı. Büyük bi kullanıcı kitlesini peşinden süürkleme imkanı olsa suyunu çıkartana kadar peşinden koşarlar. Konsolların farkı orda, dandik PS3'ün RSX'inin yapamadığı işleri arkasından dolaşa dolaşa yapabildiler bugune kadar geldi. Pc vs. ps3 bf3 'e bakıyorsun fark var kabul, ama o PS3'de BF3'ü çalıştırmanın bi nimet olduğunu anlayabilenlerin sayısı az (PS3'ü kötülüyorum burda, başka türlü anlayanlar olr). Geri dönüşü olan sana bişeyleri geri verebilen bi durum var, PS3'de geliştirme yaptığın zaman. Çünkü sabit platform. Bunun suyunu çıkartana kadar herşeyinin peşine düşersin, millete de bi voaaa dedirtecek oyun verebildiğin zaman 150TL den de 250TL den de satarsın oyunu. PC, APU CF olayı öyle değil, sorn da orda zaten.

    Madem öyle, biz kodlama altyapısını geliştricilerin değerli bulabileceği çabuk geliştirme yapabileceği hale getirelim diyorlar. Olup biten herşey bununla alakalı. Orta karar bi C# / Java programcısına Al sana GPU al sana OpenCL al sana PC geliştir hızlandır bunu diyoruz bugun. HSA, direk senin yazdıkalrın ile alakalı değil ama bu C# Java programcısını , bugun OpenCL'de iş görecek kernel yazan C++ programcısının yaptığı işlerle karşılaştırılabilecek kadar ama bunu çok daha kolay yollardan yapma imkanı veren bi altyapı geliştrime olma derdinde. Bu, oyun yapımcıları içinde ters taraftan aynı. Mantle gibi yapılar (illa mimariye bağımlı olmak zorunda değiller), uygun library altyapıları ile uygun bi erişim altyapısı ile sana aylarca sürece araştırma inceleme içinden çıkmak için debelenme sürecini haftalara indirgeyecek ortam sunumalı. Ondan sonra sen, coherent yapıyı kullnmak için "oranın adresini nerde tutacaz, pointer buraya nasıl pass edilecek, şunu şurda parse etmem gerekir mi"" diye şeylerle mücadele etmeyeceksin. çağıracağın bi fonksiyon yada belli bi template sana pointer'ın assign edileceği yeri geri bildirimini vs. sini otomatik ayarlayacak hazır o kod kısmına yerleştirecek. Ondan sonra sen coherency için dert etmeden işini görebileceksin, farklı tasarım istiyorsan onun peşinde koşacaksın. Voxel bazlı bi iş için vaktini ona ayıracaksın mesela APU'daki Coherency'i kullanıken harici CF için 3 kuruş hızlanma nasıl elde ederim diye takla atmakla uğraşmayacaksın. Yine aynı şeyi söylersem dönüp dolaşıp pazardaki % ile alakalı. büyük baş olursan sana uymaya çalışan çok olur. yoksa böyle sürünürsün. Eski yönetimleirn yeterince göremediği içinden çıkamadığı şeyler hep bunlarla alakalıydı AMD'nin anasını ağlattılar.

    Bu dediklerim ile , motorun bi kısmı hazır olmuş gibi oluyor. Belli işlemler için amerikayı yeniden keşfetmemen o donanıma uygun altyapının olması çok önemli şeyler. Developer programları buna benzer şeyler için var, ama tam bu APU / CF gibi daha düşük kullanıcı kitlelerini hedef almıyor. Geliştricilerin bunları da hedef almaalrı içn onlara hızlı geliştirme yapacakları ortam sunuman lazım tak tak halletsinler diye. %10lık kesimi dışarda bırakmasınlar, onlar için de hızlı çalışan bi kod alyapısı sunsunlar diye. uzun vadede anca olabilecek işler bunlar hep.




  • 
Sayfa: önceki 23456
Sayfaya Git
Git
sonraki
- x
Bildirim
mesajınız kopyalandı (ctrl+v) yapıştırmak istediğiniz yere yapıştırabilirsiniz.