2010. március 28., vasárnap

A jelen legjobb grafikus motorjai 1.

Egy újabb fantasztikus írást találtam a neten egy olyan témából, ami egyébként is kedves a szívemnek, olyan jó, hogy én ilyen érdekes cikket soha nem tudtam volna írni, szóval mindenkinek érdemes elolvasni! Köszönjük Zoenn.

Hol vannak már a pixelhuszárok az EGA monitorokon? A fejlődés nem áll meg, folyamatosan érkeznek a hardverizzasztó technológiai csodák a totális élethűség felé tartva. Jövőbe tekintő sorozatunk legújabb részében összeszedtük a jelen generáció legtutibb engine-jeit, azokat, amik már kivívták, illetve ki fogják vívni minden elismerésünket. - Írta: Zoenn
A pénz hatalom, a hatalom pedig azon fejlesztőstúdiók kezében van, akik tökéletesen össze tudják egyeztetni játékuk minden egyes paraméterét, ehhez pedig nem mindegy, hogy milyen játékmotort használnak. Elmúltak már azok az idők, amikor a fejlesztők maguk oldották meg a grafikai sallangmunkát is (tisztelet a kivételnek), a mai rohanó, piacközpontú világban sokkal gazdaságosabb, ha más gyártók licensz-megoldásait vásárolják meg maguknak, ezzel időt takarítva meg. Persze olyanok is akadnak, akik semmi pénzért nem hajlandóak megválni szabadalmuktól, kizárólagos egyediséget tartva fenn játékszériáiknak. Az engine fontos dolog: a kinézeten kívül felel a mesterséges intelligencia, scriptelés, hálózati kódok és a valós idejű fizika egyidejű működéséért. Mára már temérdek kiemelkedő megoldás van a piacon, amire könnyű, vagy nehéz fejleszteni, eme lista csupán tájékoztató jellegű, felhívnánk a figyelmet arra, hogy elmúltak azok az idők, amikor az Unreal és a Quake engine körül forgott a világ.

CryENGINE
Itt láthatod: Crysis, Crysis Warhead, Crysis 2, Aion: Tower of Eternity

A német Crytek hosszú évek megfeszített munkájának gyümölcseként, abszolút váratlanul hozakodott elő 2004-ben, a Far Cryjal, amely nyitott, trópusi szigetével, második világháborús japán erődítményeivel a dzsungel mélyén sokakat elkápráztatott. Pedig a megváltást a HL2-től és a Doom 3-tól vártuk, sok tekintetben a „távoli sikoly” felülmúlta a trónfosztóknak kikiáltottakat, persze, míg meg nem jelentek a szörnyek. Három évre rá a csapat megcsinálta még egyszer az üdvösséget, immár a CryEngine 2.0-val, mely egy kiadóváltást követően ért révbe a Crysis-ben. Szintén új követendő példa lett, a dögmeleg környezet mellett immár az űrlények ténykedésének megfelelően zimankóba fordult a térség, egy csapásra új távlatokat nyitva meg a motorral. Hóból soha legjobbat.


A jövő a CryEngine 3.0-é, amely már ténylegesen a motort megvásárló stúdiók kedvében jár testreszabhatóságával, MMO lehetőségeivel és DirectX 11 támogatással, de –ami a legfontosabb- immár Xbox 360 és PlayStation tulajok számára is elérhetővé téve a döbbenetes atmoszférát. Sőt, a többi megoldástól eltérően nincs is már szükség további bővítményekre, hiszen a csomag komplett: saját fizikával, audiorendszerrel és lekódolt animációkkal rendelkezik. Nagy ellenfele lehet a multiplatform engine-eknek a jövőben.

RAGE Engine
Itt láthatod: Table Tennis, GTA IV, Midnight Club: LA, Red Dead Redemption, LA Noire

Lehetett sejteni, hogy a Rockstar Games se éri be sokáig licenszelt technológiával, tény, hogy a GTA 3-ban, a Vice Cityben, San Andreas-ban, Bullyban és a Manhuntban látott Criterion’s Renderware jól kiszolgálta a karikatúraszerű bűnöző-szimulátorokat, de ideje volt a váltásnak, ahol még tovább emelik a mércét, az élő város minél realisztikusabb megvalósításával. Nem volt a piacon még alternatív megoldás, ezért hosszú évek megfeszített munkájának gyümölcseként született meg a RAGE (Rockstar Advanced Game Engine), mely a fejlesztők ping-pong szimulátorában debütált két éve, ám az igazi arcát csak a tavalyi GTA 4-ben mutatta meg.


A RAGE Engine mondhatni tökéletesen szimulálja a nagyvárosi ökoszisztémát és egy fiktív város vérkeringését, ahol az események követik egymást, ha baleset van, jön a mentő, a járókelők sem céltalanul mászkálnak, összetett MI gondoskodik mindenről (kisebb bakikkal persze), valós idejű időjárással, váltakozó napszakokkal, hatalmas látótávolsággal párosulva. Az Euphoria NaturalMotion-nel karöltve pedig minden karakter dinamikus animációt kapott, a bugyuta rongybaba-effektust elfelejthetjük, a Bullet névre keresztelt rendszer pedig a járművek, objektumok pontos, súlyt is figyelembe vevő fizikájáért felel.

Naughty Dog Game Engine
Itt láthatod: Uncharted: Drake’s Fortune, Uncharted 2: Among Thieves

Igazi, vérbeli PS3-ra optimalizált grafikus motor, híven bemutatva azt, hogy a japánok konzoljában mennyi potenciál rejtezik. Elég az E3-mas Uncharted 2-re gondolni, amely tükrözi, hogy a „Pajkos Kutyák” mi mindent tettek le az asztalra. A Jak & Dexter után, 2007-ben érkezett Unchartedben debütált a kódtömeg, kábító karaktermodellekkel és animációval felvértezve, valósághű fény-árnyék effektekkel és hollywoodi mozifilmekre jellemző átvezető animációkkal.


Már két éve dolgoznak a fejlesztők a Naughty Dog Game Engine 2.0-ás változatán, számtalan dinamikus tárggyal léphetünk kapcsolatba, tökéletesített fizikával, továbbgondolt környezet-animáció kölcsönhatással. Csiszolás történt az MI-n is és még probléma mentesebbé váltak a moziszerű átvezetők – játékmenet közti váltások, s immár teljes co-op és multiplayer támogatás is rákerült a specifikációk listájára. A Naugthy Dog-gal közreműködve, egy titkos Sony stúdió dolgozik továbbá az Edge Tools-szon, amely minden PS3-as játék látványos javításán ügyködik. Talán nem véletlenül, jó volt a Pedigree.

The Dead Engine
Itt láthatod: Dead Space, Dante’s Inferno

A Dead Space tavaly év végén minden feszültségkeltést imádó játékosban emlékezetes momentumokat hagyott. Jó döntésnek bizonyult az EA részéről, hogy a The Godfather után egy saját, egyedi frencsájzzal bízta meg az akkori Redwood Shores-t, s a remény hamarosan a pénzügyi statisztikákon immár konkrétumokra vedlett át, egy jövedelmező horror-sága ígéretes kezdő epizódjaként. Az idén májusban Visceral Games-nek átnevezett csapat nem ült a babérokon, már-már szellemi tőkeként tekintettek produktumukra, s mint az várható volt, a Dead Engine még korántsem lefutott lemez.


2006-ban az első Keresztapa játék után a fejlesztők kézhez kapták annak motorját, ideje volt kezdeni vele valamit. Mára már rá sem lehet ismerni, annyi változtatás történt rajta. Ebben a futurisztikus horror-kirándulásban mesteri fény-árnyék effektek és lélekbe hatoló hangok, valamint mindent elsöprő hangulat feledtette velünk az irányítás bakijait, melyek talán direkt nehezítették a Dead Space-t, mindenesetre így is célba értek. Az engine jövőre a pokolba költözik, Dante utazását felelevenítvén.

Unreal Engine
Itt láthatod: Unreal Tournament 3, Gears of War,
Mass Effect 1-2, Bioshock, Deux Ex 3, Mirror’s Edge,
Borderlands, Brothers in Arms: Hell’s Highway, Singularity,
Rainbow Six: Vegas etc. etc.

A valaha volt legtöbbet megvásárolt engine jól szimbolizálja az Epic Games mérföldkövét, hiszen ennyi fejlesztő nem tévedhet, ha már több millió dollárt leszurkoltak érte. Olyan kiadók is beruháztak ebbe a megoldásba, akik saját technológiákban sem szenvednek hiányt, de mégis mi a siker oka? Az hogy gyönyörű? Annyira könnyű rá fejleszteni? Nem, az Unreal Engine-nek lelke van. Immár a 3.0- ás verziónál tart, a fejlődése folyamatos, egészen az 1998-as debütálása óta. Akkoriban pl. a Quake 2 ellen küldték harcba, és jól megosztotta a játékos társadalmat, volt kinek ez, volt kinek az id megoldása jött be jobban. Egyértelmű, hogy nem tud senki levonni mélyre szántó következtetéseket, hogy az egyik fél felé billentse a mérleget. Mára már az UE egyet jelent a minőséggel és a könnyű fejlesztési lehetőséggel.


Az Epic Games mindig arra törekedett, hogy legyen szó bármilyen műfajról az akciójátékokon felül, a motorjuk mindig dübörögjön megfelelően, hogy az ügyfél és a végső produktum tulajdonosa is jól járjon. Többek tekintettek rá követendő példának, annak ellenére, hogy nem tökéletes. Bizonyára hallottatok arról, hogy miért kopaszok a Gears of War hősei: azért mert az engine nem képes a hajat teljesen valósághűen, minden szálra kiterjedően megjeleníteni, annak ellenére, hogy a külső és belső terek és a karaktermodellek más részei is briliánsak. A fejlődés pedig a 2012-re ígért negyedik eljövetelben mutatkozik meg újabb lépcsőfokként, minden eddiginél büntetősebb látvánnyal, bár nem hiszem, hogy ekkora sikert tud be majd a konkurencia megerősödése mellett. De ki tudja?
Folytatás következik...

2010. március 26., péntek

Lassan beérik az OpenTK projek


Lassan beérik az OpenTK projekt. Négy éves fejlesztés után végre megjelent az OpenTK 1.0 RC-1 verzió, ami azt jelenti, hogy nem kell sokat aludni már a végleges változatig. Hurrá!
De mi is az OpenTK? Az OpenTK vagy a teljes nevén az Open Toolkit egy C# nyelven írt szabad wrapper ami .NET környezetben (Mono-t is beleértve) teszi elérhetővé az OpenGL, OpenAL és OpenCL API-k használatát.

2010. március 23., kedd

