Lehetne valamivel gyorsabb, de szerintem akkor is közvetettebb a feldolgozás menete, mint konzolon, ott ugyanis nincsenek korlátozva az átviteli sávok, közvetlen kapcsolat van GPU-CPU között, ami az adatmozgatást megkönnyíti, ráadásul nem kell annyi, és olyan méretű driver minden eszközhöz, hanem mindent megpróbáltak a gyorsaság érdekében hardveresen implementálni. (pedig ott is van valamiféle API, amin keresztül elérik a hardvert, nem hiszem, hogy assembly-ben írnák a grafikus motort) Egy PC-n egy nagy étvágyú oprendszer is ott figyel, míg konzolnál max. egy 20 megás FW van, ami a menürendszert tartalmazza és éri el a perifériákat/memóriakártyát/vinyót. Ezért van szerintem az, hogy hiába egy erős gép X1950 XTX-szel, nem fogja úgy futtatni pl. a Star Wars TFU II-t, mint egy X360, sem egy GeForce 3 Ti a Halo 2-t.

Egyébként nem is tudtam, hogy változott a VLIW minta a 6-os sorozatú radeonon. Ezek szerint a szuperskalár feldolgozóegységek csak 3 komplex+1 egyszerű utasítás végrehajtására képesek? Lehet, hogy ezzel is gyorsítani akartak a folyamaton, hogy gyorsabban kódolja le a mintákat a driver.

Ha natívan programozod a hardvert, akkor nincs szükség driverre. Ahogy Johan Andersson mondta a GDC11-en: The best graphics driver is no graphics driver.

Igazából ezt az egész dolgot nem Richard Huddy találta ki. Már régóta téma ez. Richard Huddy csak hangot adott ennek, hogy lássa a reakciókat.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Az OpenGL-t kifejleszti? A mostani kártyák melyik opengl verziót támogatják?

[ Szerkesztve ]

Hi, i'm new to APHEX TWIN, so i was wondering how much the IQ requirements was to enjoy his stuff. and understand all the underlying themes, because its really complex stuff. I have IQ of 119 but i heard that you need atleast 120 is it true?

A Khronos fejleszti. A mai generációk az OpenGL 4.1-et támogatják.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Magyarul a PC-s kompatibilitás öli meg saját maga elől a PC-s játék ipart. Vicces, és egyben eléggé furcsa helyzet. Lehet ezért az üzletpolitikát okolni, de a PC legnagyobb ellensége saját maga. Úgy lett kifejlesztve, hogy kompatibilitás terén maximálisat nyújtson és ez is lesz a veszte a PC-s játék iparnak.

PS4

Nem világos, hogy itt egy eredendő gondról van szó, vagy csak olyanról aminek megoldása nagyon nagy befektetés lenne. Mert, nem lehetne kitalálni valami magas szintű GPU programozási nyelvet, amit a videókártya driver a program első indulásakor "natívra" fordít? Akkor aztán olyan hw specifikus trükköket alkalmaz, amit csak akar. Tisztába vagyok vele, hogy magas szintű nyelveket nehéz jól alacsony szintűre fordítani (a kézi optimalizációhoz képest), de másfelől pont hogy magas szintű nyelveknél van erre jobb esély ha a cél platform nagyon sokféle, mert a fordító jobban "érti" hogy mit akartál elérni, és mert nem kötsz ki számára alacsony szintű részleteket, ezzel megkötve a fordító kezét. Egy ilyen magas szintű nyelv is tulajdonképpen egy API... csak más megközelítésű, mint a DirectX vagy OpenGL. Azaz, amit mondok az az, hogy tán az "API" megközelítésének radikális megváltozótátásával ez a vízfej lényegtelen mértékűre csökkenthető.

[ Szerkesztve ]

"Magyarul a PC-s kompatibilitás öli meg saját maga elől a PC-s játék ipart."

