quote:

I love conspiracy theories as much as the next guy, but I don’t think that’s quite true. If I’d put my cynical hat on, then sure: making graphics APIs hard to use is an interest of middleware providers. You could also say that making sure there are lots of different APIs is an interest of middleware providers too! The harder it is to make things, the better for them, right.

In practice I think we’re all too much hippies to actually think that way. I can’t speak for Epic, Valve or Frostbite of course, but on Unity side it was mostly Christophe being involved in Vulkan, and if you think his motivation is commercial interest then you don’t know him :) I and others from graphics team were only very casually following the development – I would have loved to be more involved, but was 100% busy on Unity 5.0 development all the time

quote:

Orijinalden alıntı: Mete Can Karahasan

quote: Orijinalden alıntı: tersol Teknik bilgim yok denecek kadar az ama heryerde dile getirdiğim bir şüphem var o da dx12'nin beklentilerin yarısını dahi karşılamayacağı. bu arada dostum sen adamı eleştiriyorsun ama adam çoğu hareketinde haklı zira aynı olay için birden fazla farklı konu açılıyor, konular olması gereken yerlerde değil rastgele açılıyor, bu da bilgi karmaşasına, düzensizliğe sebep oluyor. yönetim bu konuda hiçbirşey yapmıyor. geçen nvidia tian x ile ilgili 3 konu açıldı halbuki daha önce konusu açılmış güncellenmişti. aynı konunun 2.cisini sen açtın 3.cüsünü başkası. her önüne gelen kendi konusunu açarsa çöp olur bu forum ki o yolda ilerliyor zaten

Tek konu, tek fikir: muhteşem bir tartışma ortamı. Sonra da tutup eleştirin başka insanları, çok tutarlı bir yöntem gerçekten. Tekrar söylüyorum, fikirlere saygı duymadan, insanlar niye tartışmaya girmiyor diyemezsiniz. Siz kovuşturuyorsunuz çünkü. Lafının tersini yapmak diye buna derler.

quote:

Orijinalden alıntı: Rubisco

GL'i tek başına MS baltalamadı. 3dLabs dibini dinamitledi. Bundan, kendisine de ekmek çıkableceğini düşünen başkaları da direk-dolaylı olarak çatışmalara dahil olup çanak tuttu. Nvidia da var bunların içinde, GL için ben yokum diyen MS de var. vs. vs. kaç yıllık kan davası gibi mevzu bunlar.

Vulkan için şimdiye kadar olmamış, görülmemiş bi biçimde herkes uyum içinde çalışıyor. Direk olarak lazım olan esas alanlar hedeflenip onların üzerine gidiliyor (debugger'ından araortam formatına, tam detaylı spec.lerine kadar).

Ms'nin dx9, konsol ve desteği ile geliştirme araçlarının daha işlevsel olması ipi kopardı götürdü zaten.

Dx12, MS'nin daha önceden olmadığı kadar bi baskı tehdit altında olacak(2000'li yıllarda şimdikiyle karşılaştırılabilecek yapılar yoktu, o yüzden dahil etmemek lazım). Vulkan için birileri çıkar başka bi taraftan aşağıyı bi güzel dinamitler, orasını bilemeyiz. Ama şimdiki ortak çalışma gruplarının geçmiş ile alakası yok.

Kafa kurcalayan, detayının belli olmadığı ve mesela GLSL yapısı değişecek mi, shading altyapısını tamamen değiştirecekler mi, başka bi shading dili-yapısı için ne-nasıl yapacaklar, bunları yaparlarken geçmişteki gibi çıkar çatışmaları olacak mı? Bunların detayları belli değil. Ama GL 4.5 ile yapılabilecekleri tamamen kenara atıp yeni başlangıç için herkes ortakça peşinden koşarken, bu sefer olabilir gibi geliyor.

Dx12'de Ms donanım üstünde dikte edici konumunu değiştirmeyip, dx12'nin speclerini değiştirip donanımları bi anda uyumsuz yapablme gücünü elinde tutuyor. Oysa olması istenen Dx'in ben şunu bunu isterim, eyyy GPU firması, donanımda bunu nasıl yaparsan yap demesi ve gerisine karışmamasıydı. Tersi olduğundan, şu özelliği şöyle istiyorum ve donanımında da bunu böyle yapacaksın diyor.

Vulkan bu noktada tamamen olması istenen şekilde ilerliyor gibi şimdilik.