OpenCL valamint GT300/RV870

Most, hogy próbálom magam elhelyezni az OpenCL világában egyre több információt és nagyon profi módon összeállított anyagot lelek fel magyar nyelven is és ez igen nagy örömömre szolgál. Most egy levelet sikerült elcsípni a Google segítségével. Remélem nem haragszik meg a szerzője, hogy belinkelem. Szóval olvassuk csak mert nagyon érdekes...

Üdvözlet mindenkinek,
István mondta, hogy szóljak pár szót az én gumicicámról, név szerint az OpenCL-ről. Aki esetleg már ismeretes a fogalommal annak a bevezető nem fog sok újat mondani, de az új kártyákról érdemes elolvasni az ismertetőket.
Az OpenCL egy új GPGPU eljárás/programnyelv/keret ami az Apple szárnyai alatt látta meg a napvilágot. A kezdeményezés lényege hogy egy egységes keretet adjon a GPGPU fogalomnak, ami könnyen kezelhető és mindenek felett platform független (a Mac OSX alatt léteznek a legrégebb óta működő compilerek). A kezdeményezés olyannyira ígéretesnek bizonyult, hogy felsorakozott mögé mindenki, akit az IT világban érdemes lehet megemlíteni (a lista irdatlan hosszú, minden nagy névvel rajta). A fejlesztés illetve szabványok jóváhagyója a Khronos Group (www.khronos.org). Az új keretrendszer roppant rugalmas és kényelmes is, nagyon jól struktúrált programok írhatók benne ahol jól elkülöníthetők és szinkronizálhatók a CPU-n és a GPUn végzett számítások. A keret egy-két említésre méltó tulajdonsága: a device-okon (lett légyen az GPU vagy CPU vagy akármi) lefutó programkód C szabvány nyelven írandó/írható, OpenGL hívások engedélyezettek device-ról (ergo kirajzoláshoz nem kell CPU-ra visszatérni sem buffert cserélni a CPU-val), a device-on futó kód (ezentúl kernel) runtime fordul (jól megírt program CPU-n lekérdezi a device képességeit (shader szám, elérhető memória, stb.), ehhez mérten paraméterezi fel a kernelt, majd ezekre optimalizálva fordítja le a kódot az OpenCL compiler. Így a jól megírt program minden kártyán optimálisan futhat, de más előnyei is vannak (bár kellemetlenségeket is okoz, ez tény)). Jól láthatóan a vörösök és a zöldek is nagy erőbedobással dolgoznak a fejlesztői környezeteiken és elsősorban az OpenCL támogatás az ami bővül minden egyes újabb verziónál. Szerintem mindenképp érdemes legalább egy pillantást vetni az új keretre, és megfontolandónak tartom a nagyobb lélegzetvételű új projektek ebben a nyelvben történő elkezdését. A cross-platform jellege, a gyártófüggetlensége, az OpenGL-el nem titkolt házasítása, a jól strukturáltsága, a C nyelv ismertsége és az óriási támogatása miatt szerintem futótűzként fog elterjedni a használatban. Aki jól tud CUDA-ban programozni, annak nem lesz nagy was ist das elsajátítania, mert a nyelv szintaktikája és megközelítése javarészt a CUDA-ra hasonlít. A nyelv felépítésében az NVIDIA volt a domináns.

Hol tart az OpenCL most?

NVIDIA nem kis lépéselőnyben van ATi-val szemben. NVIDIA-nak már van Mac-Linux-Windows alá CPU-ra és GPU-ra fordító compilere olyan segédprogramokkal, amik a kernelek debuggolását és optimalizálását is elősegítik (egy apró kényelmetlensége, hogy a kernelt nehezebb debuggolni, mert runtime fordul, ezért a fordítási hibák nem a program többi része mellett dobnak fordulási hibát. Ha az ember használ valami bonyolultabb fejlesztői környezetet, ami teszem azt támogat változókövetést, stb. akkor ezeket a funkciókat nem lehet használni a kernel debuggolására, mert a host processzortól független a program futása. Ezekhez a problémákhoz nyújt segítséget a VisualProfiler nevezetű okosság zöld oldalon). ATi nemrég fogadtatta el a teljes CPU támogatást natív 64-bites műveletekkel és gőzerővel dolgozik a GPU-s compileren. Amint ezt a csúfos lemaradását behozza az ATi, a zöldek elkezdhetnek rettegni.

Milyenek lesznek az új generációs GPU-k?

Megpróbálom az eddigi jól-rosszul palástolt vörös partiságomat leplezve objektíven tálalni a tényeket. Az NVIDIA GT300 kódú lapkája egy nem titkoltan GPGPU-ra épített chip. A zöldek ha félhivatalosan is, de bedobták a törülközőt az asztali szegmensbe szánt kártyákkal, elmondásuk szerint nem látnak már benne akkora piacot, és elsősorban az ipari felhasználás és az általános számításokra szeretnének koncentrálni. Az új kártyájuk DX11 alatt nyújtotta teljesítményt nem tartják olyan fontosnak. (Ez valószínűleg azért van, mert a 4xxx Radeon széria nagyon csúnyán elkente a GT2xx kártyák száját, és az ATi aggresszív árpolitikája ellehetetlenítette az NVIDIA-t a piacon. A korábbi 25%os piaci részesedésről 50% fölé emelkedett az ATi egyetlen év alatt. A vörösök megoldásai rendre felülmúlták ár/teljesítmény arányban a zöldekét. Az NVIDIA ilyen módon szeretne új piacon egyeduralkodóvá válni, ami teljesen érthető és logikus lépés.) Hardverben viszont nem kis lemaradással küszködik az NVIDIA, november végére saccolják az első GT300as kártya startját, ekkorra a vörösök már a Radeon 5870X2 kártyával fognak jelentkezni, aminek már a nevét is csak félve merem kimondani. A vörös tábor két hete dobta piacra az első RV870-es lapkával ellátott kártyájukat, a Radeon 5870-et és a kistestvérét, az 5850-et. Ezek nem titkoltan DX11re lettek bedrótozva, és ezzel érzésem szerint végleg megpecsételődött az NVIDIA sorsa a játékpiacon. A napvilágot látott tesztek azt bizonyítják, hogy az 5870 ereje DX11 támogatás nélkül is 85-90%-át hozza a korábbi kétmagos megoldásoknak (4870X2 és a GTX295), ami figyelemreméltó teljesítmény. Az NVIDIA új megoldása is várhatóan hasonló eredményt fog nyújtani, bár ez a DX11 hardveres elhanyagolása miatt (A DX11 legnagyobb újítását, a tesszalátor egységet nem implementálják, hanem a CUDA magok fogják emulálni) nem lesz ennyire látványos a játék teszteken. Az új üdvöskékről most is elmondható az a különbség, ami mindig is megvolt: a zöld kártyák memória, memória sávszélesség és textúrázó egység gazdagok, és ezt a jó tulajdonságukat a megszokottnál jobban erősítették, míg a vörösök annyira Shader processzor gazdagok, amennyire azt nem szégyellték (és textúrázó egységből is rápakoltak azért annyit, amennyi a korábbi generációs GTX295-ön van, csak hogy ne érje szó a ház elejét). Alább áljék pár hasznos link az érdeklődőknek, akik a kártyák újításairól szeretnének informálódni (rövidített verzió a linkek után):
Röviden a Fermi nevű GT300-as kártya egy nagyon memóriagazdag, gyorsítótáraiban bővebb, memóriasávszélben nagyobb megoldás lesz, mint a Cypress névre keresztelt 5870, és legnagyobb előnye ebben rejlik. A CUDA magokhoz rendelt cache 64kByte, szemben a Cypress 32kByte-jával. A CUDA magok csoportjaihoz rendelt L2 cache is figyelemreméltó méretű (768kByte), de ezt nehéz összemérni a Global Data Share-rel a Shaderek között, mert az egy 64kByte-os gyorsító tár a VRAMhoz. Az RV870 előnyei pedig a brutális számítási kapacitás (1600 shader proceszor egy magon. Egy db shader képességei a prohardveres oldalról olvashatók le) és talán a legfontosabb, hogy natív 64 bites felépítésűek a shaderek (A GT300 egy 32 bites architektúra, így következő generációváltásig biztos nem lesz fejlődés ilyen téren), ergo nem lassulnak a számítások fele tempóra 64 bites műveletek mellett. Az RV870-et a maga szerény 2,7 TFLOPS teljesítményével ha szembeállítjuk a beígért GT300 650 GFLOPS (64 bit) illetve 1,3 TFLOPS (32bit) teljesítményével, akkor azt hiszem elfogultság nélkül állíthatom hogy bármily szomorú is, annak ellenére hogy az NVIDIA kifejezetten az ipari és kutatási szegmenst akarja megcélozni a kártyáival, az ATi megoldások nagyon erősen meg fogják szorongatni őket (ha csuklóból nem verik el), különösen ha számításba vesszük azt is, hogy az ATi elsősorban az otthoni felhasználáshoz mérten fogja beárazni a kártyáit, nem pedig az ipari szegmenshez mérten. Objektivitásomat megtartva addig, hogy lenyeljek egy nagyon frappáns cikket (csak hogy miért vagyok vörös párti), véleményem szerint november-december tájára biztosra veszem hogy elkészül az ATi-s OpenCL compiler GPU-ra, és az akkor kijövő Radeon 5870X2, a maga előrelátható 5 TFLOPS-os 64 bites számítási kapacitásával félelmetes lesz. Én hobbi és napi szinten otthon vagyok a témában, onnan ez a tájékozottság. Ezután az ismertető után engem kár kérdezni, hogy milyengépet lenne érdemes venni. (Noha konkrét ötleteim azért vannak)
Nagy Máté Ferenc
2009. Okt. 8., Cs, 11:59:45 CEST

Szép új jövő? A GPGPU ma és holnap 2.

Bár mindenki sokat várt a GPGPU-tól, a gyártók nem siették el a támogatását. Az NVIDIA-nál sokáig csak a kiváltságosak érhették el a bétás CUDA GPGPU és PhysX csomagot. Ráadásul üzletpolitikai szempontból csak a G92-es maggal felvértezett GeForce 9-es szériánál használhattuk ki a GPU erejét – később persze minden GeForce 8-as kártyán engedélyezték ezeket a funkciókat. Ugyanígy az AMD-nél sem siettek a nagydobra verni a kártya ezen képességeit, a Folding@Home kliens is csak nemrég került bele a Catalyst telepítőcsomagba.
A döcögős indulás mégsem befolyásolja a GPGPU jövőjét, mert több kutatóintézet és nagy számítási kapacitással operáló vállalat a következő generációs szuperszámítógépeket „szuper gyors” számításokra képes grafikus vezérlőkkel teletömve képzelik el. Igaz, a grafikus vezérlőkön felül vannak még vetélytársak, ilyen például Playstation 3-ból ismert Cell processzor (amelyet már régóta alkalmaznak ilyen célokra, továbbfejlesztett változata pedig a kétszeres pontosságú feladatoknál is meglehetősen fürge), de az Intelnél is erősen készülődnek, hogy új fejlesztésükkel törjenek a babérokra. Összességében véve már nyugodt lélekkel kijelenthetjük, hogy a GPGPU-k jövője biztosított.