A kompatibilitás miatti vízfejért cserébe kötetlenebbül, innovatívabban lehet fejleszteni a GPU-kat. Szóval nem vagyok benne biztos, hogy akár csak sebességben végeredményben nem éri ez meg.

Már maga a messze menő kompatibilitás is fejtörést okoz a legtöbb átlagfelhasználónak, így aki teheti konzolt vesz. Cserébe lehet nem olyan erős a masina, viszont nem kell bajlódnia a telepítgetéssel stb.. + exkluzív játékokhoz is hozzájut, és még lehetne sorolni egy konzol előnyét, ami PC-s körben hátrány, mintsem előny. Szóval szerintem attól, hogy 20x erősebb egy PC a konzolnál, attól még nincs nyert ügye.

PS4

Teljesen egyetértek, hardverközeli programozásról beszélni egy ilyen széttöredezett platformon vicc. Az ürge inkább menjen lobbizni az MS-hez hogy a köv. DX API biztosítson alacsonyabb szintű elérést, ne ilyen nevetséges marhaságokat nyilatkozzon.

A cikkhez: azt valaki igazán elmagyarázhatná, hogyan javítana azon a platformosodás vagy a cloudosodás, hogy a kód nagy részét meg kéne írni több platformra is, nem értem hogyan került a cikkbe.

Jó látni hogy valaki gondolkodik is mielőtt hozzászól nem csak nyomja a mantrát mert AMD-s mondta, de közben nem ért hozzá.

A platformokkal kevesebb lesz a lehetséges konfiguráció. Most jelenleg túl sok lehetőség van a CPU-GPU mixelésével. Ennek egyszerűsödnie kell, ha valóban erre akarunk menni. Mivel natív támogatásról lenne szó, így minden lehetséges hardverhez meg kell írni a rendert. Minél kevesebb ilyen van, annál könnyebb a munka.
A Cloud az csak egy másik lehetőség a problémára. Ezen nem javít, csak opció arra indulni, mert az API az korlátozni fog.

Nem Huddy ötlete ez. Ő csak elméleteket vázol fel/hirdet ki a problémákra. Johan Andersson (Frostbite motor) is reagált erre (láthatóan támogatja):
I've been pushing for this for years in discussions with all the IHVs; to get lower and lower level control over the GPU resources, to get rid of the serial & intrinsic driver bottleneck, enable the GPU to setup work for itself as well as tear down both the logic CPU/GPU latency barrier in WDDM and the physical PCI-E latency barrier to enable true heterogeneous low-latency computing. This needs to be done through both proprietary and standard means over many years going forward.

I'm glad Huddy goes out and in public talks about it as well, he get's it! And about time that an IHV talks about this.

This is the inevitable, and not too far, future and it will be the true paradigm shift on the PC that will see entire new SW ecosystems being built up with tools, middleware, engines and games themselves differentiating in a way not possible at all now.

- Will benefit consumers with more interesting experiences & cheaper hardware (more performance/buck).

- Will benefit developers by empowering unique creative & technical visions and with higher performance (more of everything).

- Will benefit hardware vendors with being able to focus on good core hardware instead of differentiating through software as well as finally releasing them and us from the shackles of the Microsoft 3 year OS release schedule where new driver/SW/HW functionality "may" get in.

This is something I've been thinking about and discussing with all parties (& some fellow gamedevs) on different levels & aspects of over a long period of time, should really write together a more proper blog post going into details soon. This is just a quick half-rant reply (sorry)

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

A shading nyelvek (ilyenje mind az OpenGL-nek, mind a SX-nek van) elég rég óta már így működnek.

Amúgy meg a driver az API hívásokat is gépi kódra fordítja, vagy szerinted pure C/C++ kód fut a hardveren?

micsoda megállapítások istenem szabvány ami limitál , hihetetlen, nagyon okosak ezek a bittech amd dolgozók

[ Szerkesztve ]

NEM FIZETETT REKLÁM! >>armegoszto.hu<< Folyamatosan friss akciók.

