Megjelent a menedzselt DirectX azaz a SlimDX legújabb kiadása. A márciusi relase számos hibajavítást tartalmaz, tovább növeli a teljesítményt és az osztálykönyvtár stabilitását, valamint hiányzó funkcionalitásokat is pótol. Ezért a frissítés mindenképpen javasolt.
SlimDX akcióban
Jelen kiadásnál egyébként eltértek a készítők attól a hagyománytól, hogy a natív DirectX SDK frissítésével egy időben adják ki a legújabb verziót, mivel a legutóbbi DirectX kiadás 2010 júniusában volt. A frissítésekkel pedig tovább már nem volt érdemes várni.
[prog.hu] A Doom és a Quake sorozatok atyja a közelmúltban egy egyesek számára minden bizonnyal meglepő kijelentést tett egy informatikai híroldalnak adott interjújában. John Carmack ugyanis közölte, hogy szerinte ma már a Direct3D és nem az OpenGL képezi a PC-s grafikai csatolófelületek csúcsát.
"Szerint ma egyértelműen a Direct3D a jobb API", közölte a klasszikusan az OpenGL egyik legnagyobb támogatójának számító fejlesztő, akinek alkotásai a múltban következetesen az eredetileg a Silicon Graphics által kifejlesztett interfészt használták a grafikák megjelenítésére a Microsoft csatolófelülete helyett. "A Microsoft-nak volt bátorsága folyamatosan továbbfejleszteni az API-t akár inkompatibilitás árán is, miközben az OpenGL-t ez utóbbi aggályok megakadályozták ebben", indokolta "pálfordulását" a fejlesztőlegenda.
"Az elmúlt tíz évben a tényleges innováció a grafika terén egyértelműen a Microsoft nevéhez köthető. Az OpenGL nagyrészt csak követte ezt ahelyett, hogy új eljárásokat dolgozott volna ki. [..] Az igazság az, hogy csak a tehetetlenség az, ami miatt kitartunk az OpenGL mellett", közölte Carmack, aki egyébként egyértelművé tette, hogy a fentiektől függetlenül nem fognak egyik napról a másikra a Direct3D-ra átváltani. Folytatás itt.
Nem is olyan régen írtam arról a jól sikerült bemutatóról ahol nem mással, mint magával a Leonar3Do-val ismerkedhettem meg testközelből. A bemutató után tele voltam gondolatokkal, érzésekkel és ötletekkel, hiszen egy egészen új világot villantott fel számomra ez az ígéretes magyar fejlesztés. Hogy miért? Mert a Leonar3Do teljesen újraértelmezi a 3D fogalmát a felhasználók és a fejlesztők számára egyaránt. És ez szuper!
Minden rajongásom ellenére még mindig nincsen saját Leo rendszerem. Pedig vágyok rá, szeretnék egyet, látok benne fantáziát, de még mindig nem engedhetem meg magamnak. Számomra kicsit drága, pedig ennyiért még sose kínáltak ilyen jó virtuális valóság (VR) rendszert. Akkor miért nem veszek egyet? Tettem fel magamnak a kérdést. A mostani posztban erre keresem a választ...
Ebben a bejegyzésben a LinkedIn szolgáltatását mutatom be, járom körbe: mi is ez? mire használható? kiknek ajánlott?
A LinkedIn egy üzlet-központú közösségi oldal. Leegyszerűsítve egy online önéletrajz. Regisztrációt követően a felhasználók létrehozhatják a profiloldalukat, ahova feltölthető egy profilkép, korábbi munkahelyek, tapasztalatok, felsőoktatási intézmények, valamint különböző egyéb képességek, tulajdonságok.
A 2002 decemberében alapított LinkedIn 2003-ban kezdte meg működését. Jelenleg megközelítőleg 45 millió regisztrált felhasználóval rendelkezik a rendszer. A magyar felhasználók száma folyamatosan nő, köszönhetően a az új social media trendnek.
A LinkedIn rendszeren belül a felhasználók felvehetik egymást a kapcsolataik közé, mint azt megszokhattuk a legtöbb közösségi oldal esetén.
Mire használható a LinkedIn?
Allás keresésre - Megnézhetjük adott tevékenységi körökben milyen cégek vannak jelen, milyenek a vállalati statisztikái a munkavállaló szempontjából (pl. az adott vállalatnál milyen arányban dolgoznak nők és férfiak), és milyen konkrét állásajánlatok vannak az adott szektorban. Munkaerő keresésre - Mivel a profilunk egy komplett önéletrajz, lehetőség van más felhasználóknak - akár egy fejvadásznak, HR munkatársnak - megtekinteni az adatlapunkat. Ha meggyőzőek az ott található információk, az ember várhatja, hogy megkeressék, behívják egy interjúra, elbeszélgetésre. Kapcsolatépítés - Tegyük fel, hogy X-nek szüksége van egy programozóra, és egyik barátjának, Y-nak van egy programozó ismerőse, akit Z-nek hívnak. X könnyen és gyorsan megtalálhatja Z-t a LinkedIn segítségével, sőt akár megkérdezheti Y-t, hogy mi a véleménye Z-ről. Egyszerűbben fogalmazva, üzleti kapcsolatokat lehet kialakítani és fenntartani a LinkedIn segítségével.
A fenti főbb funkciók mellett van természetesen üzenetküldési lehetőség, naptári szervező.
Kiknek ajánlott a LinkedIn regisztráció?
Véleményem szerint minden cégvezetőnek, menedzsernek, középvezetőnek, egyéni vállalkozónak, egyetemi oktatónak kötelezően ajánlott. Emellett én úgy gondolom, hogy mindenki aki szeretne valamilyen formában üzleti kapcsolatokat építeni és ápolni, annak érdemes regisztrálnia, függetlenül munkahelyi pozíciótól és iskolai végzettségtől. Bár viszonylag kevés a magyar felhasználó, külföldiek között van orvos, mérnök, ügyvéd, középiskolai tanár, pék, asztalos vagy egyetemista. Elég nagy közösség alakulhat ki a magyar felhasználók részről is, csak idő kell, mire az itthon userek is ráéreznek a LinkedIn ízére.
A LinkedIn jövője...
Úgy gondolom a LinkedIn a jövőben meghatározó közösségi oldallá válhat, bár az álláskereső-, és job-portálokat nem fogja felváltani. Inkább egymást kiegészítve lesznek jelen az álláskeresési piacon. A legfontosabb, hogy ne hagyja senki figyelmen kívül a LinkedIn szolgáltatását, mert igenis van benne potenciál: érdemes álláshirdetést feladni, érdemes munkaerőt keresni, érdemes kapcsolatokat építeni...
Végül egy angol nyelvű videó, mely bemutatja a LinkedIn-t!
Új memória architektúrát vezet be az NVIDIA a CUDA-rendszereknél: a platformot használó szoftverek transzparensen látják, a GPU-k pedig közvetlenül elérik egymás és a rendszer memóriáját. Frissülnek a fejlesztői eszközök is, bővül a C++-támogatás.
Szeptemberben jelentette be az NVIDIA a CUDA eszközök 3.2-es verzióját, egy időben a Fermi-alapú Tesla gyorsítókártyák megjelenésével. Azóta eltelt öt hónap, így a féléves fejlesztési ciklusnak megfelelően időszerűvé vált a következő verzióról beszélni. Az NVIDIA bejelentése szerint a fejlesztőeszköz új változata 4.0-s verziószámot viseli és számos jelentős újítást vezet be a GPGPU platformon.
Egységes, virtuális
A CUDA 4.0 legfontosabb újdonságát a memóriakezelés alapos átrendezése jelenti, amely a következő lépés a több CUDA lapkát futtató rendszerek optimalizálása felé. Az első rendszerek igazi teljesítménynövekedést csak a kis utasításállománnyal, nagy adathalmazokon futtatott programok esetében értek el, a lapkák teljesen függetlenül dolgoztak még egy szerveren belül is. A CUDA következő iterációban az NVIDIA ezeket a korlátokat bontotta le, elérhetővé téve a CUDA memóriát a többi GPU, illetve más eszközök számára is. Ezen az úton a következő lépés a CUDA 4.0, amely még egyszerűbbé teszi a magok számára a kooperatív munkát és egymás memóriájának elérését.
Szoftveres oldalon ez két megoldásban ölt testet: egyrészt a teljes CUDA platform (CPU-k és GPU-k) egységes virtuális memória címteret kap, így az alkalmazások transzparens módon használhatják a memóriát, a virtuális címzést a meghajtó fordítja le fizikai címekre. A meghajtóra hárul így a memóriakezelés teljes feladata, az NVIDIA mérnökei szerint sikerült megoldani a sok heterogén feldolgozóegység és sok, szintén heterogén sebességű memória allokációjának és elérésének optimalizációját. Az alkalmazásfejlesztői oldalról ez a memóriakezelés jelentős egyszerűsítését jelenti, a felhasználói programok csak az egységesített memóriát látják, a háttérben pedig a meghajtó elvégzi a szükséges, alacsony szintű műveleteket.
Heterogén memória
Hardveres oldalon a GPUDirect 2.0-s verzióját aktiválja az új CUDA. Míg az 1.0-s kiadás elérhetővé tette a GPU-k mögött lévő memória elérését egyéb eszközök számára, a megoldás nem volt problémamentes és inkább a különböző csomópontok közötti Infiniband és hálózati kapcsolat optimalizálását célozta. A megoldás nagy hátránya, hogy a GPU memóriájának elérése nem közvetlen, hanem külső kérésre a rendszermemóriába került egy másolat a kért adatról, ezt tudta elérni más eszköz. A CUDA-memóriából a GPU-n és az adatbuszon keresztül a chipset és a CPU érintésével a rendszermemóriába kerülő adat által bejárt útvonal túl hosszú a csomóponton belüli GPU-k együttműködéséhez.
A GPUDirect 2.0-s verziója megszünteti a rendszermemóriába másolás szükségességét. Az adatelérés ideje így jelentősen rövidül, és a sávszélesség is kevésbé korlátozott - a GPU-k az SLI technológiából megismert módon, a PCI Express buszon keresztül közvetlenül tudnak kommunikálni. A GPUDirect 2.0 tehát gyakorlatilag NUMA-szerű (Non-Uniform Memory Access) rendszerbe rendezi a csomópontban található CUDA-magokat, a lokáis memóriát ugyanis a Tesla egységek 148 GBps sávszélességgel , a többi maghoz rendelt memóriát pedig a PCI Express 8 GBps sebességével érik el.
Komplexebb feladatok
A memória architektúra átrajzolásával az NVIDIA célja egyértelmű: míg eddig a magok meglehetősen elszigetelten dolgoztak a saját memóriájuk felhasználásával, a címtér egységesítésével és a GPU-k közti kommunikáció felgyorsításával a CUDA újabb, komplexebb feladatok elvégzésére is alkalmassá vált. A cég láthatóan próbálja a platformot a valódi általános felhasználás felé tolni, szemben a jelenleg alkalmazott magasan specializált feladatok elvégzésével.
A rendszerszintű teljesítményen túl az NVIDIA a magonkénti feldolgozás sebességének növelését sem tévesztette szem elől. A CUDA 4.0-ban megjelent a nyílt forráskódú Thrust könyvtár, amely a C++ Standard Template Library CUDA-s megfelelője. Ugyan a Thrust eddig is elérhető volt, az NVIDIA kutatási projektjéből kifejlődő könyvtár a platform teljes értékű tagjává vált. A könyvtár elsősorban az eddig STL-t használó C++ alkalmazásokat gyorsítja és automatikusan képes elosztani a feladatokat a CPU és a GPU között. A C++ részleges támogatása a Fermivel érkezett a CUDA-platformra, azóta az NVIDIA folyamatosan implementálja az újabb és újabb C++ funkciókat, most a virtuális függvények támogatása, valamint a new és a delete dinamikus memória operátorok kerültek be, fejlesztői kérésre.
Lassan jön
A fejlesztői eszközök terén is hozott újdonságot a CUDA 4.0 megújult a Visual Profiler teljesítményelemző eszköz, amely az alkalmazást lassító problémákra mutat rá, és mostantól hasznos tippeket is ad a magasabb teljesítmény elérése érdekében. Az új platformmal érkezik egy bináris disassembler is, amely képes lesz a CUDA fordító kimenetét analizálni. A CUDA 4.0 kiadásra jelölt verziója regisztrált fejlesztők számára március 4-én lesz elérhető, a végleges verziót illetően az NVIDIA egyelőre nem árult el pontosabb kiadási időpontot - az előző verziókból kiindulva azonban még néhány hónapig el fog tartani a friss platform csiszolása.
A most következő cikk szerzője Abu85 aki talán a legjobb "GPU" szakíró kis hazánkban. Írása 2008-ban jelent meg először, de aktualitásából szinte semmit sem vesztett így célszerű elolvasnia mindenkinek akit csak kicsit is érdekel a számítógépes grafika fejlődése.
[Prohardver] A jelenkort meglehetősen komoly kompatibilitási problémák és általános szétszórtság jellemzi. Az új DirectX 10 API – elődjeivel ellentétben – nem tudta egyértelműen kijelölni a grafikai fejlődés zavartalan ösvényét. Az interfész alkalmazását az esetek többségében gazdasági szempontok ellenzik, melynek gyökerei kifejezetten a PC-s játékipar helyzetére vezethetőek vissza. A reformok kora című cikkben részleteztük a Microsoft új API-jának forradalmi újításait. Röviden összefoglalva a DirectX 10 legfontosabb előnye, hogy az egyszerűsített alapok mellett a programok fejlesztése is könnyebbé válhat. Problémát vet fel azonban, hogy egy multiplatform játék a konzolokon nagyságrendekkel magasabb eladásokat produkál. Ennek köszönhető, hogy a fejlesztők nagy többsége az aktuális projekt konzolos változatára koncentrál. A program PC-s verziója jobb esetben egy igényes konzolport lesz. A rosszabb esetet pedig nem érdemes részletezni.
A Xenos kompatibilis tesszellátor
A fenti bekezdésből már kitalálható, hogy a PC-s játékok grafikai fejlődését inkább a konzolok képességei fogják meghatározni a közeljövőben. Ez persze messze nem azt jelenti, hogy a DirectX 10 és a 10.1-es API egyes újításait senki sem fogja használni, viszont a költségek kímélése érdekében a többség nem fog élni ezzel a lehetőséggel. Innentől kezdve érdemes a Microsoft Xbox 360 és a Sony PlayStation 3 képességeinek az irányából vizsgálni a PC jövőjét. A Sony rendszere eléggé kötetlen lehetőségeket teremt hat darab, egyéni igényeknek megfelelően felhasználható SPE magjának köszönhetően. A fejlesztők képzeletének csak a teljesítmény szab határt. Meglehetősen nehéz megmondani, hogy a programozók a PlayStation 3 exkluzív programoknál milyen csapásokon közlekednek majd, de alapvetően ez a PC szempontjából szerencsénkre teljesen irreleváns.Az Xbox 360-nak viszont sokkal kötöttebb lehetőségeket rejt a hardvere, ami előrevetíti a fejlesztők lehetőségeit a használható eljárások tekintetében. A Microsoft gépének egyik adu ásza az Xenos nevű grafikus processzorban megbúvó, úgynevezett programozható tesszellátor. Ez az egység az első lépésben az eredeti modell poligonjait kisebbekre bontja fel, majd a Displacement Map segítségével pozicionálja a vertexeket. A programozható megnevezés is innen ered, a vertexek helyét egyénileg lehet definiálni. Maga az egység azonban a beégetett, fix funkciós algoritmusok alapján bontja fel a felületet. A tesszelláció maximum tizenötszörös lehet. Ez azt jelent, hogy egy tetszőleges modellt az eredeti állapothoz képest tizenötször lehet tesszellálni. Példával szemléltetve a dolgot, az egyik legegyszerűbb beépített algoritmus segítségével egy háromszög alakú patchet fel lehet bontani úgy, hogy oldalainak felezőpontjait összekötjük. Ennek köszönhetően máris négy háromszög keletkezett. A Xenos GPU ezt a folyamatot tizenötször tudja egymás után végrehajtani. Könnyen ki lehet találni, hogy ez az egység számtalan erőforrást szabadít fel az Xbox 360 központi processzoráról és memóriájáról, mivel a rendszer erőforrásait az alacsony részletességű modell terheli. Emellett a fejlesztés is könnyebb, hiszen elég az alacsony részletességű tárgyakat elkészíteni, amit a tesszellátor majd a megfelelő minőségi szintre javít.Multiplatform fejlesztés esetén nagy valószínűséggel az Xbox 360 képességeinek feleltetik majd meg a játékot a programozók, így a tesszellációs egység használata reális fejlődési irányt sejtet. A PlayStation 3 sem probléma, mert befoghatók az SPE magok tesszellálni, vagy el is készíthetők a magas poligonszámú modellek. A PC helyzete már közel sem ilyen rózsás. Ha a projekthez csak alacsony poligonszámú modellek készültek, akkor pusztán a PC-s port végett nem fognak annyi erőforrást befektetni, amennyi szükséges a jobban kidolgozott tárgyak használatáért, ellenben a Radeon HD2000/HD3000/HD4000-es széria rendelkezik Xenos-kompatibilis tesszellátorral, így azok használata lehetséges.
A DirectX 11 kompatibilis tesszellátor
A szélesebb látókör kedvéért rögtön az elején érdemes tisztázni, hogy a Xenosban és a DirectX 11-ben használt tesszellátor nem kompatibilis egymással. A Xenos tesszellátora logikai szinten rögtön az Input Assembler mögött helyezkedik el. A rendszer használatához direkten kell címezni az egységet. A PC-n is hasonlóan kell majd eljárni a megfelelő eredmény elérése érdekében, mivel csak az AMD rendelkezik kompatibilis kártyákkal, így nem szükségesek egyéni rutinok az optimalizált működéshez. A DirectX 11-ben viszont egy masszívan felépített struktúra kapott helyett. Ez a rendszer három, szorosan összefüggő logikai szintre osztható: Hull Shader, Tesszellátor, Domain Shader. A Hull Shader szintjére érkeznek meg a feldolgozásra váró adatok. Itt lesz beállítva a testekre vonatkozó tesszellálás mértéke, illetve kijelölésre kerül az előre beépített módok közül a fejlesztő által kiválasztott algoritmus. Ezután az adatok patchként lesznek továbbítva a fix funkciós tesszellátorba.
A patchek tulajdonképpen vertex tömbök, amiket az adott objektum geometriai vázának szétszeletelésével lehet előállítani. Nagyon fontos azonban, hogy ezek nem jelentenek szükségszerűen poligonokat. Egy példával élve három vertex képezhet egy olyan a térbeli alakzatot is, ami tulajdonképpen két szakasz. Ezeket is tökéletesen lehet tesszellálni. A Hull Shader ezen kívül minden patchhez megjelöl egy kontroll pontot, amely a Domain Shader szakaszban kerül majd felhasználásra. A második szinten a tesszellátor elvégzi az utasításoknak megfelelően a feladatát, és az úgynevezett területi pontokat a harmadik szintre irányítja, amiből a Domain Shader a displacement map, a kontrollpont és a tesszellációs mérték segítségével kialakítja a végleges felületet.
A DirectX 11 tesszellátora egy tökéletes kiterjesztése a Xenosban helyet foglaló egységnek. Minden változtatás csak az előnyére vált, emellett a tesszelláció maximális mértéke már akár hatvannégyszeres is lehet. Megjegyzendő azonban, hogy hagyományos értelemben még mindig nem programozható a rendszer, így a fejlesztők nem kapták meg az egyénileg definiált tesszellációs algoritmusok kreálásának a lehetőségét.
A DirectX 11 újításai
Az elmúlt verziókban elképesztő mértékű fejlődésen ment keresztül a Shader Modell szabvány és a HLSL (High Level Shader Language) programnyelv. Az 5.0-ás verzió nem igazán bővíti tovább a lehetőségeket, hiszen a mérce már amúgy is igen magasra lett tolva. Ellenben egyszerűsíti a programozók feladatát, hiszen objektumorientált lett a nyelv. Ez a változás a felhasználóknak jelentéktelennek tűnhet, de érdemes belegondolni, micsoda előrelépés a fejlesztőknek. A mai programok rengeteg eltérő kódot alkalmaznak az adott fényhatást figyelembe véve a különböző paramétereknek megfeleltethető felületekre (legyen az virtuális fém, műanyag, fa, üveg vagy szövet). A szekvenciális alapokon nyugvó, korábbi verziójú HLSL nyelvekben ezeket a fény-anyag kölcsönhatásokat kétféleképpen kódolhatták le a programozók. Az egyik megoldás, hogy a grafikus motor összes lehetséges árnyalási metódusára egy külön shader programot kell futtatni. A mai, korszerű grafikát kezelő rendszerek mellett azonban ez nagyon sok kis programot eredményez, hiszen tucatnyi megkülönböztethető felület létezik, emellett az eltérő fényhatásokból is bőven akad.
Shader Modell 5.0
A fentebb említett öt, anyagokra vonatkozó példa három fénytípussal kiegészítve (például: körsugárzó, pont és direkt) rögtön 15 darab programot generál, ami már elég ahhoz, hogy az esetleges hibák kereséséhez és javításához aránytalanul magas időigény járuljon. Arról sem szabad megfeledkezni, hogy shader programok folyamatos generálása a hardver szempontjából is időbe telik. Ennek elkerülésére alkalmazták eddig a fejlesztők az übershadernek gúnyolt programokat, mint alternatív megoldást. A helyzet azonban alig átláthatóbb, mivel egy shader programba kell az összes kódot írni, nem kevés feltételes elágazás használatával. Az objektumorientáltság azonban jelentősen egyszerűsíti a fejlesztők dolgát, hiszen a programegységeket egy előre megtervezett hierarchiának feleltethetik meg. Interfészként megadható a felület és a fényhatás, melyben a tagfüggvények, azok tulajdonságai és bemenő paraméterei találhatók. Az osztályok pedig a függvényeket és a változókat tartalmazzák. Ennek megfelelően a hibakeresésre fordított idő jelentősen redukálódhat.
Textúratömörítés
Két új textúratömörítési eljárás került az új API-ba. Ennek nagy jelentősége van a mai programok mellett, hiszen a nagyfelbontású textúrák komoly helyigénnyel rendelkeznek a memóriára nézve. Ezen kívül a DirectX 11 már megköveteli a hardveres kitömörítést is az összes támogatott formátumra. A BC6 (Block Compression) a HDR (High Dynamic Range) alkalmazása mellett használható. Ilyen esetekben ugyanis a fejlesztők sokszor alkalmaznak Tone mapet a kép színátviteli görbéjének állítása miatt. A BC6 6:1 arányban tömöríti a képkocka HDR adatait, ami némi veszteséggel jár ugyan, de a végső eredmény rendkívül meggyőző.
BC6 textúratömörítés a gyakorlatban
A BC7 az úgynevezett LDR (Low Dynamic Range) formátumú textúrák alkalmazása mellett lehet alternatíva. Nagyon jó képminőséget eredményez az eljárás 3:1-es RGB (vörös, zöld, kék), illetve 4:1-es RGBA (vörös, zöld, kék, átlátszóság) tömörítési arány mellett. A fenti két textúratömörítési eljárást lehetőség van a driver szintjén emulálni, így a támogatás kiterjeszthető a DirectX 10-es hardverekre is. Természetesen a hardveres kitömörítés itt nem lesz alkalmazható, így a sebességre nézve negatívan ható felárat kell majd érte fizetni.
Többszálúság támogatása
Nem nevezhető meglepetésnek, hogy a DirectX API is rálépett a Multi-Threading, azaz a többszálú feldolgozás kissé döcögősen járható útjára. Szerény véleményem szerint ennek már hamarabb meg kellett volna történnie, hiszen meglehetősen problémás, hogy a piac legelterjedtebb grafikus API-ja a többmagos processzorok korában még mindig csak egy programszálon renderel. Az új API-ban az objektum megrajzolásához szükséges rajzolási parancs és az effektek létrehozásánál bekövetkező állapotváltások már több szálon lesznek kezelve. Ahhoz, hogy ez működésben megfelelően ki legyen használva, a Direct3D 11-es erőforrást az azonnali és a halasztott tartalom szintjére kell felosztani. Az azonnali tartalom egy programszálat takar, és olyan kész objektumokat tartalmaz, melyek sorrendben átadhatók a grafikus processzornak. A halasztott tartalom központi processzor által történő feldolgozása már több szálon történik. Minden egyes ilyen szál tartalmaz egy listát a saját objektumairól, így lesz ellenőrizve, hogy a számítás elvégzése megtörtént-e. Amint kész a feladat, a halasztott tartalom behívásra kerül az azonnali tartalomba. Jó hír, hogy a rendszer működése az API szintjén változott meg, így nem szükséges hardveres módosítás a problémamentes feldolgozáshoz. Ez azt jelenti, hogy a Windows Vista operációs rendszerben bemutatkozó WDDM (Windows Display Driver Model) és a megfelelően felépített eszközmeghajtók mellett bármelyik, minimum DirectX 10-kompatibilis grafikus kártyával használható az új feldolgozási elv. Azt persze érdemes megemlíteni, hogy a fő feldolgozási szál továbbra is túlterhelhető, tehát a tökéletes eredmény eléréséhez a fejlesztőnek is optimalizált eljárásokat kell alkalmaznia.
További változás még a DirectX 11-ben, hogy a maximum alkalmazható textúraméret akár 16384x16384 pixeles is lehet. Ezenkívül a Conservative oDepth eljárás segítségével akkor is lehet a Depth Bufferbe írni, ha az Early Z check és más, úgynevezett Z gyorsítási funkciók nincsenek kikapcsolva.
General-Purpose GPU és a fizika
Az NVIDIA és az AMD jó ideje tolja a grafikus processzoron történő általános számítási feladatok szekerét. Az egész elképzelés azon a tényen alapszik, hogy bizonyos, nagymértékben párhuzamosítható számítási feladatokban a központi processzorok teljesítménye messze le van maradva a grafikus processzorokéhoz képest. Mindkét nagy GPU-gyártó cég rendelkezik a termékeik képességeihez igazított programozási interfésszel. A zöldek ezt CUDA-nak, míg a vörösek Stream SDK-nak nevezték el. A fejlesztőknek viszont sokkal fontosabb lenne egy olyan szabványos GPGPU API, amelyet mindkét cég maximálisan támogat. Ezzel a lépéssel jelentősen megkönnyíthető lenne a grafikus processzoron futtatható programok fejlesztése, hiszen nem kell két eltérő interfészre megírni a projektet. Jelen állás szerint a feladat betöltésére két versenyző esélyes. Az egyik jelentkező a Khronos Group által fejlesztett OpenCL (Open Compute Language), míg a másik a DirectX 11-ben bemutatkozó Compute Shader technológia.
Az OpenCL elsősorban az APPLE támogatását élvezi, és várhatóan a legtöbb operációs rendszeren elérhető lesz. Az NVIDIA-val ellentétben az AMD nagyon szoros kapcsolatban van a fejlesztőkkel, ami vélhetőleg annak köszönhető, hogy a riválisaihoz képest előnyösebb pozíciót akar kiharcolni a platform irányelveinek meghatározása szempontjából.
NVIDIA Cuda
A Microsoft Compute Shader a DirectX 11 része lesz, így nem nehéz kitalálni, hogy csak a Windows rendszereket fogják támogatni. A fejlesztés a főbb gyártók bevonásával zajlik. A Redmondi óriáscég nagy reményeket fűz a technológiához; a fő cél elsősorban olyan programok létrehozása, ami a játék fizikájára, mesterséges intelligenciájára és a grafikai minőséget nagymértékben javító effektekre van kihegyezve.
A jelenleg is elérhető GPGPU interfészek közül a CUDA a legkidolgozottabb. Az AMD azonban az esetleges támogatásra nemet mondott a zöldeknek, így borítékolható, hogy a rendszer a jövőben a szükséges támogatás hiányában nem fogja felvenni a versenyt az általános API-kkal szemben. Megjegyzendő azonban, hogy ha a Santa Clara-i cégnek sikerülne valamelyik következő generációs konzolba egy GeForce GPU-t passzírozni, akkor az a CUDA helyzetét meglehetősen pozitív irányba befolyásolná.
Fizika a játékokban
Ezen a területen nagyon kényes a helyzet. Ha a fejlesztők előre megírt rendszert akarnak használni, akkor két lehetőségük van. Választhatják az NVIDIA Ageiatól megvásárolt PhysX technológiáját, vagy az Intel Havokot, amelyet az AMD is támogat. Mindkét rendszer kellően nagy támogatottsággal rendelkezik, és ami a legfontosabb, elérhetőek Xbox 360 és PlayStation 3 konzolra is. A PC-n meglátásom szerint a PhysX némi előnyre tett szert, bár ez viszonyítás kérdése, de a GPU-alapú gyorsítás lehetősége semmiképp sem elhanyagolható tényező. Az Ageia felvásárlása után egy általános zűrzavar alakult ki, az NVIDIA ugyanis nem igazán magyarázta el, mi kell ahhoz, hogy a program a grafikus processzort használja a fizikai számításhoz.
A PhysX technológiát kétféle licensznek feleltették meg a karrierje kezdetén. A különbség abban merült ki, hogy a teljes licenszhez olyan speciális, Novodex API kiterjesztések tartoztak, amelyek lehetővé tették a fizika számítását az Ageia PhysX P100 elnevezésű gyorsírókártyán. Az elkészült programokat ebből a szempontból tehát két részre lehet osztani. Az egyik hányad csak a központi processzort használta a feladatok kalkulálására, míg a többi termék a fizikai gyorsító processzor segítségét is igénybe vette, amennyiben a felhasználó rendelkezett a szükséges hardverrel. A CUDA-kompatibilis NVIDIA termékek jelenleg csak azokat a programokat képesek gyorsítani, amelyek a teljes licenszes NOVODEX API-t használták a számításokhoz. Az éppen készülő projektekkel már más a helyzet, a PhysX technológia régóta ingyenes, így az adott cég megújíthatja meglévő korlátozott licenszét teljes támogatásúra. Minden fejlesztőnek mérlegelnie kell, hogy érdemes-e az előbbi lépést megtenni. Jelent-e komoly változást az ütemtervben az extra támogatás beépítése? Természetesen a felhasználókat az a kérdés érdekli a legjobban, hogy milyen esetekben tudják hasznosítani a GeForce grafikus rendszer fizikai számításra alapozó extra képességeit. Ha az adott program teljes licensszel rendelkezik, akkor lényegében mindig.
Az igazsághoz azonban hozzátartozik, hogy sok esetben nincs értelme a fizikát a grafikus processzoron számítani, egyszerűen nincs komoly haszna az eredményeket tekintve. Példának érdemes az Unreal Tournament 3-at felhozni. Ez a játék minden esetben kihasználja az NVIDIA PhysX lehetőségeit, ellenben nem árt megfigyelni, hogy csak akkor van komoly sebességnövelő hatása a technikának, ha a pálya fizikai komplexitása meglehetősen magas. Az eredeti, PhysX rendszert nem igazán használó pályákon a teljesítmény a grafikus rendszeren történő fizikai számítás hatására elenyésző mértékben növekszik. Ezen a ponton lépnek be a képbe a konzolok. Az Xbox 360 és a PlayStation 3 a PhysX technológiát csak a központi processzoron képesek futtatni, ami limitálóan hat majd a jövőben megjelenő játékok fizikai összetettségére. Emellett tovább rontja a helyzetet, hogy a fizika szerves része a játékmenetnek, így annak butítása, illetve feljavítása komoly aggályokat vet fel. Abban az esetben sem javulna a helyzet, ha az AMD belépne a PhysX-et erősítő cégek táborába, hiszen ha valami nem működik megfelelően konzolon, akkor jelenleg nagyon kicsi a PC-s támogatás esélye.
Voxel space és ray-tracing
Az utóbbi időben igen parázs vitákat vív egymással az Intel és az NVIDIA. Ennek elsősorban az Intel Larrabee nevű fejlesztése az oka. Ez a chip több általánosan programozható és viszonylag egyszerű felépítésű processzormagot tartalmaz, ami teljesen új koncepció a grafikus kártyák piacán. A kékek nyilvánvalóan termékük tökéletességét hirdetik, míg a zöldek elég negatív nyilatkozatokkal hívják fel a figyelmet az eszköz hibáira. Az AMD hivatalos véleményét nem lehet tudni, ők ebben a nyilatkozatháborúban inkább csak külső szemlélőként vesznek részt. A Larrabee megjelenéséig még legalább két év van hátra, de már most világossá vált a csatában résztvevő cégek vezetői számára, hogy a vesztes nagy árat fog fizetni. Az NVIDIA teljes mértékben kiáll a DirectX logikai futószalagja mellett, ami nem csoda, hiszen a felépített GeForce birodalomban majd egy évtized munkája van benne. Az Intel kvázi új szereplő lesz az önálló grafikus kártyák piacán, így alapvetően a befektetett pénzen kívül minimális a vesztenivalója. Az AMD egyfajta kakukktojásnak tűnik a harcban, ugyanis nekik alapvetően mindegy, merre halad tovább a kor, hiszen technológiáikkal mindkét irányvonal kényelmesen követhető. Az NVIDIA ellen tökéletes fegyvert jelentenek jelenleg az R600 mikroarchitektúrára épülő termékek, míg az Intel ellen egy megfelelően felépített Fusion rendszer vehetné fel a harcot. Nehéz megjósolni, hogy mit hoz a távolabbi jövő, de mindenképp kiindulhatunk egy-két vezető fejlesztő elképzeléséből, és a jelenlegi renderelő futószalag esetleges gyenge pontjaiból.
A render futószalag változásai
Érdemes a mellékelt képre vetni egy rövidke pillantást. Az ábra azt vázolja fel, hogy kezdetben minden grafikai program egy szoftveresen definiált renderelő futószalagot használt. A számítások teljes egészében a processzort terhelték. A DirectX futószalagja tulajdonképpen egy előre definiált render. Az alapjai az 1992-ben megjelenő IrisGL-re épülő OpenGL API-ban bemutatott szerkezetnek feleltethetők meg. A logikai felépítése modellezés esetén geometrikus traszformációkra épül, míg a leképzésre a raszterizálást használja. Ez a struktúra a mai napig nem változott, csak egyes elemei bővültek a kornak megfelelően. A DirectX 11 felépítése pedig már feszegeti a fenti két eljárás elméleti határait. A geometrikus transzformációkra épülő modellezés a tesszellátor bevezetésével gyakorlatilag elérte fejleszthetősége csúcsát. Talán egy apró lépcsőfokot jelenhet még az egyénileg definiálható tesszellációs algoritmusok bevezetése, de ez igazából nem számítana kiemelkedő ugrásnak a jelenlegi fix funkciós egységhez képest.
Persze nem feltétlenül kell a modellezésnek a geometrikus transzformációkra építeni, mert van más megoldás is, melynek neve Voxel Space. A közhiedelemmel ellentétben a messze nem újkeltű eljárást jelenleg elsősorban az orvosi képfeldolgozásnál használják. A játékok szempontjából régebben lehetet voxeles rendszerrel találkozni. Hogy példa is legyen szem előtt, az Outcast nevű játék ezt az eljárást használja, emellett érdemes megemlíteni Ken Silverman Voxlap nevű motorját is. De mi is a voxel definíciója? Tulajdonképpen a virtuális térfogat egyfajta elemi egysége, ahogy a pixel a kép területének a legegyszerűbb megközelítése. A név is innen ered: Volumized Pixel. Voxelnek a 3D-s motorban előre definiálhatót szélessége, magassága és mélysége van; minél kisebb ennek az egységnyi értéke, annál jobb lesz a grafika, viszont a teljesítményigény is ennek megfelelően növekszik. A technika nagy előnye, hogy a poligonhoz képest sokkal kevesebb adatmennyiséget kell tárolni. Nagyon jó alkalmazási területe a Voxelnek a terep kirajzolása, ugyanis tökéletesen leképezhetők vele a barlangok és más kiálló ívek, emellett a technológia alapjai miatt viszonylag kevés erőforrásigénnyel még rombolhatóvá is lehet tenni a virtuális térséget. Általános probléma azonban, hogy a közelben lévő voxelek esetenként nagy kockákat eredményezhetnek. Hasonló a jelenség az aliasing problémához, mely a pixelekből felépülő képeknél fedezhető fel. Ennek csillapítására számtalan kis trükk létezik. Legegyszerűbb megoldás, ha a pixel színének meghatározásához nem csak a hozzá tartozó, hanem a környező voxelek értékeit is figyelembe vesszük.
Sugárkövetés
Az Intel Larrabee bemutatók visszatérő anyaga. A sugárkövetés, idegen szóval ray-tracing a raszterizálás riválisának tekinthető. Technikailag a ray-tracing előnye, hogy nem csak poligon alapú felületekkel képes dolgozni. A számítás szempontjából csak az az információ számít, hogy a fényforrásból kiinduló sugár hol metszi az adott objektumokat. A ray-tracing lényege, hogy a virtuális térben leírt környezetből a fénytan törvényeihez hasonlóan történik a képkockák leképzése. A fénysugarak útját a fényforrásból kell addig nyomon követni, amíg az a nézőpont irányában át nem halad a kép egyik pixelén. Közben persze rengeteg interakció történhet a virtuális térben, így a számításnál figyelembe kell venni, hogy a sugár milyen objektumoknak ütközik neki, és azok a fény mely részét tükrözik vissza, nyelik el vagy eresztik át. Ezen a ponton rögtön található egy nagy probléma: közel sem biztos, hogy a fényforrástól követett fény valaha is eléri a képernyőt. Éppen ezért teljesítmény szempontjából sokkal kifizetődőbb, ha az egész eseménysorozatot visszafelé követjük, azaz a képernyő minden pixeléből a nézőpontnak megfelelően indítunk sugarakat. Ezt backward ray-tracingnek nevezzük.
A feldolgozás menete röviden úgy zajlik, hogy a nézőpontból az adott pixelen át kilőtt sugarat vagy sugarakat (bilineáris vagy jobb minőségű szűrés esetén) követjük az eltalált felületig, majd a beesési pontból újabb sugarak indulnak ki a tükröződések, a fénytörések, illetve a fényforrások irányába. Ha az új sugarak által eltalált felület tükröző vagy áttetsző, akkor megint újabb sugarak indulnak ki az előzőeknek megfelelően. Rögtön észrevehető, hogy rengeteg kis sugár lesz a jelenetben. A számítás legkínosabb pontja a pixel végső színének meghatározása, ami a fényhez irányuló sugarak felülettel bezárt szöge alapján történik. Itt bizony a mai rendszerek számítási teljesítmény szempontjából elhasalnak. Arról nem is beszélve, hogy a különböző virtuális anyagok másképp reagálhatnak a fényre, így az árnyalási modelleket sem szabad figyelmen kívül hagyni. Alapvetően elmondhatjuk, hogy a ray-tracing a raszterizálásnál jobb képminőséget állíthat elő, de nagyságrendekkel magasabb teljesítményigénnyel rendelkezik. A manapság használt raszteres grafika a shaderekkel kiegészítve ugyan az esetek többségében egyfajta utánzott (csúnyán fogalmazva fake) eredményt kelt, de összhatásban rendkívül ütőképes.
Példák, konklúzió
Példákkal előállva az alábbi képet 14 darab Sony Cell processzor számolja (egy ilyen processzor található a PlayStation 3-ban) épphogy folyamatos sebességben, Full HD felbontásban.
Érdemes még az NVIDIA demonstrációját is megnézni, egy Quadro Plex 2100 D4 rendszer eredményét, amelyben négy darab G92-es (a GeForce 8800 GT alapja) chip teljesít szolgálatot fejenként 1 GB memória társaságában. A sebesség szintén folyamatos Full HD felbontásban.
A fenti két példához még mindenképp hozzátartozik, hogy a jelenet minden esetben statikus volt, ami messze nem felel meg a játékok által támasztott igényeknek. Egy interaktív, háromdimenziós program dinamikus jelenetet eredményez, amiben az objektumok helyzete folyamatosan változik. Ez megköveteli a használt térrendező fa újragenerálását, ami további időveszteség.
A valós idejű sugárkövetés a fellelhető információk alapján bizony nagy falat lesz még a belátható időn belül megjelenő hardvereknek is. Természetesen a raszterizálásnak is vannak határai, hiszen az eljárás hatékonysága egyenes arányban csökken a jelenetben használt poligonszám növekedésével. Ez a távoli jövőben még a ray-tracing előnyét is eredményezheti. Ha azonban időponthoz akarjuk kötni ezt a dolgot, akkor még mindig minimum egy évtizedes időtávot érdemes feltételezni. A Larrabee dokumentációkon nagy valószínűséggel azért kapott a technika kiemelt figyelmet, mert a nagyméretű chip feltételezhetően raszterizálásban nehezen veszi fel a versenyt a konkurens GeForce és Radeon modellekkel. Ez persze messze nem azt jelenti, hogy az Intel projektje kudarc lesz. Számtalan területen megvillanthatja még tudását a rendszer. Talán érdemes megjegyezni, hogy az előzetes beszámolók birtokában John Carmack (ID tech 6) és Tim Sweeney (Unreal Engine 4) éppen fejlesztett motorjai bizony visszatérnek a szoftveres renderelés vonalára. Célplatformnak a 2012-2014 körül megjelenő, következő generációs konzolok vannak megadva, de biztosra vehető, hogy a PC-n is lehet majd találkozni a két rendszerrel. Márpedig a szoftveres render a Larrabee malmára hajtja a vizet.
Larrabee technikai demó
Az elmúlt években sok változáson ment keresztül a számítógépes grafika fejlődése, és az elkövetkező időszakokban várhatóan hasonló ütemű fejlődésre lehet számítani. Egyértelműen látszanak egyes cégek úgymond reformtervei. Ettől függetlenül fontos szem előtt tartani azt, hogy a felhasználók többsége elsősorban nem a vásárlandó kártya mögött rejlő technológiát nézi, hanem a jelenben felmutatott értékeket. Ennek ékes példája volt az AMD Radeon HD 2900 nevű próbálkozása, mely közel másfél évvel megelőzve korát technológiailag fasírtot készített a GeForce 8800 sorozatból. A termék azonban mégsem lett sikeres, ami annak köszönhető, hogy nem tudott megfelelni az akkoriban támasztott követelményeknek. Persze az architektúra fejlettségére alapozó AMD az új termékcsaládokkal most kamatostul kapja vissza azt, amit akkor elveszített. Ha egy elvont párhuzamot vonunk a Larrabee rendszerére nézve, akkor láthatjuk, hogy az Intel grafikus elképzelése bizony négy évvel is megelőzheti korát, már ha a 2010-re ígért megjelenés valós adat. Ez nagyon meg fogja nehezíteni a kékek szereplését a GPU-piacon. Szerencsére a Larrabee kellően univerzális termék ahhoz, hogy több piacon is szerepeltessék. Érdemes megfigyelni, hogy az Intel elképzelései mennyire újszerűek, és az eddigi megoldásokkal összehasonlítva komolyan megváltoztathatja a jelenleg elterjedt logikai futószalagot. Ha a piac a kékek terveinek megfelelően formálódik, és kedvező körülmények alakulnak ki az eszközük képességeihez, akkor komoly sikerekre számíthatnak. Fennáll azonban annak az esélye, hogy megosztott lesz az új technológiákról a fejlesztők véleménye.
[Prohardver] A Khronos Group a GDC (Game Developers Conference) alkalmával bejelentette, hogy elkészült a WebGL 1.0-s szabvány, ami a háromdimenziós tartalmak böngészőben való megjelenítését kínálja. A platform az OpenGL ES 2.0 alapjaira épül, vagyis a natív támogatáshoz ez a felület kell, de a PC-k az OpenGL 2.1-es API-n keresztül is használhatók. A Google Chrome 9 már kezeli a WebGL-t, továbbá az érkező Firefox 4.0, Opera 11.50 és az új Safari számára sem jelent majd problémát a háromdimenziós tartalmak megjelenítése.
Megjelent a menedzselt DirectX azaz a SlimDX legújabb kiadása. A márciusi relase számos hibajavítást tartalmaz, tovább növeli a teljesítményt és az osztálykönyvtár stabilitását, valamint hiányzó funkcionalitásokat is pótol. Ezért a frissítés mindenképpen javasolt.
Bejegyzések
