63
-
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. -
dez #53 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. -
dez #52 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. -
floatr #51 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... -
dez #50 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. -
dez #49 Számszerűsítenéd azt a "jó már"-t? -
floatr #48 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. -
Yv@n #47 Igen. nvidiának hívják :)
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. -
dez #46 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. -
dez #44 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. -
floatr #42 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. -
dez #41 Kicsit lassú a felfogásod. -
dez #40 Ez nem lenne túl hatékony megoldás... Lásd hsz #38. -
dez #39 Ott valami gáz van. -
dez #38 Amiért a grafikát sem lehet. 1 CPU mag: 10 GFLOPS, 1 mai csúcs GPU: 4-500 GLOPS... És ez csak a shader teljesítmény, van ott más is. -
dez #37 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. -
dez #36 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. -
dez #35 Ki beszél itt erről? Mi lenne ha olvasnál is (#10), nem csak írnál? Nagyon rossz szokás egy fórumozótól! -
irkab1rka #34 köcsögök, miért nem vettétek meg ti :) most már késő.
beeeeee
-
toto66 #33 10 év múlva
A gyerekenek megmutatjuk hogy milyen is volt... Egy Vista emulátorral -
endale #32 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ő. -
sanner011 #31 LOL x) -
orkaman #30 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.
-
floatr #29 Majdnem olyan sokan veszik h az már szinte nyereséges :)
dez: "világszínvonalú fizetés"... wow, ismét -
Yv@n #28 "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. -
Jonah #27 "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.
-
#26
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. -
#25
..éshát ismerjük az intel piaci magatartását :(
'végünk' -
fixpont #24 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? -
feamatar #23 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. -
feamatar #22 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...