A platformokkal kevesebb lesz a lehetséges konfiguráció. Most jelenleg túl sok lehetőség van a CPU-GPU mixelésével. Ennek egyszerűsödnie kell, ha valóban erre akarunk menni. Mivel natív támogatásról lenne szó, így minden lehetséges hardverhez meg kell írni a rendert. Minél kevesebb ilyen van, annál könnyebb a munka.

A platformosodás nem igazán szűkíti a piacot. A processzorokkal akkora probléma eddig nem nagyon volt, azok viszonylag egységesnek számítottak (x86), az nVidia ARM-es platformja pont hogy jobban bezavar a képbe. Attól hogy egyfajta processzor mellett leszűkül a lehetséges GPU típusok köre, még nem jelenti azt hogy nem kéne a többire is megírni a kódot hogy fusson. Pontosabban ha platfrom-only játékok jelennének meg, azoknál előnyt jelentene, de attól meg az ég óvja a PC-s játékipart, az a totális halálát jelentené.

A Cloud az csak egy másik lehetőség a problémára. Ezen nem javít, csak opció arra indulni, mert az API az korlátozni fog.

Az idézethez:
This needs to be done through both proprietary and standard means

A csóka amúgy nekem úgy tűnik, pont arról beszél hogy egy standard, hardverközelibb, rugalmasabb API-t kéne kifejleszteni.

"Amúgy meg a driver az API hívásokat is gépi kódra fordítja, vagy szerinted pure C/C++ kód fut a hardveren? "

Dehogy hiszem... a szándékosan idézőjeles "natív" alatt azt értettem, amit az AMD-s illető mondott, hogy kihagyod az absztrakciós réteget (ami DirectX vagy OpenGL). Azaz, arra gondoltam, hogy közvetlenül a videokártya memória területére irkálna a lefordult program, nem pedig DirectX eljárás hívásokon keresztül és DirectX-specifikus adatszerkezeteken át kommunikálva tenné ezt. Mert gondolom ebből adódik az overhead, amiről itt szó van, de szóljatok ha nem. De ezt a fordítás nem előre végezné el a szoftver készítője, hanem a driver végezné el a kliens gépén. Mert a driver ismeri, hogy mit hogy jó csinálni adott hardveren. És így persze a program készítője soha nem is fér hozzá közvetlenül a hardverhez, továbbra is csak a driver teheti ezt, és az absztrakciós réteg technikailag mégis ki lett iktatva.

[ Szerkesztve ]

Már az OpenGL - pontosabban a Khronos Group - is régóta üldözi az elavult 'rögzített funkcionalitású' feldolgozóegységhez kapcsolódó utasításokat, valamint a gyártóspecifikus implementációkat. (így kényszerültek a gyártók, a driver-ben eszközölni okosításokat) Amúgy is már jó-ideje a gyártók által írt shader programok szimulálják a régi feldolgozóegység működését, ezáltal lehetővé téve, hogy még a régi trend szerint készült alkalmazások is működjenek (valamint sokszor nem a játék fejlesztői által írt shader-program fut le, hanem egy mondjuk úgy hogy 'manuálisan, direkt optimalizált' program). A konkrét natív programozás ebben a kontextusban bullshit. Nem tekinthető technológiai előrelépésnek mint az SM amit még nagyrészt üdvözítve fogadott a szakma, A halandó kezdő fejlesztők pedig fogták a fejüket, és tűzre dobták könyveiket.

Valaki már említette Repi GDC-s nyilatkozatát, illetve megtekinthető a prezentáció is, hogy mit kellet latba vetniük a PS3-as Frostbite továbbfejlesztésén, csak hogy játszható legyen majd a BF3. Mindez jelentősen visszaveti a fejlesztés ütemét, a határidőket pedig a kiadók szeretnék betartatni, amit csak a többi platform, és az egész játék minőségének rovására lehet megtenni. (valamit az eddigi játékok supportjának visszavágásával) Az egész pedig onnan indul, hogy hát mára már sovány a PS3-ban található grafikus erőforrás.