GPU PhysX vs CPU PhysX

A tudományos célokat szolgáló felhasználás minden bizonnyal még erősebb lapkák kifejlesztésére sarkallja a gyártókat, amelyek ugyan nemcsak a játékosok igényeit fogják szem előtt tartani, ám nagyobb számítási kapacitásuk révén a játékosok társadalma is profitálhat majd a folyamatból. Ismerve a grafikuskártya-felhozatalt, nem állíthatjuk, hogy túl sok gyártó van a piacon. Az AMD és NVIDIA mellett még a szebb napokat is látott S3 jelentkezett GPGPU-alkalmazással, ám a kis teljesítménye miatt nem várhatunk tőle csodát, illetve még a támogatottsága is kérdéses. Talán az Intel mozgolódása jelzi, hogy mégis milyen nagy piacot jelent ez a projekt a gyártók számára. Bár nagy a titokzatoskodás a téma körül, az Intel évek óta gőzerővel fejleszti a Larrabee kódnév alatt futó egységet, amelyet elsősorban grafikus magnak szánnak, ám egy egészen új elgondolásnak hála kiválóan alkalmas párhuzamosított számolásokra. A Larrabee érdekessége, hogy egységesíti a grafikus kártyáknál jelenleg is alkalmazott masszív párhuzamosított architektúrát az x86-os utasításkészletű processzorok tudásával (konkrétan egyszerűsített x86-os magokat felhasználva). Ez ily módon nagy átvitelt (pontosabban jobb sávszélesség-kihasználtságot) és remek programozhatóságot biztosít. A Larrabee felépítésének előnye, hogy nem csupán a DirectX és OpenGL grafikus API-kat támogatja, hanem a szoftveres úton megvalósított renderelésben is kiváló teljesítményt nyújt majd, amennyiben elkészül.

Fizika padlógázzal

Bizonyára sokan emlékeznek az Ageia PhysX kártyájára, amelynek külön bővítőkártyaként nem jósoltunk nagy jövőt, ám maga a technológia életképesnek bizonyult. Rontott a PhysX helyzetén, hogy már megjelenés után arról szóltak a hírek, hogy a GPU-k számítási kapacitása elegendő lesz a fizika számításához. Ez valóban igaznak bizonyult, amit az a tény is megerősített, hogy a kártya képességeit bemutatandó Cell Factor program megjelenítési sebessége a gyorsítókártya nélkül sem lassult be jelentősen. Azóta jelentős változások történtek, és a PhysX licenc az NVIDIA kezébe, a számítás pedig a CUDA-nak köszönhetően a GPU feladatsorába került, amit egy-két játékprogram valóban kihasznál. Ilyen például az Unreal Tournament 3, amelyhez léteznek nagyon látványos, direkt a fizikai gyorsítási képességre kihegyezett pályák – ezek már nem igazán futtathatók élvezhető sebességgel PhysX-gyorsítás – tehát CUDA-t támogató NVIDIA kártya – nélkül. Ugyanígy (számszerűsítve) látható a fizikai gyorsítás hatása a 3DMark Vantage CPU-tesztjében és még néhány programban, de egyelőre még nem számolhatunk be széles körű elterjedtségről.

Viszlát OpenGL, viszlát DirectX?

Ha már a jövő latolgatásánál és a szoftveres renderelésnél tartunk, érdemes megemlíteni, hogy az egész grafikus megjelenítéssel foglalkozó iparág látszólag elmozdult jól megszokott helyéről és a fix feladatok helyett az általános célú feladatfeldolgozást helyezi előtérbe. E tény részben a klasszikus értelemben vett – tehát csak az előre meghatározott feladatkör elvégzésére alkalmas – grafikus kártya halálát jelenti, amit már évekkel ezelőtt megjósoltak a játékfejlesztők. A kérdés csupán az, hogy mikor fog ez bekövetkezni, viszont jól látható, hogy a fejlesztések gyorsvonat sebességével robognak ebbe az irányba. Ennek következtében valószínűleg vissza fogunk térni a Direct3D és OpenGL API-k előtti időre, amikor a processzor még nyers erővel, szoftveres úton renderelt, csak most a CPU helyett a grafikus kártya fogja ugyanezen számolásokat elvégezni. A programozóknak és fejlesztőknek ez egyaránt azt jelenti, hogy valós programnyelvben kell (például az OpenCL) kódolni, míg ennek következtében a felhasználók számára teljesen mindegy lesz, melyik gyártó kártyáján játszunk. Egyetlen paraméter lesz ugyanis a döntő: a számítási kapacitás.
Ugyanakkor nem szabad azt hinnünk, hogy a programozásban a „szabad kéz” teljes mértékben megoldást jelent minden problémára. Nincs arra garancia, hogy az adott problémára a fejlesztő a legoptimálisabb megoldást találja-e meg, ezáltal esetenként nehezebb dolga is lehet, mint egy előre definiált és adott lehetőségekkel megáldott DirectX esetében. Arra sem számíthatunk, hogy az eddig uralkodó és jól bejáratott alkalmazásprogramozási felületek (DirectX, OpenGL) eltűnnek, de mindenképpen tartaniuk kell a lépést a változással – talán itt jön el ismét az az idő, amikor nem a DirectX-hez igazodik a grafikus kártyák tudása, hanem fordítva, mint a DirectX 9 előtti időkben.
írta Papp Gábor, 2009. február 09.

2010. március 22., hétfő

A GPU és CPU közös jövője 1.

A PC-k hőskorában még örülhettünk, ha grafikus kártyánk már elboldogult az SVGA-felbontással és az egyszerűbb játékokkal, hiszen akkoriban szó sem volt HD-ről vagy fotorealisztikus háromdimenziós megjelenítésről. Arról pedig álmodni sem mertünk, hogy a VGA-kártya egyszer a CPU babérjaira tör – márpedig most éppen ez történik.
Már a 90-es évek elején is sokat lehetett hallani a 3D-s gyorsítás fogalmáról. Ez a fogalom akkoriban az otthoni felhasználók körében kimerült az S3 Virge vagy az ATI Rage 3D szerény képességeiben, de az igazi lavinát a 3dfx Voodoo kiegészítő kártyája indította el. Ezt követően egymás után jelentek meg a gyorsabb változatok, majd az SLI-technológia. Időközben azonban az ATI és az NVIDIA is felnőttek ahhoz a feladathoz, hogy igazi 3D-s gyorsítással ellátott kártyát készítsenek – igaz, nem a 3dfx által megvalósított GLide API-vonalon, hanem az OpenGL- és a Direct3D-szabványnak megfelelően.
A Voodoo megjelenése óta eltelt 12 év alatt a grafikus magoknak – röviden GPU-knak – egyre komolyabb feladatokat kell végrehajtaniuk, ezáltal egyre több számítás terhet vesznek le a központi processzor válláról, már ami a megjelenítést illeti. Felépítés szempontjából a grafikus magok rendkívül nagyot léptek előre, komplexitás és gyártástechnológia tekintetében felvehetik a versenyt a CPU-kkal, míg bizonyos feladatoknál számítási kapacitásban már meg is előzték azokat.
Persze a grafikus megjelenítésért felelős lapka a felépítéséből adódóan sokáig nem helyettesíthette a processzort, azonban az új évezred elején debütáló NVIDIA GeForce 3 és az nFinite FX Engine névre hallgató programozható Vertex shader egység, valamint a shader modell első generációjának megjelenése magával hozta a programozható GPU-k korát. Ezt követően a GeForce FX és – az ATI oldaláról – a Radeon 9700 harmadik generációs GPU-k hoztak további fejlődést a shader modell 2.0 és a Vertex mellett már a programozható pixel shader egység megjelenésével.

GPGPU

Természetesen a GPGPU-nak rövidített általános célú (General Purpose) grafikus processzoroknál (GPU) sokkal többről van szó, mint a GeForce 3, az ATI Radeon 9700 vagy az NVIDIA GeForce FX esetében, ám az tagadhatatlan, hogy ebben a tekintetben ezek a lapkák szolgálnak technológiai alappillérként.
Az igazi áttörést a DirectX 10 által megkövetelt egyesített shader architektúra (Unified Shading Architecture) hozta meg, amely leváltotta a külön feladatokra specializálódott pixel és Vertex shader processzorokat. Az NVIDIA G80 és AMD R600 kódnevű lapkák voltak az első grafikus magok, amelyek az említett felépítésnek megfelelően készültek, akárcsak a jelenleg forgalomban lévő G92, GT200 és RV770 magok. Ezek a több mint száz univerzális feldolgozó egységet felvonultató magok olyan speciális párhuzamos adatfeldolgozási feladatokra is rávehetők, amiket korábban csak a CPU tudott kiszámolni. Ez azonban nem jelenti azt, hogy a CPU kiváltható a GPU-val, sőt, ez a közeli jövőben sem várható azon egyszerű oknál fogva, hogy ez az erősen párhuzamosított, grafikus megjelenítésre kihegyezett architektúra – legújabb generációs shader modell esetében – legfeljebb egyszeres pontosságú, 32-bites lebegőpontos számítások esetén használható hatékonyan.
Ezzel szemben egy 64 bites (kétszeres pontosságú) lebegőpontos számításnál már erősen csökken a teljesítmény és a CPU sokkal erősebbnek bizonyul, tehát még várni kell az igazi áttöréssel. Ez elsőre nem látszik a GPU-k adatlapján, így például az RV770 esetében sem. Ott hiába ámuldozott a szakma az 1,2 TFLOPS számítási teljesítményen – ez ugyanis csak az egyszeres pontosságú számításokra vonatkozik. A kétszeres pontosságra vonatkozó adatot az apró betűs részben olvashatjuk, ami csak 240 GFLOPS. Ráadásul a GPU végrehajtó egységei nagyon érzékenyek a kódra, ezért – és a lehető legjobb kihasználtság végett – az erre alkalmas környezetben (mint például az NVIDIA Cuda vagy az AMD CTM fejlesztőkörnyezete) a kódot külön kell optimalizálni és megfelelő nyelvre fordítani.

A jelen: AMD Stream és NVIDIA CUDA

