Üye Girişi
Bağlan Google+ ile Bağlan Facebook ile Bağlan
Yeni Kayıt
Tüm Forumlar
  • Tüm Forumlar
  • Donanım / Hardware
  • Dahili Bileşenler
  • İşlemci
  • Bu Konuda
Şimdi Ara

AMD Zen: 32 Çekirdekli EHP APU’su Yolda! (3. 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ü
5 sn
86
Cevap
4
Favori
3.602
Tıklama
Daha Fazla
İstatistik
  • Konu İstatistikleri Yükleniyor
Konuya Özel
1 oy
Öne Çıkar
Cevapla
Sayfa: önceki 12345
Sayfaya Git
Git
sonraki
Giriş
Mesaj
  • Bir ara da şunu göstermişlerdi:

    AMD Zen: 32 Çekirdekli EHP APU’su Yolda!

    Bundan bir şey çıkmadı. Şimdi yine bir laflar dönmüş ama 1-2 yıla ne olduğu, ne olmadığı anlaşılır.
  • rabitelli kullanıcısına yanıt
    Phi mini Linux çalıştırır. Kendi başına işlemci olduğundan Tesla faln gibi tamamen bi altyapı üstünden %100 bağımlı olarak çalışmak zorunda değil. Küçük işlemci çekirdekleri olduğundan, doğal olarak tek bi çekirdeğin çok fazla gücü yok, bu yüzden de karmaşık işletim sistemi işlemleri yapamaz. Ama kart mini linux gibi bi yapı ile boot ediyor. PCI üstünde, takılı bulunduğu sistemdeki ana işlemci ile (host ile) esasında aynı makina-kasa içinde 2 farklı bilgisayar gibi çalışıyorlar. Tesla vs. kendi başına verilen işi yapabilse bile, temelinde işletim sistemi gibi kendi başına çalışmasını sağlayacak bi yapı tam olarak yok, temeli CPU bazlı değil çnkü. Phi kendi başına çalışır ama dışardan veriye ihtiyacı olduğundan, bunu beslemek için de karmaşık yapı gerekmesin diye argesi kolay olsun diye bu tarz kart şeklinde yaptılar


    Xeon Phi de co/accelerator sınıfında olduğundan, esas işlem gücünü host-cpu değil bu tarz hızlandırıcı kartlar-yapılar yaptığından, AMD veya diğerlerinin hedef olarak birbirlerinin en hızlı-güçlü yapılarını hedef almaları normal. IBM'i kıstas alsalardı belki bütün bi BluGene box'ı hedef alırlardı.

    Yani CPU temeli olan, hızlandırıcı SIMD ilaveleri var diye Phi ile karşılaştırmışlardır.

    Phi'nin yakında-ilerde CPU gibi soket şeklindeki versiyonu olacak. 2 soket işlemci gibi birine CPU diğerine Soket Phi takılabilir olması için de çalışıyorlar.

    Knights Hill, yeni versiyonu , yüksek miktarda HBM/DRAM karışımı düşünülürken daha farklı tasarım ise tamamı HBM içeren tasarıma yöneldi.

    Öbür taraftan da çok yüksek miktarda BW = yüksek veri transferi demek. Veri transferi, her zaman yapılan hesaptan daha fazla güç tüketilmesine yol açar. Bunun için alternatif yollara gidilmeli(eski dost, yeniden gündemde kavramları gibi, FPGA temelli sade algo hızlandıran yapılar, direk bellekde hesap yapılmasını sağlayan PIM / processing in memory tarzı yapılar vs.). Ama şimdlik bi yol-trend var diye de, sonuna kadar zorlamadan hepten bu tarz yollara gidilmeyecek gibi duruyor (fotonik zımbırtılardan farklı ram-depolama türlerine vs. kadar).

    Nod küçültüp güç kullanımını azlatmak, yüksek bw'yi kullandığın zamanki ilave güç ihtiyacının bi kısmını karşılar. Şimdiye kadar da böyle oldu ve böyle olacak.

    Alakasız , Fury'yi Sandra ile latency + bw vs. şeklinde test eden kimse çıkmadı mı?
    Nvidia'nın yeni kartı, HBM tarzı bellek kullanırken tamamen o BW'yi verimli kullanmaya yönelik tasarlanacağından, yani mimari temelden farklı yaklaşımla kurulacağından, perf. zıplaması yüksek seviyede olacak-olmalı. Bunun götürüsü olarak da yüksek bw=yüksek güç tüketimi olduğundan, 16nm fet yapı ile güç tüketimi aşağı çekilmiş olacak. vs. vs.




  • Rubisco kullanıcısına yanıt
    saol, cidden bi nane annamadıydım konuyu ilk okuduğumda. imdi bi şeyler canlalandırabiliyorum zihnimde

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

    Orijinalden alıntı: Chris Brown

    5820K aldım, memnunum , içim rahat. Belki biraz pahalı ama hakkını veriyor.

    Anakart üreticileri intel'e model yetiştiremezken , amd de anakart alternatifi bir elin parmakları kadar. Anakarta 500TL ve üzeri papa verilince insan hakkını almalı, bu da şuan AMD de çok mümkün değil. Kullanım alanına göre AMD intel ile denkliği ya zar zor sağlayabiliyor, yada hiç sağlayamıyor. Yahi şöyle söyleyeyim, İntel i7 nin en düşük Cpu sunun bile dengi AMD de yok ki , intel seviye uç noktalarda. Bu sebeple amd nin şu saatten sonra bu denkliği sağlaması çok çok zor. İmkansıza yakın hatta. Mühendislerin daha çok fırın ekmek yemesi lazım ki amd büyüklük olarak intel ile kıyaslanamaz bile.

    Bu sebeple zaten intel don değiştirir gibi soket değiştirip kullanıcıları bolca masrafa sokuyor. Bunun gereksiz olduğunu bilenlerde zaten, sistemlerini ona göre kurmalılar. Alınan sistemlerde bir yada 2 model üst cpu takılabilir olmalı ki, o sistem uzun ömürlü olsun. Bu sebeple bütçesi olan düşünmeden soket 2011 V3'e geçebilir.

    Son söz, amd fırıncı olsa inteli yakalaması zor. Cpu yerine bütünleşik grafik yongası güçlü bir tasarım çıkarmalılar, 7850K ' nın çok daha gelişmiş bir versiyonu olmalı mesela, orta sınıfa hitap eden.

    Bende önceki yorumlarımda hep bundan bahsettim.

    Daha önceleri biçoğumuzun merakı olmuştu gpu ya cpu nun işini yaptırmak. Daha doğrusu onuda bir işlemci olarak kullanmak. Heleki profesyonel ekran kartlarındaki pararlel işlem yeteneğini göz önüne getirdiğimizde bu dahada açığa çıkıyor. İntelin 3500 liralık işlemcisinin 1 saatte yapacağı işi en fazla 600 TL lik, profesyonel ekran kartına çevrilmiş bir ekran kartı yada 1000 Tl civarı bir profesyonel kartın 15 dakikada yapması olasıdır. (Rakamlar örnek. birebir değer değil ) Tabiki bu sadece bir alanı kapsıyor gibi görünsede bu tip bir işlem biçiminin gücü hakkında bizlere bilgi veriyor.

    Bu yüzden amd gpu ile cpu bir araya koyduğunda ilk aklıma gelenşey bu olmuştu. Özellikle endüstriyel alanda bi devrim niteleğinde olabileceğini düşünmüştüm.

    Amd de a10 6800k nın ardından sitesinde bunu açıkca dile getirmiş ve bir mimari olarak bize göstermişti. GPu ile cpu yu bir işlemci gibi kullanarak çok daha iyi performans vaaddiğini söylüyordu özellikle endüstriyel çözüm olacağını söylüyordu.

    Amd verdiği sinyaller ile bunun üzerine gideceğini dahada geliştireceğini artık bu tümleşik ve karma teknolojiyi daha kullanılır ve kullanıcı dostu haline getireceğini ve kullanıcılara sunacağını gösteriyor bana göre.

    Amd bu konuda intel e oranlı iyi bir gelişim gösterdi. Ancak intelin eli de armut toplamaz amd iyi bir gelişim gösterdiğinde. O da bu HSA teknolojisini işlemcilerine yerleştirecektir diye tahmin ediyorum. Masaüstünde olmasada server tabanlı çözümleri hali hazırda mevcut intel in bu açıdan.

    Söz konusu iş ise amd diyorum ben. Şuan her bir iş ortamında amd nin iyi çözümleri olduğunu düşünüyorum. Sadece masaüstü kullanan yada ağırlıklı olarak masa üstü kullanan işletmelerde amd nin işlemcileri yeterli olacaktır genellikle. Mutlaka ve kesin demesek bile. Dolayısı ile Amd yi övmekte en azından arkasında durmakta haklı nedenlerimizi var. Ancak amd de kendini toparlamalı birazdaha ıspatlamalı ben burdayım demeli artık. Bunu kısmen a10 serisi ile başardı. Tabiki çok yetersiz şuan. Daha fazlasını ümit ederek bekliyoruz.




  • quote:

    Orijinalden alıntı: os_lnx

    quote:

    Orijinalden alıntı: Lana-Del-Rey

    quote:

    Orijinalden alıntı: Orlando DeJoseph

    Boş çekirdekler bunlar

    Bazı kişiler tarafından "ayçekirdeği" olarak da adlandırılır.

    Evet mesela ben biraz böyle görüyorum. Arada espirisinide yapıyorum.

    Çok çekirdek çok fazla çekirdek ve çok daha fazla çekirdek. Tek çekirdekte yeterli performansı ve tepkimeyi göstermedikçe. Masaüstünde çok iyi olamayacaksın. Orada iyi olamayınca dizüstü ve mobil pazarada el atamayacaksın. E tabi bu 3 pazarda olamyınca geriye ne kalıyor. Sadece serverlar için işlemci ürüten kısmen küçük bir firma olarak hatırlanmaya başlarsın çok değil 2020 de. Sonrasındaki gençler seni hatırlamaz bile.

    Açıkcası zen mimarisi ile masaüstüne gelecek olan yeni amd lerden pek ümitli değilim. İntelin g3220 çift çekirdek işlemcisinin tepkimeleri daha iyi olabilir. Sonuç olarak bazı testlerde g3220 nin arkasında kalan bir yeni nesil 2016 model amd işlemciyle karşılaşabiliriz.

    Gerçi benim dediklerime okadar inanmayın. Beşiktaş bu sene şampiyon diye konuda açmıştım. (Futboldan başka bir alanda şampiyon olmuştur umarım kendimi aklarım )

    Bu arada alıntı yaptığım kişi nick ini hiç sevmedim. Sevdiğim sanatçının ismini taşıyor. Onun ismini değil bu forumda dünyada kimseye layık görmem. Bu hiç hoşuma gitmedi hemde hiç..

    Sen ne diyorsun ya deişik

    bu ne kibir ya

    < Bu ileti mini sürüm kullanılarak atıldı >




  • quote:

    Orijinalden alıntı: Rubisco

    Phi mini Linux çalıştırır. Kendi başına işlemci olduğundan Tesla faln gibi tamamen bi altyapı üstünden %100 bağımlı olarak çalışmak zorunda değil. Küçük işlemci çekirdekleri olduğundan, doğal olarak tek bi çekirdeğin çok fazla gücü yok, bu yüzden de karmaşık işletim sistemi işlemleri yapamaz. Ama kart mini linux gibi bi yapı ile boot ediyor. PCI üstünde, takılı bulunduğu sistemdeki ana işlemci ile (host ile) esasında aynı makina-kasa içinde 2 farklı bilgisayar gibi çalışıyorlar. Tesla vs. kendi başına verilen işi yapabilse bile, temelinde işletim sistemi gibi kendi başına çalışmasını sağlayacak bi yapı tam olarak yok, temeli CPU bazlı değil çnkü. Phi kendi başına çalışır ama dışardan veriye ihtiyacı olduğundan, bunu beslemek için de karmaşık yapı gerekmesin diye argesi kolay olsun diye bu tarz kart şeklinde yaptılar


    Xeon Phi de co/accelerator sınıfında olduğundan, esas işlem gücünü host-cpu değil bu tarz hızlandırıcı kartlar-yapılar yaptığından, AMD veya diğerlerinin hedef olarak birbirlerinin en hızlı-güçlü yapılarını hedef almaları normal. IBM'i kıstas alsalardı belki bütün bi BluGene box'ı hedef alırlardı.

    Yani CPU temeli olan, hızlandırıcı SIMD ilaveleri var diye Phi ile karşılaştırmışlardır.

    Phi'nin yakında-ilerde CPU gibi soket şeklindeki versiyonu olacak. 2 soket işlemci gibi birine CPU diğerine Soket Phi takılabilir olması için de çalışıyorlar.

    Knights Hill, yeni versiyonu , yüksek miktarda HBM/DRAM karışımı düşünülürken daha farklı tasarım ise tamamı HBM içeren tasarıma yöneldi.

    Öbür taraftan da çok yüksek miktarda BW = yüksek veri transferi demek. Veri transferi, her zaman yapılan hesaptan daha fazla güç tüketilmesine yol açar. Bunun için alternatif yollara gidilmeli(eski dost, yeniden gündemde kavramları gibi, FPGA temelli sade algo hızlandıran yapılar, direk bellekde hesap yapılmasını sağlayan PIM / processing in memory tarzı yapılar vs.). Ama şimdlik bi yol-trend var diye de, sonuna kadar zorlamadan hepten bu tarz yollara gidilmeyecek gibi duruyor (fotonik zımbırtılardan farklı ram-depolama türlerine vs. kadar).

    Nod küçültüp güç kullanımını azlatmak, yüksek bw'yi kullandığın zamanki ilave güç ihtiyacının bi kısmını karşılar. Şimdiye kadar da böyle oldu ve böyle olacak.

    Alakasız , Fury'yi Sandra ile latency + bw vs. şeklinde test eden kimse çıkmadı mı?
    Nvidia'nın yeni kartı, HBM tarzı bellek kullanırken tamamen o BW'yi verimli kullanmaya yönelik tasarlanacağından, yani mimari temelden farklı yaklaşımla kurulacağından, perf. zıplaması yüksek seviyede olacak-olmalı. Bunun götürüsü olarak da yüksek bw=yüksek güç tüketimi olduğundan, 16nm fet yapı ile güç tüketimi aşağı çekilmiş olacak. vs. vs.




    Çok bilgilisin. Çok teknik konuşuyorsun. Yada yazıyorsun diyelim. Yazdıklarını anlamayı çok isterim. Ama senin bu alanda bilgi kapasitene sahip olmak bi yana yazdıklarını anlayabilmek bile benim için epey yol katetmek demek. Ama yazdıklarından birazda olsa bişeyler anladım gibi bu sefer. Detaylı bilgi içinde ayrıca teşekkür ederim. Ve bir soru ekliyim. HBM + dram veya yalnızca hbm tasarımı konusunda hangisi daha iyi olabilir ? Neden bilmem ama tamamı HBM olan bir tasarım kulağa daha hoş geliyor. Senin bu konuda bir düşüncen vardır eminim. Cevabın muhtemlen teknik detaylar içerecek ama olsun varsın.




  • quote:

    Orijinalden alıntı: Seras Victoria

    server işlemcisi haberleri vermeyin desktop sanan ergen intel fanları aklı sıra geyik yapmaya çalışıyor sonra.

    Tamam guzel diyorsunda server islemcisinde gpu ve hbm bellegin ne isi var

    < Bu ileti mini sürüm kullanılarak atıldı >
  • selmand kullanıcısına yanıt
    GPU'yu bir nevi hızlandırıcı olarak kullanıyorsun, yardımcı işlemci(ler) gibi. Çok verilen örnektir ama mesela büyük matrisler üzerinde çalışıyorsun ya da bir şifreleme/şifre kırma uygulaması yapıyorsun diyelim, GPU muazzam fark yaratıyor.
  • os_lnx kullanıcısına yanıt
    HBM tarzı yapının esas çipin yakınına takılması gerekiyor. Bunun için de şimdilik taşıyıcı yüzey ile yapılıyor (taşıyıcı yüzey= interposer). CPU-GPU veya başka olacaksa diğer çipler ile HBM çipi aynı ana taşıyıcı üstünde, aynı board üstüne yerleştirilip bağlantıları sağlanıyor. Yüksek frekanslı , yüksek bw içeren çip-çip arası bağlantı yapmak her zaman kolay değildir. Bu yüzden yakın olmak zorunda. Yakın olmak zorunda olduğu için aynı kart-pcb-taşıyıcı vs. üstüne bütün çipler konumlandırılmak zorunda. Bağlantı sayısı arttıkça bu yapıyı sürebileceğin frekans seviyesi göreceli de olsa düşmeye başlıyor (HBM'de de çok bağlantı var). Bi ekran kartı için bütün kartın pcb'sinde konumlandırılmıyor yani HBM çipleri. GPU'nun etrafında, ona yakın olacak şekilde, GPU'paketine yakın konumlandırılıyor.

    SAdece HBM 'yi bol bol kullanmayı herkes ister. Şimdilik bu pek mümkn değil. DRAM çipleri gibi, ekran kartında mesela, GPU çipinin belli meseaferlerde etrafını HBM ile döşüyemiyorsun. yukarda yazdığı gibi GPU ile aynı taşıyı kart üstünde, GPU'ya çok yakın olmak zorunda. AMD'Nin Furry kartlarında, GPU ve HBM çipleri farklı yerlerde üretiliyor, farklı tesislerde bir araya getiriliyor. Dolayısı ile o taşıyıcı kartın büyüklüğü ile, GPU ile HBM arasındaki bağlantıların sağlanabileceği genişlikte olmak zorunda. 16 GB ve üstünü AMD'nin ürettiği şekilde rahatça takamıyorsun. Bu yüzden ilk başta HBM+DRAM ile verimli bi altyapı ve yüksek bellek şeklinde düşünülmüştü(SAdece AMD değil Intel tarafından da). GPU'lar point-to-point bağlantılı çalışır. Yani her bi bellek kontrolcüsü bi bellek çipi grubuna bakar. CPU için anakarta taktığımız ramlar gibi kafamıza göre belirlenemez. CPU için 4GB için 2x2GB çip takabilrsin, 4x 1GB da takabilirsin. GPU için her bi kontrolcüye 1 çip takarsın. 128 bit demek 4x32 / 4 tane çip takabileceksin demek. Ekran kartı / GPU temelinden devam ediliyorsa, o zaman bellek altyapısını da HBM'ye göre veya HBM + DRAM yapısına uygun şekilde değiştirmek gerekir. AMD bunu Fury'de yapmadı, karşılığında da zararla oturdu kısmen.

    GPU için bellek çiplerini, kartın mimari temelini değiştirmeden olduğu gibi kullandığımızda bellek kontrolcüleri ile limitleniyoruzsak, o zman kullanabileceğimiz HBM çipi sayısı ve toplam bellek miktarı da bu şekilde belirlenmiş oluyor. AMD tarafı, mimaride değişiklik yapmadığı için 4 çip ile 4 GB şeklinde limitli şu an.

    Intel-Nvidia da aynı şekilde lmitliler. GDDR5'ler, point-to-point, noktadan noktaya bağlantı olduğundan, Intel isterse mini CPU temelli mimari gelştrimiş olsa, kartlar üstündeki dram çipleriyle eşleşecek şekilde kontrolcü yapıları gerekir. İşte bunları HBM ile değiştiremezler mi? DRAM çipleri kartların üstünde GPU'nun büyüklüğüne göre çok geniş bi alan kaplıyorlar. Oysa HBM, GPU çipine yakın olmak zorunda ve bu yüzden aynı taşıyıcıda bulunmak zorundaydı. Böylece GPU-Çipin çok yakınına konumlandırılabilrise ve GPU ile aynı taşıyıcı üstünde olmaz ise çok sayıda HBM çipinin mümkün olma ihtimali var. Oysa şimdilik bu tarz olasılıklar yok. 16 tane HBM çipi için bellek kontrolcü ve 16 çipi GPU ile sorunsuz bağlantı sağlayacak kadar yakın olma zorunluluğu var. Bu da işleri karıştırıyor. Bu yüzden Nvidia Pascal vs. için GPU'nun olduğu bloğu esas karta bi tür taşıyıcı kart ile bağlamayı düşünüyor(bu tarz taşıyıcı ile / ek olarak başka bi yapının üstüne takılan kartlara mezzanin kart faln gibi isimler veriliyor). INtel'in de o tarz farklı tasarımları var.

    önceden sadece HBM için tasarım yapılıyordu. Bunun getireceği zorluk ve başka sorunlar yüzünden, çip başına düşecek HBM sorun olduğundan, çipi bölümlendiriyorlar. Bu şekilde çip içinde farklı alanlar belirleniyor, her alanın kendisinin kontrol edeceği ulaşacağı bi ram alanı oluyor. Bu yaklaşımdan hareketle çip/çip içindeki bölümlerin direk olarak HBM için kısıtlaması azalıyor (detayını bilmiyorum, belki HBM için bu şekilde daha fazla bağımsız bağlantıya izin veriyordur, belki bağımsız kontrolcüsü vardır, belki fiziksel limit engeli olmuyordur). Bunun üstüne ilave dram bellek kontrolcüsü de ekleyeceklermiş. Böylece 16 gb HBM + 384 GB dram olacakmış. Bu, yukarda yazdığım engeller ile ters düşmüyor mu bilmiyorum. Ama Intel tarafı Phi için dha çok ram gerektiğine ve bu şekilde hiyerarşik bi yaklaşımın katkısı olacağını düşünüyor. Ram gerektiği kesin , ama bu tarz hbm+ddr4 dram tarzı yapı çipi ne kadar karmaşıklaştırır ayrı mevzu. Çipin içinde bellek kontrol birimlerinin alışılmışın çok üstünde yer kaplıyor olması lazım bunun için.

    AMD Nvidia tarafında bu kadar büyütmeyi düşünecekler mi fikrim yok. NVidia taşıyıcı/mezzazin kart ile başlayabilir. Bu şekilde 16 GB'a sorunsuzca ulaşabilmeleri lazım. 16 GB çoğu durum için oyununda pro3d'ye kadar yeterli. 32 GB versiyon da çıkartacaklar diye bliyorum. Bugün karmaşık sahne yüzünden yüksek ram gerektiğinden CPU rendera mahkum oldukları için bu tarz kartlar acayip kurtarıcı olacak. Mimarinin de bu kadar yüksek BW'den düzgün yararlanacak şekilde yeniden dizayn edilmesi lazım. Bu da yapılması gereken işleri ve karmaşıklığı iyice arttırmış olacak.

    Genelde nod değişimlerinde yüksek ilelemeler görülmesi bu yüzden zaten.




  • quote:

    Orijinalden alıntı: Rubisco

    HBM tarzı yapının esas çipin yakınına takılması gerekiyor. Bunun için de şimdilik taşıyıcı yüzey ile yapılıyor (taşıyıcı yüzey= interposer). CPU-GPU veya başka olacaksa diğer çipler ile HBM çipi aynı ana taşıyıcı üstünde, aynı board üstüne yerleştirilip bağlantıları sağlanıyor. Yüksek frekanslı , yüksek bw içeren çip-çip arası bağlantı yapmak her zaman kolay değildir. Bu yüzden yakın olmak zorunda. Yakın olmak zorunda olduğu için aynı kart-pcb-taşıyıcı vs. üstüne bütün çipler konumlandırılmak zorunda. Bağlantı sayısı arttıkça bu yapıyı sürebileceğin frekans seviyesi göreceli de olsa düşmeye başlıyor (HBM'de de çok bağlantı var). Bi ekran kartı için bütün kartın pcb'sinde konumlandırılmıyor yani HBM çipleri. GPU'nun etrafında, ona yakın olacak şekilde, GPU'paketine yakın konumlandırılıyor.

    SAdece HBM 'yi bol bol kullanmayı herkes ister. Şimdilik bu pek mümkn değil. DRAM çipleri gibi, ekran kartında mesela, GPU çipinin belli meseaferlerde etrafını HBM ile döşüyemiyorsun. yukarda yazdığı gibi GPU ile aynı taşıyı kart üstünde, GPU'ya çok yakın olmak zorunda. AMD'Nin Furry kartlarında, GPU ve HBM çipleri farklı yerlerde üretiliyor, farklı tesislerde bir araya getiriliyor. Dolayısı ile o taşıyıcı kartın büyüklüğü ile, GPU ile HBM arasındaki bağlantıların sağlanabileceği genişlikte olmak zorunda. 16 GB ve üstünü AMD'nin ürettiği şekilde rahatça takamıyorsun. Bu yüzden ilk başta HBM+DRAM ile verimli bi altyapı ve yüksek bellek şeklinde düşünülmüştü(SAdece AMD değil Intel tarafından da). GPU'lar point-to-point bağlantılı çalışır. Yani her bi bellek kontrolcüsü bi bellek çipi grubuna bakar. CPU için anakarta taktığımız ramlar gibi kafamıza göre belirlenemez. CPU için 4GB için 2x2GB çip takabilrsin, 4x 1GB da takabilirsin. GPU için her bi kontrolcüye 1 çip takarsın. 128 bit demek 4x32 / 4 tane çip takabileceksin demek. Ekran kartı / GPU temelinden devam ediliyorsa, o zaman bellek altyapısını da HBM'ye göre veya HBM + DRAM yapısına uygun şekilde değiştirmek gerekir. AMD bunu Fury'de yapmadı, karşılığında da zararla oturdu kısmen.

    GPU için bellek çiplerini, kartın mimari temelini değiştirmeden olduğu gibi kullandığımızda bellek kontrolcüleri ile limitleniyoruzsak, o zman kullanabileceğimiz HBM çipi sayısı ve toplam bellek miktarı da bu şekilde belirlenmiş oluyor. AMD tarafı, mimaride değişiklik yapmadığı için 4 çip ile 4 GB şeklinde limitli şu an.

    Intel-Nvidia da aynı şekilde lmitliler. GDDR5'ler, point-to-point, noktadan noktaya bağlantı olduğundan, Intel isterse mini CPU temelli mimari gelştrimiş olsa, kartlar üstündeki dram çipleriyle eşleşecek şekilde kontrolcü yapıları gerekir. İşte bunları HBM ile değiştiremezler mi? DRAM çipleri kartların üstünde GPU'nun büyüklüğüne göre çok geniş bi alan kaplıyorlar. Oysa HBM, GPU çipine yakın olmak zorunda ve bu yüzden aynı taşıyıcıda bulunmak zorundaydı. Böylece GPU-Çipin çok yakınına konumlandırılabilrise ve GPU ile aynı taşıyıcı üstünde olmaz ise çok sayıda HBM çipinin mümkün olma ihtimali var. Oysa şimdilik bu tarz olasılıklar yok. 16 tane HBM çipi için bellek kontrolcü ve 16 çipi GPU ile sorunsuz bağlantı sağlayacak kadar yakın olma zorunluluğu var. Bu da işleri karıştırıyor. Bu yüzden Nvidia Pascal vs. için GPU'nun olduğu bloğu esas karta bi tür taşıyıcı kart ile bağlamayı düşünüyor(bu tarz taşıyıcı ile / ek olarak başka bi yapının üstüne takılan kartlara mezzanin kart faln gibi isimler veriliyor). INtel'in de o tarz farklı tasarımları var.

    önceden sadece HBM için tasarım yapılıyordu. Bunun getireceği zorluk ve başka sorunlar yüzünden, çip başına düşecek HBM sorun olduğundan, çipi bölümlendiriyorlar. Bu şekilde çip içinde farklı alanlar belirleniyor, her alanın kendisinin kontrol edeceği ulaşacağı bi ram alanı oluyor. Bu yaklaşımdan hareketle çip/çip içindeki bölümlerin direk olarak HBM için kısıtlaması azalıyor (detayını bilmiyorum, belki HBM için bu şekilde daha fazla bağımsız bağlantıya izin veriyordur, belki bağımsız kontrolcüsü vardır, belki fiziksel limit engeli olmuyordur). Bunun üstüne ilave dram bellek kontrolcüsü de ekleyeceklermiş. Böylece 16 gb HBM + 384 GB dram olacakmış. Bu, yukarda yazdığım engeller ile ters düşmüyor mu bilmiyorum. Ama Intel tarafı Phi için dha çok ram gerektiğine ve bu şekilde hiyerarşik bi yaklaşımın katkısı olacağını düşünüyor. Ram gerektiği kesin , ama bu tarz hbm+ddr4 dram tarzı yapı çipi ne kadar karmaşıklaştırır ayrı mevzu. Çipin içinde bellek kontrol birimlerinin alışılmışın çok üstünde yer kaplıyor olması lazım bunun için.

    AMD Nvidia tarafında bu kadar büyütmeyi düşünecekler mi fikrim yok. NVidia taşıyıcı/mezzazin kart ile başlayabilir. Bu şekilde 16 GB'a sorunsuzca ulaşabilmeleri lazım. 16 GB çoğu durum için oyununda pro3d'ye kadar yeterli. 32 GB versiyon da çıkartacaklar diye bliyorum. Bugün karmaşık sahne yüzünden yüksek ram gerektiğinden CPU rendera mahkum oldukları için bu tarz kartlar acayip kurtarıcı olacak. Mimarinin de bu kadar yüksek BW'den düzgün yararlanacak şekilde yeniden dizayn edilmesi lazım. Bu da yapılması gereken işleri ve karmaşıklığı iyice arttırmış olacak.

    Genelde nod değişimlerinde yüksek ilelemeler görülmesi bu yüzden zaten.

    Yaa yine mi ? ................. Dedim yazıyı görünce. Ama dikkatlice okudum.

    Birşeyler anladım. Ancak Bw den bahsediyorsun biraz açarmısın bu kullandığın kısaltmayla ilgili dataylı bilgi bulamadım.




  • os_lnx kullanıcısına yanıt
    Bw yani bandwidth yani bellek bant genişliği. Çip ile bellek arasındaki iletişim kapasitesini belirtir. Hbm yapısı gereğiyle gpu ya yakın olmak zorunda. Nvidia ve AMD ikilisi bunu verimli kullanabilmek için nod değişimini yani 14-16 nm yi bekliyor. Hocamız kısaca bunu diyor.

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

    Orijinalden alıntı: Foxbat

    Bw yani bandwidth yani bellek bant genişliği. Çip ile bellek arasındaki iletişim kapasitesini belirtir. Hbm yapısı gereğiyle gpu ya yakın olmak zorunda. Nvidia ve AMD ikilisi bunu verimli kullanabilmek için nod değişimini yani 14-16 nm yi bekliyor. Hocamız kısaca bunu diyor.

    Şimdi taşlar yerine oturuyor. Çok teşekkür ederim.
  • http://wccftech.com/amd-patent-zen-apu-integrated-fpga-hbm2/
    Böyle bi haber gördümde çok anlayamadım mimari deteylar vsden,rubisco gibi biri açıklar belki.
  • quote:

    Orijinalden alıntı: Rubisco

    HBM tarzı yapının esas çipin yakınına takılması gerekiyor. Bunun için de şimdilik taşıyıcı yüzey ile yapılıyor (taşıyıcı yüzey= interposer). CPU-GPU veya başka olacaksa diğer çipler ile HBM çipi aynı ana taşıyıcı üstünde, aynı board üstüne yerleştirilip bağlantıları sağlanıyor. Yüksek frekanslı , yüksek bw içeren çip-çip arası bağlantı yapmak her zaman kolay değildir. Bu yüzden yakın olmak zorunda. Yakın olmak zorunda olduğu için aynı kart-pcb-taşıyıcı vs. üstüne bütün çipler konumlandırılmak zorunda. Bağlantı sayısı arttıkça bu yapıyı sürebileceğin frekans seviyesi göreceli de olsa düşmeye başlıyor (HBM'de de çok bağlantı var). Bi ekran kartı için bütün kartın pcb'sinde konumlandırılmıyor yani HBM çipleri. GPU'nun etrafında, ona yakın olacak şekilde, GPU'paketine yakın konumlandırılıyor.

    SAdece HBM 'yi bol bol kullanmayı herkes ister. Şimdilik bu pek mümkn değil. DRAM çipleri gibi, ekran kartında mesela, GPU çipinin belli meseaferlerde etrafını HBM ile döşüyemiyorsun. yukarda yazdığı gibi GPU ile aynı taşıyı kart üstünde, GPU'ya çok yakın olmak zorunda. AMD'Nin Furry kartlarında, GPU ve HBM çipleri farklı yerlerde üretiliyor, farklı tesislerde bir araya getiriliyor. Dolayısı ile o taşıyıcı kartın büyüklüğü ile, GPU ile HBM arasındaki bağlantıların sağlanabileceği genişlikte olmak zorunda. 16 GB ve üstünü AMD'nin ürettiği şekilde rahatça takamıyorsun. Bu yüzden ilk başta HBM+DRAM ile verimli bi altyapı ve yüksek bellek şeklinde düşünülmüştü(SAdece AMD değil Intel tarafından da). GPU'lar point-to-point bağlantılı çalışır. Yani her bi bellek kontrolcüsü bi bellek çipi grubuna bakar. CPU için anakarta taktığımız ramlar gibi kafamıza göre belirlenemez. CPU için 4GB için 2x2GB çip takabilrsin, 4x 1GB da takabilirsin. GPU için her bi kontrolcüye 1 çip takarsın. 128 bit demek 4x32 / 4 tane çip takabileceksin demek. Ekran kartı / GPU temelinden devam ediliyorsa, o zaman bellek altyapısını da HBM'ye göre veya HBM + DRAM yapısına uygun şekilde değiştirmek gerekir. AMD bunu Fury'de yapmadı, karşılığında da zararla oturdu kısmen.

    GPU için bellek çiplerini, kartın mimari temelini değiştirmeden olduğu gibi kullandığımızda bellek kontrolcüleri ile limitleniyoruzsak, o zman kullanabileceğimiz HBM çipi sayısı ve toplam bellek miktarı da bu şekilde belirlenmiş oluyor. AMD tarafı, mimaride değişiklik yapmadığı için 4 çip ile 4 GB şeklinde limitli şu an.

    Intel-Nvidia da aynı şekilde lmitliler. GDDR5'ler, point-to-point, noktadan noktaya bağlantı olduğundan, Intel isterse mini CPU temelli mimari gelştrimiş olsa, kartlar üstündeki dram çipleriyle eşleşecek şekilde kontrolcü yapıları gerekir. İşte bunları HBM ile değiştiremezler mi? DRAM çipleri kartların üstünde GPU'nun büyüklüğüne göre çok geniş bi alan kaplıyorlar. Oysa HBM, GPU çipine yakın olmak zorunda ve bu yüzden aynı taşıyıcıda bulunmak zorundaydı. Böylece GPU-Çipin çok yakınına konumlandırılabilrise ve GPU ile aynı taşıyıcı üstünde olmaz ise çok sayıda HBM çipinin mümkün olma ihtimali var. Oysa şimdilik bu tarz olasılıklar yok. 16 tane HBM çipi için bellek kontrolcü ve 16 çipi GPU ile sorunsuz bağlantı sağlayacak kadar yakın olma zorunluluğu var. Bu da işleri karıştırıyor. Bu yüzden Nvidia Pascal vs. için GPU'nun olduğu bloğu esas karta bi tür taşıyıcı kart ile bağlamayı düşünüyor(bu tarz taşıyıcı ile / ek olarak başka bi yapının üstüne takılan kartlara mezzanin kart faln gibi isimler veriliyor). INtel'in de o tarz farklı tasarımları var.

    önceden sadece HBM için tasarım yapılıyordu. Bunun getireceği zorluk ve başka sorunlar yüzünden, çip başına düşecek HBM sorun olduğundan, çipi bölümlendiriyorlar. Bu şekilde çip içinde farklı alanlar belirleniyor, her alanın kendisinin kontrol edeceği ulaşacağı bi ram alanı oluyor. Bu yaklaşımdan hareketle çip/çip içindeki bölümlerin direk olarak HBM için kısıtlaması azalıyor (detayını bilmiyorum, belki HBM için bu şekilde daha fazla bağımsız bağlantıya izin veriyordur, belki bağımsız kontrolcüsü vardır, belki fiziksel limit engeli olmuyordur). Bunun üstüne ilave dram bellek kontrolcüsü de ekleyeceklermiş. Böylece 16 gb HBM + 384 GB dram olacakmış. Bu, yukarda yazdığım engeller ile ters düşmüyor mu bilmiyorum. Ama Intel tarafı Phi için dha çok ram gerektiğine ve bu şekilde hiyerarşik bi yaklaşımın katkısı olacağını düşünüyor. Ram gerektiği kesin , ama bu tarz hbm+ddr4 dram tarzı yapı çipi ne kadar karmaşıklaştırır ayrı mevzu. Çipin içinde bellek kontrol birimlerinin alışılmışın çok üstünde yer kaplıyor olması lazım bunun için.

    AMD Nvidia tarafında bu kadar büyütmeyi düşünecekler mi fikrim yok. NVidia taşıyıcı/mezzazin kart ile başlayabilir. Bu şekilde 16 GB'a sorunsuzca ulaşabilmeleri lazım. 16 GB çoğu durum için oyununda pro3d'ye kadar yeterli. 32 GB versiyon da çıkartacaklar diye bliyorum. Bugün karmaşık sahne yüzünden yüksek ram gerektiğinden CPU rendera mahkum oldukları için bu tarz kartlar acayip kurtarıcı olacak. Mimarinin de bu kadar yüksek BW'den düzgün yararlanacak şekilde yeniden dizayn edilmesi lazım. Bu da yapılması gereken işleri ve karmaşıklığı iyice arttırmış olacak.

    Genelde nod değişimlerinde yüksek ilelemeler görülmesi bu yüzden zaten.

    Ek olarak bi soru daha sorayım.

    "Ekran kartı / GPU temelinden devam ediliyorsa, o zaman bellek altyapısını da HBM'ye göre veya HBM + DRAM yapısına uygun şekilde değiştirmek gerekir."

    Amd niçin bunu yapmadı diyorum. Kendi ayağına sıkmaya benzemiyormu. Bi bakıma öncüsü olduğun yaygınlaştıracağın teknolojide yada tasarımda diyelim her neyse, bunu yapmamanın nedeni nedir.

    Aceleci mi davrandı bir adım atmak için. Yoksa rakiplerin ne yapacağını mı görmek istedi ?




  • os_lnx kullanıcısına yanıt
    Rakip diyeceğin Nvidia var sadece. Intel ağırdan alır / alıyor. Pentium temelli CPU olduklarından, üstüne AVX eklentili SIMD üniteleri olduğundan, HBM tarzı yapıya göre esas işlem yapan altyapıyı / mimariyi değiştirmek çok çok çok daha zor. Şimdilik sadece bellek arabirimini değiştirecekler. CPU kompleksi bellek kontrol yapısını aynı şimdiki iCore mimarisindeki(SB ve sonrası) gibi ring bus ile ulaşıyor. Bu da genelde verimli bi yapı. En azından CPU içinde, çekirdek dışı yapıyı tanımlayan uncore denilen, çekirdekler arası ve diğer çip içi sistem birimlerini birbirine bağlayan yapı için ring bus anlamlı. SB için çekirdek >> L3 cache arasında toplamda 400GB'dan büyük bi BW taşıyabiliyor ringbus. Phi için bu çok daha geniş ve büyük. Normal şartlarda bi noktaya kadar sorun yok. Ama için içine HBM gibi çok büyük BW sunan yapı girdiğinde, sürekli Çip <<--->> HBM arasında veri transferi gerekecek. Masaüstü için 50GB bile ulaşamadığımızı dikkate alalım. Ekran kartlarında , bellek erişiminin %100 net mimari detaylarını bilmiyorum, yani ram çiplerine nasıl dağıttıklarını bilmiyorum (GDDR5 noktadan noktaya bağlantı olduğundan, mesela 512 bit kart için 8x tane 64bit kontrolcü gerekiyor. yazma istemi için komut gönderildiğinde, bu her bi shader grubunun kendine tahsis edilmiş L2'sine mi yazıyor ve o kısma karşılık gelen bellek kontrolcülerine ve bellek çiplerine mi yazılıyor, yoksa bi yazma kuyruğuna eklenip bütün bellek çiplerine mi dağıtıyor gibi tam detaylarını bilmiyorum). Ama Phi gibi bi yapıda olsa bile, ring bus'ın BW'si ile karşılaştırılabilecek seviyede HBM'nin sağladığı BW var. Bu da çipin HBM ile iletişim sırasında sürekli %100 BW kullanımı olamayabileceği anlamına geliyor olabilir. Yada ring bus'ı devasa boyutlarda BW'ye sahip olacak şekilde tasarlıyor olabilirler. AMD'de olan ilk durum, Intel'in yapmak için uğraştığı da ikincisi olabilir.

    AMD, esas altyapısında değişiklik yapmamış. HBM bi nevi şimdiki GDDR5'lerin yerini almış. Bunun için bellek kontrolcülerinde ne kadarlık farklılık gerekti (yada gerekti mi) vs. detayları belli değil. HBM'ler için tam net latency testi faln yapan da görmedim daha. Bi yerde BW testi yapıp, 390x ile aralarındaki farkın %20 az olduğunu gösteriyordu (gerçekte %33 civarı BW farkı olması lazım. Fury 512GB, 390x 384GB ). ROP hariç herşeyi artınca sanki yetersiz kalmış gibi kabul ediyoruz. HBM'nin, artacak olan ROP'ların getireceği ilave yükleri kaldıramayacağını veya mimarinin buna uymadığını düşünmüş olmalılar. Daha çok ROP rasgele eklenemiyor ve her bi shader Engine 1-16 arası CU, max 4 ROP grubu olacak şekilde organize ediliyor. O zaman Fury'de daha çok ROP olabilmesi için ya Shader ENgine yapısının değişmesi, 1 tane daha fazla Shader Engine içermesi gerekecekti. Fazladan 1 Shader Engine demek +16 ROP demek olacaktı ama +16 CU da demek olacaktı. Yani 4 değil 5 shader engine olacaktı. O zman ilave Geometri / raterizer altyapısı vs. de demek olcaktı. Toplamda 4096 değil 4160 shader, 80 ROP gibi olacaktı. AMD'nin tam CU --> L2 --> Bellek kontrolcü altyapısını bilmiyorum(yukarda bahsettiğim her shader engine'in L2'de kendi payı-kısmı, bunların da aktarıldığı kendi bellk kontrolcüsü olabilir, veya yazma istemleri bi sıraya kuyruğa eklenip bütün bellek çiplerine yazılıyor olabilir). Şu an 290 >> 390x'e kadar olan Hawaii temelindeki 8 bellek kontrolcü yapısını 4 HBM çipine eşleştirmişler. Daha çok Rop için 5. Shader Engine eklenseydi, belki bi uyuşmazlık çıkma ihtimali olabilir. Hani çipin büyümesi vs. dışında, bellek erişim altyapısı yüzünden 8 bellek kontrolcü -->> 4 HBM çipi şeklinde erişim kurulmuş olabilir. Eğer bu varsayım doğru ise, bellek erişimi üstüne yazdığım 2 olasılıktan 1.si doğru olmuş olacak (her Shader Engine'in kendine tahsis edilen L2 alanına veriyi yazması, bellek kontrolcülerin de burdaki veriyi kendi çiplerine yazması. Yani bütün yazma işlemlerinin bi tür global kuyruğa eklenmesi ve bütün çiplere aynı anda yazılması değil. Yani 1. Shader Engine 'den gelen okuma-yazma talepleri mesela 1. ve 2. bellek kontrolcüsüne iletiliyor gibi. Genelde GPU'nun tamamı kabaca aynı anda aynı işin biçok kopyasını çalıştırdığından, 1. Shader Engine ile 4.Shader Engine aynı kodu / okuma yazma talebini işler. Bu sayede de bütün bellek erişimi aynı esas işin okuma yazması gibi olur. Temelde GPU'lar hep bu mantıkla çalışır. 1.Shader Engine'de 1.CU ayrı telden, 2. ayrı telden, 2. Shader Engine'deki Cu'lar farklı işlerle faln uğraşmaz. Nvidia için de bu böyledir ).

    Bunlardan ne sonuç çıkıyor, AMD Shader ENgine altyapısını değiştirmek istememiş, sadece teorik limiti olan 16 CU'ya kadar genişletip bırakmış (1-16CU arası olabiliyor Shader Engine). O zaman da ROP tarafından lmiitleniyorsa(Hawaii'deki 2816 shader + 64ROP'a karşın 4096 shader +64ROP), Shader Engine yapısını değiştirmediklerinden ilave ROP eklenememiş. Belki çipin büyümesi belki ilave tasarım gerekmesi v.s yüzünden 5. Shader Engine de eklenmemiş. Böylece ROP açısından limitleniyorsa kesin olrak arge'den kısıp bırakmış oluyorlar.

    Eğer 5. Shader Engine eklenebilseydi, bu sefer de bellek kontrolcü ile bağlantı sorunu olacakdıysa, bellek erişim altyapısında daha fazla değişim olması gerekecekti, bi nevi asimetrik erişim gerekebilirdi, yada 970'dekine benzer sorun olabilirdi: 5 tane Shader Engine 'i 8 tane bellek kontrolcüyle eşleştirmek gerekecekti. Bunun için, yukarıda varsaydığımız 1 ShaderEngine --> 2 Bellek kontrolcü gibi bi yaklaşım varsa, uymayacaktı. Belki 5GB lık olabilseydi olurdu o zman. Belki o zman da 5. HBM çipinin konumu açısından sorun çıkacaktı. bunlar da arge isteyen sorunlar.

    Alakasız, Nvidia da her bi GPC bir bellek kontrolcü ile ilişkili. Bu yüzden çipi büyütürken, 980 için mesela 4 GPC 4 bellek kontrolcü, sonrasında 5 GPC 5 bellek kontrolcü gibi gidebiliyorlar. Ama 970'deki soruna da yol açıyor bu.

    AMD HBM'yi Hawaii'ye uydurup biraz genişletip rekabetçi bişey çıkartmak istemiş olmalı. Çok az yeniden dizayn var gibi (yani yüksek seviyeli bakınca, yoksa silikon tarafından bakıncan güç yönetimi vs. bi sürü şeyler de var). Yani buna ayağına sıkmış der miyiz bilemiyorum. Argeden kısıp idare etmeye çalışmışlar, hep yaptıkları gibi. Intel de daha büyük ring bus ile idare etmeye çalışacak onun gibi. Ama, mimari tasarımı bu büyük BW'den yararlanacak şekilde değiştirmeyen zararını görecek gibi. Çünkü Çip <<<--->> Bellek çipleri arasında veri transferleri esasında en çok enerji tüketiminin olduğu yerdi. 800 tane shaderın yapacağı hesap sırasında harcanan enerji ile, elde edilen sonucu Dram'a yazmak kabaca benzer seviyelerde enerji tüketir mesela. Bunu, HBM ile sürekli yüksek miktarda BW kullanımı şeklinde ele alırsak, esasında baya artacak bi güç tüketimi sorunu demek bu.

    AMD'Nin bu konunun esası olan sunumda bahsettiği gibi HBM için olan transferler güç bütçetsinin büyük bi kısmını kapsıyor olacak. Bu yüzden hesaplama sisteminde vs. de değişikliklere gidilmesi gerekiyor.

    Nvidia Maxwell'de HBM tarzı bi yapı kullanmayı hem düşünmüyordu, hemde tam yapamazdı diye biliyorum. Yani AMD'nin kim ne yapacak diye bakınmasını gerektirecek bi durum yok esasında. Pascal ile mimari dizayn olarak bu yüksek BW 'li belleklere uygun yapı hazırlıyorlar. Bu yüzden yeni HBM tarzı yapı kullanacak mimarisinde perf çıtasını çok çok yükseğe taşıyacaklar.

    Xeon Phi'ler, accelerator olarak HPC pazarın %30 küsürlük kısmındalar. Yani AMD'yi çoktan geçmiş konumda. AMD'Nin Intel'in Phi için ne yaptığını direk taktığını zannetmiyorum.

    AMD de sonraki nesilde HBM yapısına uygun mimari dizayn yapabilirse idare eder gibi geliyor. Yoksa Nvidia'nın yeni dizaynı ağır gelecek baya.




  • redoracle R kullanıcısına yanıt
    ÖNce FPGA temelinden daha önce yazdığım şeylerdeki gibi yazacaktım. FPGA'lara spesifik görev verip belli işi hızlandırmaya çalışmak faln gibi amaçları olabilir. Intel'in FPGA-CPU hibridi amaçları var vs. Yerine göre CPU/GPU'da belli işi donanım komutlarıyla yaptırma yerine (sonuçta ne yaparsan yap bi yapının senin yaptırmak istediğin işi işletmesi çalıştırması gerekiyor, senin yapmak istedğin iş bi altyapının üstünde çalışması gerekiyor). FPGA ile sadece işin belli bi kısmını esas donanıma vermeden, o altyapı üstünde çalıştırmadan çalışacak şekilde belki geliştirmeler yapılabilir. Ms'nin Catapult sistemi, bing arama sonuçlarını ve tüketilen enerjiyi baya azaltıyor. Bunun için CPU 'nun bütün işletim sistemi içinde çalıştırdığı altyapıdaki bi program değil, FPGA üstnde sadece algo'nun belli kısımları çalışıyor vs. vs.

    Bu linkte ve SS'de AMD HBM tarzı yapılara çok daha önceden lanse ettiği 3rd PArty IP olayı ile custom dizayn yapmak peşinde olabilir. APU+FPGA+HBM'den oluşan değişik bi yapı mesela.

    Öbür taraftan patent detaylarına bakamdım, ama HBM kompleksinde gösterdiği reconfigurable logic fabric diye gösterdiği şey HBM'nin kontrolcüsü ile de alakalı olabilir, PIM denilen bi yapı ile de alakalı olabilir (PIM = processing in memory, bellekde işlem yapmak , bellek içinde işlem gerçekleştirmek). PIM yeni bi kavram yaklaşım değil (FPGA'lar gibi). Hatta Micron'nun PIM temelinde diyebileceğimiz işlemcisi faln bile var (Micron Automata http://www.micron.com/about/innovations/automata-processing http://www.micronautomata.com/ ).

    Önceki msjım'da da , bu konuya kaynak olan haberlerde de AMD'nin HBM tarzı yapılarda oluşacak olan çok fazla transferin güç tüketiminin önemli bi kısmını oluşturacağından bahsettildi ya. Sonra da PIM tarzı yapıların ön plana çıkabileceğinden faln bahsetti. bu ss'in bi kısmı da belki o tarz bi yapı ile alakalıdır. Sen bellekteki iki dizinin birbiri ile mantıksal karşılaştırmlara / işlemlere tabi tutulmasını istiyorsun mesela (1. diziyi 2. dizi ile or and xor vs. etmek istiyorsun mesela). Bu tarz bi lojik ara yapı ile, verinin CPU-GPU içine taşınmadan bellek dışına çıkartılmadan bazı işlemlerin yapılabilmesi, bazı modifiye işlemlerinin yapılabilmesi amaçlanıyor olabilir.

    Yok sadece FPGA ile alakalı ise, PIM ile alakalı değilse, ordaki logic fabric denen yapı sadece HBM'Nin kendi kontrol yapısını tasvir ediyorsa sadece en başta yazdığım FPGA ile alakalı kısım geçerli demek olacak.




  • Rubisco kullanıcısına yanıt
    Elinize sağlık hocam şimdi anlam kazandı biraz,demekki cpu-gpu gücünden bile faydalanmadan bazı şeyler yaptırılabilecek veya fpga+gpu+cpu 3ü birden hsa gibi birlikte çalışabilecekler anladığım kadarıyla,eğer intelde aynı komut setlerini kullanacaksa hem baltalanmaz bu sefer belki(bazı amd komut setlerinin yazılımcılar tarafından kullanılmadığı için hiç olması).
  • redoracle R kullanıcısına yanıt
    FPGA ve GPU tarafının Intel ile alakası yok, o yüzden hiç sanmam. Ama HSA temelinden uyumlu bi geliştirme FPGA veya bu tarz hibrit yapılara nasıl uyarlanabilir bilmiyorum. Amaç kodlama-optimize etme açısından öyle HSA için. Yine de bi taraftan zaten pro / bilimadamı veya işi gücü bu olanlar bunları kullanmak ister, bu yüzden de herşeyini öğrenmek zorunda, bu yüzden HSA tarzı bi yapıya gerek yok diyebiliyoruz. Öbür taraftan da bilgisayarcılar bi bilimadamının yazdığı koda pok atıyor, bi bilimadamı da bilgisayarcının yazdığı kod için ya arkadaş bu ne yazmış nası çıkacaz içinden diyorlar.

    Ortalama kanaat olarak bakarsan temeli bilgisayar olmayan birinin yazdığı kodu debug etmek genelde daha kolaydır diye kabul edilir. Bi fizikçiyi faln ele al, genelde açıklama-comment vs daha düzgün olur, daha düzgün yazarlar. Bi bilgisayarcı gelip fizikçinin koduna baktığında da, debug edip yanlışı düzeltmek istediğinde daha az problem yaşar. Genelde böyle olur veya deneyim ile buna benzer inanç gelişmişliği var işte.

    İş böyle karışık olunca, esasında HSA yolu gayet mantıklı gibi. Özellikle de işin içine farklı yapılar bir arada olduğu durumda.

    200 milyon $'lık süperbilgisayarı kullanacaklrın elbette eşşek gibi çalışmaları gerekiyor. Ama daha geniş kitleler hedef alındığında, HSA yolundan daha çok fayda görülebilir gibi.

    yani fpga cpu gpu aynı komut setini kullanmayacak. Ama, HSA yardımı ile yapılacak işin bunlara dağıtımı vs. daha kolay ayarlanabilir gibi.

    Önemli olan bugsız ve verimili yapı olması. Bi noktadan sonra yönelenler çıkar.

    Xeon Phi'ye neden o kadar kısa zmanda ve çok talep oluştu? Çünkü x86 CPU bazlı olan kodun Phi'ye aktarımı görece kolay. Yepyeni bi dil öğrenmek zorunda değilsin, veya bi dilin içine sokulmuş donanıma özel tonla başka kavram yapı öğrenmek zorunda değilsin. Kısmen, hiçbişey yapmadan Intel'in kendi yazılımlarıyla CPU'dan Phi'ye port edebiliyorsun ve CPU'ya göre gayet iyi sonuç veriyor(Intel Parallel Studio XE ile ). Bunlar illa süper paraleleştrilebilen algolar faln olduğundan dolayı değil, CPU'nun daha iyi becerdiği işleri de CPU'ya göre mesela 10x'e kadar hızlandırabildiği için. CPU'da yer yer çokca seri-ardışık kod varken bunu GPU'ya aktardığında duvara toslar. Oturup o ardışık çalışan kod kısımlarını o GPU'da verimli çalışması için yeniden dizayn etmek gerek. Oysa Phi için CPU kodunu aktarırken bile görece kabul edilecek miktarda hızlanma sağlanıyor (2x Xeon 8 çekirdekli sisteme göre mesela). İyice uğraşmadan bile idare edecek yapısı olması, Intel'in de desteği ile Phi'nin çabuk kabul görmesini sağladı.

    AMD+CL tarafında, salt güç lazım olan durumlar için kesinlikle ama kesinlike rakipsiz. Ama öğrenme süreci, AMD'nin bazen CL driverında insanların buldukları bi bug'ı aylarca düzeltmemesi gibi sorunların olduğu da oldu. Intel Nvidia gibi tam gaz herkese her şart altında destek peşine düşmediği de oldu geçmişte. Çok tekrarladığım gibi CL 'in esas miladı AMD'Nin GCN'i çıkarttığı zamandır. O zmandan bu zamana yeterli gelişmeyi de kullanıcıların Cuda varken tercih etmemesinden geçmek öğrenmek istememesinden tut AMD'nin tonla hazır kütüphane vs. sunmaması da oldu.

    AMD, BLAS ve FFT kütüphanelerini faln açtı 2013'de. Tamamını herşeyiyle diye biliyorum. Çok önemli bişey bu aşırı önemli hemde. Bi noktadan sonra yüksek perfli ve açık kaynaklı bu tarz optimize kütüphaneler bulmazsın. Bu zaman içinde AMD kullanımı bi miktar arttı ama feci seviyelerde değil.

    Phi örneğindeki gibi, AMD'Nin mesela bi x86 cpu kodunu GCN donanımında çalışacak CL çeviricisi gibi bişey sunması lazım diyecez, ki öyle bişey dünya üzerinde yok, imkansız yani. Phi için, normal Xeon işlemci de PHi de x86 temeline kurulular. Bu yüzden aktarması görece kolay. x86 CPU kodunu GCN için CL'e aktarmak ise deveye hendek atlatmak gibi bişey.

    CL diğer taraftan CPU üstünde de verimli şekilde çalıştırılabiliyor. E o zman CPU için de CL temelinden yazsalardı? Dünya öyle yürümüyor işte. Böylece tamamen CPU üstüne kurulu bi yapıyı otomatik şekilde CL'e aktarıp, GCN GPU'sunda verimli oalcak şekilde çalıştıramıyorsun.

    Bütün bunları birleştirince işte HSA temeli, işe yarar gibi. Buna benzer hibrit yapılar düzgün geliştirilebilirse, HSA da yeterince ilerler ise faydalı olur.

    Elit elit takılıp ya ne gerek var şu şurdan bu burdan kodluyoz işte diyenler var. GEliştirme zamanının mesela %60'ından fazlasını platform üstünde optimizasyona harcayıp bu lafları edenler, işte bütün geliştricilerin kendileri gibi herşeyi dibine kadar bilmesi gerektiğini sananlar var (Intel mühendisi diye illaki laf çakmak amacıyla söylemiyorlar yani. Zamanında Mantle'a laf çakıp Apple Metal'a iimiş diyip, GL herşeye yteeeer MAntle ıyyyk diyip, sonra Vulkan sana canım feda moduna girenler bunlar).

    Hepsini birleştirdiğinde, bu tarz 3lü yapıyı kodlamanın zorluğu neresinin ne yapacağına göre değişir. İşin CPU-GPU tarafında zaman alacak kısmını FPGA'da yaptırıp, bi taraftan %50 geliştirme zamanı elde edebilrisin. Öbür taraftan FPGA'daki kısmı geliştirmek için gereken zaman çok çok uzayabilir, veya FPGA'ya verimli şekilde uyduramayablirsin (5!'i FPGA'da hesaplatıp heeyy tamam bu iş diyen MS'nin akıllı elemanları gibi yada ). Bi taraftan verdiğini bi taraftan kaybedeceksek yokuz biz işte dedirtmemeleri lazım kullanıcısına.

    HSA için o tarz FPGA-DSP gibi yapılara çabuk verimli çıktı verecek altyapıların da kurulması lazım. Nasıl nereye kadar olur bilmiyorum, ama uğraşıyorlar.




  • Rubisco kullanıcısına yanıt
    Güzel yazmışınız gene hocam sağolun,iş yazılımda,kütüphanelerde,kodlarda bitiyor gene yani,Amdnin iyi bir yazılımlarla iyi bir yerlere gelmesi mümkün ama daha çok yolu var anlaşılan.
    Amdyi microsoft alıcak diye haberler vardı,alsa bu kütüphaneleri,kodları,yazılımları çıkarmak için uğraşırmıydı acaba,yoksa intelle al gülüm ver gülüm piyasayı idaremi ederledi beraber merak etmedim değil şimdi,yada samsung gibi bi teknoloji devi alsaydı bu yazılımlara,kodlara vs destek verirlermiydi,çünkü çok basit şeyler değil bu işler kaynak akıtmak gerekli oldukça?
  • izlek onemli bir kelime.
    • 
Sayfa: önceki 12345
Sayfaya Git
Git
sonraki
- x
Bildirim
mesajınız kopyalandı (ctrl+v) yapıştırmak istediğiniz yere yapıştırabilirsiniz.
Hizmet kalitesi için çerezleri kullanabiliriz, DH'yi kullanırken depoladığımız çerezlerle ilgili veri politikamıza gözatın.
Kabul Ediyorum