sx,dx,x:read

"Most jelenleg túl sok lehetőség van a CPU-GPU mixelésével."

Ez miért gond? Két független dolognak tűnik nekem... Ha a GPU-t közvetlenül érd el, akkor eltekintve a shader nyelvektől (amiket eleve nem érint a CPU típusa), C-t C++-t vagy ilyesmit használsz, nem? A C/C++ meg lefordul x86-a is, ARM-ra is, MIPS-re is...

sztem 5-10 éven belül a szoftver rendernek van létjogosultsága

"Az internet olyan, mint az MTV: annak idején az MTV nagyon trendi volt, aztán hirtelen elavult” - Prince

Szóval a mostani JIT szerű grafikus apizgatás helyett. gpu gépi kódra compileolt grafikára gondolsz?

Nem, ő pont JIT-ről beszélt.

Az AMD Fusion fantázianevű projektje nem valami ilyesmiről szól? Mármint egymással teljesen kompatibilis elemekből felépülő, különböző teljesítményszintű platformok megvalósításáról?
Abba az elgondolásba ez szépen beleillik.

Amiről a cikk beszél, az minden API-ra igaz lesz, az overhead nem egy megkerülhető fogalom. Az OpenGL-nek valóban kárára vált a visszafelé kompatibilitás, viszont fontos tudni mellé, hogy egy ideje már be van vezetve egy deprecation model, amivel fokozatosan kikopnak az API-ból a régi megoldások, tehát ezáltal szálkásodik maga az API.

Ezen felül, az OpenGL-nek van egy beágyazott rendszerekbe szánt változata, az OpenGL ES, ami eleve egy "vékonyabb" API, és amennyire én tudom, az emlegetett OpenGL-es konzolokon, hordozható eszközökön eleve ez van. Konkrétan ennek az irányába konvergál az asztali OpenGL 4 is, és a WebGL is ehhez képest került meghatározásra. Az, hogy vékonyabb az API, ott jön ki, hogy ha egy API minél kevesebb emulált funkciót kínál, annál sanszosabb, h a fejlesztő ténylegesen hardverközeli programot ír. A másik fontos szempont, hogy kisebb API-ra könnyebb "pehelysúlyú" drivert írni.

Magára a cikkre reagálva: nyilvánvalóan igaz technikailag nézve, de az nagyon erős erős csúsztatás, hogy a draw call-ok számával lehetne emelni a grafikai színvonalat. 2000-hez képest 20 000 draw call nem jelent feltétlenül jobb grafikát, pusztán rosszabb kötegelést (batching). Olyan API-t kell használni, és olyan könyvtárakat, amik nem rejtik el a programozó elől a kirajzoló utasításokat, és akkor kézben lehet tartani a kötegelést. Ez természetesen nem pusztán a renderelő szubrutinon múlik, eleve olyan modellekkel kell szolgálni, lásd modell és pályaoptimalizáció.

A D3D 10 óta ott is elmentek a lightweight irányba, de nagyon lehet látni, h még a DX 10 mód is eléggé ilyen prémium dolog a játékokban, és a D3D 9 az alap ami tuti h gyorsra meg van írva, szóval azon a fronton nagyon bátor dolog volt a kompatiblitás elhagyása, de láthatjuk is, h tetűlassú migráció lett az ára.

Egyébként az OpenGL-ről még annyit, hogy az OpenGL 3 az eredetileg nem az az API lett volna, amit ma annak ismerünk, hanem volt abból egy elég széles körben beharangozott draft, ami még a mostani "újjal" sem igen lett volna kompatibilis. Na az lett volna az az állkapocsleejtős innováció azon a fronton, ami elmaradt.

A többszálú renderelés meg egy mese. Eleve akkor lenne értelme, ha rendertargetenként lenne maximum egy szál, ami azért eléggé korlátos párhuzamosíthatóság, utána pedig jön a command buffer, ahol a driverben összeszorul az egész, és kénytelen is, hogy összeszoruljon, ugyanis
1) PCI-Express sín
2) a GPU EGY dolgot tud (hatékonyan) több példányban csinálni, pont ez a Cayman nagy újítása, hogy abban ez már a múlté, de azért még nincs mindenkinek 6900-asa otthon

Szóval jah, nagyon jó lenne a közvetlen command buffer kezelés, de pl. az OpenGL eleve streamként képzeli el a rendszert, és ott csücsül az API-ban a kezdetek óta az aszinkron glFlush() - magyarán szar batching mellett is össze lehet várni egy rakás draw call-t. Ha meg a parancssorozat kezelgetése a nehézkes, az már tisztán CPU overhead. Az sem mindegy, de driver-driver-driver...

"Szóval a mostani JIT szerű grafikus apizgatás helyett. gpu gépi kódra compileolt grafikára gondolsz?"

Nem, én itt eleve csak arról a kódrésztől beszélek, ami a CPU-n fut. Ha jól értem annak a vízfejéről beszélt az AMD-s fazon.

Nem rossz ötlet amit mondasz, de ami igazán fontos az eleve így működik.

Az igazán fontos alatt értsd azt például, hogy van egy rakat kirajzolandó objektumunk, és mindegyikhez egy program (shaderekből), hogy azt hogyna is kell kirajzolni. Ezeknek a futtatása teljesen a GPU-n történik, GPU specifikus assembly kóddal, béke van.

A probléma az, hogy sokféle program van (meg paraméter, meg textúra, meg stb.), szóval az oké, hogy onnantól kezdve h beállítgatjuk a dolgokat, és rácsapunk a GPU hátsójára, h gyihááá, onnantól kezdve piszokgyors és nem igényle CPU-t, de mivel, mint mondtam, sokféle beállítás van, ezért a gyakorlatban legrosszabb esetben az van, hogy minden egyes apró objektumnál a GPU ugyan tudná még darálni, de elfogyott amunka, és várakozik, hogy a CPU felparaméterezze a következő munkamenetét. Na egy ilyen "gyiháá"-t hívnak draw call-nak.

Ez ellen az egyik védekezési mód, egy álomvilágban, az lenne amit a cikk ír, hogy legyen rövidebb a gyeplő, és akkor nem kell annyit várni, amikor irányt akarunk váltani a szekérrel. A másik megoldás meg az, hogy előbb gondoljuk át, hogy mit is akarunk, képezzünk rendezett csoportokat, aztán oldjuk meg minél kevesebb draw callal ugyanazt a kirajzolási sorozatot. Sokszor nem mernek durvább rendezéseket bevetni renderelés előtt, mert annak is van saját költsége, ami viszont általában megtérül.

Bocs az előbbi naiv megfogalmazásért, de másoknak hasznos lehetett ezt tisztába tenni. Amit te akarsz, ahhoz hasonló meg volt már régen, a display list-ek (OpenGL). Lehetett olyat csinálni, hogy egy ponton azt mondod, h na most jegyezd meg mit csinálok, aztán egy API hívás sorozat, na köszi, eddig tartott, aztán azt a sorozatot elmentette, átstruktúrálhatta a saját kedve szerint ("lefordíthatta"), aztán azt akárhányszor újra meghívhattad.

Csak annyi a baja a megoldásnak, hogy a paramétereket is mentette, szóval így nagyon kötött. De egyébként igen, egy ehhez hasonló dolog, egyénileg testreszabható paraméterezéssel nem lenne rossz. csak valószínűleg bőven elég bonyolult lenne már maga az implementáció, nemmég úgy megírni, hogy profitáljon is belőle a driver.

[ Szerkesztve ]

Gyakorlatilag erre vannak a konzolok Azaz ilyen gondolatsíkon vagy, hogy is mondjam.