Ms'nin XB1 için bütün derdi, Dx11'de yapamadığı PC ile ortak geliştirme olayını başarmak (pardon, Dx9 Win7 öncesi ve X360'da da bunu istiyorlardı. Basiretsiz yönetici heryerde var önemli değil. Bilmem kaç seneye patladı sadece). Dx11 de ıkındılar ıkındılar olmadı. Dx12 için çok daha fazla ortak geliştirme imkanı verecek. E tabi PC'yi konsol seviyesine getirip sonra insanların XB1'e vuşşş harika demelerini beklemek olmaz. Bakalım bu yoldan yan mı çizecekler, yoksa tek programlama bakışı , geliştirme ortamı , tek appstore mantığını yürütebilecekler mi? Bu yol çok daha karlı mı olacak, yoksa yine aynı haltı yiyip ellerine yüzlerine mi bulaştıracaklar? Bilmem kaç milyar dolar arge için harca, doğru düzgün yazılım altyapısı hazırlamaktan aciz ol. Yıllllaaar önce kendi çip iletişim altyapılarını(API) kuran Japon konsol yapımcı-geliştricileri nasıl gülüyordur :(( Yine pardon, o Japon konsol yapımcıları da kendi sonlarını getirmişlerdi. Herkesi düdüklemeye çalışmayan geliştricilerinden , bu işlerden anlayan aklı başındaki insanlara kadar homurdanıp duranlardan başka ses gelmeyince iş bu yoldan devam etti edecek zaten.

XB1'e dx12 getirip çağ da atlatamıyoruz, bari bol bol daha kolay yapılabilen oyun getirelim de bu konsol işi gittiği yere kadar devam etsin? Bilmem kaç sene sonra bi konsol daha çıkartırsak söz, bu sefer herşeyini adam gibi yapacaz, mı?

Daha açık hali yok Mantle'ın, açılayacak da. SDK dedik o yok, Mart'ın later'ında dediler , vakti gelmemiş demek daha.

Mantle = Vulkan'ın kendinden donanıma göre driverı olan hali gibi bakabiliyor muyuz şimdilik? Peki şu an Dx11 için olan Dx shader'larını MAntle'a aktarmaya yarayan altyapıyı Dx12 için de sunacak mı AMD? DX12'de CPU---> GPU emir iletimi Mantle'dan daha hızlı, ama MAntle'ın GPU'da yaptığı iş de Dx12'den daha hızlı gibi şimdilik. O zman Dx12 oyununun, iyileştirilmiş Mantle versiyonu ile 3-5 kuruş daha fazlasını ortaya koyma ihtimali olamaz mı? AMD-Oyun geliştricisi bunun altına girer mi? Ana çatısı Dx12'ye benzeyen (dx11 -->> MAntle'ı yapmak kolay değil), AMD'nin Dx12 shaderlarını da kullanmasına imkan veren araç ile bazı oyun yapımcıları Dx11'de düşünmedikleri Mantle versiyonunu dx12 içn düşünürler mi? AMD herşeye yetişemeyecek kadar kaynak sıkıntısı yaşarken oyun yapımcısına destek de verir mi?

Dx12'den veya Vulkan'dan ne beklenmesi gerektiğini bilmeyen varsa, benim fikrimdir saygı duyman gerekir, ben bi halta yarayacağına inanmıyorum şeklinde yaklaşmak demek = eksik bilgim var ve bunu kabul ediyorum ama buna rağmen istediğimi söyleyebilmeliyim demek. Bu ne demek, adı benden gelmez.

quote:

Orijinalden alıntı: Rubisco
AMD MAntle'ı nasıl buldu ile, Bunu neleri göze alarak lanse etti diye sormak bence daha doğru. AMD belki yenilik adına, belki MS'yi sıkıştırmak adına, belki başka çaresi olmadığını düşündüğünden ve MS bi tarafını kımıldatmadığından, MAdem bu desteği veremeyecekti, niye bu işe girişti, orasını da bilemiyoruz. Bildiğimiz tek şey, bi güzel herkesin ağzına 1 parmak bal çaldı, sonra ben vermiom dedi. Bu da dx12'yi hızlandırıp öne çekmiş hatta erken lanse edilmesini tetiklemiş olabilir. GL 5.0 / Vulkan'a temiz bi temel oldu, o yüzden sağlam teşekkür eden bi sürü insan var, böylece daha da güdüleyici destekleyici bi etkisi oldu.

quote:

