"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.
""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.
"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.
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.
"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.
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.
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.
"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.
"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.
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.
Jó, mondjuk az is lehet, hogy azért kockáztattak, mert addig is több játék jött ki, ami ezt az engine-csomagot támogatja. Meg így kevesebb idõ maradt a "többieknek" más megoldás után nézni, stb. Viszont nem látom, milyen extrákat építettek volna a chipbe külön a Havok miatt.
Akár igazad is lehetne, de ha annyira a Havokra optimizálnák a chipet, már jóval korábban megvették volna a céget (nehogy más vegye meg v. más probléma merüljön fel idõközben), nem akkor, amikor lényegében már kész a hw.
Ebben az az szép h a valódi okot sosem tudjuk meg. Max ha pár év múlva a DX-ben/OpenGL-ben is megjelenik, akkor sejthetõ h mi történt.
Egyébként: "Larrabee is a different sort of beast than the traditional GPU, and I've described before how its many-core x86 design is particularly suited for physics and real-time ray tracing. I've also talked about how Intel has crammed some specialized hardware onto the chip in order to make it better at the kind of raster graphics that traditional GPUs do."
Nem vaktában választották éppen azt a céget, és nem szeptemberben döntött az intel errõl. Mindegy...
Tévedés, éppenhogy az az alapelvem, hogy többet feltételezek, mint az átlag intelligenciaszint és tárgyi tudás, de sajnos sokszor csalódnom kell.
A Larrabee-t már több éve fejlesztik, és eleve eléggé általános célokra alkalmasnak tervezték. Most már a befejezõ szakaszban vannak, 2008 vége felé már akár az üzletekben is lehet. (Kb. 1 év, mire magas kihozatali arányú tömeggyártás révén a piacra kerül valami az elsõ prototípus elkészülte után.) 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.
Így eleve adott volt a dolog, nem ezt kellett a Havokhoz igazítani, hanem utóbbit ehhez. Plusz nem is akarnál Havokra optimalizálni, mert jópár más célra is fel akarják használni.
Nálad kezd alapérvvé érlelõdni a másik hülyének nézése
Spec arra céloztam h a saját architektúrájukat próbálják arra optimalizálni, hogy ez és a hasonló alkalmazások használatakor nagyobb teljesítményt produkálhassanak óccsóért, mint a táposabb konkurencia. Vszeg már egy ideje ezzel foglalkoztak, és most vált hivatalossá.
Nem mellesleg ami intel, az jóval hamarabb lehet ipari szabvány (vagy csak szimplán népszerûbb), mintha egy kisebb cég keretén belül futna. SZVSZ egyszerûen meglátták a tendenciát, mint annak idején a jelfeldolgozási irányváltás a '90es évek közepén. Eléggé kis piaci szelet volt a DSP anno, viszont mára nincsen számítógép a funkciói nélkül.
Az sli driverek még mindíg rengeteg hibát tartalmaznak. Hogy ez épp mitõl jött elõ azt nem tudni, frissebb driverrel is jó már, de attól még tény marad, hogy ha sli rendszerrel akarsz játszani, akkor gyakrabban kell böngészd a driver oldalt a gyártónál, mint különálló kártya esetén.
Mondjuk továbbra is azt mondom, hogy pusztán a support (Havok FX támogassa Larrabee) miatt nem kellett volna megvenniük. Lehet, hogy az egész Havok Physixet (nem keverendõ a GPU-s gyorsítást támogató Havok FX-szel) át akarják íratni Larrabee-támogatásúra. De akármit is csinálnak, potenciális veszélyt jelentenek az AMD-re és Nvidiára, így azok - ha nem akarnak függeni az Intelt pillanatnyi széndékaitól, jókedvétõl, amit zsarolásra is felhasználhat - lassan kereshetnek más megoldást.
Látod, ezért vált értelmetlenné a másik topikban a vitánk: mert az érvekkel mit sem törõdve egyszerûen újraiteráltad a mondókádat. --- Jó, hogy belinkelted azt a cikket, csak kár, hogy nem értetted. Nem technológiai alapok kellenek nekik (fõleg hogy azok már rég le vannak fektetve), hanem nagyon is a fizikai gyorsítás miatt kellett nekik a Havoc. Itt van a lényeg:
Intel can make Havok's physics engine and other software scream on Larrabee, so that when then the new GPU launches the company can advertise "good enough DX10 performance" coupled with "but check out what we can do with physics and AI."
Arról van szó, hogy a Larrabee nagyon jó lesz nagy teljesítményt igénylõ számításokban, de nem feltétlenül lesz a csúcson DX10 teljesítményben (fps). Viszont megfelelõ fizikai supporttal mondhatják azt, hogy "elég jó DX10-ben is, miközben fizikában sokkal jobb, mint a konkurencia". Plusz nyilván kellõ marketingtevékenységet fognak kifejteni, hogy minnél többet számítson ez a dolog.
Nem, a tiéd... (Te jössz) --- Egyébként visszakanyarítva a témát, ha már télleg így alakult, nem biztos h kizárólag a fizikai gyorsítás a céljuk a felvásárlással. Valószínûleg a technológia alapok is kellenek nekik, akár a saját GPU továbbfejlesztéséhez is.
Az AMD, meg az NVIDA meg azért rinyálnak, mert tartanak az intel kikalkulálhatatlan lépéseitõl.
Az ODE nem támogatja jelenleg a GPU-s gyorsítást, és nem biztos, hogy úgy van kialakítva, hogy ez megvalósítható lehet vele teljes átírás nélkül. A Physix sem támogatja a GPU-kat.
Akkor lenne parasztvakítás, ha semennyit sem gyorsítana, plusz alapból is több-mint-elég fps-t produkálna 1db kártya is minden játékban, minden körülmények között. Nem így van.
köcsögök, miért nem vettétek meg ti :) most már késõ.
beeeeee
10 év múlva A gyerekenek megmutatjuk hogy milyen is volt... Egy Vista emulátorral
10 év múlva Win alatt 1 mag nézi a gépedet, hogy milyen illegális anyag van rajta, 1 mag téged azonosít a retinád alapján, egy a mikrofonon keresztül hallgatózik, 1 tartja a kapcsolatot az FBI-al. Rákattintassz egy gyanús linkre, megnézi, emelkedett-e a pulzusod, kitágult-e a pupillád aztán visznek is. Bíróság sem kell ott a bizonyíték a szerveren, a Microsoft világrendõrség a ház elõtt fejbelõ.
ugyan már 10 év távlatában, az elsõ 10 processzormag végzi a fizikai gyorsítást, a directx kap 2 magot, az oprendszer (Windows 2017 HDXXQ Astala vista) 3-4-en eléldegél csak úgy magában (végzi azokat mûveleteket amikrõl semmit se tudsz).
Az erõforrást igénylõ alkalmazás (érstd: játék) kap még 10 processzormagot, és még mindig marad pár mag az egyéb futó programkra.
Persze a windows néha optimalizálja, és 31 mag kell a desktophoz, 1 maradékon még osztozik minden más.
Majdnem olyan sokan veszik h az már szinte nyereséges :)
"Nem tudok róla, hogy külön támogatás kell minden játékba." Nem feltétlen kell, de van ahol elég fos eredményt kapsz enélkül. Pl cimbáromnak 7xxx szériás kártyán nv kártyán engedélyezett sli mellett crysis demo játszhatatlan sebességet produkált, sli driverbeli letiltása után pedig használható lett.
"A messze itt nagy kesleltetest jelent, mivel minden kepkockahoz eloszor a cpu-nak el kell kuldenie az adatokat a ppu fele, kivarnia amig kiszamolja az uj adatokat, majd a cpu visszahozza es elkuldi a gpu fele."
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.
A pc játékgépek azoknak valók akik még nem nõttek ki a "nekem van erõsebb gépem bibí" korból. Ha nem játékra kell akkor nem kell annyira erõs pc, nyugodtan lehet 5 évente fejleszteni pct, 5 évente konzolt. De használhatóság miatt a legjobb egy notebook.
Nekem mint a temaban laikusnak magyarazza mar el valaki, hogy most jonnek lassan a 4-8-16 magos procik itt vannak szinte maholnap, miert nem lehet 1-1 szimplan magra bizni a fizikat?
egyébként szvsz nem gáz, hogy a Havok az INtelnél van, már most több mûködõ alternatívája van.Sony pl ODEt licenselte PS3 hoz, amellett a Physics SDKja is nagyon igényesen van megcsilva, meg még van egy csomó cucc Bullet, Newton meg hasonlók, de ezek minõségérõl nem szólnék.
egy ferrari 10 év múlva is ferrari egy quad slihez 2 év se kell hogy elavuljon, azért hülyeség quad slit venni mert sokkal nagyobbat bux rajta, mintha vennél egy középkategóriás kártyát és azt cserélgetnéd újabbra meg újabbra(úgy hogy közben arányaiban is kevesebbet veszít értékébõl, ergo jobban eladható) . Az SLI parasztvakítás, akkor inkább már tényleg konzol...
Vector szorzo az a fizikai proci ugyan úgy, mint a GPU, csak GPU-ban van még pár felesleges egység :)
Ezért hülyeség, egy majdnem GPU-t pluszba berakni.
Szerintem egyszerûen új mérnökök kellettek az Intelnek, és így könnyebb volt õket felvenni :)
Nem temettem én a Havokot, csak azt mondom, hogy esetleg kisajátíthatja az Intel. Ott hibádzik kicsit az érvelésed, hogy a Havok FX-et (csak ez a rész ismeri a GPU-s gyorsítást) egyelõre kevés játék támogatja. Nincs olyan sodra, ami elvinné az Intel hajóját is. Inkább az Intelnek kell majd komoly marketingtevékenységgel létrehoznia ezt a sodrást. Így majdnem olyan lesz ez a dolog, mintha a Havok FX egy új szoftvercsomag+API lenne, amit nem feltétlenül oszt meg egy cég a konkurenseivel. Legalábbis a mérleg mindkét serpenyõjében vannak érvek. Amik a kisajátítás mellett szólnak: 1. Ha a Larrabee elég jó lesz, eladja az magát. Na meg az Intel marketinggépezete és piaci nyomásgyakorlási képessége. 2. Az AMD és az Nvidia meg nekiállhat sajátot írni, ami évekbe telik.
De az is lehet, hogy meghagyják az AMD/Nvidia támogatást, csak kicsit majd mostohán kezelik. :) Fõleg ha már kellõ piaci részesedést értek el, ahogy írtad. Amúgy már azzal, hogy a felvásárlás miatt ez potenciális veszély, eleve arra kényszerül az AMD és az Nvidia, hogy saját megoldások után nézzenek... Tehát ezzel valószínû eleve elrontotta az Intel a "közös nagy bulit", ahelyett, hogy diszkréten csatlakozott volna.
Talán erre, plusz arra gondol Huang, hogy a puszta támogatás eléréséhez még nem kellett volna feltétlenül felvásárolniuk a céget.
A Larrabee-vel egyébként a GPGPU fronton is nyomulni akar az Intel.
Ja, az Intel jópár GPU fejlesztõt "vásárolt fel" innen-onnan... :)
Sztem nem ártana ha VGA -ba szerelnének fizikai gyorsítót is, akár a grafikai teljesítmény csökkenésének árán is. A prociknak meg megkéne hagyni az AI számításokat, vagy valami megosztást, márha lehetséges... legalábbis ez az én elképzelésem.
Mar mashol leirtam mi a physx baja. A legnagyobb gond, hogy a fizikai gyorsitas messze van a grafikai megjelenitestol. A messze itt nagy kesleltetest jelent, mivel minden kepkockahoz eloszor a cpu-nak el kell kuldenie az adatokat a ppu fele, kivarnia amig kiszamolja az uj adatokat, majd a cpu visszahozza es elkuldi a gpu fele.
Ezzel szemben a dx10 geometry shader-e pont erre (is) jo. Az elso lepesben a gpu kiszamolja az uj vertexeket (deformalodasok, ruhaanyagok, roncsolodas, reszecskek), majd kirajzolja oket, vegul kiszamolja a fizikat es vagy tovabbkuldi azokat a cpu fele (utkozesek) vagy visszairanyitja az elso lepes fele (reszecske effektek). Igy a cpu tenyleg csak a jateklogikat kezeli. Ennek primitiv 2d-s implementacioja volt a hardveres sprite utkozes kezelese a regi mikrogepeken. (pl. c64) Ez tunik a jo megoldasnak, es mindossze annyi kell, hogy a gpu kepes legyen uj vertexeket felvenni. Ezt a feature-t hivjak geometry shader-nek, es az osszes uj dx10-es jatek kepes lesz hasznalni, meghozza egyseges feluleten.
Az intel larrabee-jenek egyebkent szurkolok, mert ha bevalik akkor egy nagyon konnyen programozhato es barmire alkalmas altalanos cpu tombot kapunk. Ha eleg sok van beloluk, akkor az utolso dedikalt hardveres egyseget is ki lehet dobni a gepekbol. Ilyen volt a xerox parc alto gepe is, ahol a videokartya csak egy ramdac-bol allt es minden grafikat a cpu egyik szala szamolt hyperthreading-ben valtogatva a feladatokat.
Idezet a cpu leirasabol: (1972-bol!!!) "The Alto's CPU was a very innovative microcoded processor which used microcode for most of the I/O functions rather than hardware. The microcode machine had 16 tasks, one of which executed the normal instruction set (which was rather like a Data General Nova), with the others used for the display, memory refresh, disk, network, and other I/O functions. As an example, the bit map display controller was little more than a 16-bit shift register; microcode was used to fetch display refresh data from main memory and put it in the shift register."
Porsche, Ferrari, és egyéb sportautók überLOL. Ki az az állat, aki ilyet vesz? Sokat fogyaszt, drága, kényelmetlen , kicsi, nem lehet bele pakolni rendesen, pattog a rosszminõségû úton, fennakad az úthibán, könnyen ellopják, drága a szervíze, ha elromlik, 10x annyiba kerül rá akár egy gumi is stb..... Különben is a városban csak 50-nel lehet menni. Semmi értelme. Értelmes célokra tizedéért van a legtöbb igényt kielégitõ szintén akár 240-el is menni képes autó. Na és mégis veszik az emberek , de vicces... :)
Azért ne temesd a Havokot, szerintem szó sincs errõl. Az AMD és az Nvidiának természtesen nem teszik hogy az Intel meg akar jelenni egy olyan piacon ahol eddig nem volt ott és a két cég feloszthatta egymás között, persze hogy nem örülnek egy erõs harmadik érkezésének. Az Intel idáig csak az office és mobil szegmensnek gyártott GPU-t, de most úgy tûnik idõvel belevág a gémer szegmensbe is, elõször gyaníthatóan a közép kategóriát megcélozva késõbb, talán a felsõbb kategóriában is megjelenve. Az Intel ezt nem felvásárlással éri el mint az AMD, hanem inkább saját fejlesztéssel, ami persze hosszabb idõ, szóval 3-5 év biztos kell neki mire kifutja magát.
"Igazából nem értem, miért vásárolták fel ezt a céget" - mondja az Nvidia vezérigazgató. Ugyan már ki hisz neki. Tökéletesen tisztában van azzal milyen tervek dédelget az Intel.
A Havok tuti nem azért kell az Intelnek mert tönkre akarja tenni, egyszerûen nem érdeke, neki ez pont azért kell hogy piacra tudjon lépni. Gondolj bele ha az Intel kijön 2009-ben egy új hardwarrel, software támogatás nélkül akkor hogy lehet majd a gémer piacon eladni? Sehogy. De mivel új piaci belépõ, ezért nem igazán fejleszt még rá senki, azért mert túl kicsi a piaci részesedése, azért nem éri meg a fejlesztõknek hogy rá építsenek. És ez 22-es csapda, hisz addig nem is tud kitörni amíg nincs szoftware támogatás és ez által a játékok sem támogatják a használatát.
Az Intel ezért inkább megvette a Havokot, és mint tulaj nyomást tud gyakorolni a fejlesztõkre hogy tegyék bele a saját sokmagos procijainak és Larrabeejának támogatását akkor is ha annak még zéró piaci részesedése van a gémer szegmensben. És ezzel meg tudja alapozni a jõvõt, hisz szoftwarrel már a hardware is jobban eladható, a nélkül viszont csak papírnehezék.
Abban nem érdekelt az Intel hogy kivegye a Havokból a konkurens termékek támogatását, vagy hogy megszünetesse a terméket. Hisz ha ezt tenné és lenne egy software ami csak az õ hardwarét támogatja, ami még új piaci belépõ, akkor szerinted hány játékba építenék be? Semennyibe, hisz nem igazán lenne eladható. Az Intelnek mint új piaci belépõnek az AMD és Nvidia farvizén kell behuznia a palettára a Larrabeet, olyan middlewaret kell írnia ami a már most támogatott konkurenseken kívül a saját termékét is támogatja, így esélye nyílhat arra hogy az õ terméke is beléphessen a piacra.
Persze nagyon hossszú távon, amikor már az Intel terméke is hasonló részesedéssel bírna mint az AMD és az Nvidia, már elõnyt kovácsolhatna abból hogy kirekesztené a konkurenseit. De ez még oly távol van, legalább egy évtized. Ráadásul addigra már szerintem nem is lesz szüksége az Intelnek a Havokra, neki csak addig kell amíg a piacra lépést ezzel meg tudja alapozni, utána már szerintem túl fog adni rajta.
Dez, a felvilágosító központ. Na most már minden vili, ugye? GPU folding, emberek, GPU folding! Csak egy példa arra, mi mindenre alkalmas egy videokari... :)))
Tisztázzuk: a Havok FX egy szoftver (volt?), egy fizikai motor, ami a GPU-t használta a számítások gyorsítására.
"A játékok 98% nem támogatja"
Nem tudok róla, hogy külön támogatás kell minden játékba. A drivernek kell ismernie az adott játékot, és az optimális módot kiválasztani, stb. De tudtommal már kézzel is lehet csinálni profilokat.
"akkor meg mit csináljon az egyszeri gamer egy gyorsítókártyával... tegyem be a gépbe csak azért, hogy még 1 ventilátor pörögjön. Bah, hagyjuk."
Pl. az egyik kártyát be lehetne fogni a fizikára...
Nem lesz a GPU-n belül fizika-proci, hanem a GPU számoló egységei erre is be lesznek fogva. Már ha lesz hozzá szoftver, ugyanis az Intel éppen lenyúlta.
"Az AMD, NVIDIA -nál meg mi az az álszeteskedés , miért nem ünnepelnek, hogy nem lesz fiz. proci ?" Éppen hogy így nagyobb lesz az igény pl. a Physixra, ami számukra konkurencia, mert a GPU alapú fizikázás lehet most elgáncsolva egy idõre.
"Inkább attól félnek, hogy az Intel komoly GPU -t fejlesztet majd az így szerzett mérnökökkel :)" A Havoknál nem GPU tervezõk dolgoztak. Az Intel Larrabee GPU-jától meg már eddig is lehetett tartani. Miért örülne annak az AMD és az Nvidia, hogy majd az Intel jól a Larrabee-re optimalizálja v. teszi kizárólagosan azon használhatóvá a Havok FX fizikai motort?
"Vagy AMD,NVIDIA szerette volna, hogy mindenki felesleges fiz. karit akarjon ?.." Miért szerette volna?
"sokszoros SLI is überLOL. Ki az az állat, aki *csak játékra* ilyet vesz?"
Akinek világszínvonalú fizetése van, és nem gond ennyit költeni a hobbijára. Mert pl. van egy jó nagy monitorja, és kicsit zavarja, hogy az újabb játékok fps-e le-le esik ilyen 10-re.
"Értelmes célra természetesen használhatatlanok az ilyen gépszörnyek." GPGPU alkalmazásokra nagyszerû. Ha tudnád, mi az, ugye.
El vagy keveredve. Nem keresek sokat, mégis kettõt is vehetnék, ha akarnék bármikor... de minek??? Felesleges, értelmetlen. A játékok 98% nem támogatja, akkor meg mit csináljon az egyszeri gamer egy gyorsítókártyával... tegyem be a gépbe csak azért, hogy még 1 ventilátor pörögjön. Bah, hagyjuk.
Nem hülyeség egyébként a fizika proci. Tehermentesíthetné a procit. Csak fele ennyit sem ér. De amúgy jó. Meg ha lenne esetleg támogatása. Meghát, a legtöbb ember aki gépet fejleszt, eléggé a pénze határán jár... Nem hiányzik hogy minden játék csak fiziksz karival menjen. :)
Az az "állat" vesz ilyet aki megengedheti. Az meg aki nem annak marad az az ilyen hozzászólás írása mint a tied
Külön fizikai processzor baromság. (kb. DAC nélküli 3D videó kártya) Az AMD, NVIDIA -nál meg mi az az álszeteskedés , miért nem ünnepelnek, hogy nem lesz fiz. proci ? Inkább attól félnek, hogy az Intel komoly GPU -t fejlesztet majd az így szerzett mérnökökkel :) Vagy AMD,NVIDIA szerette volna, hogy mindenki felesleges fiz. karit akarjon ?..
Talán nem kéne mesterségesen generált, fiktív, betegesen pazarló "igényekre" játszani, akkor nem buknának nagyokat.
sokszoros SLI is überLOL. Ki az az állat, aki *csak játékra* ilyet vesz? Értelmes célra természetesen használhatatlanok az ilyen gépszörnyek.
Informatika és tudomány
