Mint ismeretes a PC-s játékpiacon mindegyik grafikus vezérlőket fejlesztő cég segíti az egyes stúdiókat a jobb grafikai effektek vagy szimulációk létrehozása érdekében. Ezek nagyrészt olyan effektgyűjtemények, amelyeket a fejlesztők beépíthetnek a játékba, esetenként változtatás nélkül, vagy kisebb-nagyobb módosítással, annak érdekében, hogy jobban igazodjon a specifikus igényekhez. Az NVIDIA például ezt a csomagot ma GameWorks SDK-nak, míg az AMD Radeon SDK-nak hívja, és az Intel is rendelkezik ilyen effektekkel, noha a fejlesztőkörnyezetüknek speciális gyűjtőneve nincs.
Régebben az effektfejlesztések rendkívül konzervatívan zajlottak, így az egyes cégek még össze is dolgoztak, hogy a fejlesztőknek a lehető legjobban optimalizált formában és nyílt forráskód mellett adják át az effekteket. Manapság viszont történtek változások. A legtöbb bírálatot ebből a szempontból a bezárkózó NVIDIA kapta, mivel a GameWorks effektek forráskódját sokszor még a fejlesztőkkel sem osztják meg, így nagyon nehézkessé vált ezeknek az optimalizálása. Nem mellesleg számos GameWorks effektek minősége rendkívül gyenge, példának okáért ott a HairWorks, aminek a hiányosságait az adott fejlesztő a hozzáférhetőség hiányában javítani sem tudja.
Az Intel gyakorlatában is megtört korábban az egységesség, így a vállalat arra törekszik, hogy olyan effekteket tervezzenek, amelyek az IGP-k extra képességeit használják, így egyfajta exkluzivitást biztosítva, bár a nyílt forráskódot megőrizték, hiszen ez a legtöbb neves fejlesztőnek és kiadónak alapvető igénye. Sajnos úgy néz ki, hogy az AMD sem marad válasz nélkül, és több olyan fejlesztés is készül a Radeon SDK-ba, amelyek már nem a "mindenkivel barátian bánunk" vonalat követik. Ennek az első szelét láthattuk már a Lichdom: Battlemage című játékban, ahol a fejlesztők egy frissítés során letiltották a TressFX-et például az NVIDIA aktuális hardverein.
Eleinte ez az AMD magánakciójának tűnt, de mára kiderült, hogy a valódi ok az volt, hogy ez a program a TressFX 2.2 verziójának kísérleti OIT (Order Independent Transparency) algoritmusát használta, ami már nem a Tomb Raiderben használt PPLL (Per-Pixel Linked Lists) gyorsítóstruktúrával oldotta meg a sorrendtől független átlátszóságot, hanem egy sokkal specifikusabb formában érte el azt, hogy a folyamatok megfelelő sorrendben érjék el az UAV-ket. Ez az algoritmus azonban csak GCN-en garantált hibátlan eredményt, illetve a nyílt forráskódot kihasználva az Intel írt még hozzá olyan kiegészítéseket, amellyel a saját IGP-in is üzemképes maradt az effekt.
Ez a probléma a jövőben nagyobb mértéket is ölthet, mivel az AMD ugyan továbbra is szabványos kódokat fog szállítani a fejlesztőknek, de ez nem mindig elég. Vannak bizonyos eljárások, amelyeket a Microsoft például a DirectX API-n belül nem ajánl, noha kétségtelen, hogy ezek formailag megvalósíthatónak tekinthetők. Az egyik ilyen kérdéses algoritmus a mutex-alapú zárolási séma használata. A mutual exclusion, azaz kölcsönös kizárás ismert funkció a programozók számára, hiszen biztosítja, hogy több versengő folyamat közül csak az egyik férhessen hozzá az adott erőforráshoz. Ezzel a DirectX API-n belül elvben biztosítható a folyamatok megfelelő sorrendű hozzáférése az UAV-khez, ugyanakkor a gyakorlatban ennél sokkal problémásabb a helyzet, mivel a DirectX-en belül a shadereket nem lehet várakoztatni, vagy az erőforrásokat elzárni.
Részben az ilyen igényekre vezette be a Microsoft például a raster ordered views funkciót a DirectX 12-ben, amely egy mondhatni biztonságos sémát kínál a fejlesztőknek arra, hogy a versengő folyamatok megfelelő sorrendben kapjanak hozzáférést az UAV-khez. Itt önmagában azt kell nézni, hogy egy ilyen formában írt kód esetében a működés a raster ordered views funkciót támogató hardvereken garantáltan ugyanazt a – megfelelő programkód esetén – hibátlan eredményt adja majd. Az AMD azonban inkább a mutex-alapú zárolási sémát fogja használni az érkező effektjeiben, mint például a TressFX 3.0-ban is. Ez ténylegesen szabványos kód és valóban működhet DirectX API-val, ahogy a Lichdom: Battlemage példája is mutatja, de garantálni az AMD csak azt tudja, hogy a GCN architektúrára épülő Radeonokon megfelelően fut.
Jó hír persze, hogy például a TressFX új verzióiban megmarad a PPLL gyorsítóstruktúra is, amit a fejlesztők igény esetén aktiválhatnak az alternatív architektúrákat használó hardverekre, így ezek is képesek majd az OIT megvalósítására, ugyanakkor kérdéses, hogy ezt a többiek értékelni fogják-e. Nyilván itt arról van szó, hogy a PPLL gyorsítóstruktúra rendkívül memóriapazarló, és nagyobb erőforrás-igényel is rendelkezik, ami miatt előnyösebb a mutex-alapú zárolási séma használata az AMD számára.
Ezekkel az akciókkal az AMD egy picit magára hagyja a piacot, hiszen úgy állnak hozzá a dolgokhoz, hogy eldöntötték magukban: mi megyünk előre és ti majd jöttök, amikor akartok. Ez azonban a piacra nem fog ennyire egyszerű elvvel lecsapódni. Bőven elképzelhető, hogy például a fejlesztők úgy döntenek, hogy nem megfelelő működés mellett letiltják például a mutex-alapú zárolási séma használó TressFX kódot, ami akár történhet az adott gyártó kifejezett kérésére is. Egy ilyen iránynak legalább annyira káros hatásai lehetnek, mint például a GameWorks SDK-nak, csak éppen nem általánosan optimalizálatlan effektekhez vezet, hanem szegmentálódáshoz. A PC-piacnak viszont egyikre sincs szüksége.
Alapvetően sokkal többet fejlődhetne a PC, ha a cégek effektfejlesztési stratégiája nem lenne olyan önző a játékosokkal szemben. Együttes erővel többre lehetnének képesek, ahogy azt régebben is tették, míg ma abszolút káros az az irány, amelyben az NVIDIA mesterségesen magas gépigényeket akar, vagy amelyben az Intel olyan effekteket erőltet, amelyek specifikus kiterjesztéseket használnak, illetve amelyben az AMD rendkívül specifikus – noha bizonyos tekintetben szabványos – algoritmusokat kínál, és ezek a gyakorlatban nagyon nehezen tekinthetők átfogó megoldásnak.
Abban a közegben, ami most kialakulóban van technológiai szempontból jelentősen elhúzhatnak azok a kiadók és fejlesztők, akik korábban eldöntötték, hogy saját lábra állnak, és saját eljárásokat fejlesztenek mindenre, így a gyártóknak csupán a segítségét kérik, de a beleszólásra jogot már nem adnak nekik. A jövőben hatványozottan érdemes ezt az irányt megfontolni mindenkinek, mivel egyre előnyösebbnek tűnik kimaradni a gyártói érdekek által táplált cicaharcból.