I5 9400F, Asrock B365M Pro4, Asus RTX4070 Super Dual EVO 12GB, 16Gb DDR4, Seasonic Focus 650 Platinum TV: 65A7GQ

"...kevés olyan hely van a földön.."

Jelen esetben a nagy kezdőbetűs Földről van szó.

Ha jól sejtem a konzolon is pont ez a helyzet: etetni kell a GPU-t, ütemezni kell a parancs löketeket, stb. Tehát itt nincs különbség. Mégis ott jóval kevesebb az overhead, ha jól értettem amit az AMD-s mond. Én annak a résznek a megtakarítására firtattam, ami PC és a konzol közti ezt különbséget adja. Ha ez főleg a hardverre specializálódásból adódó nagyobb léptékű (átfogóbb) optimalizációból adódik, akkor esélytelenül hangzik, de ha afféle "bagatell" dolgokról van szó, hogy teszem azt (csak példa, nem tudom jó-e) DirectX-nél állandóan kreálsz egy tonna adatstruktúrát ami úgyis csak át lesz konvertálva GPU-specifikusra aztán el lesz dobva, akkor ott talán reális javítani a helyzeten. De, nem tudom, csak egy felvetés részemről, hogy tán más API megközelítéssel elviselhető redukálható lenne ez... nekem olyasmi jutott eszembe, amit API helyett már inkább DSL-nek hívna az ember.

"elég bonyolult lenne már maga az implementáció, nemmég úgy megírni, hogy profitáljon is belőle a driver"

Én az implementációt a driver részeként képzeltem el, pont mert a drivet tudja hogy egész pontosan hogy működik a GPU. De persze az egész csak afféle gondolat felvetés...

[ Szerkesztve ]

Érdekes, jó kis irás, okosabb lettem.

ott a kisértet a ganéná.... by: Bendegúz

programozzanak *.asm-ben

laza 100xoros gyorsulás lenne

Kicsit eltérve a témától: a Dx api kicsit vakítás mivel egy nagyon fontos dolgot kihagytok a dologból!!!!! DX = MS windóz és ez valakinek nagyon sokat megér .
Az open gl el a nagy probléma részben a platformfüggetlenség lenne és ez nem érné meg mindenkinek. ( és utolag dx api-n programozni könnyebb az open gl hez képest és a játékok hamarabb elömleszthetik a polcokat amik + 3 hónap munkával csiszolnának akkor már ki lehetne adni és nem lenne a sok kezdeti bug ) De ez az én véleményem ......

[ Szerkesztve ]

Miért nem csinálnak egy nagyjából stabil ISA-t a GPU/stream processorokhoz is mint az x86 a CPU-khoz? (vagy valami újat ami mindkét félét magába foglalja) Akkor nem lenne ez a szenvedés. Csak le kéne fordítani a kódot és kész. És nem lennének OS-hez sem kötve a játékok.

[ Szerkesztve ]

Eltekintve az üzleti kavarásoktól... gondolom nincs egyetértés benne, hogy annak milyennek is kéne lennie. Főleg ha jövőállónak is kéne ennek lennie. Fiatal az egész számítástechnika, hát még a GPU-s téma. (A nem OS-hez kötött játék meg ezen bőven túlmutat, hisz ált. azok az alkalmazások sem OS függetlenek, ahol nem kell vektor grafika.) Meg persze más célokra más teljesítményű GPU praktikus esetleg... ebből és adódik valamennyi változatosság (mondjuk konzolhoz képest, ahol ez is fix).

Nem hiszem hogy az API-t akarná eltüntetni a fickó, hanem inkább saját gyártófüggő API-t szeretne, mert azért a programozó is lusta valahol

mzso: Az is egy lehetőség, de az intel a Larabe-val nem pont azt szeretné? Sőt ott a GPU is kvázi x86-os lenne.

[ Szerkesztve ]

"Ugyan ez a mechanizmus kb mindenre igaz, nem csak videó kártyára: a hőskorszakban mindennel sokkal könnyebb látványosan haladni."

Igen, ebben teljes mértékben egyet értek. Hogy a példámnál maradjak, a Crysis-től nem látom szebbnek a 2. részt.Pedig eltelt majd 4 év. Négy éves hardver ma meg már a süllyesztőben. Csak az elmélet(ed) szerint ez később még gázabb lesz és még kevésbé fogunk jelentős változást látni az idő múltával.

"Amit most konzolban vagy egyéb "fix" hardverben látsz (mondjuk egy Mac), valószínűleg nem lehetne olyan, ha nem lett volna a PC."

Miért is?? A MAC és egyéb alter. gépek vagy célhardverek (mint a konzol) mindég más vonal volt mint a PC. Szerintem ezek nem a PC-k létezésének köszönhetik a létezésüket.

"Nem kicsit kell többet ülni előtte, és azt a plusz munkaidőt neked, a végfelhasználónak kellene megfizetni. "

Így is a végfelhasználó fizeti meg, csak nem drágában veszi meg a szoftvert, hanem hardvert cserél, hogy normálisan működjön. Így lehet eladni az új hardvereket. A pénz így is úgy is el van költve.Ez mivel jobb? Hát annál, hogy a hardver gyártók is kapnak a tortaszeletből amit pénzek hívnak.

"A programozók agya, mivel csak emberek, nem fejlődik (illetve de, csak az evolúció lassú), a szoftverek viszont egyre bonyolultabbak. A hardver (még) fejlődik, arra lehet nyújtózkodni..."

Mivel én nem értek a programozáshoz, csak az alapján tudok ítélni amit eddig láttam a fejlődéstörténelemben. Ezért gondolom azt, hogy valami nem kerek.

..--OLDSCHOOL FOREVER--..

Ebben úgy tűnik osztod a véleményem te is...

..--OLDSCHOOL FOREVER--..

"Amit most konzolban vagy egyéb "fix" hardverben látsz (mondjuk egy Mac), valószínűleg nem lehetne olyan, ha nem lett volna a PC."

Miért is?? A MAC és egyéb alter. gépek vagy célhardverek (mint a konzol) mindég más vonal volt mint a PC. Szerintem ezek nem a PC-k létezésének köszönhetik a létezésüket.

Az XBOX360 CPU-ja egy IBM PowerPC alapú processzor, a Cell-hez hasonló, mondjuk ez nem PC. Viszont az ATI Xenos GPU az abszolút rendelkezik PC-kapcsolattal, mert az ATI R500 GPU-k rokona, azaz az x1800-x1900 sorozat testvére. (Ebből következően az XBOX360 játékátiratainak jól kéne futni ezeken a VGA-kon, de mint tudjuk, nem így van.)

A PS3 Cell processzorokra épül, ami nem PC, viszont a GPU-t az Nvidia fejlesztette, és ha minden igaz, a G70 GPU rokona. Ez megint csak PC-kapcsolatot jelent.

Tehát adott két DirectX 9 szintű grafikus képességű konzol, amik a fix hardvernek köszönhetően olyan megjelenítést képesek létrehozni, amihez PC platformon sokkal erősebb hardver kell.

Szerk: Ahogy ddekany mondja, a MAC is PC alapú ma már, pontosabban Intel x86 alapú.

[ Szerkesztve ]

#tarcsad

"Richard Huddy egy rendkívül érdekes kijelentést tett az elmúlt héten a bit-tech számára adott interjúban."

Semmi újdonság nincs ebben. Már az őskorban is tudtuk, hogy ha a program a vason fut, akkor gyorsabb lesz, mintha interpreter, különböző kompatibilitási rétegek, stb.

Valamit valamiért.
Az API és driver funkciókat kellene egybeolvasztani akkor eltűnne meg meglehetősen vastag réteg, azaz a DX nagy része, így sokkal gyorsabbak lehetnének a játékok.

Mutogatni való hater díszpinty