A két nagy gyártó nem meglepő módon saját utakon kezdett bele a GPGPU-képességek kiaknázásába, ennek hála saját SDK-kat (rendszerfejlesztői készlet) fejlesztettek a programozók számára, de olybá tűnik, a CUDA nagyobb népszerűségre tett szert. A PhysX-képességek mellett olyan nagyszerű alkalmazásokat említhetünk meg, mint például a Badaboom konvertálóprogramot, a PowerDirectort vagy a PhotoShop CS4-et (Quadro kártyák esetében Premiere CS4 is) és még 155 más egyéb szoftvert – bár ezek nagy részének otthon nem vesszük semmilyen hasznát. Ezzel szemben az AMD nem adta közre pontosan, hogy mely programok támogatják a Stream-technológiát, de vélhetően jóval kevesebb, ami annak is betudható, hogy a projekt hivatalosan csak december óta létezik.


Real Time 3D Fluid and Particle Simulation and Rendering

Mivel az egész GPGPU-téma újdonságnak számít, a támogatottság jelenlegi helyzetéről nehéz többet elmondani. Jó jel, hogy a programozók gyorsan ráharaptak a témára, így további szoftverek támogatása várható még ebben az esztendőben.

OpenCL mindenekelőtt

Mint láthatjuk, a CUDA és Stream – illetve a CTM – legnagyobb hátránya, hogy nem kínálnak egyforma programozási nyelvet a fejlesztők számára, annak ellenére, hogy mindketten a C nyelvet használják. Ez körülbelül olyan helyzetet idéz elő, mint a 3dfx idejében a Glide és a Direct3D esete volt. Elképzelhető tehát, hogy lesznek támogatottsággal kapcsolatos viták. Ennek elkerülése végett a programozók kezébe olyan egységes, platformfüggetlen nyelvet és környezetet kell adni, amely kompatibilis mindegyik gyártó fejlesztésével és a magas mellett natív alacsony szintű hozzáférést enged közvetlenül a hardverhez és a memóriához, így megkerülve az OpenGL és DirectX API-kat. Ilyen például a teljesen ingyenes és nyílt OpenCL-szabvány, amelynek jogait az Apple birtokolja.


Az első OpenCL demó ami a GPU-t használja

A Khronos csoport neve alatt az Apple azonban számos nagyvállalattal (például Intel, NVIDIA, ATI, IBM, 3DLabs, EA) együttműködve közös erővel dolgozik a szabvány tökéletesítésén, mivel a leíró nyelv végleges változata rekordgyorsasággal (már tavaly decemberben) elkészült. Az OpenCL sokak szerint forradalmasítja a számítástechnikát és a lapkákban rejlő erőforrás-kihasználást – és ez alatt nemcsak a grafikus magokat értjük, hanem az akár mobiltelefonokba való processzorokat is. Úgy tűnik, a gyártók is hisznek az újdonság erejében, hiszen az AMD már a kezdetekkor teljes mellszélességgel az OpenCL támogatása mellett döntött, majd az NVIDIA is rábólintott a projektre, ám a CUDA sem merül feledésbe.
Bizonyára sokakban felmerül a kérdés, hogy ez mind szép és jó, de mit lép a Microsoft? Nos, a redmondi óriás sem ül a babérjain és továbbra sem kíván szakítani a hosszú évek alatt kemény munkával felépített DirectX birodalommal, így a 11-es változat része lesz a Compute Shader. Ez gyakorlatilag ilyen formában egy API-hoz kötött GPGPU-támogatás, szemben az OpenCL-lel, amely – mint említettük – független. Nehéz megmondani, melyik szabvány lesz a győztes, hiszen hiába érkezik későn a DirectX 11, a VGA-gyártók természetesen támogatni fogják, ezzel szemben az OpenCL egy jóval kötetlenebb eszközt ad a programozók kezébe, ami nem csak Windows alatt használható, hasonlóan az OpenGL-hez. Továbbá arról sem szabad megfeledkezni, hogy az egész GPGPU-s mizéria többről szól, mint a játékok látványvilága, tehát ez is az OpenCL malmára hajtja a vizet. Azonban még korai találgatásokba bocsátkozni...
írta Papp Gábor, 2009. február 09.

2010. március 21., vasárnap

Tao Start 08 - Glut szövegelés

Bármilyen programról is legyen, szó általában ki kell írni bizonyos dolgokat a képernyőre. A játékokban ilyen például, hogy mennyi töltényünk van, mennyi életünk maradt stb. Ezzel kapcsolatban rögtön eszünkbe jut, hogy mi lenne, ha mondjuk, egy 512×512-es textúrába megrajzolnánk az összes karaktert, amiből szöveget alkothatunk, majd kiíráskor ezeket a megfelelő módon bizonyos méretű négyzetekre húznánk. Ez nagyon jó ötlet, ezt használja például a Quake 3 a számok kijelzésére (életerő stb).

2010. március 20., szombat

Del Piero 300

Egy évvel ezelőtt egy olasz csatársztár spártai egyszerűséggel elért 300-as gólrekordjáról emlékeztünk meg, most egy másik fenomén (Il Fenomeno Vero) érte le ezt a mérföldkövet. Alessandro Del Piero a hétvégén belőtte 300., majd öt perccel később a 301. gólját a Juventusban, azaz Filippo Inzaghihoz hasonlóan duplázva érte el a rekordot, de a két csatár közti hasonlóság itt véget is ér.
Del Piero egészen más típusú játékos, mint a Tizenhatos Tábornoka. Nem befejező csatár, így még szebb eredmény, hogy ő is elérte a 300-as határt, de ő mellette számtalan gólpasszt is kiosztott a csapattársainak. A Juventus legendája gyakorlatilag mindent megnyert a torinóiakkal, az pedig, hogy 2010-ben is ő a Juve legjobb játékosa, egyrészt zsenialitásának bizonyítéka, másrészt a hitvány Juventus komoly kritikája.

Del Piero 300-301

Del Piero 35 évesen már nem gyors, de erényeit ugyanúgy állítja az imádott csapat szolgálatába, mint amikor 1993-ban először lépett pályára a Juventusban. A torinói óriásklubbal végigélte az elmúlt 17 év minden sikerét és bukását, soha nem került komolyan szóba, hogy elhagyja a klubot, még akkor sem, amikor a csapatot a bundabotrány miatt 2006-ban a másodosztályba száműzték. Ehelyett gólkirály lett a Serie B-ben is, majd egy évvel később a visszajutó csapattal megismételte ugyanezt az első osztályban is.


Juventus - Siena

A 300-as határt minden idők egyik leggyengébb Juventusában érte el, de a góljain egyáltalán nem látszik, hogy vele is szaladna az idő. Diego Maradona mondta róla, hogy „Del Piero igazából soha nem fog kiöregedni”, amit a hétvégén a 300.-kal kevésbé, a 301.-kel már sokkal inkább bizonyított: ehhez a lövéshez olyan tökéletes rúgótechnika kell, mint az övé.
Egy Del Piero-léptékű sztárnál komoly eredmény, hogy nincsenek ügyei, nem szerepel a pletykalapok címlapján. Titokban vette feleségül csapattársa, Nicola Amoruso húgát 2005-ben, akivel 1999 óta vannak együtt, két gyermekük született. Signora Del Piero a Siena elleni meccsen is ott volt a díszpáholyban, és "300" feliratú pólóban ünnepelte a csatár barátaival a történelmi gólt. Öt perccel később azt is bizonyította, hogy jól ismeri férjét: Del Piero következő góljánál az egész díszpáholy háttal a pályának ugrált, a pólójuk hátán a "301" felirattal.
Mártha Bence

Fulham - Juventus (4-1)

Története egyik legnagyobb győzelmét aratta csütörtök este a Fulham, amely hazai pályán 4-1-re elintézte a Juventust, így 5-4-es összesítéssel búcsúztatta az olasz csapatot, és bejutott az Európa-liga negyeddöntőjébe. A továbbjutást jelentő találatot Clint Dempsey lőtte, az amerikai azonban nem feledkezett meg a két gólt szerző Gera Zoltánról sem, aki szerinte bizonyította a klasszisát. Jonathan Zebina a Juventus rasszista szurkolóira panaszkodott, míg Alessandro Del Piero elmondta, meg sem fordult a fejében, hogy kieshetnek. Részletek...

2010. március 17., szerda

A Microsoft Office Outlook nem indítható el

Ma reggel a munkahelyemen, az egyik gépen nem indult el az MS Office Outlook 2007 levelező program. A következő hibaüzenetet dobta ki a felhasználónak:

A makrancos Outlook

Természetesen az elmondások alapján semmi sem került fel a gépre illetve le, „10 perce még működött most meg már nem” – jött a jól ismert szöveg. :) Persze vannak ilyen informatikai démonok, el kell fogadni. Első lépésként a klasszikus trükk, újraindítás. Hatástalan maradt. Na, ilyenkor jön a fejvakarás. Szerencsére a Google apó újra segített és ezer hála az internetes közösségnek, a megoldás a következő, parancssor indítása (cmd) és az Outlook mappában a következő parancs kiadása:

Outlook.exe /resetnavpane

Ezután megint minden kerek volt, újra működni kezdett a rendszer. Hogy mi váltotta ezt ki, nem tudom.

Sokoldalú egyoldalúság

Bizonyára senki sem kételkedik abban, hogy a Möbius-szalag egyfajta sík, hiszen papírlapból készült. Minden valamirevaló papírlapot pedig be lehet festeni valamilyen színre, mondjuk kékre vagy vörösre. De ha megpróbáljuk ezt a műveletet, végigfut a hideg a hátunkon: a Möbius-szalag esetében ez keresztülvihetetlen!
Ha az így kapott felületet elkezdjük kiszínezni, mondjuk matematika előadások unalmas pillanataiban az a meglepő dolog történik, hogy – megfordítás nélkül! – „mindkét oldalát” sikerült kifesteni. Valaki esetleg csak legyint rá, de a dolog matematikai jelentősége óriási. Most tegyünk fel magunknak egy kérdést: hány „éle” van ennek a csíknak? Ránézésre úgy néz ki, hogy kettő, de azért „számoljuk” csak meg. Húzzuk ceruzánkkal vonalat a szalag felső éle körül, és most döbbenünk rá, hogy a szalagnak nincsen kettő éle, csak egyetlen határvonala van, egy önmagába visszatérő görbe. Azaz topológiailag azonos a körrel. Ez a felismerés valószínűleg mindenkit megborzongat, így engem is, igyunk is rá egyet.

A rejtélyes Möbius-szalag és a Klein-palack döbbenetes elismerése késztette a matematikusokat: mindaz ami a világon van, topológiailag - a matematikának a folytonosság törvényszerűségével foglalkozó ága - két puszta számmal leírható!
Hölgyeim most önökön a sor, vegyenek a kezükbe egy darabka kelmét és vágjanak a közepébe egy kerek nyílást, és így van, lyuk keletkezett rajta vagy ahogy a matematikusok és Jenő mondaná tréfásan: a teljes valóság részleges tagadása. Most pedig fedjük be a lyukat egy foltdarabbal, úgy ahogy a waldenokat is díszítik az ügyes leánykezek. A lyuk lefedésére elegendő feltétel az, ha a folt kerülete csak kicsit nagyobb, mint maga a nyílás, nos, hát vegyünk tűt és cérnát és a foltanyag kerülete mentén varjuk körbe a lyukat. A folt eltűnik hamarosan és felmerül mindenkiben a kérdés, hogy vajon mindez mire volt jó? Nos, ez csak gyakorlat volt ahhoz, hogy megmutassuk, miként lehet egy lyukat úgymond „betömni”. A kérdés az, lehetséges-e ezt a bonyolult műveletet másként is elvégezni? A válsz nemleges, azaz egy lyukat másféleképpen elfedni nem lehet, ha csak nem akarjuk a lyuk széleit összehúzni a folt nélkül. Valóban igaz ez az állítás? A topológia kimutatta, hogy nem. Van egy másik módja is a lyukak betömésének. A lyukat eltüntethetjük úgy is, hogy hozzávarrjuk a Möbius-szalagot, annyi követelményünk van vele szemben, hogy a „kerülete” (hiszen már tudjuk, hogy a Möbius-szalag topológiailag azonos a körvonallal) kicsit legyen nagyobb, mint az eltüntetendő lyuk kerülete. Ne is habozzunk tovább, hölgyeim öltésről öltésre varrják hozzá a lyuk kerületéhez a Möbius-szalagot. Csaknem minden simán megy egészen az utolsó öltésig, de ott azonban valami furcsa dolgot tapasztalunk. A megmaradt foltrészt csak abban az esetben tudjuk odaölteni, ha egészen felhasítjuk az anyag széléig a kimaradt lyukrészt és utána a segítő hasítékot összevarrjuk. No, sebaj, áldozatok nélkül nincsen siker. Ha mindezzel végeztünk meggyőződhetünk arról, hogy a lyuk eltűnt, megszűnt létezni, de az eredetileg lyukas anyaggal valami furcsa dolog történt. Próbáljuk csak befesteni az egyik oldalát kékre másikat pedig vörösre. Nem fog sikerülni, hiszen a foltozandó anyag egyig oldala eltűnt, nemhiába mondják sokszor, hogy a nők igazi boszorkányok. Nemcsak hogy eltüntették a női ujjak a kelme egyik oldalát, hanem – ó, borzalom! – csak egyetlenegy határoló élet hagytak meg a kettőből. Ez lenne hát a geometria első fantomja.

A kávéscsésze és a fánk

Most egy ujjba kísérletet hajtsunk végre, vegyünk a kezünkbe egy gumilabdát, vágjunk rajta egy lyukat és a már fent ismertetett módon varjuk hozzá a Möbius-szalagot. Hosszabb-rövidebb húzogatás és nyomogatás után a végeredmény az ábrán szépen látható, amihez egy-egyszerűbb módszer segítségével is eljuthatunk. Most ne gumilabdát, hanem egy gumicsövet vegyünk a kezünkbe, vágjunk az egyik oldalára egy lyukat és a tömlő egyik végét a nyíláson át a tömlő belsejébe dugjuk, majd belül végighúzzuk, egészen a tömlő másik végéig, a két véget pedig kerületük menté összeerősítjük. Az így nyert tárgyat elég már csak néhányszor meghúzogatni, nyomogatni, hogy a kívánt formát megkapjuk, az úgynevezett Klein-palackot. Ez nem más, mint a mi csodás szalagunk térbeli változata. Ennek megvan a maga „belseje”, és hozhatunk benne sört is a sarki talponállóból, de sajnos szomjan maradunk. És ez nagy hiba! Hamarosan rájövünk ugyanis, hogy a palacknak sem „belseje” sem „külseje” nincsen, hiszen egyetlen egy síkból áll, ami a belseje és külseje is egyszerre.
Gondolom, sokakban felvetődik a kérdés, mi lenne, ha nem csak egy lyukat vágnánk a gumilabdánkra, hanem többet is, és közülük néhányat bevarrnánk a Möbius-szalaggal? A kérdés nagyon érdekes, ugyanis az a valami ami a műveletek során létrejön nyújtható és húzható is és így topológiailag sok azonos forma jöhet létre. Amikor ezt a matematikusok fontolóra vették arra a következtetésre jutottak, hogy valamennyi téralakzat topológiailag azonos azzal a gömbbel, amelybe néhány kerek lyukat vágtak, majd közülük néhányat Möbius-szalaggal bevarrtak. Ez azt jelenti, hogy a Földön bármilyen téralakzat leírható ezzel a módszerrel (a lyukak nagysága és a gömb mérete nem fontos) vagyis két pozitív számmal, ahol ez első kivágott lyukak számát jelöli, míg a második a Möbius-szalaggal bevarrt lyukakét! A Klein-palack topológiai leírása például: 1,1 (egy kivágott, és egy bevarrt lyuk).
Ezért nem lehet megkülönböztetni például topológiailag a kávéscsészét és a fánkot, hiszen a fánk képlékeny és ezért könnyedén átalakíthatjuk egyfülű kávéscsészévé anélkül, hogy bárhol is elszakítanánk. Tehát az a matematikus, aki képtelen megkülönböztetni a fánkot a kávéscsészétől, az nem más, mint a topológus.
Lám mi mindent tárt már fel a fürkésző emberi elme, csodálatunk nem véletlen, hiszen a matematika birodalma óriási. Így hát néma csodálattal, bölcsen – hiszen elfogyott a sörünk – és halkan csukjuk be ismét az ablakot amelyen át bepillantást nyertünk ezen varázslatos világba. Abba a világba, amely csupán a beavatottak előtt tárja fel titkait, de mégis hagy mindenki számára még felfedezésre váró vidéket, hiszen a felfedezés öröme oly nagyszerű! A kérdés csak az, hogy a kedves olvasó bevállalja-e a hozzá vezető fáradtságos utat: igen vagy nem?

2010. március 16., kedd

Tao Start 07 - Textúrázás alapfokon (II.)

Az előző textúrázási OGL példában a kockánk minden oldalára ugyanazt a textúrát feszítettük fel. Sokszor viszont az a feladat, hogy egy bitmap bizonyos részét használjuk csak fel. A most következő példa nagyon egyszerű, textúraként egy olyan bitmap-et használunk amely négy kisebb részből áll. Akkor most csináljuk azt, hogy a kocka két oldalára a teljes képet, a másik négy oldalára pedig csak a textúránk egy-egy negyedét húzzuk rá, így 4 oldalon különböző képeket kapunk.

Tao Start 06 - Textúrázás alapfokon (I.)

A legutóbbi OGL leckében a kockánk nagyon szépen lett kiszínezve, de mi van akkor, ha szeretnénk szöveget is rátenni? Például, hogy OpenGL. Gondolhatnánk, hogy megrajzoljuk poligononként, de ez elég durva munka lenne, hisz láttuk, hogy egy kocka megrajzolása is benne van két oldalban. A megoldás a textúrázás. Ezt úgy kell elképzelni (bár gondolom azért mindenki tudja, hogy mi is ez), hogy van egy képünk és annak bizonyos részét "ráhúzzuk" a poligonra.

2010. március 15., hétfő

Szabadság, szerelem…

1941. március 15.

„Milyen furcsa volt, mikor idejöttem Sopronba. Hogy megremegtetett az első foltos gruben. Elszorult a szívem, s a kérdések ezer tépázó karja csimpaszkodott lelkembe... Itt van-e? Enyém-e még? Nem felejtett-e el? Szeret-e?... Aztán keresni kezdtem kutató szemmel.”

RUZSINSZKY LÁSZLÓ: Tempus

Ott állam a Petőfi téren fekete, kopott grubenomban, nadrágom ráborult csillogó csizmámra. Erősen fújt a szél, és a hatalmas hópelyhek viharosan kavarogva zúdultak ránk, ezen a gyönyörű márciusi napon. Tele volt a tér bursokkal, a kis selmeci sapkák erdészeket, bányászokat rejtettek vegyesen, mind együtt voltunk…
Március talán a legszebb hónapok egyike. Nem csak a tavasz illata keveredi benne a szerelem szavával, hanem a szabadság rendíthetetlen hírnöke is. Mert bár legyünk jók és rosszak, bűnösök és áratlanok, az ember álmai és vágyai mindenhol egyformák a világon. Hiszem, hogy ami velem megtörtén ezen a napon, a mi márciusunkban, az bármely országban, és korban is megtörténhetett volna. Március a mi történelmünk, és ez olyan szép. Tetszik, vagy nem, emberek vagyunk, és születésünk pillanatában egyenlőnek és legfőbbként szabadnak születünk. Nem csupán a genetikai azonosság köt össze élőlényeket, hanem az együtt megélt élmények, a rokoni érzések, és a szeretett, mely őrök védőbástyaként emelkedik a legszentebb dolgok fölé, mint amilyen a család is. Vágyainkért, pedig az ősi ösztön harcra buzdít, és mi küzdünk, az utolsó csepp vérig, s ha elbukunk, azt is büszkén tesszük. Ez mindig is így volt, és így is lesz. De nem hiszem, hogy én akkor ezekkel törődtem volna egy cseppet is, hisz csak a szerelem járt a fejembe…
Ha megkérdezem magamtól mit jelent számomra március tizenötödike, azt felelem mindent. Hogy miért? A válasz oly egyszerű. Szeretni, élni, álmodni, fájni, könnyezni, csókot adni, és kapni, szabadság nélkül nem lehet. Engem is valami megfoghatatlan, és nemes érzés fogott el akkor ott, az aprócska téren. Hűvös volt, és az erős nyugati szél az ember arcába mart. Talán még az eső is szemerkélt, de akkor ott ezzel senki sem törődött. Egyedül álltam a tömegben, és csak őt kerestem. Nem mozdultam, csak a tekintetem járt fel és alá szüntelenül. Hosszú, és nehéz percek teltek el, míg végre megpillantottam őt, gyönyörű volt. Hajával könnyedén játszott el a szellő, arca piroslott a csípős hidegtől. Nem vett észre, és valamiért én sem akartam, hogy megpillantson. Tudtam, hogy ott lesz. Tudtam, hogy Selmec boldog, régi fészke lopta bele szívébe az akadémikus titkok és tradíciók fenséges erejét. Szerettem.
Úgy gondolom, minden kornak meg van a maga Petőfije. A miénknek is. Csak lehet, hogy nem ismerjük fel, hogy ő az. Március tizenötödike és utána minden nekem erről szól. Hogy az ember kényszer nélkül szabadon születik. Megismerése, hogy szerethessünk, hogy vágyaink legyenek, hogy nyomot hagyjunk: itt jártunk, ezek voltunk mi, ilyenek voltak álmaink, és tetteink. Élni és szeretni nem lehet szabadság nélkül! Hogy mikor szabad egy ember? Úgy hiszem elegendő, ha a szíve az, mert onnantól kezdve rabságban tartani nem lehet, és ha mégis, akkor szilaj vadlóként, habzó szájjal kitör, s hozza tűzbe akár a világot is. Ha a szív nem szabad, a könnynek nincs íze, a szerelmes ölelésnek és csóknak nincs varázsa. Hiszem, hogy ezzel az ünneppel is kincset kaptunk a múltból. Hogy mit kezdünk vele, nem tudom. Sokan talán elfecsérlik, de tudom őrökké élni fog.
Na, ne higgye senki, hogy nekem mindez akkor végigszaladt a fejemben, számomra csak ő létezett gondolataimban, és semmi más. Mindezt csak később értettem meg, és magam is meglepődtem rajta. Akkoriban még fájt minden. Fájt a távozás Selmecről, fájt édesanyám halála. El akartam menni, úgy éreztem semmi keresni valóm nincs ezen a helyen. De mikor szemébe néztem, és láttam csillogását, abban a pillanatban mindent máshogy gondoltam. Kíváncsi lettem a világra, a Földre, ahová születtem. Szerettem volna látni minden szépségét, és láttam is, egy kéznyújtásnyira. Látni akartam akkor az óceánokat, újra a tengert, a hegyeket, az embereket. Ha van csoda, akkor ez az, s ezt meg is tudom kivételesen nevezni, szerelem. Egy kis mikro univerzum, melynek képletét egyetlen fizikus, matematikus leírni nem tudja, a legcsodálatosabb elme sem tud felérni vele, s nincs gyógyszer mely jobb orvosság volna, az élet összes bajára. Minek is magyarázzam, hisz köztünk van, csak vegyük észre, könyörgöm. Én vele tanultam meg kicsit élni, szeretni, írni, és vele éreztem először a szabadságot is. Bárhol is fogok járni, bárki is lesz majd feleségem, kedvesem, én mindig hozzá fogok hazajönni, nála lesz az otthonom…
Egy selmeci diák

Az Ifjúsági Kör rendezte emlékünnepség a soproni Petőfi téren 1941. március 15-én. Elől az elnökség: Dr. Ormos Károly bánya-, Hibbey Albert erdő-, Hegybíró Béla bánya- és Sághy István erdőmérnök hallgató; mellettük Molnár János rendőrfelügyelő.

2010. március 14., vasárnap

A Khronos Group prezentálta az OpenGL 4.0 specifikációit

A Khronos Group a jelenleg is zajló Game Developers Conference alkalmával bemutatta a nyílt forráskódú OpenGL API 4.0-s verziójának újításait. A rendszer a nemrég debütált új generációs grafikus kártyákhoz alkalmazkodik, így a Radeon HD 5000-es termékcsalád már támogatja az API-t, sőt az NVIDIA is bejelentette, hogy a Fermi architektúrára épülő GeForce-ok is képesek lesznek az OpenGL 4.0-ra írt programok futtatására.

2010. március 11., csütörtök

Gumilepedő geometria

Itt az ideje, hogy képzeletbeli matematikai birodalmunkban másfele vegyük az irányt. Felejtsünk el most mindent, mindent, amit ábrázoló geometriából valaha is tanulhattunk. Mindent, ami mérhető, a hosszúságot, a szögeket, a kockát és más hasonló kellékeket. S ettől kezdve csak azt vegyük fontolóra, ami ezek után a geometriában megmarad. De marad-e még egyáltalán valami?
A választ erre a kérdésre Euler adta meg először, egy aprócska fejtörő által. A kelet-poroszországi Kö-nigsberg városa a Pregel-folyó két partján terül el. A folyóban két sziget található, amelyek egymással és a két parttal hidak kötnek össze. Lásd ábra.

A Pregel-folyó négy különálló részre bontja Königs-berg városát, ezek a részeket A, B, C és D jelöli a rajzon. Ezeket a városrészeket hét híd köti össze. A kérdés már adott, a válaszhoz viszont készítsük el a rejtvény egyszerűsített ábráját. Minden csúcspont-ból, ami nem a séta kezdő és végpontja, páros számú élnek kell kiindulnia. Valamennyi ilyen csúcsból tovább is kell tudni haladni ezért közülük az egy pontba befutókat párba kell tudnunk állítani. Azonban ebben az esetben minden csúcsból páratlan számú él fut ki, ezért ez nem lehetséges.
A königsbergi polgárok vasárnapi sétájuk során előszeretettel járták be a hidakat és vetődött fel bennük a kérdés, hogy vajon van-e olyan sétaút, amely minden hídon keresztülvezet, de mindegyiken csupán egyszer? A válasz nemleges, ne is törjük a fejünket tovább. Ezt Leonhard Euler bizonyította be 1735-ben. Euler döntő felismerése az volt, hogy a megoldáshoz vezető úthoz a szigetek és a hidak geometriai elrendezése nem vezet. A szigetek és a két folyópart reprezentálásához elegendő csupán egy-egy pont, amelyek között a hidak létesítenek kapcsolatot, és ezen kapcsolatoknál is csak az fontos, hogy az egyes hidak esetében fennállnak-e vagy sem. Ezek alapján próbálja meg mindenki kitalálni, hogyan is oldotta meg Euler ezt a kis fejtörőt.
Most képzeljük el fejben az ábécénk összes nagybetűjét minden díszíts nélkül. Ezek a betűk alakjukban különböznek egymástól, hiszen ezek alapján ismerjük fel őket írás és olvasás során, de éppen a betűalakot kell elfelejtenünk most! Hiszen a betűk, szögarányokkal, hosszúságokkal, számokkal leírhatóak, és mi ezeket a fo-galmakat nem is ismerjük, ne felejtsük el. Ezért az, I, J, U, M, N, V, C, L, W, S és a Z betűket azonosnak fogjuk tekinteni. Hogy miért? Ha megfigyeljük valamennyi betű egyetlen önmagába vissza nem térő vonalból áll, és másutt ér véget, mint ahol kezdődik. Hoppá! Észre se vettük és máris átléptük egy másik világba, hiszen a geo-metriától való elszakadás a topológia alapvető vonása.
Elképzelhetjük ezt úgy is, hogy valamely betűt felírunk egy rugalmas gumilapra, majd a gumilap húzko-dásával és nyomkodásával igyekszünk egy másik betűt alkotni a leírtból. Ez csak akkor sikerülhet, ha a kísérletet a topológiailag azonos betűk csoportján belül folytatjuk. Ezt a megfigyelésünket nem csak az ábécé nagybetűire alkalmazhatjuk, hanem más alakzatokra is kiterjeszthetjük.
A topologikus transzformációk precíz definíciójának kimondása Gauss-tanítvány Augustus Möbius ér-deme. Kezdetben a vizsgálatok szinte kizárólag a 2D-os felületekre szorítkoztak. Ekkor jött a nagy felfedezés, miszerint vannak olyan felületek, amelyeknek csak egy oldala van! A kedves olvasó is könnyen előállíthat ilyen csodálatos szerkezetet: elegendő, ha papírból csíkot vág ki és azt félfordulatnyit elcsavarja majd a két végét ragasztóval összeilleszti. Kész is a varázslat, előállt Möbius csodálatos szalagja! Egy újabb fantom került az olvasó kezébe, most a geometria birodalmából.

2010. március 10., szerda

Graphic Device Interface új verziója (GDI+)

Ha Windows-os alkalmazásunk grafikát használ, akkor ehhez elengedhetetlen volt a GDI használata. A Windows XP megjelenésével jelentős fejlődésen ment keresztül és immár GDI+ névvel szerepel az a grafikus interfész, melyen keresztül számtalan grafikai lehetőség tárul elénk. A GDI+ megvalósítása egyetlen GdiPlus.dll nevű állományból áll. Fontos tudnunk, hogy ezt nem csak a Windows XP alatt használhatjuk, hanem a Windows NT 4 SP6, Windows 2000, Windows 98 és Windows Millennium Edition operációs rendszereken is, így programjaink grafikai lehetőségeit kibővíthetjük ezen rendszerek alatt is, használjunk akár C, Basic, Delphi vagy bármilyen egyéb fejlesztői környezetet.
A GDI (Graphic Device Interface) egy programozók által elérhető Windows API. Célja, hogy az alkalmazások számára biztosítsa a grafikus támogatást. Olyan eljárások és függvények gyűjteménye, amelyek nagyban megkönnyítik a grafikus effektusok, formázott szövegek és egyéb objektumok megjelenítését a képernyőn és a nyomtatón egyaránt. Két alapvető részből áll: Win32 GDI és kernel-mode GDI. Az előbbi az alkalmazások, utóbbi pedig a kernel módú grafikus meghajtók (az eszközmeghajtók is használhatják) számára készült. A Win32 GDI közvetlenül meghívható programból a GDI32.DLL használatával (a %systemroot%\system32 könyvtárban található), míg a kernel-mode GDI-t főleg az opercációs rendszer hívja meg a WIN32K.SYS fájlból (helye ugyanott). Mindkettő egyik oldalról kapcsolatot teremt a fizikai eszközzel a másik oldalon ezt metódusokon, tulajdonságokon és eseményeken keresztül jeleníti meg, ezért a programozó számára eszköz-független környezetet biztosít (a Windows nem is teszi lehetővé a programoknak, hogy közvetlenül elérjék az eszközöket). Mi a GDI+ és milyen fő részekre osztható?
A GDI továbbfejlesztéseként, számos új technológiát magában foglalva megtalálható a Windows XP és Windows .NET Server (BizTalk, Commerce, Exchange, SharePoint Portal, stb.) operációs rendszerekbe beépítve és gyakorlatilag bármilyen fejlesztőkörnyezetben felhasználható. A GDIPLUS.DLL-en keresztül hívható meg. Windows XP előtti rendszerekben is használható, ehhez először a kliensgép rendszermappájába kell elhelyezni. A Microsoft ezt jogilag lehetővé teszi, sőt letölthető a honlapjukról a http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdkredist.htm címről vagy a www.microsoft.com oldalon a keresőbe írjuk be: GdiPlus.dll. Három alapvető részre bontható:
  • 2D vektor grafika
