Új hozzászólás Aktív témák
-
Auratech
őstag
Érnek a dolgok. Lassan megtanuljuk kimondani azt hogy larrabíí
Érdekes lesz, amikor a gpu-k és a cpu-k ugyanúgy 64 magosak lesznek és képesek lesznek ugyanazt a kódcsoportot futtatni. A cpu nativan dx11-es lesz a gpu meg bedolgozik a cloud-ba az open cl-en keresztül.
Lehet hogy csak a feliratot fogják cserélgetni a c/gpu-n?Videokártya helyett lesz General Processing Extension GPE
-
#97
shabbarulez
őstag
shabbarulez
őstag
Detailed Larrabee Die shot shown by Intel [link]
-
Auratech
őstag
Ma is kaptunk egy kis adalék infot a várható prociról. A korábban hozzászóók elmondásai alapján veszi fel az intel a kesztűt.
"Nehogymá a processzoraik csak az oprendszerek futtatására maradjanak. A többire meg ott a zsíros gpu "
Csak az a baj, hogy piásan nem lehet komondani azt, hogy larrabee. Az hogy Ati, meg intel, az könnyű kiolvasni, de azt, hogy larrabee, az kutya nehéz
-
#95
Auratech
őstag
shabbarulez
#94
Auratech
őstag
válasz
shabbarulez
#94
üzenetére
Kétéves távlatról beszélsz körülbelül. A larrabee piaci bevezetése csak a virtualizációs folyamat katalizátora lesz. Megjelenése után a gpuk-nak kötelező lesz általános feledatokat végezni egységes (talán openCL) rétegen keresztül. A sokasodó magokkal dolgozó processzorok feleslegessé teszik az alaplapi gyengusz igp-t. A larrabee lassú víz partot mos alapon minden számítási eszközt gyártót kényszeríteni fog az általános használatra. Ami különbséget fog tenni a hardverek között, az a szabványok beemelésének sebessége. Látok Dx11-es CPU-t, x86-64-es shadereket, meg egy bazi nagy felhőt
Szerintem simán látszik a szerveroldali erőforrások forradalmán, hogy leszűrődik a dedikált felhasználókig a technológia. A játékok kikényszerítették a sokszálú utasításkezelést. Egy videokártyában kicsiben hasonló zajlik, mint egy mainframe gép munkája egy hatalmas adatbázison. A végeredmény ott a valóságra hajazó interaktív képi világ, emitt a gazdaságot mozgató erők értelmezhető leképezése. A géplélek evolúcióját láthatjuk: mechanika, elektronika, információ feldolgozás, adattárolás. Amint elég struktúrált lett, magába szippantotta a telekommunikációt, most kajázza a sugárzott médiát és folyamatosan támadási pontokat keres az emberi lélekben. Mindig a meglévő struktúrákat használja fel tehnológiai áttörésekre, ahogy a telefonvonalakat a net. És ez jó így, mert legalább ellenerőket kell kifejlesztenünk ott, ahol a géplélek egyenlőre tehetetlen. A teremtő képzelet földjén. Larrabee, én így szeretlek! -
#94
shabbarulez
őstag
Hakuoro
#90
shabbarulez
őstag
Véleményem szerint azokra a piacokra ahova a Larrabeet szánják nem fog olyan nagy gondot okozni hogy drága gyártani. Elsősorban a HPC piacon fog ez domborítani, ahol a GPGPU-k megjelenésével szemben meg tudja majd védeni az Intel eddigi pozícióit. A másik a grafikus munkaállomás piaca lesz, ahol új szereplőként kell majd piacot szerezni az amd/nvidia páros hasonló termékeitől. Minkét piacon a software lesz a döntő szempont, ahogy ezt már korábban is fejtegettem. A harmadik már 32nm-en szerintem a Sandy Bridge mellé integrálva leválthatj az eddigi GMA-t, mondjuk egy 8 magos Larrabee tömb bőven elég lesz IGP-nek. Az ezen a piacon jelentkező GPGPU jelenlét erősődése megint egy olyan tényező ami az Intelt piacai megvédésére sarkallja. A játék piac szerintem csak ez után fog következni és nem lesz túl nagy szerepe. Ebben a piacban messze nincs annyi bevétel, profit meg méginkább mint amit az előbb felsorolt háromban veszteni lehetne a pozíciók erősítése nélkül. A Larrabee még hosszú ideig nem lesz egy játékosonak szánt piacvezető chip, ezzel az Intel mindig is tisztában volt. A GPU-k ára nagyon nyomott így a bevétel csekély a profit meg minimálisabb már ha épp van. Ezzel szemben a HPC vagy workstation piacon megfelelő prémium felárak mellett lehet a terméket értékesíteni és oda jobban ia passzol a Larrabee felépítése.
-
Auratech
őstag
Az adatáramlást a virtualizált processzusok közt egyfajta per-to-peer struktúra oldhatja meg a beépített redundanciával és dinamikus áramlási modelljeivel. A host gépek afféle árnyló processzorként, a memória meg cache-ként vesz részt a a nagy varázslatban.
Az egyik elment vadászni, ez meglőtte, ez hazavittte.... -
Auratech
őstag
Nekem is szivem csücske a larrabee megjelenése. Szerintem a dx11 nativ futtathatósága és a larrabee x86-os kompatibilitása egy felé mutat. Le akarják nyomni a cuda és stream computing konkurenciát. Azok pedig az openCL implementálásával és elért helyzeti előnyükkel piacon maradhatnak. Nem véletlenül akar az N-vidia x86-os procit csinálni (és fog is, [megvette a VIA-t]) Az Ati(amd) rendelkezik x86-os licensszel.
A gpuk és cpuk funkcióinak fúziója egyértelműen látható. Egyenlőre elkülönült funkciókkal, majd hangsúly eltolódással, végül közös rétegen dolgozik minden számítási erőforrás. A virtualizáció oldja meg a közös munka szervezését.
Ahogy a most megjelent VirtualBox 2.2 hardveres open GL támogatást ad.
Ez nekem két hónapja napi őrületem. Most Működik egy host xp ATI4850-el, minden funkciójával.És működik egy virtualis xp (8800gts-el a második slotban) Nvidia gpu támogatással, cuda-val, phisycs-el. Stabilabban mint a korábbi xp-n belüli, öszvér megoldással, ami szintén működik, ha a virtuális gép nem foglalja a gpu-t.
A larrabee ezt a hőskorszaki trükközést teszi a múlttá. A virtualizált környezetben a dos/multitasking váltáshoz hasonló paraigmaváltás zajlik. Prekognitív polythreading. Ez a jövő. És a hálózatok sebességének növelése sem a gyorsabb video továbbítást szolgálja. A lokális sebességek (100-10000Mbit..és a következők) hálózatra költöztetése szintén a virtualizációt érlelik. Az erőforrások határai elmosódnak. Az igénybe vehető számítási teljesítmény feladatfüggően, magától értetődően rendelkezésre állhat, mint az információ ma. A közösségi oldalak kapcsolatainak mintájához hasonlóan a hasonló szoftveres erőforrásokkal ellátott gépek társulnak hasonló feladatokra. Olyan mintázatokat mutatva, mint az agy funkciófüggő MRI képei. Csak nagyságrendekkel gyorsabban és összetettebben. -
gV
őstag
-
vers
tag
nem csoda a larrabee, egy ati gpu megeszi reggelire
méghozzá azért mert az ideális fogyasztás/frekvencia tartomány 600-1000mhz-es sávban van , és ebben az esetben lehet a legtöbb tranzisztort ráapplikálni a chiprea cell egy nulla ha gfx-rol van szó , viszont fizika , ai, egyéb müveletekben nagyon jo
a larrabbe sem lesz más -
P.H.
senior tag
The multi-media extensions in today’s mainstream processors implement vector operations only in a limited fashion. Vector instructions are characterized by large numbers of operations which are performed as the result of one instruction (Single Instruction Multiple Data, SIMD). Compared with scalar operations, this can be said about the multi-media instructions, but it is a far cry from what vector computers like the Cray-1 or vector units for machines like the IBM 3090 did.
To compensate for the limited number of operations performed for one instruction (four float or two double operations on most machines) the surrounding loops have to be executed more often. The example in section A.1 shows this clearly, each cache line requires SM iterations.
With wider vector registers and operations, the number of loop iterations can be reduced. This results in more than just improvements in the instruction decoding etc.; here we are more interested in the memory effects. With a single instruction loading or storing more data, the processor has a better picture about the memory use of the application and does not have to try to piece together the information from the behavior of individual instructions. Furthermore, it becomes more useful to provide load or store instructions which do not affect the caches. With 16 byte wide loads of an SSE register in an x86 CPU, it is a bad idea to use uncached loads since later accesses to the same cache line have to load the data from memory again (in case of cache misses). If, on the other hand, the vector registers are wide enough to hold one or more cache lines, uncached loads or stores do not have negative impacts. It becomes more practical to perform operations on data sets which do not fit into the caches.
Having large vector registers does not necessarily mean the latency of the instructions is increased; vector instructions do not have to wait until all data is read or stored. The vector units could start with the data which has already been read if it can recognize the code flow. That means, if, for instance, a vector register is to be loaded and then all vector elements multiplied by a scalar, the CPU could start the multiplication operation as soon as the first part of the vector has been loaded. It is just a matter of sophistication of the vector unit. What this shows is that, in theory, the vector registers can grow really wide, and that programs could potentially be designed today with this in mind. In practice, there are limitations imposed on the vector register size by the fact that the processors are used in multi-process and multithread OSes. As a result, the context switch times, which include storing and loading register values, is important.
With wider vector registers there is the problem that the input and output data of the operations cannot be sequentially laid out in memory. This might be because a matrix is sparse, a matrix is accessed by columns instead of rows, and many other factors. Vector units provide, for this case, ways to access memory in non-sequential patterns. A single vector load or store can be parametrized and instructed to load data from many different places in the address space. Using today’s multi-media instructions, this is not possible at all. The values would have to be explicitly loaded one by one and then painstakingly combined into one vector register.
The vector units of the old days had different modes to allow the most useful access patterns:• using striding, the program can specify how big the gap between two neighboring vector elements is. The gap between all elements must be the same but this would, for instance, easily allow to read the column of a matrix into a vector register in one instruction instead of one instruction per row.
• using indirection, arbitrary access patterns can be created. The load or store instruction receive a pointer to an array which contains addresses or offsets of the real memory locations which have to be loaded.
It is unclear at this point whether we will see a revival of true vector operations in future versions of mainstream processors. Maybe this work will be relegated to coprocessors. In any case, should we get access to vector operations, it is all the more important to correctly organize the code performing such operations. The code should be self-contained and replaceable, and the interface should be general enough to efficiently apply vector operations. For instance, interfaces should allow adding entire matrixes instead of operating on rows, columns, or even groups of elements. The larger the building blocks, the better the chance of using vector operations. In [11] the authors make a passionate plea for the revival of vector operations. They point out many advantages and try to debunk various myths. They paint an overly simplistic image, though. As mentioned above, large register sets mean high context switch times, which have to be avoided in general purpose OSes. See the problems of the IA-64 processor when it comes to context switchintensive operations. The long execution time for vector operations is also a problem if interrupts are involved. If an interrupt is raised, the processor must stop its current work and start working on handling the interrupt. After that, it must resume executing the interrupted code. It is generally a big problem to interrupt an instruction in the middle of the work; it is not impossible, but it is complicated. For long running instructions this has to happen, or the instructions must be implemented in a restartable fashion, since otherwise the interrupt reaction time is too high. The latter is not acceptable. Vector units also were forgiving as far as alignment of the memory access is concerned, which shaped the algorithms which were developed. Some of today’s processors (especially RISC processors) require strict alignment so the extension to full vector operations is not trivial. There are big potential upsides to having vector operations, especially when striding and indirection are supported, so that we can hope to see this functionality in the future.
([link], 8.4.: Upcoming Technology: Vector Operations)
Amit kiemeltél, az miben mond ellent annak, hogy "összességében lehet számítani erősen visszafogott cache-koherencia megvalósításra"?
-
dezz
nagyúr
Hát tudod, elég ritka lehet az az eset, amikor olyan kevés adattal dolgozunk, hogy az éppen elfér a regiszterekben, és nincs szükség a cache-re...
Idéznék néhány ide vonatkozó részletet a wikis oldalról:
"Larrabee includes explicit cache control instructions to reduce cache thrashing during streaming operations which only read/write data once.[7], explicit prefetching into L2 or L1 cache is also supported.""Each computer core in the Cell (SPE) has a local store, for which explicit (DMA) operations are used for all accesses to DRAM. Ordinary reads/writes to DRAM are not allowed. In Larrabee, all on-chip and off-chip memories are under automatically-managed coherent cache hierarchy, so that its cores virtually share a uniform memory space through standard load/store instructions. However, Larrabee cores each have 256K of local L2 cache, and other L2 segments take longer to access, which is somewhat similar in principle to the Cell SPUs."
"Because of the cache coherency noted above, each program running in Larrabee has virtually a large linear memory just as in traditional general-purpose CPU; whereas an application for Cell should be programmed taking into consideration limited memory footprint of the local store associated with each SPE (for details see this article) but with theoretically higher bandwidth. However, since local L2 is faster to access, an advantage can still be gained from using Cell-style programming methods."
"Cell uses DMA for data transfer to/from on-chip local memories, which has a merit in flexibility and throughput; whereas Larrabee uses special instructions for cache manipulation (notably cache eviction hints and pre-fetch instructions), which has a merit in that it can maintain cache coherence (hence the standard memory hierarchy) while boosting performance for e.g. rendering pipelines and other stream-like computation."
"Though Larrabee Native's C/C++ compiler includes auto-vectorization and many applications can execute correctly after recompiling, maximum efficiency may require code optimization using C++ vector intrinsics or inline Larrabee assembly code."
-
P.H.
senior tag
"Pl. minimalizálni a memória-hozzáféréseket, azaz amennyire lehet, cache-ből/-ben dolgozni, hozzáférés esetén előre beolvasni 1-1 blokkot (erre külön új pre-fetch vezérlő és egyéb cache-kezelő utasítások vannak, amiket többnyire kézzel kell beleírni a kódba)[...]
A Larrabee erőssége pont az lehet, hogy amennyiben megtartják a 64 byte-os cache-line méretet, akkor az 512 bites végrehajó egységek mellett nincs szükség ilyen jellegű "speciális" optimalizációra ill. külön prefetch utasításokra: az 512 bites feldolgozás esetén egyrészt a mem->cache előbetöltés helyett lehet közvetlen mem->regiszter load is, tárolásnál pedig a temporal/non-temporal eset csak abban különbözik, hogy hova (globális memória/ring vagy pedig lokális/cache azonnali újrafelhasználás esetén) megy a tárolás, eltérve a jelenlegi x86-megoldásoktól, ahol pl. több, maximum 16 byte-os utasításeredményből kell összerakni egy cache-line-t.
Mivel a 64 byte-os kimenetek nagy valószínűséggel más szálak bemenetei lesznek a párhuzamosságra törekvés miatt, így a cache-koherencia jobbára csak skalár műveleteknél játszhat, ezért összességében lehet számítani erősen visszafogott cache-koherencia megvalósításra, főképp a skalár esetek kis száma miatt.
Területben nézhetjük az Atomhoz, csak ugye az egységeknek nem kell(ene) pl. komplex decoder, külön TLB-k, kiesik pár x86-mód (valószínűleg csak a flat módot fogja ismerni a saját memóriájában, a rendszerszintű védett memóriakezelés a driver dolga marad), stb...
-
dezz
nagyúr
"Larrabee will also feature 64-bit operations, which makes us believe that the mentioned 2TFLOPS might very well be double precision."
Ilyenek után én nem nagyon alapoznék arra, amit ott írnak...
Mindenesetre, az a 2 GHz egy elméleti érték. Még ha tudja is önmagában 1-1 mag (ami még nem biztos), a gyakorlatban elérhető órajelet a hőtermelés, ill. az alkalmazott hűtés határozza meg. Még nem készült el a chip, így mindez egyelőre bizonytalan.
Az eredetileg tervezett 32 mag@45nm törölve lett, az új cél a 48 mag@32nm. Ez 1.5x annyi mag... Miközben a 45nm->32nm váltással nem feltétlenül esik drasztikusan a fogyasztás. Ez is lefelé húzhatja a majdani órajelet.
A 45nm-es Cell már elkészült, 4-4.5 GHz-es órajelekről lehet hallani, moderate fogyasztás mellett. Így a 32nm-esnél további jelentős órajel emelés várható.
-
gV
őstag
(látom, nem érdemes előre túl sokmindent leírni, csak ismételheti az ember magát ): Abban nincs 1-ciklusos 512 bites vektor egység. És ott a hőtermelés sem probléma, hiszen elég kicsi, de itt a sok kicsi sokra megy (+ a vektor egység fogyasztása).
valóban, de nem csak nekem kell leírnod, mert mások is az én véleményemen vannak [link]
-
dezz
nagyúr
"van már 2GHz-es Atom nem hiszem h gond lenne elérni ezt az órajelet a Larrabeenek"
(látom, nem érdemes előre túl sokmindent leírni, csak ismételheti az ember magát
): Abban nincs 1-ciklusos 512 bites vektor egység. És ott a hőtermelés sem probléma, hiszen elég kicsi, de itt a sok kicsi sokra megy (+ a vektor egység fogyasztása).A Z550 64 bitet sem tudja. [link]
"hány tranzisztorból áll egy cell SPE?"
21 millió.
(#67): "nem biztos h a Larrabee magjai nagyobbak az ugyanis a 3 millió tranzisztoros P54-ből +AVX+a nagyobb cacheből áll"
Ez a képlet teljesen helytelen. 1. A P54C (ami uarch szempontból alapvetően P5 család) max. órajele 120 MHz volt, és nem csak a csíkszélesség/hőtermelés miatt; term. még nem is hallott a 64 bitről és HW SMT-ről sem. Tehát itt egy teljesen új maggal van dolgunk, aminek az őse a P5 uarch. 2. Az 512 bites AVX szép helyet foglalhat, főleg hogy a 4-way SMT miatt 4 regiszterkészlkettel is rendelkezik. 3. Egy teljes L2-vel bővült a dolog, az ugyanis nem volt.
Nézzük csak meg az Atomot (Silverthorne, ami még 32 bites):
Core + L2&L2 tag = ~44500 tranyó. (Kicsit meghízott a 3 millióhoz képest!
) A Larrabee-ban fele ennyi a L2, úgy számolva ~29100 tranyó. De ebben még nincs benne az 512 bites AVX...Nézzük a területben. Ugyancsak IO, Fuses, PLL nélkül az Atom 3.1*(3/5) * 7.2 = ~13.4 mm^2. Fele L2-vel számolva: 13.4*(1-1/5) = ~10.7 mm^2. De hozzájön még az 512 bites AVX. A 45nm-es Cell 1 SPE-je 6.54 mm^2.
Szóval szerintem elmondhatjuk, hogy a Larrabee egy magja 1.5-2x nagyobb lesz, mint egy SPE.
(#69) Abu85: Kösz, hogy a #62-es alján elejtett megjegyzésemet teljesen figyelmen kívül hagytad.
Érdekes lesz szemlélni, ahogy az egyre kifinomultabb (és persze egyre több textúrával és poligonnal dolgozó), de valahogy mégsem olyan élethű rasztergrafika lassan átadja a helyét a ray-tracingnek és más, még fejlettebb megoldásoknak... Na akkor jön el a Larrabee ideje! Mármint grafikában, mert összetettebb GPGPU-s alkalmazásokban már előbb is labdába rúghat.
-
Remélem, az AMD is gőzerővel fejleszti az általános számításokra alkalmas cuccosát (lehetőleg olyan felépítésűt, ami végül befutó lesz)!
Egyszer már beleestek abba hibába, hogy elkényelmesedtek a sikerek láttán (K8 vs P4), aztán jött a pofon Core2 néven... Nagyon nem kellene a mostani GPU-k jó szereplése láttán hátradőlni.
Ja, ezt már régen is akartam kérdezni: Az AMD tervez valami komolyabb kapcsolatjavítást a grafikai programok fejlesztőivel annak érdekében, hogy az AMD karikon is legalább nV szinten menjenek ezek? Most rengeteg a bug, komoly sebesség problémák vannak, GPU render sehol sincs, ráadásul a tervező programok fele csak nV-n fut 3D támogatással.
Vagy ez a terep megmarad az nV felségterülete?Köcc!
-
Abu85
HÁZIGAZDA
Persze az R600-at az AMD mérnökök fejezték be, a Drivert meg a Transmeta segítségével írták meg hozzá. Az ATI erre nem lett volna képes önmaga. Ezért mondtam, hogy az NV nagyon jól kitervelte az egészet, csak az a pici homokszem annyira megfogta a gépezetet, hogy bukó lett belőle. Most, hogy a gyártás is ki van szervezve az AMD-nél, nagy a baj, mert talpon marad a banda ... NV-nél pedig közel egy év fejlesztési munka ment kárba, hiszen a CUDA helyett a mérnökök dolgozhattak volna a GPU vonal fejlesztésén is.
rumkola: A DX11 compute shadert mutogatja az NV, hogy grafikailag mire lehet majd használni. Nyilván ez is jelzi, hogy mennyire a GPGPU vonalon gondolkodnak, mert egyszerűen látják, hogy a rendszerük hagyományos GPU-ként már nem versenyképes.
-
Szerintem az Ati nem a Cuda miatt ment volna csődbe, hanem az r600-at adták volna ki félkészen. Így is állati későn jött, és valami olyasmire emlékszem abból az időből, hogy nehézségek voltak a befejezésével.
Az AMD nélkül szvsz nem jutott volna odáig az ATi, hogy a CUDA pofon tudja vágni.#69: Értem, köszi a választ!
-
Abu85
HÁZIGAZDA
Már a múlt év nyara óta az AMD viszi az eladásokat a középkategóriában. A fejlesztőket ez érdekli. A fejlesztőknek küldött kimutatósok alapján egy GT200-ra 9-10 RV770 jutott eladásban, így nem kétséges, hogy a friss piacon az AMD fölényben van. A GF 8-9-cel már kevesen törődnek, mert a DX10 eljárásokra kevesek lesznek. Mindemellett az is nagyon sokat számít a szerződések felbontásában, hog az NVIDIA nem teljesíti a fejlesztők igényeit. Folyamatosan rágják a zöldek fülét, hogy DX10 leírások kellenek, de alig csinál ilyet az NVIDIA. Az AMD viszont ontja magából a DX10 és DX10.1 alapú programozási dokumentációkat, így a programozók csak abból tudnak tanulni. Nyilván ez azt is magával vonja, hogy fejlesztési segítséget is csak az AMD tud nyújtani, mert az NV leragadt a DX9-nél. ... Jelenleg ez a szomorú valóság. Jól gondolkodott az NV csak nem számítottak rá, hogy az AMD megveszi az ATI-t, így tulajdonképpen a CUDA-val kapcsolatos világuralomra törő tervek összeomlottak, pedig pont az ATI-nak kellett volna kapitulálnia.
-
rumkola
nagyúr
Ezt nagyon jól tudom, így igaz. De az meredek, hogy a gef tulajok kisebbségnek számítanak. Mellesleg itthon a 3650 és hasonlók társai fogynak a legjobban, nem a 48xx és pláne nem a felső kategória, persze nyilván ez nem igaz az egész világra.
ÉVEKIG azt hallgattuk, hogy az nv pénzeli a játékfejlesztőket és csak ezért jó a grafkarijuk. Most az intel kapcsán az a szöveg, hogy már nem lehet pénzelni senkit...
hagyjukmár -
Ha esetleg nem is egyértelműen számszerűen a mai napon, de nagyon jól látható, hogy nem az nVidia termékei a "sláger" és jelen pillanatban nem is néz ki úgy a helyzet, hogy ez rövid időn belül változni fog. Egy fejlesztés hosszú távú munka, és aki kicsit előre gondolkozik, az láthatja, hogy nem a G200-as csippek vannak túlnyomó többségben a potenciális vevőknél, és az új vásárlások javát ATi csippes kártyák fogják jelenteni. Ha másból nem, akkor a kártya gyártók szempontjából jól látható. Egyre többen pártolnak el az nVidiától, és szünnek meg az exkluzív nVidia partnerek és árulnak Ati terméket is már.
-
Abu85
HÁZIGAZDA
Gyakorlatilag jól látod. Ugyanazt akarják csak más a megközelítés. De nem a Larrabee felépítésű rendszernek még nincs értelme, mert a hagyományos GPU felépítés jobb eredményeket hoz. Persze ez a jövőben minden bizonnyal meg fog változni, de én továbbra is azt gondolom, hogy a több évvel nem ideális a hardvernek megelőznie a korát. Egyszerűen a Larrabee-re 2010-ben még nem lesz igény, mert senki sem használ szoftver render motort. A többi piacon persze jó lehet a chip.
gV, rumkola: Az a világ megszűnt ahol a pénz dominált. Lehet játékokat venni, de annyira drágán, hogy az nem éri meg (csak a Physx támogatás 5 milla volt a Mirror's Edge-be, és piaci hatása semmi nem volt). A játékfejlesztők arra a hardverre dolgoznak ami elterjedtebb a célközönségnél, ezért bontja fel mindenki a TWIMTBP szerződéseket, mert a Radeonok nagyon gyors ütemben terjednek, egyszerűen ezekre a rendszerekre kell figyelni, mert a GeForce tulajok már kisebbségnek számítanak, az elterjedtség alapján.
A pénz nem minden erre az NV az élő példa. Iszonyatos költségvetéssel dolgozott a TWIMTBP program, és most ott tartanak, hogy a partnereknek kell könyörögni, hogy gyártsanak GeForce-ot.Dr. Akula: Az NV még bele is menne, de hát az Intel nem szereti a konkurenciát.
-
#95904256
törölt tag
"hány tranzisztorból áll egy cell SPE?"
Pontos adatot nem találtam, de egy Cell-ről ( PPE + 8 SPE ) készült fotón a teljes chip kb. 10%-át teszi ki egy SPE. A 90nm-es chipek felülete 220 négyzetmiliméteres, ami kb. 250 millió tranzisztort jelent. Ebből következik hogy kb. 20-30 millió tranzisztorból állhat egy SPE.
-
gV
őstag
Persze nekik majd az lesz az előnyük, hogy a játékfejlesztőkkel jobb lesz a kapcsolatuk, mint az Intelnek.
nem hiszem, az Intel már most is nyomul a játék piacon, most még a procijaival idővel talán havooknak is nagyobb hangsulyt fektet, végül a Larrabeet az előbbi kettőnek köszönhetöen könnyü dolga lesz beadni a fejlesztőknek
dezz: van már 2GHz-es Atom nem hiszem h gond lenne elérni ezt az órajelet a Larrabeenek
hány tranzisztorból áll egy cell SPE? -
dezz
nagyúr
Itt van még egy kis infó: http://en.wikipedia.org/wiki/Larrabee_(GPU)
Bár egy sima újrafordítás után is el fognak rajta futni a dolgok, azonban (legfőképpen a memóriahozzáférési bottleneck miatt) a Cell esetén alkalmazott optimalizációs eljárásokhoz hasonlók (*) nélkül csak igen lassan, egymást hátráltatva. Tehát értelmes teljesítményt ebből sem lesz sokkal könnyebb kihozni.
* Pl. minimalizálni a memória-hozzáféréseket, azaz amennyire lehet, cache-ből/-ben dolgozni, hozzáférés esetén előre beolvasni 1-1 blokkot (erre külön új pre-fetch vezérlő és egyéb cache-kezelő utasítások vannak, amiket többnyire kézzel kell beleírni a kódba); figyelembe venni a ring-busz jelenlétét; és persze sokszorosan párhuzamosítani + SIMD-esíteni kell a számításokat, stb. (Egyébként 256 KB RAM-ból még mindig jobban ki lehet jönni, mint 256 KB cache-ből, utóbbiban minden adat-/utasítás-szóhoz kiegészítő adatok is tartoznak.)
Jóval nagyobbak a magjai, mint a Cell SPE-i, így azonos csíkszélességen a Cell van előnyben számítási teljesítményben.
Nem hiszem, hogy 1.5 GHz-nél jelentősen magasabb órajelen működne, lásd az Atom max. gyári órajele is 1.8 GHz, és abban nincs 1-ciklusos 512 bites vektor egység. (Már ez is szép teljesítmény a frissített, de alapvetően régi mikroarchitektúrától.) Ott a hőtermelés sem probléma, hiszen elég kicsi, de itt a sok kicsi sokra megy.
Bici: Összetettebb feladatokban ez lesz jobb, de ahol a nyers erő számít jobban, ott a GPU-k.
-
Mi a különbség az "egy egyszerű sokmagos processzor", ami "általánosan jó mindenre" és a GPGPU között?
Nem az általánosan használhatóság a célja mindkettőnek, csak különböző API-n keresztül?Nekem kevésbé hozzáértőként az jön le, hogy ugyanazt akarja mindkettő, csak egyik CPU oldalról közelít, a másik meg GPU oldalról.
-
Abu85
HÁZIGAZDA
Konkrétan a GPGPU piacra az NV koncentrál teljes erővel. Az AMD csak részpiacnak tekinti, tehát ők inkább GPU-t terveznek.
A Larrabee az egy egyszerű sokmagos processzor, általánosan jó mindenre, de helyenként lassú lesz, illetve inkább azt mondanám, hogy a konkurens célzottan fejlesztett megoldása jobb lesz.
A szoftveres renderelés visszatértével az Intel nyilván előnyben lesz, mert a Larrabee már jövőre itt lesz, és szarrá tökéletesítik a rendszer, míg az AMD csak pár év múlva jön elő hasonló chippel. Persze nekik majd az lesz az előnyük, hogy a játékfejlesztőkkel jobb lesz a kapcsolatuk, mint az Intelnek. -
Nyilván nem egy középkategóriás változattól várok ilyet az adott konzol megjelenése után két héttel, hanem 2-3 évvel a PS4-5-6 megjelenése után egy csúcskategóriás Larrabee-től (annak utódjától), vagy vele azonos képességű AMD cucctól, akár több kártyával/procival - sli/cf/akármi kiépítésben.
-
Abu85
HÁZIGAZDA
Persze, hogy akarnak hasonló chipet, csak nincs értelme olyan hardvernek, ami 4-5 évvel megelőzi a korát. Speciel az R600 egy évvel volt a kora előtt, és láttad mi lett belőle. Persze utólag megérte, de az elején nem volt versenyképes.
Az Intel azért csinál Larrabee, mert ha csinálna eg normális GPU-t, akkor 4-5 év mire felzárkózik az AMD mögé. Akkorra pedig már kopogtatni fog a szoftver render.
-
R.Zoli
őstag
És mennyire kell az AMD-nek mondjuk majd az akkori RV990 vagy akárhányas GPGPU-ját módosítani ,hogy egy larabee ellenfele legyen?Vagy inkább úgy kérdezem, hogy akarnak-e egyáltalán az AMD-nél a larrabee ellenfelei lenni? Ergo nem látom ,hogy egy kellően módosított jelenlegi AMD GPGPU miben tud kevesebbet mint a larrabee...
-
-
válasz
#06658560
#51
üzenetére
Szerintem ez valahogy úgy fog menni, hogy veszel egy lapot, amin lesz 2-3-több darab valamilyen gyors busz pl. HyperTransport, és abba pakolod be a procikat. Ezek lehetnek akár slot, akár socket formájúak is.
Kérdés, hogy ha egy procit másodlagosként használok, akkor lesznek-e kihasználatlan részei? Vagy lesznek külön master meg slave procik?És az is lehet, hogy ez mind hülyeség, és egész máshogy lesz.
-
#06658560
törölt tag
Ez a nagy integráltság egyébként egy érdekes problémát fog előidézni: ha nekem kevesebb processzorteljesítmény kell, de több GPU teljesítmény, akkor veszek egy "procit". Aztán ha megfordul a dolog, vagy mégtöbb GPU kéne, vehetek egy újat? Biztos menni fog a régi alaplapban? Nem pazarlás ez akkor így? Nem lesz így rengeteg féle párosítás, amiknek kicsi lesz a forgalma, és így nagyon drágává válnak?
-
#49
Bici
félisten
shabbarulez
#48
válasz
shabbarulez
#48
üzenetére
Oks, köszi!
(a többieknek is) -
#48
shabbarulez
őstag
Bici
#44
shabbarulez
őstag
In oder magok vannak benne, így jóval kevésbé komplexek a magok mint az out orderes core2-ek. Ezen kívül nincs benne mmx,sse1-4, meg sok olyan dolog amire nincs szükség. A larrabee alapja egy p54c, ami pentium 1-es még mmx nélküli változat. Persze ez csak egy alap, sok köze nem lesz a végső termékhez, csak ugyanúgy benne vannak a gyökerek mint minden mai x86-os prociban. Pl. a p54c 3 millió tranzisztorból áll, míg pl. egy mai Core2 Duo 410 millióból. Vagyis ha csak bután arányosít az ember, figyelmen kívül hagyva mindent az kvázi azt jelentené hogy egyetlen Core2 Duo helyére 135 PI-et lehetne bepréselni. Persze ennek így sok értelme nincs hisz a PI a régi formájában ma már használhatatlan, a Larrabee mag rengeted kiegészítést pakol mellé(nagyobb L1, van L2, 16 utas SIMD, 4 szálas SMT, gyors vektor végrehajtó egység saját utasításkészlettel, stb)hogy elérhesse végső formáját.
-
#95904256
törölt tag
"inkább sokkal kissebb"
Sokkal kisebb nem lehet, hiszen az ATOM-ot is eleve úgy tervezték hogy minél kisebb méretű legyen. A legjelentősebb különbség is csak abból adódhat hogy az ATOM 512kB-nyi L2 cache helyett csak 256kB-ot kapnak a Larrabee magok, de cserébe az ATOM 64 bites SSE egységéhez képest 512 bites végrehajtókat fog kapni.
"nagyon hasonlo a cellhez , de az 3-4 ghz-en zakatol, igy ha összehasonlitjuk akkor olyan mintha a cellbe lenne 30 proci, ujabb csikszélességen már beleférne valodi 30 mag 3 ghz-en, az simán odakenne a larrabeenak"
Megjegyzem, nincs infó arról hogy a Larrabee milyen frekvencián fog ki jönni. Az 1GHz-et csak példaként, számítási alapként emlegetek. Valójában az is lehet hogy 3GHz-en is fog menni. Ami nem elképzelhetetlen, tekintve a Pentium4, Core2, i7 processzorok is képessek erre.
Másfelől amennyire hasonló a Cell-hez, annyira el is tér.
- a Cell-ben van egy központi processzor, a Larrabee-ban mindegyik egyenrangú.
- a Cell DMA-val éri el a memóriát, a Larrabee magok meg egybe látják
- a Larrabee magok cache koherens lesz, vagyis mindegyik mag rálát a másikra
- a Larrabee magok egyszerre 4 szálat képesek kezelni, a Cell SPE-k egyet -
#44
Bici
félisten
shabbarulez
#42
válasz
shabbarulez
#42
üzenetére
"ugyanannkora szilíciium területre 4x több Larrabee mag fér mint Core2, miközben a teljesítménye közel 4x akkora."
Mit nem tud egy Larrabee mag, amitől ennyivel hatékonyabb?
-
#43
rup1u5
nagyúr
shabbarulez
#42
rup1u5
nagyúr
válasz
shabbarulez
#42
üzenetére
Hát ez érdekes.
Kösz a válaszokat srácok! -
#42
shabbarulez
őstag
rup1u5
#39
shabbarulez
őstag
Még anno a 2007-ben közölt slideokon is rajta volt hogy a Larrabbe magok sokkal kisebbek lesznek mint a Core2 magok. Ezek kis méretű, de nagy párhuzamosságú magok, ugyanannkora szilíciium területre 4x több Larrabee mag fér mint Core2, miközben a teljesítménye közel 4x akkora. Ezért van hogy sokkal nagyobb számítási teljesítményre képes ugyanakkora processzor magméret mellett. Egy felső kategóriás Larrabee nagy valószínűséggel nem lesz nagyobb a ma megszokott felsőkategóriás GPU méreténél. Anno először még 2009 elejére, szóval úgy közel mostanra ígérték a Larrabee megjelenését, ami még 45nm-en készült volna, nagy valószínűséggel 32 maggal. Ez követte volna 32nm-en egy 48 magos utód 2010-be. Most úgy néz ki a 45nm-es változat törölve lett. Persze ugyanúgy ahogy a GPU-kból is csinálnak kisebb shader számú változatott, a Larrabeeből is lesznek kevesebb magszámml bíró változatok, más piaci szegmenseket is megcélozva mint a felső kategória.
-
vers
tag
válasz
#95904256
#40
üzenetére
inkább sokkal kissebb
nagyon hasonlo a cellhez , de az 3-4 ghz-en zakatol, igy ha összehasonlitjuk akkor olyan mintha a cellbe lenne 30 proci
ujabb csikszélességen már beleférne valodi 30 mag 3 ghz-en, az simán odakenne a larrabeenak
csak egy gond van a programozhatoság..., kiba nehéz -
#39
rup1u5
nagyúr
TESCO-Zsömle
#26
rup1u5
nagyúr
válasz
TESCO-Zsömle
#26
üzenetére
Már vártam, hogy mikor fog valaki beszólni!
Bár nem értek hozzá de szerintem az rv770-ben lévő shader proci és egy x86-os proci nem ugyan az/ugyan akkora. C2D-ben a kér mag se sokkal kisebb mint egy rv770. És ebből 80db, plusz tokozás meg hővezető kupak. Nem tudom elképzelni, hogy fog kinézni de kiváncsian várom.
-
#36
Male
nagyúr
Major Major
#34
Male
nagyúr
válasz
Major Major
#34
üzenetére
Ezt csak az Inteltől lehet licenszelni... még jó hogy mindenhová be akarja nyomni.
A hír alapján... elsőre nem jött össze amit akartak... a Larrabee csak azért nem bukik még meg, mert az Intelnek sok pénze van... ha lesz rá elég egy-két évig, akkor lehet belőle valami.
-
#34
Major Major
senior tag
Major Major
senior tag
Csak én kapok hidegrázást attól, hogy a x86 ahelyett, hogy szépen átadná a helyét modernebb architektúráknak, most még a video piacot is be akarja kebelezni?
-
mephi666
nagyúr
válasz
#95904256
#31
üzenetére
majd kiderül mi lesz... bő 10éve szerintem senki nem gondolta, hogy a 3dfx pár éven belül elbukik... erre így lett... az nvidia is anno új dologgal jött elő és bejött neki...
hiába voltak pl a v5 6000-nek brutális adatai, nem hozta a t&l hiánya miatt amit vártak tőle és egy gagyibb gef2 körbeverte 2soron... lehet, hogy ez az intel által felállított irány sem hozza valami miatt majd, amit sokan szeretnének... majd meglátjuk, ha kézzel foghatjuk... addig pedig larabébit se temessük és a mostani gpu-s megoldásokat se majd meglátjuk: "when it's done"... addig meg még sok víz lefolyik a dunán... -
#28
#95904256
törölt tag
TESCO-Zsömle
#26
#95904256
törölt tag
válasz
TESCO-Zsömle
#26
üzenetére
"Senki sem tud semmit, csak dobálóztok itt a hülyeségekkel, mert mindenki milyen viccesgyerek. A topik harmada meg már OFF. Ennek mi értelme??"
Ha OFF-ba rakja, akkor miért ne tegye? Hidd el, unalmasnak tálnád a világot ha mindenkinek olyan arca lenne mint neked. Cserébe mindenki tudna mindent.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Alchemist
addikt
Gondolom, a tervben van egy olyan hátsó gondolat is, hogy nemcsak grafikus renderelésre lesz jó az igen sok x86-os mag, hanem számításigényes, jól párhuzamosítható feladatokhoz is, amihez programozás szempontjából verheti a CUDA alapú rendszereket.
Kérdés, hogy mindez a kis fogyasztásigényű, energiahatékony piacra hogyan törhet majd be... blade szerverekbe még igen jó lehet, de notikhoz megfelelő TDP..?! -
#21
#95904256
törölt tag
raszputyin
#7
#95904256
törölt tag
válasz
raszputyin
#7
üzenetére
"CPU téren x86 forever, mert soha senki nem lesz elég tökös a váltáshoz"
Nem csak x86-os processzorok vannak a piacon. Mindenki azt használja amire úgy gondolja hogy neki a legkedvezőbb, miért kellene váltaniuk?
-
#19
cskamacska
addikt
raszputyin
#7
cskamacska
addikt
válasz
raszputyin
#7
üzenetére
AZ IA64-re gondolsz, amit nagyjából semmi nem támogatott, mert nem volt kompatibilis mással?(MS épp hogy támogatta, legalábbis fejlesztett hozzá oprendszereket)
Ne viccelj, a driveríróknak egy Vista már pokol volt, és 4 év alatt lassan eljutunk oda, hogy rendesen vannak támogatva a 64 bites oprendszerek(vindózok), egy drasztikusabb váltásba belehalna a szoftveripar. -
-
nLali
őstag
-
Abu85
HÁZIGAZDA
Igen ... az árazás az hatalmas talány. De a chip nagyon nagy lesz, így túl alacsony árral nem versenyezhetnek. Én kezdésnek, úgy 2 TFLOPS-ot várok. Az AMD azt már év végére tudni fogja, jövőre meg megy a 3 TFLOPS-ért. És ott van a felépítés előny is, mivel a Radeonok teljesen a DX futószalagra készülnek.
Mike Abrash szerintem azért nyilatkozott szerényen a rendszer teljesítményéről, mert az elmúlt években az Intel idióta marketingesei, forradalmi sebességet és ray-tracing-et ígértek. Nyilván Mike van olyan jó szakember, hogy átlátja a helyzetet és tudja, hogy ezekből egyik sem lesz igaz. Forradalmi lesz a rendszer ez tény, de felkészítette a felhasználókat, hogy ne várjanak túl sokat. -
#95904256
törölt tag
Leginkább annak aki ki tudja használni és / vagy szüksége is van rá.
Nem kis számítási potenciál van banne. Ha jól tudom a 32-48 mag mindegyike 4 szálat lesz képes futtatni ( in-order ), így elég jól lehet majd etetni az 512 bites ( 16 lebegőpontos szám / regiszter ) műveletvégzőket. Ez 1 GHz-es órajel mellett egy jó hatékonysággal kihasználható ~1 TFlops-os számítási kapacitást jelent. Egy 3GHz-es Core2Quad 50-100 GFlops-os teljesítményéhez képest nem olyan rossz...
szerk.: csak 32 magos lesz az első
-
#7
raszputyin
senior tag
Ste
#3
raszputyin
senior tag
Nyomásgyakorlás a szoftveres világra, hogy inkább ezt támogassák?
Amúgy volt már egy hasonló meccs, mikor az Intel megpróbált modernebb és hatékonyabb kódkészletet bedobni a PC világba, ha már úgyis jön a 64 bites átállás. A Microsoft könnyedén leszerelte őket, ha jól emlékszem.
CPU téren x86 forever, mert soha senki nem lesz elég tökös a váltáshoz -
rup1u5
nagyúr
na ez az, hogy 5-6 év. addigra már semmire nem lesz elég egy ilyen elsőgenerációs x86 halmaz. és ha már kezdéskor is kevés a teljesítmény akkor, hogy akarnak profitot kihozni belőle?
Hány raklap x86-os mag fog kelleni ahhoz hogy elérjenek egy gtx 280 szintet?
Én valahogy úgy vagyok ezzel a föltámasztott szoftver rederel mint Besenyő Pista bácsi a kőolajfinomítóval : "Há'nemfognekiksikerüülni!" -
gV
őstag
Bár az Intel a Larrabeere elsősorban grafikus processzorként tekint, az előadásból arra lehet következtetni, hogy a rendszer teljesítménye a DirectX és az OpenGL alatt nem lesz túl meggyőző.
ez attól függ hány maggal jelenik meg 10 alatt biztos így lesz, de ha 24-32-48 akkor már elég lehet a mai 30-40e ft-os vgák ellen, kérdés ha így lesz jövőre meglehet majd kapni 20e ft-ért
(a többieknek is)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- HIBÁTLAN iPhone 14 Pro Max 128GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3523
- LÉZEREZÉS! külföldi billentyűzet magyarra kb. 20-30p alatt!
- GYÖNYÖRŰ iPhone 13 Pro 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3357
- Dell USB-C, Thunderbolt 3, TB3, TB4 dokkolók (K20A) WD19TB/ WD19TBS/ WD22TB4, (K16A) TB16/ TB18DC
- Dell Latitude 3340 Core i3-4005U CPU hibás laptop
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest