Gyurkity Péter

AMD: lőttek a fizikai gyorsításnak a grafikai chipeken

Az AMD és az nVidia szerint is negatív következményekkel járhat a Havok Intel által történt felvásárlása. A processzorgyártó szerint saját többmagos chipjeire kellene bízni a fizikai gyorsítás elvégzését.

Az Intel még szeptemberben jelentette be, hogy felvásárolta a Havok céget, amely motorjával a fizikai számítások elvégzését teszi lehetővé a grafikai chipeken, vagyis a megoldás által a GPU-n belüli gyorsítást választották. Talán nem véletlen, hogy most mind az AMD, mind pedig az nVidia részéről negatív vélemények érkeztek - mindkét cég egyetért abban, hogy a felvásárlás negatív következményekkel járhat a piacra nézve.

Az AMD részéről Richard Huddy nyilatkozott, aki az ATI felvásárlásával került a céghez. Szerinte a Havok FX támogatása elenyésző marad, sőt az is lehet, hogy meg sem jelenik a jövőben, illetve az Intel minden további támogatás nélkül ereszti szabadjára a motort. Kételyeiket elsősorban azzal magyarázzák, hogy a cég jelenleg még nem gyárt különálló grafikus chipeket (bár tervezik), vagyis számukra a Havok felbukkanása és gyors terjedése elsősorban azt jelentette volna, hogy csökken az erős központi processzorok jelentősége, mivel a motor a GPU-k lehetőségeit növelné. Ezen elgondolásból kiindulva a rivális úgy véli, hogy az Intel szándékosan dobná a süllyesztőbe, vagy legalábbis hátráltatná a Havok indulását.

Az nVidia vezérigazgatója, Jen-Hsun Huang eközben úgy nyilatkozott, hogy bár a motor megszerzése néhány ponton előnyös lehet az Intel számára, mindenhol máshol negatív tendenciákat indíthat be. "Igazából nem értem, miért vásárolták fel ezt a céget" - tette hozzá Huang, kiemelve, hogy a piacon még bőven vannak lehetőségek, hiszen jelenleg számos kisebb-nagyobb cég igyekszik saját megoldását ráerőltetni az érdeklődőkre.

Mindkét cég pesszimista a közeljövőt illetően, de azt sem felejthetik el, hogy a DirectX 11 megjelenésével fellendülhet a piac ezen szegmense. Ez azonban még odébb van, hiszen a Vista első javítócsomagjának részeként egyelőre a DirectX 10.1 érkezik majd. Egyelőre az Ageia is szenved saját PhysX kártyáival, amelyek szintén a fizikai gyorsítás keresztjét veszik magukra. A cég éppen most csökkentette a kártyák árát 99 dollára, mivel a kereslet eddig elkeserítő volt.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • dez #63
    "Ha smt-s a cpu, akkor nem kell elmenteni a regisztereket, csak select vonalat valtani a magban a regiszter blokkok kozott. Ezt utasitasonkent is meg lehet tenni."
    Tudom, én sem az elmentésről beszéltem, hanem arról, hogy hely kell a regiszter-bankoknak. Nem is kevés: több, mint megegyező méretű memóriának.

    "Ha van cache, akkor nem szabalyos az eleresi ido, viszont ha van smt akkor a hosszu eleresek alatt egy masik szal fut."
    Ha nincs cache (más van helyette), nem életbevágó az SMT sem.

    "Az eredmeny, hogy a hardver futas kozben optimalizalja a kodot, tehat nem a forditonak vagy a programozoknak kell gondolkodniuk."
    Cserébe viszont a procinak kell jó sok tranyóból állnia.

    "Ez fejlesztes szempontjabol jo, es az osszteljesitmeny is megfelelo."
    A Cellnél az ilyen "kényelmi" szolgáltalásokat áldozták be a kinyerhető teljesítmény oltárán. Ideje lenne ezt megemésztened.

    "Ha negyszeresen pechje van a magnak meg mindig csak annyira lassul le, mintha nem lenne smt, tehat egy cell spe sebessegere."
    Ez egy értelmetlen mondat.

    "A cell lehet gyorsabb, de csak akkor ha az adott magra optimalizalnak."
    Akkor viszont nagyon gyors lesz, és ez volt a cél.

    "Ez addig jo, amig mindenki azt a magot hasznalja. Az x86-os architektura pont azert jo, mert a legvaltozatosabb hardvereken is elfut a kod es egy fejlettebb rendszeren is kepes kihasznalni a nagyobb teljesitmenyt."
    Aha, aztán a legjobb x86 mag lead ilyen 10 GFLOPS-t... Több magra meg itt is optimalizálni, párhuzamosítani kell.

    "Ha van egy program ami 256KB-os local store-ra van irva, akkor nem tud mit kezdeni egy 512KB-ossal."
    Ha rosszul van megírva, vagy a szokásosnál erősebben optimalizálva van.

    "Cache eseten automatikusan javul a teljesitmeny. Ha egy spe-s programnak nem eleg a gep ereje vagy a local store, akkor ujra kell irni az elejetol."
    Programra válogatja, ne általánosíts. Pl. az IBM rtRT-je (real-time ray-tracer) közel egyenesen arányosan gyorsul a felhasznált SPE-k, sőt Cellek számával. PS3-on fut egy adott sebességgel, egy 2 Celles blade-en kb. 2,5x gyorsabban (6 vs. 16 SPE) (link), és egy 8 Celles Blade Centeren meg utóbbihoz képest szépen 3,5x gyorabban (link).

    "X86-os programnal viszont eleg venni egy nagyobb gepet. Az utobbi olcsobb es kenyelmesebb is. Ezert van az, hogy a vista alatt futnak a regi 386-os idokben irt win32-es programok is."
    Futnak, de hogy? Nem lesznek automatikusan többszálasak, és nem tudnak automatikusan nagyobb adatbázist kezelni, mint ami ott a maximum volt.

    "Senki nem orulne, ha egy pc-s jatek csak egy bizonyos cpu-n futna. Mondjuk az oblivion csak P4-en, a cysis csak core2 quad-on es minden gepbol tartani kellene egyet hogy felvaltva jatszhassunk a ket jatekkal."
    LOL, tudod, a konzol már csak ilyen, külön össze kell rakni hozzá a szoftvert (még ha csak portolásról is van szó adott esetben; vagy eleve több-platformos fejlesztésről, ahol azért egyedileg kell ezt-azt optimalizálni).

    A Cell PPE (Power Processing Element) magja különben is egy általános proci, amin elfut a szoftverek nagy része, főleg azok kevésbé számításigényes magja, és csak a számítás-igényesebb részeket kell átdolgozni az SPE-kre. Mellesleg PC-s vonalon is ez jön be, hogy az ilyen részeket a GPU fogja számolni.

    "Mondjuk a sony ezt megjatszotta, ott vehetsz egy ps2-est es egy ps3-ast is ha mindennel jatszani akarsz..."
    Sony bashing nem maradhat el... Egyébként meg ez csak a legolcsóbb, 40 gigás típusra igaz.

    "Pc-n meg eleg egy darab gepet otthon tartani."
    Aha, aztán félévente cserélni. És egy idő után a korábbi programok nagy része már nem ér semmit.

    "Ez is jol mutatja az x86-os architektura elonyeit. Es ez csak az intel es az amd tervezoinek koszonheto, akik komolyan vettek a kompatibilitast."
    Bla-bla-bla. Hol kompatibilis egy SSE2-as kód akár egy Pentium III-mal? Vagy egy SSSE3-as egy P4-gyel? Vagy egy SSE4-es egy Core 2-vel?
    Hogy az újabb procik (többé-kevésbé, OS-függően) futtatják a régebbi programokat? Ja, jó lassan. Erre egy újabb Cell is képes a legbutábban, vagy túl specifikusan megírt kóddal is. Miközben egy jó kód automatikusan kihasználhatja az újabb magokat, nagyobb LS-t.

    "A cell meg sajat ujabb verzioival sem kompatibilis."
    Hülyeség.
  • kvp #62
    ""ami mindossze egy regiszter keszlet valtast igenyel"
    Ez pl. a Cell SPE-i esetén 128db 128 bites regiszter váltását igényelné (2KB), de a mai DX10-komp. GPU-knál már ilyen 1024-es számok figyelnek... Bár valószínű a Larrabee magjaiban kevesebb lesz, és a shader-compilerre hárul majd a feladat ennek elfedésére."

    Ha smt-s a cpu, akkor nem kell elmenteni a regisztereket, csak select vonalat valtani a magban a regiszter blokkok kozott. Ezt utasitasonkent is meg lehet tenni. (tehat egyet innen egyet onnan, egyet amonnan alapon, lasd sun cpu-k vagy xerox parc alto)

    "Éppen azért van local storage ram az SPE-kben, és nem cache, mert előbbinél egy 32 bites adat vagy utasítás word a tényleg 32 bit, nem egy egész cache-line, ami a többszöröse. Ezt értsd már meg, hogy ha cache lenne, sokkal kevesebb lenne belőle.
    Úgy tűnik, kevered a cache-es rendszer karakterisztikáját a local storage-esével. Utóbbinál nincs kiszámíthatatlan memória-művelet (tehát hogy nem tudhatjuk, hogy a cache-ből jön-e az adat, vagy a rendszer-memóriából). Ha a local storage-et címzed meg, akkor onnan jön, ha meg DMA-zol, akkor nem."

    Ha van cache, akkor nem szabalyos az eleresi ido, viszont ha van smt akkor a hosszu eleresek alatt egy masik szal fut. Az eredmeny, hogy a hardver futas kozben optimalizalja a kodot, tehat nem a forditonak vagy a programozoknak kell gondolkodniuk. Ez fejlesztes szempontjabol jo, es az osszteljesitmeny is megfelelo. Ha negyszeresen pechje van a magnak meg mindig csak annyira lassul le, mintha nem lenne smt, tehat egy cell spe sebessegere. A cell lehet gyorsabb, de csak akkor ha az adott magra optimalizalnak. Ez addig jo, amig mindenki azt a magot hasznalja. Az x86-os architektura pont azert jo, mert a legvaltozatosabb hardvereken is elfut a kod es egy fejlettebb rendszeren is kepes kihasznalni a nagyobb teljesitmenyt. Ha van egy program ami 256KB-os local store-ra van irva, akkor nem tud mit kezdeni egy 512KB-ossal. Cache eseten automatikusan javul a teljesitmeny. Ha egy spe-s programnak nem eleg a gep ereje vagy a local store, akkor ujra kell irni az elejetol. X86-os programnal viszont eleg venni egy nagyobb gepet. Az utobbi olcsobb es kenyelmesebb is. Ezert van az, hogy a vista alatt futnak a regi 386-os idokben irt win32-es programok is. Senki nem orulne, ha egy pc-s jatek csak egy bizonyos cpu-n futna. Mondjuk az oblivion csak P4-en, a cysis csak core2 quad-on es minden gepbol tartani kellene egyet hogy felvaltva jatszhassunk a ket jatekkal. Mondjuk a sony ezt megjatszotta, ott vehetsz egy ps2-est es egy ps3-ast is ha mindennel jatszani akarsz... Pc-n meg eleg egy darab gepet otthon tartani. Ez is jol mutatja az x86-os architektura elonyeit. Es ez csak az intel es az amd tervezoinek koszonheto, akik komolyan vettek a kompatibilitast. A cell meg sajat ujabb verzioival sem kompatibilis.
  • dez #61
    "Hat nem, csak akkor ha a videokartyan van a tuner. Minden mas esetben utazik egyet az adat a rendszermemorian keresztul, majd overlay-kent kerul ki a videokimenetre. (live texture-kent) Mindketto lehet dma-s de azert a rendszermemoria nem tul gyors."

    Hát, én határozottan úgy emlékszem, hogy egyszer az egyik tuner leírásában azt fejtegették, milyen körülmények között tud megvalósulni a közvetlen írás, de mindegy.

    "ami mindossze egy regiszter keszlet valtast igenyel"
    Ez pl. a Cell SPE-i esetén 128db 128 bites regiszter váltását igényelné (2KB), de a mai DX10-komp. GPU-knál már ilyen 1024-es számok figyelnek... Bár valószínű a Larrabee magjaiban kevesebb lesz, és a shader-compilerre hárul majd a feladat ennek elfedésére.

    Éppen azért van local storage ram az SPE-kben, és nem cache, mert előbbinél egy 32 bites adat vagy utasítás word a tényleg 32 bit, nem egy egész cache-line, ami a többszöröse. Ezt értsd már meg, hogy ha cache lenne, sokkal kevesebb lenne belőle.

    Úgy tűnik, kevered a cache-es rendszer karakterisztikáját a local storage-esével. Utóbbinál nincs kiszámíthatatlan memória-művelet (tehát hogy nem tudhatjuk, hogy a cache-ből jön-e az adat, vagy a rendszer-memóriából). Ha a local storage-et címzed meg, akkor onnan jön, ha meg DMA-zol, akkor nem. Plusz nem áll le a kód-végrehajtás az DMA elindulása miatt. Szóval nem tudom, miről beszélsz. Ja, hogy FUD-olsz már megint. Egyébként meg double-bufferinggel lehet javítani a kihsználtságon.

    "A lenyeg, hogy nem kell a kodot modositani, ha valtozik a magok szama, a cache merete, vagy a cpu belso felepitese."
    Ebben azért nem lennék olyan biztos. Bizonyos magszám felett, ha megőrzik ezt a teljesen általános célú felépítést, egy igen széles memóriabusz is szűk lesz.
  • dez #60
    Az RTRT egyelőre csak egy érdekesség lesz, amit valószínűleg csak kisebb felbontásokon fog tudni használható sebességgel. De mint szó volt róla, a szokásos raszterezős megoldást is tudni fogja, azaz DX1.x-et, elfogadható sebességgel.
  • kvp #59
    "Tudtommal a tuner kártyák közvetlenül a grafkártya memóriájába pakolják a képet, a proci segítsége nélkül (hacsak nem aktív valamilyen procis filter)."

    Hat nem, csak akkor ha a videokartyan van a tuner. Minden mas esetben utazik egyet az adat a rendszermemorian keresztul, majd overlay-kent kerul ki a videokimenetre. (live texture-kent) Mindketto lehet dma-s de azert a rendszermemoria nem tul gyors.

    "Ha olyan egyszerűek lesznek azok a magok (márpedig annyihoz igen le kell őket egyszerűsíteni), akkor nem valószínű az SMT. Ha van is, max. 2 utas, nem több."

    4 utas az smt, ez benne van a hivatalos dokumentacioban. A statikus smt-hez nem kell szinte semmilyen eroforras. Annak idejen a xerox parc alto-k 16 utas smt-t hasznaltak, es meg kezzel forrasztottak a cpu-ikat logikai kapukbol. Az smt csak annyi, hogy ha blokkol egy memory read, akkor nem all neki a mag varni, hanem atkapcsol a kovetkezo szalra, ami mindossze egy regiszter keszlet valtast igenyel. (mivel cache van bennuk lokalis memoria helyett, ezert az intel cpu-k kepesek dinamikusan tobb szal adatait cache-ben tartani, ehhez mar csak a tobb regiszter keszlet kell, ami a cache-hez kepest elhanyagolhato meretu) Ez az egyetlen a cell-ben ami hianyzik a konnyu programozashoz es a kozel 100%-os mag kihasznalashoz. (tehat megegyszer: dinamikus hardveres cache + hardveres smt)

    "Amúgy legalább rá vannak kényszerülve, hogy a local store-okban dolgozzanak. Ha hétköznapi kódot futtatnának, ami állandóan a külső ramhoz akar férni, sokkal lassabb lenne az egész. Persze nyilván akad olyan feladat, ami így a lassabb."

    Tegyel bele smt-t es mindjart 100%-os lesz a cpu kihasznaltsag, mivel amig az egyik ir vagy olvas addig a masik szamol. Ha mindegyik szal irni/olvasni akar, akkor pedig pont a cell-ek egyszalu teljesitmenyet kapjuk mint legrosszabb esetet. A gf8800-asok is ettol olyan hatekonyak, mivel a tobbszalusag mellett jelen levo smt megharomszorozza a szamitasi teljesitmenyuket. (soha nem kell ramra varniuk mert tobbnyire van ket masik 16-os szal koteg ami eppen futhat) Az alapelv, hogy az elso szal olvas, a kozepso szamol a harmadik ir, majd helyet cserelnek.

    "Ja, nagyszerű, az ósdi x86 további területeket foglal el."

    A lenyeg, hogy nem kell a kodot modositani, ha valtozik a magok szama, a cache merete, vagy a cpu belso felepitese. Az x86 mara egyfajta nagysebessegu java bytekodda valt, ugyanis minden mai cpu on the fly forditja. (a p4 es a crusoe just in time modon, de az nem valt be)

    Egyebkent az elso shader kodot futtatni kepes pc-s videokartya is x86-os volt, az ibm pgc kartyaja 1984-bol, x86 assembly-ben programozhato vertex es geometry shader-rel, vga minosegu truecolor (640x480xRGB332p) keppel. Az autocad peldaul ki is hasznalta rendesen.

    http://en.wikipedia.org/wiki/Professional_Graphics_Controller
    http://www.seasip.info/VintagePC/pgc.html

    Fontos, hogy az intel mindig kiadja a teljes hardveres dokumentaciot, tehat barki kepes driver irni a hardvereikre (a grafikus kartyaikra is). Igy konnyen lehet, hogy minden alternativ os tamogatni fogja a hardveruket, sot meg a microsoft is megteheti, hogy maga ir drivert, elkerulve ezzel az nvidia-nal tapasztalt vistas hibakat vagy az ati fele biztonsagi reseket. Ez az egyik fo ok, amiert az emberek megbiznak az intel termekekben. Lehet, hogy nem ok a leggyorsabbak, de senki mas nem ad ennyire reszletes dokumentaciot a termekeihez. Es mostanaban meg akar ugy is alakulhat, hogy ok lesznek a leggyorsabbak is.
  • shabba #58
    Az Intelnek mivel új piacra lép be, új termékkel legfőképp a sw támogatáson kell dolgozni ahogy korábban is írtam. Biztos hogy fizetni fognak egyes húzónév játékgyártóknak hogy a grafikai enginejükbe építsenek be real time raytracing támogatást is. Végülis az ő elképzelésükkel ugyanazt az utat kell végigjárni mint ami anno grafikai gyorsítók hőskorában volt. Ott is volt egy software rendering ami széleskörben használt volt és jöttek grafikus gyorsító termékek amik kevésbé voltak elterjedve, de a gyártók rávették a fejlesztőket a támogatásra és akkor máris eladható volt a termékük.

    Az Intenel ugyanazt kell végigjátszania a RTRT-vel, olyan enginekre lesz szüksége, neves húzótermékeknél amiknek lesz raszteres és RTRT engine átiratuk így az ő Larrabeejának képességei is megmutathatók. És ha a termék beválik, a látványvilága jobb lesz akkor szépen lassan terjedésnek indulnak mint ahogy anno a softwares renderingről áttértek a játékosok a grafikai gyorsítókra. Csak persze ez most sokkal nehezebb menet lesz, hisz anno az ez szűz piac volt, most pedig erősen bebotonozott állásokat védnek, régi, bizonyított piaci szereplők. Közel sem lesz olyan 1xű meggyőzni a felhasználókat arról hogy az ő termékük jobb.

    Az első Larrebbe generáció biztos nem lesz átütő siker, a célja inkább csak az lesz hogy létezzen működő hw amin a további fejlesztéseket szélesebb körben lehessen folytatni, és a kezdeti újdonságra fogékony rétegnek bemutatkozzon. A következő amikor már a gyártástechnológia lehetővé teszi hogy összeintegrálják az általános céló procit és a Larrabeet, mint a Cellnél már jobban sikeresebb lehet, de szerintem egy jelentősebb áttöréshez el fog terni legalább 5 év, addigre meg már lesz 3. generáció is Larrabeeből. Persze akár az is lehet hogy gámer fronton totál zsákutca lesz, a totális negatív fogadtatás miatt, akkor majd használja HPC-re, multimédiára az új képességeket az Intel, végülis több fronton bevethető a nagy számítási terljesítmény.

    Elsőre nem hinném hogy helyből a felső kategóriás vasakat célozná meg Intel mint konkurens termék, inkább a középkategóriás termékekkel szemben kínálná a RTRT-t. Persze itt is lehet hasonló trükköket alkalmazn mint grafikus kártyáknál az SLI, több "cell like" procit kell pakolni az alaplapra. Ahogy már ma is az extrém játék konfigoknál 2 procis rendszereket építenek a gyártók, úgy a jővőben akár egy 2 procis feállás lehet egy közép kategória, a 4 procis meg a felső. Végülis az Intel abban érdekelt hogy inkább több általa gyártott procit vegyen a fogyasztó és ne a konkurens videokártyáira költse a pénzét.
  • dez #57
    "Csak az alaplapok nem tamogatjak. Meg a windows driver modellje. Es a physx jelenleg pci-os nem pcie-s. Minden mas oke."
    Tudtommal a tuner kártyák közvetlenül a grafkártya memóriájába pakolják a képet, a proci segítsége nélkül (hacsak nem aktív valamilyen procis filter).

    "Mig a cell egy sima in order, skalar cpu"
    Hányszor írjam még le, hogy nem skalár, hanem vektor (abból sem az első generáció)?

    "addig az intel fele megoldas egy marek szabvany x86 akar lenni."
    Azért majd meglátjuk, mennyire szabvány.

    "Ezek szerint rendes legalabb 32 bites virtualis memoriat kapnak a magok. Az smt funkcionalitas mar biztos, tehat lehetoseg lesz tobb szalat futtatni egy magon egy idoben."
    Ha olyan egyszerűek lesznek azok a magok (márpedig annyihoz igen le kell őket egyszerűsíteni), akkor nem valószínű az SMT. Ha van is, max. 2 utas, nem több.

    "Ez a ket feature gyakorlatilag az ami a cell-bol nagyon hianyzik a programozoknak."
    Az SMT miért is olyan fontos az SPE-knél? (A PPE SMT-s.)
    Amúgy legalább rá vannak kényszerülve, hogy a local store-okban dolgozzanak. Ha hétköznapi kódot futtatnának, ami állandóan a külső ramhoz akar férni, sokkal lassabb lenne az egész. Persze nyilván akad olyan feladat, ami így a lassabb.

    "Ha rendes x86 szeru utasitaskeszletet kapnak a magok, akkor meg a meglevo kodok is maradhatnak, es ha kesobb az intel atall out of order magokra vagy megduplazza a lokalis memoria (cache) meretet (vagy esetleg elfelezi), akkor sem kell ujrairni semmit. Ez volt az a feature ami miatt meg mindig x86-os rendszereket hasznalunk es amit semelyik masik gyarto nem tudott kovetkezetesen veghezvinni."
    Ja, nagyszerű, az ósdi x86 további területeket foglal el.
  • dez #56
    Természetesen azon vannak, hogy viszonylag jól teljesítsen DX10-ben is.
  • kvp #55
    "Normálisan megírt driverek esetén és megfelelő hardvertámogatottság mellett ez nem igaz. A PCIe alapból támogatja a point-point kapcsolatokat harmadik (hoszt) közvetítő nélkül is."

    Csak az alaplapok nem tamogatjak. Meg a windows driver modellje. Es a physx jelenleg pci-os nem pcie-s. Minden mas oke.

    "Egyébként többtíz leegyszerűsített x86 magról van szó, kiegészítve valamilyen újabb SSE egységekkel a gyors vektorszámítások végett, talán SSE5 lesz a neve."

    Ha jol latom, akkor a larrabee a pentiumok tudasat orokli a 486-osok helyett. Ez azt jelenti, hogy pipelined in order cpu tomb lesz. Mig a cell egy sima in order, skalar cpu, addig az intel fele megoldas egy marek szabvany x86 akar lenni. Ezek szerint rendes legalabb 32 bites virtualis memoriat kapnak a magok. Az smt funkcionalitas mar biztos, tehat lehetoseg lesz tobb szalat futtatni egy magon egy idoben. Ez a ket feature gyakorlatilag az ami a cell-bol nagyon hianyzik a programozoknak. Ha rendes x86 szeru utasitaskeszletet kapnak a magok, akkor meg a meglevo kodok is maradhatnak, es ha kesobb az intel atall out of order magokra vagy megduplazza a lokalis memoria (cache) meretet (vagy esetleg elfelezi), akkor sem kell ujrairni semmit. Ez volt az a feature ami miatt meg mindig x86-os rendszereket hasznalunk es amit semelyik masik gyarto nem tudott kovetkezetesen veghezvinni.
  • Abu85 #54
    Dez én nekem tetszik a Larrabee, de nem látom, hogy miért vennék azt az emberek pusztán a fizikai számítások jó teljesítménye véget.

    Gondolj bele mi van most az asztali PC piacon. Technikai szempontból vizsgálva van a GF8 ami tökéletesen teljesíti a saját kora követelményeit. Teljesen a Pixel Shader programok futtatására tervezett, de a D3D10 Geometry Shader alapú és komoly számítást és erős Stream output használatot követelő újításira teljesen alkalmatlan. Magas Texel Fill-Rate értékek, a jelenleg használt egyszerűbb textúrázási eljárások gyors végrehajtására. Ezzel szemben az HD Radeon egy vérbeli D3D10-es kari, következetes teljesítménnyel, magas számítási teljesítménnyel, a unified Shader és a Geometry Shader lehetőségeinek gyakorlati támogatásával. Felkészítve a jövőbeli textúrázási eljárások gyors futtatására.

    A Larrabee-nél még a fejlesztők meggyőzése is problémás lesz. Szintén a jelenlegi helyzetből kiindúlva... Az nV biztosít némi anyagi támogatást, hogy az ő karijainak megfelelően legyen némileg heggesztve a játék. Miért is nem mennének bele a fejlesztők, GF8-ra írjuk a szoftvert és legrosszabb esetben 10-20%-al lasabb lesz Radeonon. De mi van fordítva? Az AMD meggyőzheti a fejlesztőket a Geometry Shader lehetőségeiről és a Stream output erőteljes használatáról. Kétlem, mert ezetsetben nem igazán futna folyamatosan a program a GF8-on ami nem túl jó dolog a kari eladásait figyelembe véve.
    A Larrabee-vel is ez lesz, nehéz lesz meggyőzni a fejlesztőket... pontosabban drága lesz.