Magában foglalja az úgynevezett rajz primitívek (vonalak, görbék, Bézier görbék, alakzatok (téglalap, kör, stb.)) készítését, a képeket leíró matematikai függvényekkel.
  • Bitképek kezelése
Teljes körű a bitképek támogatása különböző színmélységben, felbontásban, formátumban. Ezenkívül a velük végzett fájlműveleteket is támogatja.
  • Tipográfia
Az elkészült ábrák különböző eszközökön való megjelenítésének lehetővé tétele a legjobb minőségben. Egy papíron megjelent rajz nem biztos, hogy egy képcsöves monitoron ugyanúgy néz ki, mint egy LCD kijelzőn (sőt biztos, hogy nem) vagy a nyomtatón. A GDI+ külön foglalkozik ezen problémák elhárításával. Mennyivel tud többet a GDI+, mint az elődje?

Színátmenet támogatás

Lineáris átmenetek készíthetők vele, amivel különböző alakzatokat lehet kitölteni. Meg kell adni a kezdő és végszíneket a köztük lévő átmenetet a GDI+ kiszámolja. Beállítható az is, hogy vízszintesen, függőlegesen, egy középpontból vagy valamelyik sarokból indulva történjen mindez.

Cardinal Splines

Egy vonal leírható referenciapontok halmazaként. Ez annyit jelent, hogy megadunk referencia pontokat, amelyeken a vonalnak át kell mennie. A pontok közti szakaszt a GDI+ fogja felépíteni, méghozzá görbékből, mindig figyelve a következő pont utáni irányt. Ezzel a technológiával egyenletesebb, élektől mentes szakaszokat kapunk, ellentétben azzal a megoldással, amikor egyenesek kötik össze a pontokat.

Independent Path Objects

A GDI-ben az objektumok létrejötte után a művelet befejezéséhez vezető út törlődött. A GDI+-ban nem, ezért több objektum is felépíthető az út ismételt létrehozása nélkül.

Transzformációk és mátrix objektumok

Megjelent a mátrix objektum egy hatásos eszközt adva a különböző transzformációk könnyű és gyors elvégzéséhez. Egy objektum összekapcsolható egy mátrixszal és képernyőn a kettő összesítéséből származó eredmény jelenik meg.

Skálázható területek

A területek (Regions) skálázhatók, elforgathatók és átalakíthatók lettek.

Alpha Blending

A Windows 2000-ben jelent meg először ez a technológia az operációs rendszer szintjén, most a GDI+ részéről teljes támogatást kapunk, hogy beépítsük saját alkalmazásainkba. A rajzolt objektum és a háttér közötti átlátszóságot jelenti. Például kirajzolunk egy teljesen hétköznapi Windows ablakot a képernyőre, de látszik alatta az Asztal és a rajta lévő ikonok. Természetesen az átlátszóság mértéke állítható.

Több képformátum támogatása

A GDI+ Image, Bitmap és Metafile osztályai lehetővé teszik a képek mentését, betöltését és különböző formátumokra való átalakítását. A következő képformátumok támogatásával: BMP, EMF, GIF, JPEG, EXIF, PNG, TIFF, ICON, WMF.
A C# Software Online weboldalon gyakorlati példák, mintaprogramok találhatók a GDI+ használatáról.

2010. március 8., hétfő

Direct2D - Ismertető

Egy havi kihagyás után újra belevetettem magam a fejlesztésbe - máshoz úgyse nagyon értek - közbe pedig megjelent néhány olyan új technológia, amely felkeltette az érdeklődésemet. Erről adnék most itt egy rövidke kis áttekintést. Tehát most a Windows-on elérhető 2D-s prezentációs technológiák összehasonlításáról lesz szó. Windowson jelen pillanatban elérhető három darab 2D-s prezentációs technológia:
  • GDI (Graphics Device Interface)
Az alkalmazások javarésze (beleértve a MS alkalmazásokat), még ma is ezt használja. Az igazság az, hogy a GDI alapvető hiányosságoktól szenved. Nem támogat magas minőségű rajzolást. Nincs támogatás élsimításhoz (anti-aliasing), aminek köszönhetően a ferde vonalak csipkézettnek tűnnek. Mi több, nincs teljes támogatás áttetszőség (transparency) kezeléshez, úgy mint támogatása a félig áttetsző (semi-transparent) ecseteknek (brushes) és tollaknak (pens).
A GDI-t nem párhuzamos feldolgozáshoz tervezték és emiatt egy kevésbé hatékony lokkolási mechanizmustól szenved. A Windows 7-ben és Windows Server 2008 R2-ben újratervezték ezt a lokkolási mechanizmust, hogy legyen sokkal kifinomultabb, szemcsésebb, de a teszteredmények azt igazolják, hogy az új Direct2D még mindig jobban skálázódik.
Egy másik probléma, hogy a GDI handle-k totális száma limitált 10240/process és 65536/session-re, mert belsőleg a Windows egy 16 bites egész számot használ, hogy tárolja az indexeit ezeknek minden egyes session-höz. A stock objektumok kikerültek a limitációból. Az egyetlen út áthidalni ezt a limitet egy új session beiktatása, de ez növeli a memória használatot.
  • GDI+ (Graphics Device Interface Plus)
A fő probléma a GDI+-al szerver oldali forgatókönyveknél az, hogy nincs hivatalos támogatás futtatni Session 0 izolációs szinten. Ez annyit tesz, hogy függvények, amelyek próbálnak kapcsolatot teremteni a megjelenítő eszközzel, hibákat fognak kapni, mert nem engedettek Session 0 izolációban. Egyéb függvények is elbukhatnak, mert még ha nem is tűnik úgy, hogy a függvény kapcsolódik a megjelenítő eszközhöz, használhatna valamilyen kerülő utat, ami tiltott.
Máskülönben a GDI+ támogatja az anti-aliasing-et és alpha-blending-et egyaránt, tehát minőségbeli problémái nincsenek mint a GDI-nek, viszont vannak teljesítménybeli problémái továbbra is a lokkolási mechanizmus miatt, és ez az új Windowsokban (Windows 7, Windows Server 2008 S2) sem lett tovább fejlesztve.
  • Direct2D
A Direct2D a Windows 7 részeként megjelenő új 2D-s prezentációs technológia, részben az elavult GDI/GDI+ leváltására. Nemrégiben portolásra került Windows Vista alá is, így a Windows Vista Platform Update keretében mindenki gépére felkerülhetett. Sajnos hozzá kell tegyem, hogy Windows XP-re nem nagyon várható ez a technológia, ugyanis a Direct3D 10 tetejére épül, ami pedig erősen támaszkodik a Vista óta bevezetett új driver modellre, ennélfogva nem valósítható meg az XP-re történő visszaportolás. Megjegyezném, hogy az új Internet Explorer 9 is a Direct2D-t fogja használni weboldalak megjelenítéséhez, használva a GPU erejét az oldalak rendereléséhez.
Technikailag a D2D többszálúság (multi-threading) és Session 0 tudatában lett tervezve az elejétől fogva. A legtöbb többszálazott esetben a D2D lehet szabadon lokkolható használva több egyszálú factory-t, egyet minden egyes szálhoz. Egy factory széles lokkolás mindenképp lesz, ha az adott programnak használnia kell a többszálú módját a factorynak, de ez sokkal szemcsésebb, kifinomultabb, mint a GDI és GDI+ esetében. A hatása a lokkolásnak elhanyagolható és nem exponenciálisan növekszik a szálak számával.

A GDI összehasonlítása a Direct2D-vel

Még mielőtt kitérnék a címben szereplő témára, erősen érzékelhető a neten utánaolvasgatva, hogy eléggé ketté osztja a társadalmat ez a technológia. Egy Direct3D-s játékfejlesztő, akinek a kisujjában van az egész D3D, nevet egyet és azt mondja, hogy én megcsináltam ugyanazt a demot Direct3D-vel 500 sorba, amit a Microsoft Direct2D-vel 800 sorba. Természetesen ez minden további nélkül lehetséges, hiszen a D3D nem zárja ki, hogy 2D-ben programozzunk, sőt mivel a D2D a D3D tetején csücsül, ez fordítva is igaz. De mindazonáltal fontos megemlíteni, hogy a D3D-n túlmenően a D2D garantálja az interoperabilitást a GDI-vel is. Tehát ez nem igazán D3D fejlesztőknek kitalált technológia, hanem sokkal inkább a GDI/GDI+ fejlesztőket próbálják kimozdítani abból az árokból, amibe már hosszú évek óta bele vannak kényszerítve. Ennélfogva ezzel a cikkel csak bizonyos mértékig tudok egyetérteni. Abban teljesen igaza van az írónak, hogy bizonyos szinten feleslegesen túl lett komplikálva, illetve ugyanazokat a konvenciókat követi, mint a D3D, pl. rendering_2d(), ami valóban zavarba ejtő lehet egy GDI/GDI+ fejlesztőnek elsőre, de ez valójában a GDI koncepcionális megvalósítása körül volt igazából elszúrva. Nincs mese, néhány dolgot újra kell tanulni, értelmezni, de annyira nem vészes.

A GDI és a Direct2D is azonnali módú 2D-s renderelő API és mindkettő ajánl bizonyos fokú hardveres gyorsítást. Ez okoz némi zavart - ugyanis akkor miben különböznek ezek egymástól? Miben hasonlítanak egymáshoz? A Direct2D teszi a GDI-t gyorsabbá? Miben különbözik a Direct2D hardveres gyorsítása a GDI hardveres gyorsításától? Ezekre keressük most a választ.

Miben különbözik a Direct2D és GDI-től?