Orijinalden alıntı: Rubisco
Ms para pulu olsa da belki beceremediğinden belki de yöneticiler bizim baktığımız gibi bakmadığından daha farklı yollara gitmiyordu. Sen Nokia'nın çöküşünü anlayabiliyorsun mesela, eğer komplo vs. yok diye bakarsan, bu hale gelmesinde kilit noktadaki yöneticiler becerememesi etkili oldu dersin. Bu Dx11-12 vs. olayları da buna benzer olabilir.

quote:

Orijinalden alıntı: Rubisco
SONY'deki kıdemli baş geliştrici diyeceğin adam, milyonların yapabildiği x86 assembly ile bi iş yapmayı becerdi diye sevinçten twitterda çığlık atıyor. Anca fanatikler oo PS4 %200 hızlanıyor der. PR imaj amacıdır belki. Ama kıdemli geliştricinin kıytırık bi kodu x86 asm ile yapabildiği için çıkartılan yaygara esasında tam bi skandaldır. Adam yazdığı kodu faln paylaşmıştı, rezalet bişi yani, bunu paylaştığı için insan utanır rezil olacam diye.

quote:

Many years ago, I briefly worked at NVIDIA on the DirectX driver team (internship). This is Vista era, when a lot of people were busy with the DX10 transition, the hardware transition, and the OS/driver model transition. My job was to get games that were broken on Vista, dismantle them from the driver level, and figure out why they were broken. While I am not at all an expert on driver matters (and actually sucked at my job, to be honest), I did learn a lot about what games look like from the perspective of a driver and kernel.

The first lesson is: Nearly every game ships broken. We're talking major AAA titles from vendors who are everyday names in the industry. In some cases, we're talking about blatant violations of API rules - one D3D9 game never even called BeginFrame/EndFrame. Some are mistakes or oversights - one shipped bad shaders that heavily impacted performance on NV drivers. These things were day to day occurrences that went into a bug tracker. Then somebody would go in, find out what the game screwed up, and patch the driver to deal with it. There are lots of optional patches already in the driver that are simply toggled on or off as per-game settings, and then hacks that are more specific to games - up to and including total replacement of the shipping shaders with custom versions by the driver team. Ever wondered why nearly every major game release is accompanied by a matching driver release from AMD and/or NVIDIA? There you go.

The second lesson: The driver is gigantic. Think 1-2 million lines of code dealing with the hardware abstraction layers, plus another million per API supported. The backing function for Clear in D3D 9 was close to a thousand lines of just logic dealing with how exactly to respond to the command. It'd then call out to the correct function to actually modify the buffer in question. The level of complexity internally is enormous and winding, and even inside the driver code it can be tricky to work out how exactly you get to the fast-path behaviors. Additionally the APIs don't do a great job of matching the hardware, which means that even in the best cases the driver is covering up for a LOT of things you don't know about. There are many, many shadow operations and shadow copies of things down there.

The third lesson: It's unthreadable. The IHVs sat down starting from maybe circa 2005, and built tons of multithreading into the driver internally. They had some of the world's best kernel/driver engineers in the world to do it, and literally thousands of full blown real world test cases. They squeezed that system dry, and within the existing drivers and APIs it is impossible to get more than trivial gains out of any application side multithreading. If Futuremark can only get 5% in a trivial test case, the rest of us have no chance.

