Teknoloji Haberleri
Aşağı Git
Tüm Forumlar
Donanım / Hardware
Dahili Bileşenler
Ekran kartı
DirectX 12 ile SLI/CF de Birleşik Vram kullanımı Onaylandı !
Bu konudaki kullanıcılar: 1 misafir, 1 mobil kullanıcı
85
Cevap 3875
Tıklama 10
Öne Çıkarma
Cevap 3875
Tıklama 10
Öne Çıkarma
-
Cevap: DirectX 12 ile SLI/CF de Birleşik Vram kullanımı Onaylandı ! (3. sayfa)
| 290x CF.. 2k..8gb VRAM...kartların kullanım süresi birkaç yıl daha uzadı o zaman |
Bu mesaja 1 cevap geldi.
| AMD sponsorlu bir kullanıcı, 5870x4 ile Metro'da bile bu tarz ayrık ekran kartı kullanımı olduğunu söylüyordu. 1GB kartlarıyla beklenmeyecek akıcılıkta çalışıyormuş Metro oyunu, sorduğunda 32x32 piksellik damalı bayrak gibi ekranın farklı bölgelerinin ekran kartlarına ayrıştırıldığı yanıtını almış. SFR gibi birşey her halde bahsettiği. |
< Bu mesaj bu kişi tarafından değiştirildi Mete Can Karahasan -- 3 Şubat 2015; 21:02:31 >
Bu mesaja 1 cevap geldi.
|
GL 5.0'ın daha öncekilerin aksine geniş bi kitle tarafından geliştrildiğini, bunda donanım-yazılım firmalarına, geliştricilere, oyun programcılarına kadar yayılan bi sürü farklı yerden insanın da dahil edildiğini unutmayın. Bu programcıların hepsi şimdiki API'lerin multi-GPU'lar için yetersiz olduğunu, temellerinin buna müsade etmediğini, nasıl sorunlar çıkardığını, driver üstünden özel ayar verilmesi gerektiğini vs. vs. hepsini bilen insanlar (oyunculardan önce onlar şikayet ediyorlar). Bunun da unutulmaması lazım yani. Dx Ms'ye daha bağımlı(dışardan destek de alınıyor yer yer). GL 5.0 da eğer bu sefer gerçekten becerebilirlerse, çok çok uzun zamandan beri ilk defa temiz-stabil-çok sağlam bi temel kurulmuş olunacak. Oyunların çoğu Dx'den GL'e mi yönelecek demek için gelecek çok muğlak, çok çok vakit var daha. Ama ilk defa en çok şikayet edenlerin de dahil edildiğini düşünürsek uzun vadede de herşeyin yolunda gittiğini varsayarsak, bu sefer Dx'i çok fena zorlayabilir. Diğer API diyince akla direk Dx geliyor olsa da, GL 5.0 / Next'i de unutmamak lazım. Direk konuyla ilgili, Mantle ile yapılabileceklerin bi kısmı bu, 2 kartın ramlarının da kullanılabilmesi olayı yani. Bunun dahası da var. 2 kartın asimetrik yapıda olabilmesi (290x + 280x), bunların ramlarının farklı olabilmesi (4gb + 3 gb), kartlara-GPU'lara farklı görevler verilebilmesi (1. kart ana render yapısını işlerken 2. kartın sadece ikincil ışık/yansımalarını işlemesi, hibrid-RayTrace gibi). Dx'e her şart altında bunun gelmesi kolay değil. Mantle için geliştricinin sorumluluğunda çnkü bunlar. Bunları, en azından kaynı kartlar için SFR benzeri bi alytyapıya oturtmaları lazım. Bunun zaman alacağı da ortada. Eğer bunun altından çok daha erken kalkabilselerdi, veya nasıl yapabileceklerini nereye kadar üstünden geçeceklerini herşeyin detayına hakim olabilselerdi XB1'i zaten +350mm2 kocaman bi çip gibi değil de mesela 7790 Crossfire gibi bi yapı şeklinde çok daha makul şartlarda üretebilirlerdi. |
Bu mesaja 2 cevap geldi.
Asimetrik CF/SLI inanılmaz olabilir  DX anti-cheat namına da faydadan çok zarar sağlıyor. API'lara biraz da anti-cheat measure koysalar çok güzel olabilir. |
< Bu mesaj bu kişi tarafından değiştirildi Brightmist -- 4 Şubat 2015; 2:02:54 >
Bu mesaja 1 cevap geldi.
Konunun başlığı halen neden Mantle değil diye tekrar sormadan edemeyeceğim. Baktıkça bir tuhaf geliyor. Sonuçta yanlış, anlamı bozuk, içerikten uzak. |
rubisco bey size pm den yurt dışı ile ilgili soru sormuştum cevap verme tenezzülü bile göstermediniz halbuki ben sizin burada her yazınızı takip ediyorum içerledim doğrusu pm den cevap atmadığınız için buradan yazmak zorunda kaldım |
Bu mesaja 1 cevap geldi.
| İster Mantle ister DX 12 olsun, böyle birşeyin mümkün olacağına inanmıyorum, çünkü her GPU sahip olduğu bellek kapasitesini kullanır. |
Bu mesaja 2 cevap geldi.
Çoklu kart düzeneklerinde mümkün olacağını ben de sanmıyorum(aradaki bağlantının genişliği-gecikmesi problem çıkarabilir. Belki bazı gelişmeler sağlanır, ama anlık ram ihtiyacını o bağlantıdan karşılayabilir mi?). Ancak, en azından yeni çıkacak çift GPU kartlarda değişiklik olabilir. 1-2 ufak düzenlemeyle, 2 GPU PCB'deki tüm bellekleri kullanabilir. SLI-CF'nin şu anki mantığı gereği, aynı veriler her GPU'nun belleğine yazılıyor. Dx12/Mantle'ın getireceği değişiklikleri göreceğiz. |
< Bu mesaj bu kişi tarafından değiştirildi False King -- 4 Şubat 2015; 12:18:51 >
Bu mesaja 1 cevap geldi.
| Zaten benim de dediğim çoklu kart kullanımı için, çift GPU'lu kartda bile API veya yazılım ile bu mümkün olamaz ancak donanımsal olarak yapılabilecek birşey, iki GPU ortak belleğe sahip olabilir ama söz gelimi ayrı olarak 4+4 yerine 2 katı 8 gb olması lazım. |
< Bu mesaj bu kişi tarafından değiştirildi Cpt. Miller -- 4 Şubat 2015; 8:19:45 >
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @false shepherd
| Fiziksel anlamda 2 GPU da kendine atanmış olan belleği yönetirken, mantıken ortak bellek havuzu kullanımı gibi bir sistemin olamayacağını üstte zaten açıkladım ve sözümün de arkasındayım, bunun nasıl mümkün olacağını sen açıklayabilirsen seviniriz. |
< Bu mesaj bu kişi tarafından değiştirildi Cpt. Miller -- 4 Şubat 2015; 12:12:40 >
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @Rubisco
|
Sen yazılımsın, senin açından tek bi tane 8 GB varmış ve tamamını doldurmaya çalışıyormuş olman ile , yapılacak işi tile eden altyapın olması durumunda, her tile kendi alanında çalışıyor (kendi 4 GB'lık alanında) olması durumunda, böylece bütün kaynakların AFR'deki gibi bütün GPU'lara aynı verilerin kopyalanması zorunluluğunun olmadığı bi ortamla ne farkı kalıyor? Bence tek başına tek kartın, 1. kart + 2. kartın ramını adresleyip, aradaki bus üstünden ulaşıp, o tek kartın toplam ram gibi iki kartın ramını adresleyip kullanması şeklinde düşünüp bunun olmayacağını varsayıyor olabilirsin (başka türllü düşünüyorsan yazarsın zaten, bu yazdığım şekilde bakıp olmaz diyenler de var). Öbür taraftan alakasız olarak, iki kartın birbirlerinin RAM alanlarına CPU tarafına uğramadan ulaşabilmeleri zaten mümkün. Nvidia da GPUDirect'in amacı bu tarz gecikmeleri engellemek. AMD SDI Link de bunu sağlıyor. Madem mümkün de niye render için tek kartı 12GB şeklinde kullanamıyorum da illaki sahneyi kırpmam gerekiyor dimi? Çünkü ikisi farklı şeyler + yazılım tarafı en yukarıda yazdığım şeyleri yapmaktan yoksun. Yok artık koca Nvidia bunu yapamamış, farklı kartı geç çift GPU'lu kartlarda bile bunu yapamıyor senin dediğin nasıl olacak? mı? Kartın diğer kartın bellek alanına ulaşabilmesi ile, yazılımın bunu tek bi sanal belleğin(virtual mem) içinde görmesi farklı şeyler. Programın, ya arabirim ile bütün bu altyapının x86 adress alanında görebilmesi, ulaşabilmesi vs. lazım, yada API üstünden bu tarz erişime sahip olması lazım. Programın tek başına görmesi Nvidia tarafında mümkün değil. AMD tarfında uzun zamandan beri x86 adressleme modu ile uyumlu. Ama program çıplak halde API ve programlama ile desteklenmeden yine yapamaz. Nvidia tarafında Cuda-driver altyapısı bunu sanal olarak yapıp (yani Nvidia GPU 1-1 x86 adresleme alanının uzantısı olmamasına rağmen bi tür çevirme - yeniden adresleme yaparak), programın GPU'yu kullanmasını sağlıyor. Ama bu, benim istediğim iki kartın ram alanlarının da kullanılamamasına cevap değil ki diyebilirsin. Cevap değil ama kısmen cevabını içeriyor. Çünkü hem Nvidia'nın arabirimi henüz programa al kardeş sana 4+4gb ama ben sana bunu 8 gb olarak gösteriyorum diyemiyor, hem de programın bunu kafasına göre sanki tek bi 8gb mış gibi kullandığı zaman oluşabilecek perf düşüşünden haberi yok. Yani programın da bunu tek bi 8 gb gibi değil, 4+4gb olduğundan haberdar olup, (olmayacak iş ama) farklı bellek alanları arasında yüksek miktarda veri transferi / diğer bellek alanında erişmesi gecikmeye yol açacak bi şekilde sık sık ihtiyacı olmaması gerek (1. kartta çalışan thread'in 2. kartın ramındaki veriye sık sık erişmemesi gerek). Cuda'nın unified memory olayı mesela cpu tarafında çalışan kodun gpu 'yu da ortak görmesini sağlıyor ama AMD'den farklı olarak bunu fiziksel olarak aynı alanda olduğundan değil, Cuda'nın yaptığı çevrim ile yapıyor. Cuda'ya bu tarz unified olayı gelmeden önce elle yapılıyordu. Cuda'nın unified olayı hala düşük perf veriyor(testleri var bakınabilirsin). O zman Programın Cuda-unified üstünden 2 kartın ramlarını tek bi ortak ram olarak görüp kfasına göre işlem yapması pek doğru bi mantık değil. O zman programın ve API'nin bu durumdan haberdar olup, bu tarz özel duruma göre de algo lara sahip olması gerek. E tamam onu bende düşünebilirim, benim itirazım, 1. kartın aynı kart üstünde 4gb ram'a hızlı + 2. kartın üstündeki 4gb rama yavaş da olsa erişip, toplam 8 GB şeklinde olması mantıklı gelmiyor diyip, senin dediğin şeyi yaparlar dememek lazım. 1. kartın her iki karta erişip ikisinin de ramını kullanabilmesi, sırf demo açısından düşünürsen yapılabilir. Bunu API üstünden dolaştırıp, thread'e farklı ram'da olduğunu saklayarak yapabilirsin. Ama API, veriyi her iki karta da yazarken ortaya çıkacak perf sorunlarıyla başedebilecek şekilde davranmalı. Bu perf düşüşü getireceğinden (yukarda o yüzden sırf demo yapılabilir dedim), o zaman her iki karta yazılacak veriler arasında ya hiyerarşi olmalı (yani 1. kart hızlı ram alanı - 2. kart yavaş ram alanı gibi), yada threadler, threadlerin dağılımı-dağıtımı (ve dolayısı ile programın kendisi) bu tarz farklı kullanımdan haberdar olup buna uygun şekilde de kendini konfigüre edebilmeli. Render yazılımlarında - Nvidia'nın altyapısında bu daha yok. Olmadığı için aynı makinaya 4 tane kart takıp 24 GB RAM varmış gibi, veya network-renderer üstünden 16 x 4 64 GB RAM varmış gibi sahneler üstünde çalışamıyorsun. Bunu, programın bütün kartlara tek bi ram varmış gibi değil, tile edebildiği (edebileceği ) ve bu şekilde thread dağıtımının yapılacağı zaman görebilecez. Gelecekte ne zman nasıl olur bilmem. Görevlerin tile edilip dağıtıldığı zaman altyapı, mesela programın başlatacağı 1000 gpu threadinin ilk 300'ü kesinlikle ve kesinlikle verilerin 1. karta yazılacağının ve bunlar için gerekli verinin başka karta taşınmayacağının, dolayısı ile görevin kartın kapasitesine göre bölünüp perf düşüşünün min. seviyede olacağıının garantisini verebilir. Aynısı oyuna da yansıtılabilir. Mete'nin bahsettiği şey, mesela SFR'imsi durumda 4 kart'ın %200 perf artışı verdiğini, ama frametimeların çok düşük kalabildiğini, bu yüzden akıcılık algısının iyi seviyede olduğu şey yani, bu tarz yaklaşım ile alakalı (ama yazılm tarafından ayarlanmış hali). Yani sen bana tek kartın, iki karta erişip tek bi 8gb ram varmış gibi davranmasını söylemiyorsun, programın görevleri 2 karta dağıtmasından bahsediyorsun, bunu tek başına söylesene dersen bişey diyemem (ben de tek başına o şekilde yazmanın eksiklik olduğunu düşünüyorum). Ama eğer 1. karttaki gpu threadinin ikinci kartın ramına sıkca erişeceği duruma göre, en baştan uygun şekilde tile edilebilirse, aralarındaki perf farkı çok fazla olmalı. |
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @scutaro
Birinci kartın ikinci kartın belleğine erişim yaptığını düşünsek bile inanılmaz derecede yavaş olacaktır, büyük bir darboğaz meydana getirecektir, gerçek hayatta getiri sağlayamadıktan sonra boş haberdir benim için, bu teknoloji patladığında kötü dalga geçeceğim o eksi verenlerle.  |
< Bu mesaj bu kişi tarafından değiştirildi Cpt. Miller -- 4 Şubat 2015; 14:30:33 >
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @Rubisco
|
< Resime gitmek için tıklayın > Böyle düşün o zman. Uygulama ve API, uygun şekilde tile ederse, threadlerin farklı ram alanına ulaşma ihtiyacı olmadan işlemesine imkan verebilir. Her bi tile kendi bellek alanına sabitlenir. < Resime gitmek için tıklayın > Bugün yapılamıyor mu bu? Yada bugünün 6-7 gpu ile GPGPU render bu şekilde yapılmıyor mu? Bu bahsettiğim şekilde yapılamıyor. Hem API hem program bu tarz erişime uygun değil tam olarak çünkü. Çünkü bütün altyapı seni 4 GB ile sınırlıyor, çünkü çift yönlü olarak bütün yükü tile edip parçaya ayıramıyor. Viewport performansın 100 fps olmasına gerek yok ama yapılabilir bi yere kadar bu. 1. kartta çalışan thread'in 2. kartın ramına sık sık erişip işlem yapması temelinden gidersen olmaz. parantez içinde olmayacak iş diye ondan bahsettim. ama uygulama ve API'yi, thread dağıtımını, threadleri mümkün olduğunca tek kartta tutacak şekilde ayarlamaya çalışman mümkün. Mümkün olduğunda iki kart arasında senkronizasyon yapmamaya çalışman mümkün. Bugün bunu nasıl yaparsın? Parçacık efekti için sık sık ram'a çıkıp yüksek BW istemesini engelleyerek yapabilirsin. Naparsın mesela, ekranı tile edersin, her tile'ı bi ROP'a atarsın. Her tile yeterince küçük ayarlandığında ROP cache içinde kalıp, her işlem için ram'a çıkma ihtiyacın olmaz. Böylece, mesela her pixel için 32 byte yazacaksan, sonra tekrar okuyacaksan(64 byte transfer yapacaksan yani), bunun yerine 1 kere 20 byte yazıp, gerisini ROP cache'den okuyabilir olacaksın mesela (64 byte vs. 20 byte, transfer karşılaştırması). Ama bunu yapmak için de Compute Shader'a ihtiyacın var. Compute shader ile ekranı tile edip / parçalara ayırıp, her bi parçanın bi ROP ile ilişkilindirlmesini sağlaman gerekiyor. Her geliştrici de bu tarz işlere yanaşmıyor. |
Bu mesajda bahsedilenler: @scutaro
windowsun çalışabilmesi x86 lisansı ana sahibi intele böyle bir yamuk yapamaz intel ile microsoft arasında bir bağ var kanıtlanamasada.. dx12 windows10 lansmanında microsoftun kozu olcak.. ayrı gpular plx yongası ile birleştirilirken çok düşükte olsa ms gecikmesi var 2ayrı gpuyu tek pcbde aynı vramde birleştiremediler.... hep gpular bu yonga ile birleşirken vramler ortak değildi... bu güne kadarki çift gpu mantığı boşaydı ozaman sli yada crossda nasıl ayrı kartların ramini birleştircekler çok ilginç yeni bir rönesans olur mimaride  yazılımsal değil donanımsal olmalı |
Bu mesajda bahsedilenler: @false shepherd , @scutaro
| SLİ CF isi ne zamanki işlemciler gibi tek GPU da 2 ve fazlası cekirdek olur o zaman çözülür her açıdan daha mantıklı çünkü fazladan kart satalım insanlara diye onu geliştirmek yerine SLİ CF gibi sistemleri yaptılar çokta istedikleri gibi olmadı |
< Bu ileti mobil sürüm kullanılarak atıldı >
Heryerde trolluk yapmak zorundamisin.Basimizda zaten bjkmurat vakasi var onun yerinemi gecmek istiyorsun. |
< Bu ileti mobil sürüm kullanılarak atıldı > Bu mesaja 2 cevap geldi.
|
Yorumlara bakınca sanki herkeste 4K monitör var , 2gb lık kartlarla CF yapmışlar da yetmemiş havası aldım. Konuda bahsedilenler mümkün olursa tabi güzel gelişme de bu 2gb kartla CF yapanların işine yaramaz pek, güçlü monitörü olan güçlü kart kullanır zaten. Benim için yeni serilerde amd mantle geliştirip birde oc kabiliyetini arttırırsa, kullanıcıda güzel etki bırakır. |
Bu mesaja 2 cevap geldi.
|
Çoğu kişi başından beri olayın nasıl işlediğini veya ne denmek isteidğini yanlış anlıyor çünkü. https://twitter.com/Thracks/status/561708827662245888 Bu adamın kendi yazdığı şey. Numa Nodların nasıl çalıştığına bakın , + elinizdeki 2 Nvidia kart ile P2P'nin nasıl yapıldığını nasıl getirisi olduğunu ne durumlarda faydalı olduğuna bakın, sonra bi sürü şey kafanızda oturması lazım. Benim orda burda karaladığım şeylerle de birleştirirsiniz en olmadı. |
980 zaten , 780 Ti den her yönden üstün bir kart değil, dolayısıyla kolay bir şekilde geçilmesinde şaşırılacak bir durum yok, testlere bakarsanız özellikle heaven bench lerde düz 780 bile geçebiliyor 980 i, üstelik her iki kartda da oc varken.
Bu mesaja 1 cevap geldi. Cevapları Gizle