A Direct2D és GDI jobbára a részletekben térnek el, abban ahogy renderelik a képet, ahogy elérik a megjelenítő hardvert, illetve némileg különböznek tervezési elvekben is.
A GDI opaque (átlátszatlan) és aliased geometriákat (paths, lines, stb.) renderel. Továbbá tud renderelni aliased és ClearType szöveget és támogatja a transparency blendinget (áttetszőségi keverést) az AlphaBlend API által. Bárhogy is, az áttetszőség kezelése inkonzisztens. A legtöbb API egyszerűen mellőzi az alfa csatornákat, némelyik pedig használja azt. Talán az egyik legfontosabb dolog, hogy a GDI renderelés nem térképezi fel könnyen, hogy egy modern GPU mit renderel a leghatékonyabban a 3D-s részén a renderelési motornak. Például a ROP-ok (Raster Operations Pipeline) nem lehetnek megvalósítottak a keverési szakászában a GPU-nak. Bárhogy is, az alfa lehet. Egy másik példa, a Direct2D aliased vonalai úgy lettek tervezve, hogy legyenek implementáltak egyszerűen mint két darab háromszög, amik a GPU-ban renderelődnek. A GDI garantálja hogy a Bresenham féle vonal rajzolási algoritmus használt.
A Direct2D opaque (átlátszatlan), transparent (áttetsző), aliased és anti-aliased (élsimított) primitíveket renderel. Szigorúan garantálja az elfogadását és renderelését áttetsző tartalmaknak. Lehetővé teszi tervezni modern felhasználó felületeket, illetve enged renderelni minden primitívet használva hardveres gyorsítást. A Direct2D azonban nem egy tiszta szuperhalmaza a GDI-nek, a primitívek indokolatlanul lassúak volnának ahhoz, hogy implementálva legyenek egy GPU-n, amik nem a Direct2D-ben jelennek meg. Ez az egyik válasz. Tehát a Direct2D nem segít növelni a teljesítményét a GDI-nek, mivel a GDI nem használ Direct2D-t. Ugyanakkor a Direct2D használ(hat) GDI-t (interoperabilitás a régi programokkal).
A Direct2D a Direct3D-t használja, hogy elnyerje a hardveres gyorsítást. A Direct3D egy user modú display driver-t használ, amely becsomagolja a parancsfolyamokat (command streams). A Direct3D leküldi ezeket a parancsfolyamokat és erőforrásokat kernel módba a hardvernek feldolgozásra. Egy nagy előnye ennek az architektúrának, hogy egy alkalmazás tudja használni mind a Direct2D, mint a Direct3D képességeit együtt, hiszen a Direct2D is a Direct3D tetején ül.
A Windows NT 4 óta, a GDI kernel módban fut. Az alkalmazás hív GDI-t, amely aztán hívja a kernel módú hasonmását. Ott, a GDI átpasszolja a primitíveket a saját driver modelljének. Ez a driver aztán elküldi az eredményeket a globális kernel módú display drivernek. Kb. a Windows 2000 óta a GDI és a GDI driverek egy független térben futnak a kernelben, ami "session space"-nek hívott. Egy session címtér létrejön minden bejelentkezett session-höz és mindegyik példányához a GDI-nek, amik futnak függetlenül ebben a különböző kernel módú címtérben.

Mi a különbség a GDI és Direct2D hardveres gyorsítás között?

A legfontosabb különbség, hogy a Direct2D a Direct3D tetejére rétegződik, míg a GDI-nek van egy saját független megfogalmazású driver modellje. Ez a driver modell (GDI Device Driver Interface vagy DDI) megfelel a GDI primitíveknek, míg a Direct3D driver modell megfelel amit a 3D-s hardver a saját grafikus processzorában (GPU) renderel. Amikor a GDI DDI először volt definiált (a 90-es évek elején), a legtöbb megjelenítést gyorsító hardver a GDI primitíveket célozta meg. Idővel, bárhogy is, sokkal de sokkal nagyobb hangsúly helyeződött a 3D-s játék gyorsításra és kevesebb az alkalmazás gyorsításra. Ennek következtében a GDI DDI nem lett implementálva a megjelenítő driverek által, s végül, a BitBlt művelet lett egyedül igazán gyorsított és a legtöbb egyéb művelet nem.

Növekedése a megjelenítő driverek összetettségének és méretének

Időközben a képernyőillesztők egyre összetettebbé váltak, ahogy egyre jobban növekedett a komplexitása a driver 3D-s részének. A magasabb komplexitású kód hajlamos elkövetni több hibát, ezért elvárás volt áthelyezni a driver-t user módba, ahol nem okozhat rendszerújraindulást. Mint ahogy a következő ábrán is látható, a megjelenítő driver ketté-osztott egy komplex user módú komponensre és egy egyszerű kernel módú komponensre:


Nehézség a sessionök és a globális kernel címterek szinkronizálásában

Windows XP-ben egy display driver két különböző címtérben létezik, session space és kernel space. Néhány részének a drivernek szükséges válaszolni plug & play és power menedzsment eseményekre. Ez az állapot szükséges, hogy szinkronizálva legyen a driver állapotával a session címtérben. Ez egy kemény feladat és a megjelenítő driverek hajlamosak hibázni, amikor megpróbálják kezelni ezeket a különböző címtereket.

Az összetett asztal

Az összetett asztalnak szükségelt a GDI, hogy képes legyen renderelni a felületre, amely aztán renderelve lett a Direct3D által a megjelenítőre. Ez nem lehetett könnyedén megvalósítható az XP driver modelljében, mert a GDI-nek és Direct3D-nek párhuzamos driver stack-je volt.
Ennek eredményeként, a Vista-ban a GDI DDI display driver megváltozott és implementálva lett Microsoft szállított driverek által, névlegesen Canonical Display Driver (CDD). A GDI renderelt egy rendszermemória biképre. Az ún. piszkos (dirty) régiók voltak használva frissíteni a videó memória textúrát, amelyet az ablakmenedzser használt, hogy összeállítsa a desktop-ot.

GDI renderelés a Windows 7-ben

A fő hátránya a Windows Vista driver modelljének az, hogy minden GDI ablakot megkellett tartani mind a videó memória felület, mind a rendszermemória felület által. Ezek az eredmények a rendszermemóriában válnak használttá minden nyitott GDI ablakhoz.

Ezen okokból a GDI megváltozott újra a Windows 7-ben, hogy biztosítsa, ne legyen szükség rendszermemória-felületre ablakonként. Mivel a GDI rendereléshez szükséges olvasni, módosítani, írni a rendszer-memória felületet, és mivel a CPU nem tud direktbe hozzáférni a videó-memóriához, a GDI módosítva lett, hogy rendereljen egy részébe a rekesz memóriának. A rekesz-memória lehet frissített a videó-memória felületből megtartva az ablak tartalmakat. A GDI visszatud renderelni a rekesz memóriába, és az eredmény aztán lehet visszaküldött az ablakfelületre. Mivel a rekesz-memória címezhető a GPU által, a GPU tudja gyorsítani ezeket a frissítéseket a videó-memória felületre. Például, a szöveg renderelés, BitBlt közös ROP-al, AlphaBlend, TransparentBlt, StretchBlt, mind gyorsított ebben az esetben. Továbbá, néhány művelet megkerülheti a rekesz-memóriát teljesen, úgy mint BitBlt, ColorFill.

Összehasonlítása a Direct2D és GDI gyorsításnak Windows 7-ben

A Direct2D és a GDI mindketten azonnali módú renderelési API-k, és mindkettőről elmondható (legalábbis részben), hogy hardveresen gyorsított. Akárhogyan is, van számos különbség közöttük.

Helye az erőforrásoknak

A GDI az erőforrásait részleges bitképekben kezeli, rendszer-memóriában alapértelmezésben. A Direct2D az erőforrásait a videó-memóriában, a megjelenítő adapterében kezeli. Ez azt eredményezi, hogy amikor a GDI-nek szükséges frissíteni a videó-memóriát, akkor ezt mindig a fizikai busz felett kell végrehajtani, kivéve ha az erőforrások már történetesen belemásoltak a rekesz-memória szegmensbe, vagy ha a művelet kifejezett lehet direktbe. Egy kivétel itt a bitképek, amelyek a CreateBitmapFromDxSurface API-val vannak létrehozva, amely rezidens a videó-memóriában. A Direct2D viszont egyszerűen átfordítja az ő primitívjeit Direct3D primitívekké, mivel az erőforrások már a videó memóriában vannak.

Metódusa a renderelésnek

A GDI egy nagy részét a renderelésnek a rekesz-memóriába teljesíti, használva a CPU-t. Direct2D-ben van egy translator (fordító), ami átfordítja az ő API hívásait Direct3D primitívekké, az eredmény aztán renderelt a GPU-n. Néhány GDI renderelés is a GPU-n teljesített, amikor a rekesz-memória átmásolt a videó-memória felületre, reprezentálva a GDI ablakot, vagy amikor ez lehetséges.

Méretezhetőség

A Direct2D renderelési hívásai mind független parancsfolyamok a GPU-ba. Minden Direct2D factory reprezentál egy különböző Direct3D eszközt. A GDI egyetlen parancsfolyamot használ minden alkalmazáshoz a rendszerben. A GDI metódusok eredményezhetnek felesleges költséget néhány amortizációjában a GPU és CPU renderelési kontextusnak. A Direct2D megközelítésében kevésbé szükséges a szerializáció a független parancsfolyamok között.

Elhelyezkedés

Természetesen, a Direct2D teljesen user módú, beleértve a Direct3D-t és Direct3D driver-t is. A GDI két módot használ, egy része a session térben van kernel módban, az API felülete pedig user módban.

Hozzáférhetősége a hardveres gyorsításnak

A GDI hardvergyorsított XP-n és Windows 7-en, amikor a DWM fut és amikor a WDDM 1.5 driver használatban van. A Direct2D hardvergyorsított minden körülmény között és bármilyen WDDM driveren, függetlenül attól, hogy a DWM használatban van-e. A Direct2D Vista-ra szintén visszaportolt, ugyanakkor érdemes megjegyezni, hogy a GDI Vista-n mindig a CPU-n fog renderelődni.

Prezentációs modell

Amikor a Windows először tervezve volt, nem volt elég hatékony a memória, hogy minden ablak tárolt legyen az ő bitképében. Ez azt eredményezte, hogy a GDI mindig logikailag direktbe a képernyőre renderelt, változó kivágású régiókat alkalmazván biztosítva azt, hogy ne rendereljen az ablakon kívülre. A Direct2D követ egy modellt, ahol az alkalmazás renderel egy háttér bufferba és az eredmény automatikusan tükrözött ("flipped"), amikor az elkészült a rajzolással. Ez engedi a Direct2D-nek, hogy kezeljen animációs jeleneteket folyékonyabban, mint a GDI (és villogás-mentesen).
Fontos kihangsúlyozni, hogy a GDI ezt a fajta hardveres gyorsítási eljárást csak a Windows 7 óta támogatja. Ugyanakkor érdemes figyelembe venni azt is, hogy a Direct2D XP-n majdnem biztos, hogy nem lesz elérhető. Szóval, aki arra adja a fejét, hogy framework nélküli, cool grafikával ellátott, GPU gyorsított, XP kompatibilis szoftvert készítsen, továbbra is a Direct3D 8/9 a járható út. Ugyanez igaz a játékfejlesztőkre is, mivel viszonylag elég nagy a tesztek alapján az overhead a D3D-hez képest. Viszont akinek adott a lehetőség, hogy Vista/Win7-re fejlesszen natív alkalmazásokat, annak mindenképp érdemes számolnia ezzel és végképp letenni a GDI/GDI+-ról.

Janka János