The fourth lesson: Multi GPU (SLI/CrossfireX) is ******* complicated. You cannot begin to conceive of the number of failure cases that are involved until you see them in person. I suspect that more than half of the total software effort within the IHVs is dedicated strictly to making multi-GPU setups work with existing games. (And I don't even know what the hardware side looks like.) If you've ever tried to independently build an app that uses multi GPU - especially if, god help you, you tried to do it in OpenGL - you may have discovered this insane rabbit hole. There is ONE fast path, and it's the narrowest path of all. Take lessons 2 and 3, and magnify them enormously.

Deep breath.

Ultimately, the new APIs are designed to cure all four of these problems.
* Why are games broken? Because the APIs are complex, and validation varies from decent (D3D 11) to poor (D3D 9) to catastrophic (OpenGL). There are lots of ways to hit slow paths without knowing anything has gone awry, and often the driver writers already know what mistakes you're going to make and are dynamically patching in workarounds for the common cases.
* Maintaining the drivers with the current wide surface area is tricky. Although AMD and NV have the resources to do it, the smaller IHVs (Intel, PowerVR, Qualcomm, etc) simply cannot keep up with the necessary investment. More importantly, explaining to devs the correct way to write their render pipelines has become borderline impossible. There's too many failure cases. it's been understood for quite a few years now that you cannot max out the performance of any given GPU without having someone from NVIDIA or AMD physically grab your game source code, load it on a dev driver, and do a hands-on analysis. These are the vanishingly few people who have actually seen the source to a game, the driver it's running on, and the Windows kernel it's running on, and the full specs for the hardware. Nobody else has that kind of access or engineering ability.
* Threading is just a catastrophe and is being rethought from the ground up. This requires a lot of the abstractions to be stripped away or retooled, because the old ones required too much driver intervention to be properly threadable in the first place.
* Multi-GPU is becoming explicit. For the last ten years, it has been AMD and NV's goal to make multi-GPU setups completely transparent to everybody, and it's become clear that for some subset of developers, this is just making our jobs harder. The driver has to apply imperfect heuristics to guess what the game is doing, and the game in turn has to do peculiar things in order to trigger the right heuristics. Again, for the big games somebody sits down and matches the two manually.

Part of the goal is simply to stop hiding what's actually going on in the software from game programmers. Debugging drivers has never been possible for us, which meant a lot of poking and prodding and experimenting to figure out exactly what it is that is making the render pipeline of a game slow. The IHVs certainly weren't willing to disclose these things publicly either, as they were considered critical to competitive advantage. (Sure they are guys. Sure they are.) So the game is guessing what the driver is doing, the driver is guessing what the game is doing, and the whole mess could be avoided if the drivers just wouldn't work so hard trying to protect us.

So why didn't we do this years ago? Well, there are a lot of politics involved (cough Longs Peak) and some hardware aspects but ultimately what it comes down to is the new models are hard to code for. Microsoft and ARB never wanted to subject us to manually compiling shaders against the correct render states, setting the whole thing invariant, configuring heaps and tables, etc. Segfaulting a GPU isn't a fun experience. You can't trap that in a (user space) debugger. So ... the subtext that a lot of people aren't calling out explicitly is that this round of new APIs has been done in cooperation with the big engines. The Mantle spec is effectively written by Johan Andersson at DICE, and the Khronos Vulkan spec basically pulls Aras P at Unity, Niklas S at Epic, and a couple guys at Valve into the fold.

Three out of those four just made their engines public and free with minimal backend financial obligation.

Now there's nothing wrong with any of that, obviously, and I don't think it's even the big motivating raison d'etre of the new APIs. But there's a very real message that if these APIs are too challenging to work with directly, well the guys who designed the API also happen to run very full featured engines requiring no financial commitments. So that's served to considerably smooth the politics involved in rolling these difficult to work with APIs out to the market.

The last piece to the puzzle is that we ran out of new user-facing hardware features many years ago. Ignoring raw speed, what exactly is the user-visible or dev-visible difference between a GTX 480 and a GTX 980? A few limitations have been lifted (notably in compute) but essentially they're the same thing. MS, for all practical purposes, concluded that DX was a mature, stable technology that required only minor work and mostly disbanded the teams involved. Many of the revisions to GL have been little more than API repairs. (A GTX 480 runs full featured OpenGL 4.5, by the way.) So the reason we're seeing new APIs at all stems fundamentally from Andersson hassling the IHVs until AMD woke up, smelled competitive advantage, and started paying attention. That essentially took a three year lag time from when we got hardware to the point that compute could be directly integrated into the core of a render pipeline, which is considered normal today but was bluntly revolutionary at production scale in 2012. It's a lot of small things adding up to a sea change, with key people pushing on the right people for the right things.

Phew. I'm no longer sure what the point of that rant was, but hopefully it's somehow productive that I wrote it. Ultimately the new APIs are the right step, and they're retroactively useful to old hardware which is great. They will be harder to code. How much harder? Well, that remains to be seen. Personally, my take is that MS and ARB always had the wrong idea. Their idea was to produce a nice, pretty looking front end and deal with all the awful stuff quietly in the background. Yeah it's easy to code against, but it was always a bitch and a half to debug or tune. Nobody ever took that side of the equation into account. What has finally been made clear is that it's okay to have difficult to code APIs, if the end result just works. And that's been my experience so far in retooling: it's a pain in the ass, requires widespread revisions to engine code, forces you to revisit a lot of assumptions, and generally requires a lot of infrastructure before anything works. But once it's up and running, there's no surprises. It works smoothly, you're always on the fast path, anything that IS slow is in your OWN code which can be analyzed by common tools. It's worth it.