Şimdi Ara

Yeni Nesil Grafikler | PC vs PS vs XBOX vs SWITCH (33. sayfa)

Daha Fazla
Bu Konudaki Kullanıcılar: Daha Az
1 Misafir - 1 Masaüstü
5 sn
2.920
Cevap
39
Favori
140.630
Tıklama
Daha Fazla
İstatistik
  • Konu İstatistikleri Yükleniyor
7 oy
Öne Çıkar
Sayfa: önceki 3132333435
Sayfaya Git
Git
sonraki
Giriş
Mesaj
  • GPU compute bu kadar önemli bir şey mi hocam? Yani yapımcılar GPU Compute'yi aktif olarak kullanmaya başladıktan sonra grafiklerde ve yapay zekada büyük sıçramalar görebilecek miyiz sence?
  • quote:

    Orijinalden alıntı: GoldPunch

    GPU compute bu kadar önemli bir şey mi hocam? Yani yapımcılar GPU Compute'yi aktif olarak kullanmaya başladıktan sonra grafiklerde ve yapay zekada büyük sıçramalar görebilecek miyiz sence?

    Yapay zeka çok çok karmaşık bişey değil, onun için çok güzel geliştirme kitleri faln var. Sen ne seviyede yapay zekadan bahsettiğini söyle ben ne zmandan sonra işlem gücü sorun olmaya başlar bildiklerimden hareketle bahsedeyim. Önceki bazı oyunlarda olduğu gibi adamın etrafından dolaşıp nanik yapıosun sana tepki göstermio gibi şeyler zaten tasarım hatası. Uygun tetik mekanizması çalışmıyor demek onlarda. 3 5 adam / mob vs. için her türlü gelişmiş AI kurarsın zaten. Binlerce npc/mob/düşman için AI kurmak istersen ve hepsinin birbirleriyle de çapraz etkileşmesini faln istersen, o zman sistemin canını okuyabilir. Kütle çekim için N-Body denilen hesaplamalar var, parçacıkların birbirleri üstüne olan etkileşimi birbirleirne uyguladıkları kuvvetlere göre hareket vs. hesaplanıyor. Çok çok fazla sayıda birim, AI üstünden birbirleri ile de etkileşebilecekleri şekilde bi sistem kurarsan (10 tanesi bell bi mesafeye geldiğinde Voltranı oluşturacak veya birleşip devasa bi boss gibi mob oluşturacak veya çok güçlü bi spell cast edecek vs.), o zman AI için de baya bi işlem gücü gerekebilir diyebilirz belki. O zaman kadar ama bi dünya birimi kontrol etmek sistemi de yorabilir. İş o tür durumlarda GPU Compute'a kayar. PC'deki mmo oyunları çok çok iyi kodlayamamaları faln gibi. ekranda 1000 lerce adam mob npc olsun istiyorsun ama oyuna göre 20 tane oldu mu bile fps 20 lere çöküyor. Daha fazla CPU gücü gerekiyor vs. Mantle ile bu tarz durumları doğru düzgün render etme imkanı ve çok fazla birimi kontrol etme imkanı olacak PC'de. Konsolda da aynısı var. Yeni konsollardaki işlemci çekirdekleri başlı başına normal bağımsız çalışabilen çekirdke olduklarından kendi başlarına bellek erişimleri vs. olduğundan daha önce görülmemiş ölçekte mmo'lara imkan vermeli konsollarda.

    Konsolların render altyapısı PC'de Mantle'dan daha fazlasına izin verdiğinden, Mantle'dan hareketle baya baya bi imkan olduğunu anlıyoruz (bu tarz detaylara erişme imkanı pek olmamaıştı daha önce). Ama şu tarz durumlar var: PC'de mesela bu tarz mmo geliştirmek isteyenler Mantle gibi bi arabirim ile sorunsuz bunu yapabilecekler, ama burda GPGPU'dan faydalanmak gibi bi mecburiyet yok (PC'de Dx altyapısınındaki yeterli olmayan bazı şeyler üstünden iş yapmaya kalkınca sorun oluyor. Mantle'ın amacı bunu aşmak. PC'de Dx üstünden 10 fps de sürüncek mmo Mantle ile 30-40-50 fps rahatça çalışabilmeli. Konsolda ise benzer tarzda mmo'ları işlemek için rahat rahat imkan var. Bi dx bi Mantle gibi düşünmesine gerek yok yapımcının ).

    Konsolda da, esnek programlanabilir bi GPU ile neler yapabileceklerini öğrenmeleri bana zaman alır gibime geliyor, işin orasında da sıkıntı var. Ryse'dan adamları eşşek gibi çalıştırdıklarını biliyoruz. Killzone'dan herşeyin CPU üstünde yapıldığını biliyoruz. Grafik için render için, kolay kolay kimsenin kısa zaman için donanıma yakın kodlama yapmayacağına da inanıyoruz. Donanıma yakın kodlama yapmak için AMD_IL'yi kullanmaları gerekiyor. Konsoldaki GPU driver/compiler zaten AMD_IL bi kod çıktısı veriyor olabilir. En azından onun üstünde ilave optimizasyon yapabilir miyiz diyecek kadar kurcalamayı düşüneceklerdir. Konsolda hala direk donanım komutlarına erişim imkanları var mı onu da bilmiyoruz (donanım komutları = ISA Assembly). Donanım komutlarına erişim imkanı varsa, daha da sonra GPU'yu çözdükçe onları da kullanıp 3 5 (veya daha fazla) ilave perf çıkartmak veya yenilikler çıkartmak isteyeceklerdir. Ama GPU'yu donanım komutu seviyesinde öğrenmek zaman alıcı iş. PS3'e göre çok daha kolay, sabit platform olduğu için her iki konsolda da çalışacağı için dert değil, ama zor iş yine de. Bilen içn x86'da asm kodlamak gibi. Bilir öğrenirsen belli işleri çatr çatr yaparsın. Compiler optimizasyon yapar, hızlı çalışan bi çıktı verir sana C ile bişey yazdığında. Sonra sen asm. ile elle optimize kod yazıp, compiler'ı yenmek istersin. Basit 20-30 satırlık bi kod için 2-3 gün zaman harcarsın, 2.5 kat fark atabilen bi kod yazabilirsin. x86 asm. yazmak ile GCN GPU'su için asm. yazmak farklı şeyler onu biliyorum, direk programın oyunun tamamı için öle 3-5 kat fark yaratack şeyler çıkmaz. Ama render'ın belli kısmında 1 saatte yazıp 100 birim perf veren bi kısmını , 30 saat uğraşıp 150 birime çıkartabilirsin. Elde ettiğin ilave performans da başka yerde kullanabilirsin. donanım komutları kullanmanın avantajı orda, eski konsollarda başka çareleri olmadığı için mecburen bunu yapıyorlardı. Nvidia'nın kendi dili yerine yer yer donanım komutlarıyla gidiyorlardı donanım aslında kısıtlı diye.

    İşin bu kısmını bu kadar uzatmamın nedeni, sabit platform için donanım komutlarına kadar inip düşük seviyede geliştirme yapmak çok önemli çünkü.

    İşin GPGPU kısmı da başka ayak, o da o kadar karışık ve zor. Nedeni şu, yıllarca herşey çiplerin belli fillrate'leri üstünden kısıtlı kaldı hep. Bunun üstüne donanım geliştricileri 1 adım öteye gitmek için daha hızlı donanım dolayısı ile daha yüksek fillrate sunudular. Sonra oyunlar daha çok fps verdi, bnun üstüne yine zorladılar daha çok fillrate ihtiyacı çıktı, yine sürünüldü. Bu sefer donanım geliştricileri yine avantaj sağlamak için 1 adım öteye gitmek için 1 adım daha hızlı fillrate için yeni donanım çıkartılar. Bu sidik yarışının yıllarca sürmesinin sonucudur bugun gördüğümüz şeyler. Shader ağırlıklı performans ihtiyacı olan yok mu, shader performansı tarafından limitlenen veya daha önemli olduğu oyunlar yok mu var. Ama hem daha az ağırlıkta, hemde shaderda ne iş yaptıkları önemli. 2d (2 boyutlu) alev efektini 5-7 pass ile yapmaya çalışırsa Metro gibi PC'lerin canını yakan oyunlar çıkar(pass = üst üste bi sürü katmanın texture'ın bindirilip hepsinin ayrı ayrı render edilmesi). Yadar Crysis3 de 3D rain yapacam diye kasarlar dünyanın kaynağını yiyen oyun çıkar mesela ortaya. Bunlara bi de Dx'in getirdiği yazılım yükü eklenince dediğim sidik yarışı kısır döngüden çıkılamaz.

    GPGPU'yu işin içine nasıl dahil edeceksin? Eski konsollarda yok böyle bi imkan zaten. PS3'de Cell üstünden yapıldığı kadar, o da GPU'nun yükünü aldıktan sonra kalanlar ile(diğer şeyleri çıkarttıktan sonra bi de). PC'de, oyunlarda GPGPU'yu kullanma imkanı Dx11 ile geldi DirectCompute ile. Dx11 çıkalı ne kadar oldu? Hangi kartlar destekliyordu çıktığında? Eski tas eski hamam yürüyen oyunlarla , eski bi ton kart varken mi Dx11 ile DirectCompute üstünden bişeyleri zorunlu kılacak oyunlar çıkacak idi? AMD de 5xxx 6xxx geldi, Nvidia da 4xx 5xx vs. faln geldi sonra noldu mesela ne değişti? Hiç. aynı tas aynı hamam herşey.

    Bugun PC'de Dx üstünden GPGPU çok kısıtlı kullanım alanına sahip. Bunun üstüne bi de Dx'in yükü biniyor. Adamlar esasında fillrate limitini hafifletmek için kullanıyorlar GPGPU'yu. BF3 4 'de mesela gölgelemenin hesaplanmasında kullanılıyor. Civilization'da texture decompression için faln kullanılıyor. Başka oyun gereksiz ışık kaynaklarını elemek için kullanıyor. Yapabiliosan gel sen yap demesi kolay, ama işin kendisi kolay değil. Forward+ denen yöntemler var, öbürünün 10 birim işlemle yaptığı sonucu bu mesela 3-5 birim işlemle yapıyor. Ama Dx11 istiyor zorunlu kılıyor. O da senin pazar payını kısıtlıyor bi nebze. Her kartta aynı şekilde çalışmıyor, Nvidia kartlarda su koyuveriyor Kepler kartlarda. Yeni yeni GPGPU'yu daha fazla kullanalım olayına girmeye çalışıyorlar PC'de ama o da kolay değil, Dx bu sefer engel. Çünkü GPGPU için CPU ile iletişim kurması gerekiyor sistemin, belli bufferları constantları yüklemesi gerekiyor karşılığında bi feedback alması gerekiyor şu işi yaptım faln diye. Sen oturuyosun burdan GPGPU ile 10 birim beklenti içine giriyorsun ama Dx ilave yük bindiriyor, sana 2 birim ilave performans anca verdirtiyor. Allah bereket versin napalm kader kurbanıyız diyorsun. DirectCompute üstünden asla ama asla yapamayacağın da tonla tonla şey var. Hem DirectCompute'un kendisinden kaynaklanan, hem Dx'in izin vermemesinden kaynaklanan. Aynı anda aynı "render target" denen zımbırtıyı Dx ile bi texture'a render edip hem de DirectCompute ile bunun üstünde modifiye yapamazsın mesela.PC'de buna imkan veren API olsa (Mantle bu tarz şeylere imkan veriyor), Metro örneğinde verdiğim 7 pass işleme işini başka şekilde yaparsın. Konsol sana bu tarz şeyleri Mantle'dan biraz daha öte bi şekilde veriyor avantajı o.

    Sonuç ne burda? Dx11 ile GPGPU geldi oyunlarda kullanmak için, kimse yüzüne bakmadı uzun süre, sonra bundan bize ekmek çıkar dediler eski usül işlerde performans arttırıcı olarak kullanalım dediler, ama Dx yüzünden bedeli oldu etkisi az oldu (yada Dx'in bedeli yükü var, eski usül iş için kullanak dahasına kasmayak dediler). Bi dünya oyun içinde GPGPU'nun yeri hala çok değil. Eskiye uyumluk dendi kullanılmadı, nasıl ypacam bilmiom dendi kullanılmadı, belli işi zor yapması dendi kullanılmadı, şu iş için kullanıyım dendi gerisi eksik kaldı, Dx ayakbağı oldu yük oldu bunu kullanırsam en kötü durumda performansım düşer dediler kullanmadılar. Eski konsollarda zaten böyle bi imkan yok. Eee ? Yeni konsollar için o yüzden daha önce hiç kullanılmamış bi alan. Ellerinde bi nevi al bununla herşeyi yapabilirsin denilebien bi ortam var kodlama altyapısı olarak. Bi süre afallıyorlar.

    PC'de sadece MAntle üstünden, Konsolda kendilğinden mesela bi render edilen texture üstünde modifiye edici hesaplama yapıp sonucu tekrar texture olarak başka bi şeyde kullanma imkanı var ve bunu hızlı bi şekilde yapma imkanı var. Bi yandan render ederken diğer yandan aynı shader'ın yan iş olarak fizik hesaplaması yapıp parçacık efekti yapması gibi imknlar var. Tonla şeye imkan var yazıp durmayım yine tonla şey. UE4 elemental demosu PC'de Nvidia kart üstünden GPU Fizik hızlandırması ile işlerken Konsolda CPU fizik üstünden işliyor. O haliyle bakarsan PS4 iyi iş çıkartmış gibi olr demoda. UE4 ama konsolda GPU fizik olayına giremez o ayrı. İş orda geliştiriciye kalıyor. UE4 motorunu kullanır render için, aama fizik için GPU'da da çalışabilecek bi yapıyı kendi geliştirir. Anca o zman iyi iş yaparlar. Yada Capcom'un Panta Rhei motoru gibi (Deep Down) iyi bi alev görseli / fluid simulation için sistemi daha iyi kullanan şeyler yaparlar.

    Bi sürü şey açısından özgür olduğun donanımda GPGPU ile çok iş yapılır, konsollar ve Mantle bu kategoride. Ama özgün düşünmen gerekiyor, bişeyleri daha esnek yapman gerekiyor. Daha önce böyle imkan PC'de de olmadı konsollarda da olmadı. Yapılabilecekler sınırsız diye kulağa bayağı gelen şeyler yazmıyım ama çok fazla şeye imkan tanır.

    Ha bi de, PS3 için faln denilen "daha konsolu öğrenemediler öğrensinler çok iş yapacaklar" diye söylenen, doğrularla beraber yanlışları içeren cümle yeni konsollar için tam olarak doğru değil. PS3 Cell açısından zordu, RSX/GPU açısından da eksikti. Öğrendiler bi ton şey, ama GPU'nun açıklarını kapamak için kullandılar. Şimdi ise, daha önce hiç olmayan bi alanda yürümeleri gerekiyor, onu öğrenmeleri gerek. Biraz daha GPU'yu kullanmayı öğrensinler baya bi ekmek çıkar hem donanıma yakın kodlamadan hemde özgün kodlama / GPGPU ile. PC'de bunun Mantle dışında karşılığı yok, o yüzden GPGPU PC'de daha az etkili yukarda kısmen bi sürü şeyden bahsettim Dx'in getiridği engellerden DirectCompute yüzünden vs. diye. İş bu sefer, konsolda / Mantle'da 100 komut ile yaptığın işi Dx/DirectCompute üstünden en az 1000 komutla yapmak zorunda olunca, performans düşünce, bu sefer Dx/DirectCompute ile olan GPGPU performansını arttırmak için yine sidik yarışına döner belki ilerde orasını bilemem.




  • quote:

    Orijinalden alıntı: Rubisco

    quote:

    Orijinalden alıntı: GoldPunch

    GPU compute bu kadar önemli bir şey mi hocam? Yani yapımcılar GPU Compute'yi aktif olarak kullanmaya başladıktan sonra grafiklerde ve yapay zekada büyük sıçramalar görebilecek miyiz sence?


    Ha bi de, PS3 için faln denilen "daha konsolu öğrenemediler öğrensinler çok iş yapacaklar" diye söylenen, doğrularla beraber yanlışları içeren cümle yeni konsollar için tam olarak doğru değil. PS3 Cell açısından zordu, RSX/GPU açısından da eksikti. Öğrendiler bi ton şey, ama GPU'nun açıklarını kapamak için kullandılar. Şimdi ise, daha önce hiç olmayan bi alanda yürümeleri gerekiyor, onu öğrenmeleri gerek. Biraz daha GPU'yu kullanmayı öğrensinler baya bi ekmek çıkar hem donanıma yakın kodlamadan hemde özgün kodlama / GPGPU ile. PC'de bunun Mantle dışında karşılığı yok, o yüzden GPGPU PC'de daha az etkili yukarda kısmen bi sürü şeyden bahsettim Dx'in getiridği engellerden DirectCompute yüzünden vs. diye. İş bu sefer, konsolda / Mantle'da 100 komut ile yaptığın işi Dx/DirectCompute üstünden en az 1000 komutla yapmak zorunda olunca, performans düşünce, bu sefer Dx/DirectCompute ile olan GPGPU performansını arttırmak için yine sidik yarışına döner belki ilerde orasını bilemem.

    Hocam anladığım kadarı ile PS4 gelecek açısından çok fazla şey vaad ediyor fakat bunun için yapımcıların uzun bir zamana ihtiyacı var. Ayrıca Compute alanında uzmanlaşmaları gerekiyor. PC tarafında Mantle haricinde başka bir karşılığı olmadığı için oyun yapımcıları Compute'ye yabancı. Fakat Sony'nin X86 kullanıyoruz diye, oyun programlamak daha kolay diye övündüğü şey Compute'siz oyun geliştirmek mi? Çünkü dediğinize bakılırsa PS4'ün çıkış oyunlarında GPU Compute ile uzaktan yakından alakası yok. Sony'de bu GPU Compute'nin PS4 için gelecek vaadettiğinin farkında olmalı ki oyun stüdyolarına gerekli yardımı sağlasın.

    Umarım AMD ve Sony mühendisleri özellikle Naugthy Dog gibi Sony'nin gözbebeği stüdyolarına iyi eğitim verirler. Çünkü insan ister istemez yeni Killzone'dan, gelecek olan Uncharted'dan çok daha iyi grafikler bekliyor. PS3'de bile öyle veya böyle çok iyi görsel şölen sunmuşlardı.




  • Rubisco bey,

    hocam bilgili olduğunuz açık ama çok uzun yazıyorsunuz valla sayfaya bakınca psikolojik olarak çöküyorum bu arada xbox vs ps olayını anlıyorum da bu konsolları niye pc ile karşılaştırırlar anlamam. elma ile armuttan farkı yok.
  • quote:

    Orijinalden alıntı: Rubisco


    Çok alakası var mı bilmiyorum ama, texture-mapping-unit ve render-output-unit denilen parçalar kullanılırken onlar da işlerini çekirdeklere mi yaptırıyor yoksa kendi iş-hatları var da onlar mı yapıyor? Eğer hepsi de aynı çekirdekleri kullanıyorsa(mesela hd7970in 2048 adet) o zaman her bir çekirdeğin aynı anda hem toplama hem de çarpma işhatları dolsun diye mi render+fizik aynı anda yapılmaya çalışılıyor?

    Eğer tmu ve rop çekirdekleri apayrı şeylerse bunları da kullanarak ne kadar daha gflop olayının suyunu çıkarabiliriz? Kabaca %10 daha çıkar mı? Mesela benim pitcairn 1280 çekirdek * 1GHz * (1 toplama + 1çarpma)= 2560Gflop/s ama tmu ve rop da kullanayım olsun 3Gflop/s.



    < Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 17 Kasım 2013; 23:41:08 >
  • Orijinalden alıntı: GoldPunch



    Ha bi de, PS3 için faln denilen "daha konsolu öğrenemediler öğrensinler çok iş yapacaklar" diye söylenen, doğrularla beraber yanlışları içeren cümle yeni konsollar için tam olarak doğru değil. PS3 Cell açısından zordu, RSX/GPU açısından da eksikti. Öğrendiler bi ton şey, ama GPU'nun açıklarını kapamak için kullandılar. Şimdi ise, daha önce hiç olmayan bi alanda yürümeleri gerekiyor, onu öğrenmeleri gerek. Biraz daha GPU'yu kullanmayı öğrensinler baya bi ekmek çıkar hem donanıma yakın kodlamadan hemde özgün kodlama / GPGPU ile. PC'de bunun Mantle dışında karşılığı yok, o yüzden GPGPU PC'de daha az etkili yukarda kısmen bi sürü şeyden bahsettim Dx'in getiridği engellerden DirectCompute yüzünden vs. diye. İş bu sefer, konsolda / Mantle'da 100 komut ile yaptığın işi Dx/DirectCompute üstünden en az 1000 komutla yapmak zorunda olunca, performans düşünce, bu sefer Dx/DirectCompute ile olan GPGPU performansını arttırmak için yine sidik yarışına döner belki ilerde orasını bilemem.

    Hocam anladığım kadarı ile PS4 gelecek açısından çok fazla şey vaad ediyor fakat bunun için yapımcıların uzun bir zamana ihtiyacı var. Ayrıca Compute alanında uzmanlaşmaları gerekiyor. PC tarafında Mantle haricinde başka bir karşılığı olmadığı için oyun yapımcıları Compute'ye yabancı. Fakat Sony'nin X86 kullanıyoruz diye, oyun programlamak daha kolay diye övündüğü şey Compute'siz oyun geliştirmek mi? Çünkü dediğinize bakılırsa PS4'ün çıkış oyunlarında GPU Compute ile uzaktan yakından alakası yok. Sony'de bu GPU Compute'nin PS4 için gelecek vaadettiğinin farkında olmalı ki oyun stüdyolarına gerekli yardımı sağlasın.

    Umarım AMD ve Sony mühendisleri özellikle Naugthy Dog gibi Sony'nin gözbebeği stüdyolarına iyi eğitim verirler. Çünkü insan ister istemez yeni Killzone'dan, gelecek olan Uncharted'dan çok daha iyi grafikler bekliyor. PS3'de bile öyle veya böyle çok iyi görsel şölen sunmuşlardı.



    Evt, x86 üstünden bahsettikleri genel kodlama yapısı için, oyunun ana hatları için, onun daha kolay olduğundan bahsediyorlar. x86'da da işleri yapmak Cell'e göre veya PPC temelli xbox'a göre daha kolay. Belli vektör işlemleri vs. için x86 üstünden hem daha programlanabilir, hem daha geniş bi kaynak / kütüphanelere erişim imkanı var, hemde en yeni kullanıcının CPU üstünde yapacağı işlemler için ister yüksek seviyeli ister düşük seviyeli her tür iş için başvurabileceği mutlaka bi yer var.

    Bu bi nevi geçiş süreci boyunca işler CPU'nın sırtında olacağından, kaynağa ulaşma açısından da sıkıntı çekmeyecekleri için problem-sorn yok.

    Sorun GPU kısmında, onun getirdiği kodlama / progrmama esnekliğinde ve Sony'nin bunu sonuna kadar kullanmalarını istemesinde. Ne yazıkki o alan da herşey için AMD'ye muhtaçlar destek anlamında, mimariye göre optimize edebilmek içn. Düşük seviyeli işler için de başvurulabilir kaynak çok hızlı azalıyor. Bunun bi yüksek seviyeli kodlama ile mimariye uygun / optimize edilmiş bi genel hatları var, bi de en azından belli işlemler için düşük seviyeli kodlama olayı var.

    Oyun içinde DirectCompute dışında GPGPU kimsenin şimdiye kadar olmadığı bi alan. OpenCL ile oyun içerisinde o kadar rahat kullanmaya çalışma, Dx ile inter-operability rahatlığı yok (Tr'çesi ne bilmiyorum / beraber çalışma / aynı tür formatlı verilerle alışveriş vs.). Dx<<-->> DirectCompute için bu inter-operability imkanı var, ama önceden dediğim gibi Dx altında GPGPU'nun çok bi yaygınlığı da yok. Oyunlarda GPGPU bi nevi bakir bi alan, DirectCompute dışında OpenGL altında GPGPU için GLSL ile veya GL Compute Shader ile oyun hemen hemen hiç yok.

    Konsolda oyun yapımcıları bu yüzden yanlızlar, ama mimariye özel kodlayabilecekleri için de bi o kadar şanslılar. Bununla ilgili küçük örnekler vs. ler faln var. ilgilenen varsa GCN GPU'su üstünde Sebbi'nin faln çalışmalarına baksınlar. Mimariye özel kodlayınca, aynı işi bodoslama yapmaya göre nasıl 2-2.5 kat fark yarattığını bazı işler için anlatıyor.

    Ama dediğin gibi GPGPU'nun ne Sony'nin dedikleri ile nede çıkış oyunları ile alakası yok. GPGPU ile mesela farklı bi texture compression motoru yazacak adamlar, Killzone'daki 3GB VRAM kullanımı 1:2 oranında ilave sıkıştırılabilecek ve bu sayede sanki 8.5-9GB RAM varmış gibi kullanabilecekler. Veya biraz abartılı sallıyorum yine, Linux'deki Compcache/Z-Ram gibi bişey yapacaklar Ram üstünde swap kullanacaklar, texture sıkıştırması + diğer veriler için sıkıştırma ile birlikte sanki 12GB ram varmış gibi olacak, vs. vs.

    GPGPU ile yapılabilecekler senin ne kadar uğraşacağına faln bağlı. Seni rezil de eder anca bu kadar mı yapabldin dedirtir, vezir de eder vay anasını dedirtir. Sparse Voxel olayını yukardaki örnekle birleştirdiler diyelim, 12 GB genişletilmiş ram gibi bişeymiz olduğunu varsay, iş görecek kadar yeni şeyler yapılabilir mesela. PC için kimse bu tür bi örnekle çıkıp, ""bizim oyun en az 3GB Vram istiyor, en az 6-7 GB Ram istiyor" gibi min. bi sistem greksinimi isteyemez, satamaz o oyunu çünkü.

    Başlarda, PC'deki kullanımına benzer şekilde kullanacaklardır. Zaman içerisinde daha özgün işlere yelken açarlar diye umut ediyoruz. PS4 için boşuna 8 ACE istenmedi yani az buçuk yetenekli bi GPU var compute için CPU-GPU arasında limit olmaması adına.

    @Tugrul_512bit ikisi içinde kendi özel birimleri var, shaderların / stream processorların / cuda coreların ne isimse artık ana hesap üniteleri dışında ayrıca tmu için ve rop için birimler var. Ama fixed function ünite onlar. Belli bi amaç için özel olarak programlanabilir değiller yada üst seviyeli bi kodlama dilinden direk GPGPU için kullanılabilir değiller. Blend için veya farklı texture modları faln için kapasiteleri işlem güçleri fark ediyor o. Daha alt seviyeli kodlama ile ve yapılarına uygun şekilde istekde bulunarak belki senin isteğin doğrultsnda amaç dışı kullanılabilirler bilmiyorum. AMD için ama en azından AMD_IL ile veya direk ISA üstünden ulaşmaya çalışıp sonuçlar ile ne yapabilirsin bakman lazım.




  • @Rubisco

    Eline sağlık.


    Eskiden isteyince yazılım modunda görüntü alınabiliyordu, o zamanlar TMU+ROP gibi şeyler kullanılmıyor muydu yoksa sadece ışıklandırma ve matris çarpımı mı yazılım tarafından yapılıyordu? 3dfx için miydi hatırlamıyorum. Sonradan donanım hızlandırması çıkınca işlemciye gerek kalmamıştı ama son yıllarda işlemci hızına bağımlı olmuş sanki herşey.
  • Her zaman oldugu gibi olay potansiyeli ortaya cikartacak yazilimcida bitiyor.

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

    Orijinalden alıntı: Tugrul_512bit

    @Rubisco

    Eline sağlık.


    Eskiden isteyince yazılım modunda görüntü alınabiliyordu, o zamanlar TMU+ROP gibi şeyler kullanılmıyor muydu yoksa sadece ışıklandırma ve matris çarpımı mı yazılım tarafından yapılıyordu? 3dfx için miydi hatırlamıyorum. Sonradan donanım hızlandırması çıkınca işlemciye gerek kalmamıştı ama son yıllarda işlemci hızına bağımlı olmuş sanki herşey.


    Fixed function hw. hep vardı. Software rendererlar faln vardı senin dediğin. Orda senin bahsettiğin işlemler GPU'da değil de CPU üstünde yapılıyordu. Quake'de mesela sw. renderer ile GL renderer arasındaki görüntü kalitesi farkı (bilmeyen için sw mod nasıl oluyor diyehttp://www.youtube.com/watch?v=jnj2xalncDY ). CPU üstünde yeterli performans elde etmek için doğal olarak çok fazla aproximiation yapmak gerekiyor, görüntünün böyle olmasına yol açanda o zaten. Bununla alakası olmasa da tam Linux Mesa'da software render imkanı var. i7 ile 10-30 fps faln gbi bazı oyunları oynatabiliyor :// (eski bi kart ile 150 fps alıyor ama). Eski için Donanım hızlandırması dediğimiz şey, pixel shader vertex shader faln gibi şeylerin esasında. Şimdi ise GPGPU. Eski donanımda API sana belli şeyleri yapmana izin vermez. Glide'da donanıma özel çok şey olduğu için o zmanın kartlarına göre hem hızlı hem esnek idi. Ama burnu havada kendini beğenmiş ve işine kimseyi karıştırmayan tiplerdi aynı zmanda "Glide Guys". O yüzden hiç gelişemedi, evrimleşemedi, milletin dünya kadar isteğini önerisini değerlendirmediler hep sırt çevirdiler hiç kulak asmadılar. Sonuçta donanım da sorun olmaya başladı maddi sorunlar da çıktı.

    Mantle ise tam tersine, herkesin Dx'den yaka silktiği, herkesin ya Allahım bize bişeye fırsat ver de az esnek olalım dedikleri bi noktada ortaya çıkardılar. Tamam AMD kökenli, yine proprietary bi API ama yıllar içinde konsollardaki esnekliği vermiş oluyor. Aklı başında bi konsol geliştiricisi ile konuşun, hala Dx11 de yapamayıp eski konsollarda yapabildiğiniz bi ton şeyi detaylıca öğrendiğinizde, ""vay anasını adamlar Mantle sayesinde resmen PC'yi konsol gibi yapmış olacak"" dersiniz. Konsolda bide ilave olark direk donanım komutlarını kullanıyorlar en azından eski konsollarda, PC'de GCN için resmi olarak bu mümkün değil Mantle üstünden bile olsa. Mantle'ın temeli AMD_IL üstüne olduğundan sanırım en düşük AMD_IL ile kod yazılabilir. Ama gayri resmi olarak da direk GCN komutlarını kullanma imkanı da var, compiler / driver bunu donanıma geçirebiliyorsa pass edebiliyorsa extradan fazla şeye imkn veriyor demek. PC için kimse Mantle üstünden GCN donanım komutlarını kullanmaz gibi geliyo bana, yada anca zorlanınca bazı rutinleri "GPU asm. optimized" yazarlar, ama normal C++ üstünden işlenecek şeylerde bile "inline assembly" olarak kullanılsa bile yer yer katkısı olr. Çok tekrarladım, hiçbi API'de mesela GCN'deki skalar uniteyi de çarpma amacı ile kullanma imkanı yok. Skalar ünitenin amacı normalde Vliw'i işe yaramaz hale getiren flow control / branch gibi komutlarda kullanılmak, vektör ünitelerini bunlar için meşgul etmemek. Çarpma işlemini %3-5 civarı hızlandırabilirsin mesela scalar ünite + vektör üniteleri interleaved kullanarak. Başka işler için, AMD_IL ile direk GCN ISA arasında ne kadar perf farkı olabiliyor bilmiyorum ama mutlaka etkisi vardr.

    Bunn konuyla ilgili kısmı, render için shader bazında yada daha doğrusu vektör ünitelerinde yapılacak işlemler için direk donanım bazında kontrol imkanı tanıması ve komutların compile edilmeden driver tarafından düzenlenmeden direk çalışmaya izin vermesi(illa shader için değil, texture işlemlerinden tut cache ile ilglii işlere kadar). Alakasız kısmı, zaman istemesi , Mantle'ın yeteneklerinden sonra bu kadarı yeterli denip low-levela inmeye gerek duymayacakları (GCN kartlar çok yaygın değil diye toplamda bütün GPUlar içinde).




  • @Rubisco

    İyice alakasız hale getiriyorum ama

    Acaba voltaj yetmediğinde gpu stabilitesini bozan şey aslında ROP ve TMU olabilir mi? Mesela valley, heaven, 3dmark için 1225mV veriyorum 1200MHz sınır. Clbenchmark programındaysa 1200mV veriyorum 1300MHz çalışıyor. Clbenchmark testleri çok kısa olduğu için yeterince zorlamıyor da ondan mı kitlenmiyor yoksa çekirdeklerin istedikleri voltajlar ile TMU/ROP bölümlerinin istediğinden daha mı az?

    Gerçek zamanlı opencl render yapan programlar var, bu programlar gene TMU kullanıyor mu yoksa herşey çekirdekler tarafından mı hallediliyor(paralelleştirilmiş sw mod gibi?)? Sadece çekirdek kullanılabilen bir yöntem varsa oyun motoru yapmak çok zor mudur? Mesela şöyle bir kalitede:http://www.youtube.com/watch?v=1SFUYFxBESk

    Not: rigid gems 2.0 ı indirdim, DX imiş. 50-60 fps alıyorum. Gayet güzel bir görüntü ama cpu darboğazı mevcut.



    < Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 18 Kasım 2013; 13:57:09 >




  • Tugrul_512bit kullanıcısına yanıt
    Cl de esas yük shader üstündedir. Rom/TMU vs. kullanılmaz. Kodun şekline göre bellek arabirimi de ağır yük altında olabilr, kodun GPU diline çevrilme şekline göre (GPU dilinde çalıştırılan donanım komutlarına göre front-end de yük altında olabilir). Render programları hesap için shaderları kullanırlar, sonra gerekli veriyi ana rutine geri yollarlar, sürekli bi copy-back durumu olur, tmu/rop'luk bi işe girmezler esasında. Gereken perspektif düzeltmelerinden 3d >> 2d dönüşümüne kadar herşey ana renderı hesaplayan kodla alakalı olr, shaderlar üstünde çalışır yani herşey.

    Belki tmu/rop tamamen programlanabilir olsa dediklerin olabilir onları da farklı amaçlarla kullanabilirdik. Carmack geçmişten beri yeterince programlanabilir olmayan pipeline diye bunlardan, bugün bile fixed-function ünitelerin varolmasından bahsediyor. Ama fixed function üniteler de her zman daha az güç tüketir ve maliyeti daha düşüktür (hardwired vs. microprogrammed arasındaki fark gibi).

    Oc için olabilir, sonuçta oyun için neyin kullanıldığını dışardan tam bilmesek bile 3d depth testten AA'ya kadar GPU 'nun genelde çok birimi aynı anda aktif kullanılır. bellek arabirimi de yük altındadır rop tmu'larda. Bios izin vermiyorsa daha fazla voltaja yada güç yetmmiyorsa daha üste çıkılmaz zaten. Bellek arabiriminin belli frekansın üstüne çıkmaması PHY implementasyonu (bellek arabirimlerinin fiziksel transistörler ile oluşturulması) ile de alakalı olabilir. Benim bildiğim Tahiti'deki bellek arabirimleri daha yüksek frekanslara çıkabilmek için daha büyk bi PHY yapısına sahip. Daha geniş transistör ağı, clock gate, clock tree yada mesh yapısı var. Sonuçta Tahiti 1700-1900mhz lere çıkabilirken bu sadece Ramların hızı değil bellek arabirimi / kontrolcü ile / bununla irtibatlı çalışan ROP / L2 / Rop-Cache vs. ile de alakalı. Pitcairn'de ise Ramlar uygun olsa bile çıkılmıyor diye biliyorum. Pitcairn de ayrıca bellek kontrolcüler çipde daha az yer kaplıyor, yani daha küçük bi PHY implementasyonu var(R9 290'da faln 512bit olmasına karşın düşük frekansda çalıştığı için Pitcairn'dekine benzer şekilde daha küçük bellek arabirim PHY ile Tahiti'nin bellek kontrolcüsünden daha az yer kaplıyabiliyor onun gibi).

    Artan Frekans ve yük ile birlikte en zayıf halka neresi ise ilk orada sorun çıkacak zaten. Perf anlamında çip içi network ile limitli oluyorlarmış çoğu durumda (bi geliştirici bunu şimdiye kadar hemen hiç ALU limitli bi durum görmedim hep birimler arası bandgenişliği yüzünden limitlenme gibi şeklinde ifade etmişti mesela). Eğer 1300mhz de ilk rop su koyuveriyosa, mesela bu da alt seviyede clock'un bütün transistör veya mantıksal birimlere dağıtılmasından sorumlu clock tree / mesh vs. gibi yapılarda kaymaya yol açıyorsa (clock skew), voltaj bunun önüne geçemiyorsa, fiziksel implementasyon esas sorun ise limit artık orda o oluyor. Yerine göre Daha az birim kullanılan mesela GPGPU ile render da, frekans artışına voltaj artışına rağmen frekans kayması atlama vs. olmuyordur mesela. Dediğin gibi GPU'daki birimlerin kullanım miktarı şekli vs. ile alakalı. Hani çip içinde devasa hızlı bi bellek olsa (onlarca MB mertebesinde), uzun süre VRAM'a çıkmak zorunda kalmasak belki frekansı daha da arttırma imkanı vs. olacaktı.

    Edit: Linki vediğin şey de öncesinde dediğin de doğru, bi nevi paralleştirilmiş sw render gibi bişey bu. Oyunların bu tür şeyleri kullanıp kullanmaması çok fazla şeyle alakalı. Ama klasik yaklaşım dediğim şeyler, bu tarz render motorunu içermemesinden eleştirdiğim şeyler. Gerçek zamanlı ray tracingi yüksek verimle her daim yapamazsın, oyuna uygulayamazın maliyeti çok olr. Cone tracing gibi tek tek bütün rayleri trace ettiğin şekillerle değilde, belli bi ray grubunun izdüşümü şeklinde render ettiğin zaman daha verimli olur. O şekilde 3 -5 günde voxel cone demosu hazırlaynlar var unity üstünden. Linki verdiğin şeyi oyun motoru haline çevrildiği zman götürüleri önemli yapılması gereken inputlara göre değişen şartlara uyum sağlamak için azalacak performans vs.

    64k demolarındaki gibi adamlar sahneyi önce tasarlayıp demo için sahnedeki herşeyi full makina diline aktarıp, oynatırkende herşeyin ordan oynatılması gibi şeyler ile, oyunda 1-1 input ses AI etkileşim vs. gibi şeyler gerekmesi birbirlerinden çok farklı şeyler. işi direk donanım seviyesine indirdiğin zaman, demoda mesela herşey sabit şekilde hazırlandığından GPU hiçbi şekilde conditional durum ile karşılaşmıyor, karşılaşmadığı için de branch'a girmiyor (conditional'ları branch için maske ekleyip paralel işlemye devam eder). donanım komutları bazında ve akışa bakınca branch hesaplaması gerekmediğinden, normalde 100+90+15+45 birim şeklinde paralel de olsa 4 branch hesaplaması gerekiyorsa, herşeyi belli olan bi render/ donanım komut dizisinde bu 250 birim şeklinde tek tip yoldan devam ediyor. Öbüründe çalıştırılacak olan branchlardan 90 birimlik veya 100 birimlik olan esas geçerli ise varsaydığımız performans düzeyinde çalışıyor (250 birim kapasitemiz olsa bile). Ters durum olduğunda 15 birimlik brach ihtiyaç duyulduğunda o yapılacak olan iş en düşük seviyedeki performans ile işletiliyor. Hiç branch olmadan 250 birimlik işin yapılabildiği bi durum ile en kötü 15 birimlik işin yapılabildiği durum arasında 15-16 kat fark var. Benim dediğim kadar basit değil bunun donanımdaki karşılığı örnek olsn diye yazdım ama buna benzer şeylerin olmadğı demo tarzı işlerde oyuna göre daima rahatlar(o 15 birim iş ile işletilen branch bi vektör ünitesinin işine yarayabilir diye de varsayabiliriz mesela hepten işe yaramaz olmayabilir).

    Ama GPGPU ile render ve oyun motorunun tasarımında daha fazla GPGPU kullanıldıkça daha farklı şeyler görebilmemiz lazım dediğim şeylerin içinde bunlr da var. Belki adam matematiksel olarak modellemenin farklı bi yolunu bulmuştur ve bunu GPGPU ile yapınca senin dediğin paralel sw moduna benzer bi yol olsa bile, oyuna uygulandığında şahane görsellik vs. elde ediliyordur, olabilir(alaksız olrak fillrate gereken, depth test vs. faln gerekn, üst üste binen katman gerken vs. drumlarda rop faln mutlaka kullanılır).

    Edit 2: Dx sorun oluyorsa, sorunsuz paralel komut yollama / dispatch vs. imkanı olsa Mantle üsütnden mesela belki 80-100 fps ile çalışır yada GPU'da front end / komut çözme GPGPU yükünü dağıtma birimleri mal mal yatmak yerine daha çok iş yapabilirdi. Mantle'ın GFX + Compute üstünde büyük etkisi olacak. Pazar darlığı yüzünden görür müyüz o kadar özgün iş bilmem ama PS4 de görmemiz lazım. Şu işi Ps4'de yapsalar takr takr FPS'yi vermesi lazım mesela. Ha madem o akdar götürü faln dedin, üstüne paralel dispatch dedin, PS4 müsait buna. 80-90 fps vermesinde oyun oldumu götürü diyorsun, böyle görüntü ile sabit 30 fps versin olmaz mı? Olur, o tarz şeyleri anlatmak istiyorum zaten.



    < Bu mesaj bu kişi tarafından değiştirildi Rubisco -- 18 Kasım 2013; 15:31:35 >




  • quote:

    Orijinalden alıntı: Rubisco


    @Rubisco

    Mesela valley/heavende bellekleri 1700 MHz yapabiliyordum ama catzillada en fazla 1525 MHz oluyor. Demekki catzilla bellek kontrolcüsünü zorluyor değil mi?

    3dmark2013'ün firestrike kısmında GPU sorunsuz çalışırken aynı frekansta icestrom kısmı bilgisayarı kitliyor. Yani icestrom sanırım farklı bir bölüme çok yükleniyor da kitliyor, firestrike tüm bölümlere dengeli yükleniyor galiba(yani GPGPU var gibi ). (afterburnerin kısayol tuşlarını kullanarak icestrom biterbitmez frekansı arttırıyorum firestrike için, bazı benchmarklarda çok kastıran/ısıtan noktalarda GPU patlamasın diye kullanılabilir ama hile sayılabilir)



    < Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 18 Kasım 2013; 15:52:19 >




  • Tugrul_512bit kullanıcısına yanıt
    3dMark 11'den beri kullanılıyor zaten. Post processing (lens flare/bloom/bazı optik yansımalar/bazı renk ayarlamaları) faln için GPGPU / Compute Shader kullanılıyor. Ama toplam render süresi içinde %8-15 kadar bi yeri var bunun sadece.
  • Yeni nesil konsol grafikleri pc yi geçemedi ki pc onlari tekrar geçsin:D killzone shadowfall mgs5 gibi oyunlara baktim valla ps3 deki beyond two souls la eşitliler.

    < Bu ileti mobil sürüm kullanılarak atıldı >
  • 60 fps olacakti sözde killzone 30 fps

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

    Orijinalden alıntı: cikopelo

    60 fps olacakti sözde killzone 30 fps


    Killzone SP zaten en basindan beri 30FPS olacakti. Multiplayer 60FPS. Ama genelde 40-50FPS arasinda geziyormus multisi. Ama cok akici gorunuyor.

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

    Orijinalden alıntı: Rubisco



    Nvidianın TXAA'sı ROP yerine GPGPU kullanıyorken, AMD nin de Edge-Detect olayı GPGPU değil mi?

    Yani performans götürüsü 16x AA dan azdır.



    < Bu mesaj bu kişi tarafından değiştirildi Tugrul_512bit -- 18 Kasım 2013; 18:21:01 >
  • quote:

    Orijinalden alıntı: GoldPunch


    quote:

    Orijinalden alıntı: cikopelo

    60 fps olacakti sözde killzone 30 fps


    Killzone SP zaten en basindan beri 30FPS olacakti. Multiplayer 60FPS. Ama genelde 40-50FPS arasinda geziyormus multisi. Ama cok akici gorunuyor.

    Alışmakla ilgili.

    Devamlı konsol oyunları oynayan bir lişiye 40-50 fps problem yaratmaz. Hatta 30 bile yaratmaz.

    Sorun benim gibi PC si olup PS4 de alacak kişilerde. Oyun ne kadar güzel olsada, isterse single olsun, 30 fps gerçekten sıkıntı yaratabilir. Bakalım görcez.
  • Pc donanimsal olarak ps4 un birkaç gömlek üstünde
    ramler haric ama ramin okadar etkili olduğunu sanmıyorum.
    Pc derken oyun pclerinden bahsediyorum
    Konsollar a ve pc ye cikan oyunlarda zaten pc üstün olmuştu
    en basit örneği max payne 3 de ps3 grafikleri ve pc grafikleri arasind baya fark var ps3 de buna ragmen 30 fps ortalama var pc de daha saglam grafiklere rağmen 60 70 fps alıyor saglam bir pc

    < Bu ileti mobil sürüm kullanılarak atıldı >
  • 30 fps hiç sorun olmaz, kart takılmadıktan sonra. C&C 3 mesela öyle, sahnedeki akıcılık da hiç eksik olmuyor.
  • 
Sayfa: önceki 3132333435
Sayfaya Git
Git
sonraki
- x
Bildirim
mesajınız kopyalandı (ctrl+v) yapıştırmak istediğiniz yere yapıştırabilirsiniz.