Jövőre készülhet el az Intel grafikus erőműve
Jelentkezz be a hozzászóláshoz.
#36
"A larrabee-k eseten annyi memoria buszt tesznek ra amennyik akarnak. A jelenlegi nvidia chipeken is 2-8 fuggetlen csatorna van. Igy akar mindegyik cpu tomb kaphat egy vezerlot."
Ezt a Cellel is meg lehet tenni. Annál is inkább, mert XDR vezérlõje van, amihez sokkal kevesebb vezeték kell. Most is többcsatornás.
"A forditoprogramokat erre talaltak ki. A forditot megirja egy ember, aztan hasznalja tobb szazezer."
Na ne mondd, tényleg? Akkor mondanál egy olyan fordítót, ami automatikussá teszi a cache-manipuláció optimizálást? Csak mert én nem tudok ilyet. Mellesleg a Larrabee-ban a megszokottnál spécibb utasítások vannak erre.
"A masik, hogy ha nem akar valaki jo kodot irni, akkor egyszeruen kihagyja az optimalizalast. Lehet, hogy nem lesz tul gyors a program, de elkeszul idore. Ez utobbi fontosabb a kiadok szamara, mint az optimalizalas."
Az is fontos, hogy ne legyen használhatatlan a kód, szóval elkerülhetetlen az optimizálás. Pontosabban, eleve ezt figyelembe véve kell megírni a kódot. Más szóval, a hagyományos kódok bár elfutnak rajta, de igencsak lassacskán.
"Nem igaz, ez csak az adatok lokalitasatol fugg."
De igaz, egy adott szóhoz tartozó cache-line mindig hosszabb, mint maga a szó, hiszen különféle kiegészítõ adatokat is tárolni kell.
"Pont az ami a cell-nel kotelezo, az x86-osok eseten pedig csak a teljesitmenyt novelo opcionalis megoldas."
Mi kötelezõ? Nem tudom, mire gondolsz.
"Ezert van a jelenlegi rendszereknel 1 orajeles cache es ezert van a larrabee-ben smt, hogy amig az egyik szal var az adatra, addig a masik szal dolgozik."
Igen, a HW SMT kompenzálja az in-order rendszert. Azonban, ennek megvan az ára is: párhuzamosan végrehajtható szálanként külön regiszterbank, ami igencsak megnöveli a magméretet. A Larrabee-nél ráadásul 4 párhuzamos szál van, és gondolom 512 bitesek a regiszterek is.
"Es mindezt teljesen automatikusan, a programozo szamara gondot nem jelento modon teszi."
A gond ott van, hogy az amúgy sem nagy cache-t is 4-felé kell osztani.
"(tehat akar arra is kepes, hogy egy utasitast az egyik szalbol, egyet a masik szalbol hajtson vegre, ezt cell-el nem lehet megoldani, mert csak szoftveres szal valtas van az spe-kben, ami jopar utasitast igenyel)"
Nem baj, mert nincs is rá szükség. A double-bufferes feldolgozás viszont minden további nélkül megoldható, elhanyagolható overheaddel.
"A larrabee-ben pont ezert van smt, hogy ez elony legyen ne hatrany"
Ezt az SMT nem igazán befolyásolja, mivel az a 16 db mûvelet párhuzamosan hajtódik végre.
"tovabba az osszes gpu-ban is ezert van 16-os parhuzamositas az spu-k 2-es megoldasa helyett."
Nem, egyátalán nem ezért. Hanem azért, mert túl sok helyet igényelne, ha több ütemezõ és branch unit lenne. Azaz ez egy kompromisszum.
Az SPU-k 4db SP FP vektormûveletet tudnak párhuzamosan.
"Kar, hogy ehhez ujra kell irni, de legalabb ujraforditani a szoftvert. Ezzel szemben az x86-os kod annyi szalat hasznal amennyit akar, aztan ha van eleg mag, akkor mindegyik kap sajatot, ha nincs akkor futnak kevesebben, multitask-ban. Igy a lassabb gepeken is fut a kod, de ha veszunk egy ujat, akkor magatol gyorsabb lesz minden regi program."
Lásd amit fent írtam. Megfelelõ tervezés és optimizálás nélkül itt is lassú lenne a kód.
Ezt a Cellel is meg lehet tenni. Annál is inkább, mert XDR vezérlõje van, amihez sokkal kevesebb vezeték kell. Most is többcsatornás.
"A forditoprogramokat erre talaltak ki. A forditot megirja egy ember, aztan hasznalja tobb szazezer."
Na ne mondd, tényleg? Akkor mondanál egy olyan fordítót, ami automatikussá teszi a cache-manipuláció optimizálást? Csak mert én nem tudok ilyet. Mellesleg a Larrabee-ban a megszokottnál spécibb utasítások vannak erre.
"A masik, hogy ha nem akar valaki jo kodot irni, akkor egyszeruen kihagyja az optimalizalast. Lehet, hogy nem lesz tul gyors a program, de elkeszul idore. Ez utobbi fontosabb a kiadok szamara, mint az optimalizalas."
Az is fontos, hogy ne legyen használhatatlan a kód, szóval elkerülhetetlen az optimizálás. Pontosabban, eleve ezt figyelembe véve kell megírni a kódot. Más szóval, a hagyományos kódok bár elfutnak rajta, de igencsak lassacskán.
"Nem igaz, ez csak az adatok lokalitasatol fugg."
De igaz, egy adott szóhoz tartozó cache-line mindig hosszabb, mint maga a szó, hiszen különféle kiegészítõ adatokat is tárolni kell.
"Pont az ami a cell-nel kotelezo, az x86-osok eseten pedig csak a teljesitmenyt novelo opcionalis megoldas."
Mi kötelezõ? Nem tudom, mire gondolsz.
"Ezert van a jelenlegi rendszereknel 1 orajeles cache es ezert van a larrabee-ben smt, hogy amig az egyik szal var az adatra, addig a masik szal dolgozik."
Igen, a HW SMT kompenzálja az in-order rendszert. Azonban, ennek megvan az ára is: párhuzamosan végrehajtható szálanként külön regiszterbank, ami igencsak megnöveli a magméretet. A Larrabee-nél ráadásul 4 párhuzamos szál van, és gondolom 512 bitesek a regiszterek is.
"Es mindezt teljesen automatikusan, a programozo szamara gondot nem jelento modon teszi."
A gond ott van, hogy az amúgy sem nagy cache-t is 4-felé kell osztani.
"(tehat akar arra is kepes, hogy egy utasitast az egyik szalbol, egyet a masik szalbol hajtson vegre, ezt cell-el nem lehet megoldani, mert csak szoftveres szal valtas van az spe-kben, ami jopar utasitast igenyel)"
Nem baj, mert nincs is rá szükség. A double-bufferes feldolgozás viszont minden további nélkül megoldható, elhanyagolható overheaddel.
"A larrabee-ben pont ezert van smt, hogy ez elony legyen ne hatrany"
Ezt az SMT nem igazán befolyásolja, mivel az a 16 db mûvelet párhuzamosan hajtódik végre.
"tovabba az osszes gpu-ban is ezert van 16-os parhuzamositas az spu-k 2-es megoldasa helyett."
Nem, egyátalán nem ezért. Hanem azért, mert túl sok helyet igényelne, ha több ütemezõ és branch unit lenne. Azaz ez egy kompromisszum.
Az SPU-k 4db SP FP vektormûveletet tudnak párhuzamosan.
"Kar, hogy ehhez ujra kell irni, de legalabb ujraforditani a szoftvert. Ezzel szemben az x86-os kod annyi szalat hasznal amennyit akar, aztan ha van eleg mag, akkor mindegyik kap sajatot, ha nincs akkor futnak kevesebben, multitask-ban. Igy a lassabb gepeken is fut a kod, de ha veszunk egy ujat, akkor magatol gyorsabb lesz minden regi program."
Lásd amit fent írtam. Megfelelõ tervezés és optimizálás nélkül itt is lassú lenne a kód.
#35
"- Az egy dolog, hogy a közvetlen memóriacímzés által egy átlag C kód fordítható és futtatható rajta, de ha ezt tesszük, nagyon gyorsan beleütközünk a memória-sávszélesség korlátaiba. És akkor ugyanúgy neki kell állni optimalizálni, a minimumra csökkenteni a memóriahozzáférések számát."
A larrabee-k eseten annyi memoria buszt tesznek ra amennyik akarnak. A jelenlegi nvidia chipeken is 2-8 fuggetlen csatorna van. Igy akar mindegyik cpu tomb kaphat egy vezerlot.
"De mivel itt cache van, tele kell tenni a kódot prefetchekkel, flushokkkal, stb. stb. Akkor már sokkal átláthatóbb, ha van minden maghoz egy belsõ, címezhetõ ramunk..."
A forditoprogramokat erre talaltak ki. A forditot megirja egy ember, aztan hasznalja tobb szazezer. A masik, hogy ha nem akar valaki jo kodot irni, akkor egyszeruen kihagyja az optimalizalast. Lehet, hogy nem lesz tul gyors a program, de elkeszul idore. Ez utobbi fontosabb a kiadok szamara, mint az optimalizalas.
"- Cache memóriából 256 KB sokkal kevesebb hasznos adatot v. kódot tud tárolni (mert egy adat-szót tartalmazó és azonosító cache-line sok szó önmagában), mint 256 KB lokális RAM."
Nem igaz, ez csak az adatok lokalitasatol fugg. Pont az ami a cell-nel kotelezo, az x86-osok eseten pedig csak a teljesitmenyt novelo opcionalis megoldas.
"- Mindkettõ in-orderes, de a Larrabee-nél ez jóval többször jelenthet várakozást, mivel az SPU-k alapvetõen a cache-sebességû lokális memóriába dolgoznak, ahol ez nem számít."
Ezert van a jelenlegi rendszereknel 1 orajeles cache es ezert van a larrabee-ben smt, hogy amig az egyik szal var az adatra, addig a masik szal dolgozik. Es mindezt teljesen automatikusan, a programozo szamara gondot nem jelento modon teszi. (tehat akar arra is kepes, hogy egy utasitast az egyik szalbol, egyet a masik szalbol hajtson vegre, ezt cell-el nem lehet megoldani, mert csak szoftveres szal valtas van az spe-kben, ami jopar utasitast igenyel)
"- Nem hátrány, hogy az SPU-kban 128 bites vektoregység van: 1. kevesebb párhuzamos mûveletre esik 1-1 ugrási egység, így kevesebbet is fog vissza, ha ugorni kell, 2. így kisebb is a mag."
A larrabee-ben pont ezert van smt, hogy ez elony legyen ne hatrany, tovabba az osszes gpu-ban is ezert van 16-os parhuzamositas az spu-k 2-es megoldasa helyett.
"- Az SPU-k kisebbek: több fér el. Azonos csíkszélességen mindig több SPU fog elférni."
Kar, hogy ehhez ujra kell irni, de legalabb ujraforditani a szoftvert. Ezzel szemben az x86-os kod annyi szalat hasznal amennyit akar, aztan ha van eleg mag, akkor mindegyik kap sajatot, ha nincs akkor futnak kevesebben, multitask-ban. Igy a lassabb gepeken is fut a kod, de ha veszunk egy ujat, akkor magatol gyorsabb lesz minden regi program.
A larrabee-k eseten annyi memoria buszt tesznek ra amennyik akarnak. A jelenlegi nvidia chipeken is 2-8 fuggetlen csatorna van. Igy akar mindegyik cpu tomb kaphat egy vezerlot.
"De mivel itt cache van, tele kell tenni a kódot prefetchekkel, flushokkkal, stb. stb. Akkor már sokkal átláthatóbb, ha van minden maghoz egy belsõ, címezhetõ ramunk..."
A forditoprogramokat erre talaltak ki. A forditot megirja egy ember, aztan hasznalja tobb szazezer. A masik, hogy ha nem akar valaki jo kodot irni, akkor egyszeruen kihagyja az optimalizalast. Lehet, hogy nem lesz tul gyors a program, de elkeszul idore. Ez utobbi fontosabb a kiadok szamara, mint az optimalizalas.
"- Cache memóriából 256 KB sokkal kevesebb hasznos adatot v. kódot tud tárolni (mert egy adat-szót tartalmazó és azonosító cache-line sok szó önmagában), mint 256 KB lokális RAM."
Nem igaz, ez csak az adatok lokalitasatol fugg. Pont az ami a cell-nel kotelezo, az x86-osok eseten pedig csak a teljesitmenyt novelo opcionalis megoldas.
"- Mindkettõ in-orderes, de a Larrabee-nél ez jóval többször jelenthet várakozást, mivel az SPU-k alapvetõen a cache-sebességû lokális memóriába dolgoznak, ahol ez nem számít."
Ezert van a jelenlegi rendszereknel 1 orajeles cache es ezert van a larrabee-ben smt, hogy amig az egyik szal var az adatra, addig a masik szal dolgozik. Es mindezt teljesen automatikusan, a programozo szamara gondot nem jelento modon teszi. (tehat akar arra is kepes, hogy egy utasitast az egyik szalbol, egyet a masik szalbol hajtson vegre, ezt cell-el nem lehet megoldani, mert csak szoftveres szal valtas van az spe-kben, ami jopar utasitast igenyel)
"- Nem hátrány, hogy az SPU-kban 128 bites vektoregység van: 1. kevesebb párhuzamos mûveletre esik 1-1 ugrási egység, így kevesebbet is fog vissza, ha ugorni kell, 2. így kisebb is a mag."
A larrabee-ben pont ezert van smt, hogy ez elony legyen ne hatrany, tovabba az osszes gpu-ban is ezert van 16-os parhuzamositas az spu-k 2-es megoldasa helyett.
"- Az SPU-k kisebbek: több fér el. Azonos csíkszélességen mindig több SPU fog elférni."
Kar, hogy ehhez ujra kell irni, de legalabb ujraforditani a szoftvert. Ezzel szemben az x86-os kod annyi szalat hasznal amennyit akar, aztan ha van eleg mag, akkor mindegyik kap sajatot, ha nincs akkor futnak kevesebben, multitask-ban. Igy a lassabb gepeken is fut a kod, de ha veszunk egy ujat, akkor magatol gyorsabb lesz minden regi program.
#34
Csak éppen sokkal lassabban.
#33
Elég alacsony színvonalú "elemzés". Ami nem jutott el az agyáig (bár tiédig sem, mert ugye hiába is írtam már le ezeket neked, de most hátha):
- Az egy dolog, hogy a közvetlen memóriacímzés által egy átlag C kód fordítható és futtatható rajta, de ha ezt tesszük, nagyon gyorsan beleütközünk a memória-sávszélesség korlátaiba. És akkor ugyanúgy neki kell állni optimalizálni, a minimumra csökkenteni a memóriahozzáférések számát. De mivel itt cache van, tele kell tenni a kódot prefetchekkel, flushokkkal, stb. stb. Akkor már sokkal átláthatóbb, ha van minden maghoz egy belsõ, címezhetõ ramunk...
- Cache memóriából 256 KB sokkal kevesebb hasznos adatot v. kódot tud tárolni (mert egy adat-szót tartalmazó és azonosító cache-line sok szó önmagában), mint 256 KB lokális RAM.
- Mindkettõ in-orderes, de a Larrabee-nél ez jóval többször jelenthet várakozást, mivel az SPU-k alapvetõen a cache-sebességû lokális memóriába dolgoznak, ahol ez nem számít.
- Nem hátrány, hogy az SPU-kban 128 bites vektoregység van: 1. kevesebb párhuzamos mûveletre esik 1-1 ugrási egység, így kevesebbet is fog vissza, ha ugorni kell, 2. így kisebb is a mag.
- Az SPU-k kisebbek: több fér el. Azonos csíkszélességen mindig több SPU fog elférni.
Persze lehetnek feladatok, ahol az egyik, és olyanok, ahol a másik alkalmazása a hatékonyabb.
Egyébként a GPU-k blokkjait ne nevezd magoknak, mert a processzor mag fogalmába jóval többminden tartozik, mint ami 1-1 ilyen blokkban van. Azok csak "egyszerû" ALU-k blokkjai. Az ütemezõ, és sokminden más külön funkcionális egységben van.
- Az egy dolog, hogy a közvetlen memóriacímzés által egy átlag C kód fordítható és futtatható rajta, de ha ezt tesszük, nagyon gyorsan beleütközünk a memória-sávszélesség korlátaiba. És akkor ugyanúgy neki kell állni optimalizálni, a minimumra csökkenteni a memóriahozzáférések számát. De mivel itt cache van, tele kell tenni a kódot prefetchekkel, flushokkkal, stb. stb. Akkor már sokkal átláthatóbb, ha van minden maghoz egy belsõ, címezhetõ ramunk...
- Cache memóriából 256 KB sokkal kevesebb hasznos adatot v. kódot tud tárolni (mert egy adat-szót tartalmazó és azonosító cache-line sok szó önmagában), mint 256 KB lokális RAM.
- Mindkettõ in-orderes, de a Larrabee-nél ez jóval többször jelenthet várakozást, mivel az SPU-k alapvetõen a cache-sebességû lokális memóriába dolgoznak, ahol ez nem számít.
- Nem hátrány, hogy az SPU-kban 128 bites vektoregység van: 1. kevesebb párhuzamos mûveletre esik 1-1 ugrási egység, így kevesebbet is fog vissza, ha ugorni kell, 2. így kisebb is a mag.
- Az SPU-k kisebbek: több fér el. Azonos csíkszélességen mindig több SPU fog elférni.
Persze lehetnek feladatok, ahol az egyik, és olyanok, ahol a másik alkalmazása a hatékonyabb.
Egyébként a GPU-k blokkjait ne nevezd magoknak, mert a processzor mag fogalmába jóval többminden tartozik, mint ami 1-1 ilyen blokkban van. Azok csak "egyszerû" ALU-k blokkjai. Az ütemezõ, és sokminden más külön funkcionális egységben van.
#32
Szigorúan magánvélemény | Can’t spell “STEAL” without EA? | Gamer's Hell: DLC, Early-A, Pre-Order, Seasons, Episodes, Regions, Loot Box, Microtransactions, MS Store, Epic Store.
#31
2x-es pontossággal tudnak.
Vain ei kuulu terroristien käsiin! CS. N. T. K. K.! SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)
#30
A mai GPU-k egyszeres pontossággal tudnak számolni (lebegõpontos számítás, 32 bit). Gondolom a Larrabee ezen javít majd. De várok még több infót is. Remélem csacsognak még valamit.
Örökzöld sláger lett a \"Hol a Start-menü?\", melyet a mai, informatikában dolgozó, az adófizetők pénzén kiképzett, magukat értelmiségnek nevező emberek költöttek. Ennyi konzervatív f@szt...
#29
Hozzatennem, hogy a jelenlegi nvidia gpu-k is 16 magonkent vannak 1 valodi gpu maghoz csatolva, tehat 16 mag kap 1 elagazasi egyseget. Ez megfelel egy altalanos cpu-nak egy 16 magos simd vektor egyseggel. Jelenleg az nvidia-nal 256 magos gpu-kat gyartanak, ami kb. 16 darab azonos orajelu larabee magnak felel meg. Az egyetlen gond a ringbus-bol adodhat, ez mar a cell-eknek sem hasznalt, viszont mivel a larrabee-nel x86-okrol van szo, ezt barmikor ki lehet cserelni crossbar-ra a szofverek modositasa nelkul.
Egy erdekes osszehasonlitas, a korabban belinkelt cikkbol:
"It’s very tempting to compare Larrabee and Cell. Both use a multitude of single cores (in-order), putting the accent on vector calculation, 256 KB of dedicated memory per core, a ring bus to connect it all, etc. The similarities are numerous at first glance. Yet, the differences are also substantial: The Cell is first and foremost a CPU. Although it’s oriented toward streaming-type applications, it is not intended for rendering calculation, and consequently, there are no texture units.
Zoom
Another major difference is in the way memory is managed. On the Cell, except for the PPE, which is the only part of the processor that has a global vision of the memory space, all the SPU's memory accesses are limited to 256 KB of local store memory. So, access to main memory must be done explicitly via direct memory access (DMA) operations. Conversely, as we saw earlier, all of Larrabee’s cores have access to the entire memory space, via a cache memory whose management is transparent to the programmer, even if the programmer does have a certain form of control. Intel’s choice greatly simplifies programming and avoids having to include a more generalist core like the PPE. This heterogeneous system is one of the Cell’s handicaps, since it complicates things for the programmer. In addition to explicit management of memory, he or she must also build two executables using two different sets of instructions, which means using two different compilers.
So Larrabee’s cores are much more complete than the Cell’s SPUs, since they support all the x86 instructions. However, their performance is also better in terms vector calculation. That’s because they operate on 512-bit vectors instead of the SPUs’ 128 bits, and while the Cell should have the advantage in clock frequency (Larrabee is expected to clock at 2 to 2.5 GHz, but that’s still very hypothetical), that doesn’t compensate for such a big disadvantage.
...
What’s more, despite the flexibility GPUs have gained, their functionalities remain heavily oriented towards raw calculation. For example, there’s no question of performing I/O operations from a GPU. Conversely, Larrabee is totally capable of that, meaning that Larrabee can directly perform printf or file-handling operations. It’s also possible to use recursive and virtual functions, which is impossible with a GPU."
Egy erdekes osszehasonlitas, a korabban belinkelt cikkbol:
"It’s very tempting to compare Larrabee and Cell. Both use a multitude of single cores (in-order), putting the accent on vector calculation, 256 KB of dedicated memory per core, a ring bus to connect it all, etc. The similarities are numerous at first glance. Yet, the differences are also substantial: The Cell is first and foremost a CPU. Although it’s oriented toward streaming-type applications, it is not intended for rendering calculation, and consequently, there are no texture units.
Zoom
Another major difference is in the way memory is managed. On the Cell, except for the PPE, which is the only part of the processor that has a global vision of the memory space, all the SPU's memory accesses are limited to 256 KB of local store memory. So, access to main memory must be done explicitly via direct memory access (DMA) operations. Conversely, as we saw earlier, all of Larrabee’s cores have access to the entire memory space, via a cache memory whose management is transparent to the programmer, even if the programmer does have a certain form of control. Intel’s choice greatly simplifies programming and avoids having to include a more generalist core like the PPE. This heterogeneous system is one of the Cell’s handicaps, since it complicates things for the programmer. In addition to explicit management of memory, he or she must also build two executables using two different sets of instructions, which means using two different compilers.
So Larrabee’s cores are much more complete than the Cell’s SPUs, since they support all the x86 instructions. However, their performance is also better in terms vector calculation. That’s because they operate on 512-bit vectors instead of the SPUs’ 128 bits, and while the Cell should have the advantage in clock frequency (Larrabee is expected to clock at 2 to 2.5 GHz, but that’s still very hypothetical), that doesn’t compensate for such a big disadvantage.
...
What’s more, despite the flexibility GPUs have gained, their functionalities remain heavily oriented towards raw calculation. For example, there’s no question of performing I/O operations from a GPU. Conversely, Larrabee is totally capable of that, meaning that Larrabee can directly perform printf or file-handling operations. It’s also possible to use recursive and virtual functions, which is impossible with a GPU."
#28
Mennyi lesz a fogyasztása? Csak nehogy az "erõmûhöz" erõmû kelljen!
#27
Ha valakit érdekel infó:
Toms Larrabee Review
Egyenlõre még kísérleti fázisban van, nem lehet tudni, hány mGPU-ból is áll majd össze.
Valószínûleg tényleg a Raytracing-et fogja célozni.
Amint kijött és mûködik, valószínûleg el kezdenek majd dolgozni az optimalizációján, megnézik, hogy az x86-os magok valójában mit használnak és a nem használt részeket kidobják belõlül.
Szóval a Larrabee II szvsz. sokkal gyorsabb lesz majd az elsõnél.
Toms Larrabee Review
Egyenlõre még kísérleti fázisban van, nem lehet tudni, hány mGPU-ból is áll majd össze.
Valószínûleg tényleg a Raytracing-et fogja célozni.
Amint kijött és mûködik, valószínûleg el kezdenek majd dolgozni az optimalizációján, megnézik, hogy az x86-os magok valójában mit használnak és a nem használt részeket kidobják belõlül.
Szóval a Larrabee II szvsz. sokkal gyorsabb lesz majd az elsõnél.
#26
Én is azt olvastam róla, hogy igazából a Raytracing és a Voxel lesz amire igazából ez jó. Valamelyik Intel nyilatkozatban is azt mondták, hogy õk is úgy 2012-14 közé teszik a technológia beérését.
Az Intel integrált grafikus chipek irodai környezetben tökéletesen megállják a helyüket, otthon internetezni és minimális multimédiára is nagyon jó, de ahogy már elõttem írták is többen X4500HD HD-ra tényleg nem igazán alkalmas, mert ugyan megbirkózik vele, de nem igazán szép.
Az Intel integrált grafikus chipek irodai környezetben tökéletesen megállják a helyüket, otthon internetezni és minimális multimédiára is nagyon jó, de ahogy már elõttem írták is többen X4500HD HD-ra tényleg nem igazán alkalmas, mert ugyan megbirkózik vele, de nem igazán szép.
Asus Commando - E6600 - 4GB DDR2 Kingston HyperX 1066 - HD 4870
#25
45 nm-es lesz. Ez középkategóriának készül, legalábbis akkor azt állították. Gondolom majd 32 nm-re állnak a következõnél (lesz idõ, mert míg bevezetik az elsõ szériát, meg mutogatnak rajta ezt-azt meg stb, telik az idõ, jön a 32 nm, ami már idén megkezdi pályafutását).
Örökzöld sláger lett a \"Hol a Start-menü?\", melyet a mai, informatikában dolgozó, az adófizetők pénzén kiképzett, magukat értelmiségnek nevező emberek költöttek. Ennyi konzervatív f@szt...
#24
Ezt írták tavaly:
A Larrabee alapegységei olyan magok, melyek az x86 utasításkészlet egy részhalmazára alapoznak, és ciklusonként két kétszeres pontosságú skalármûveletet, illetve 8–16 SSE mûveletet képesek végrehajtani, valamint folyamatvezérlési feladatokat is ellátnak. Mindegyik rendelkezik egy gyors hozzáférésû, adat- és utasításcache-re osztott elsõszintû gyorsítótárral, az egymás közötti kommunikációra pedig a megosztott másodszintû gyorsítótárat használják. Ennek mérete a magok számától függ, magonként 256 kB adódik hozzá. A chipbe 16–24 mag kerül, melyek a jelenlegi x86-os processzoroktól eltérõen in-order rendszerûek, vagyis nem rendezhetik át feldolgozás közben az utasítások sorrendjét.
Itt még lehet olvasgatni.
A Larrabee alapegységei olyan magok, melyek az x86 utasításkészlet egy részhalmazára alapoznak, és ciklusonként két kétszeres pontosságú skalármûveletet, illetve 8–16 SSE mûveletet képesek végrehajtani, valamint folyamatvezérlési feladatokat is ellátnak. Mindegyik rendelkezik egy gyors hozzáférésû, adat- és utasításcache-re osztott elsõszintû gyorsítótárral, az egymás közötti kommunikációra pedig a megosztott másodszintû gyorsítótárat használják. Ennek mérete a magok számától függ, magonként 256 kB adódik hozzá. A chipbe 16–24 mag kerül, melyek a jelenlegi x86-os processzoroktól eltérõen in-order rendszerûek, vagyis nem rendezhetik át feldolgozás közben az utasítások sorrendjét.
Itt még lehet olvasgatni.
Örökzöld sláger lett a \"Hol a Start-menü?\", melyet a mai, informatikában dolgozó, az adófizetők pénzén kiképzett, magukat értelmiségnek nevező emberek költöttek. Ennyi konzervatív f@szt...
#23
whoájem17: szerinted valakit érdekelsz még? Mert engem nem igazán.
X4500HD nem rossz, de nem is jó. HD képességei nem rúgnak labdába a konkurenciával. Az a mázlija, hogy olyan áron, amin adják nincs ellenfele. (Asztaliban kb a 2400/2600Pronak felel meg.)
X4500HD nem rossz, de nem is jó. HD képességei nem rúgnak labdába a konkurenciával. Az a mázlija, hogy olyan áron, amin adják nincs ellenfele. (Asztaliban kb a 2400/2600Pronak felel meg.)
Örökzöld sláger lett a \"Hol a Start-menü?\", melyet a mai, informatikában dolgozó, az adófizetők pénzén kiképzett, magukat értelmiségnek nevező emberek költöttek. Ennyi konzervatív f@szt...
#22
Ez a HD lejátszás így leírva rendben van, de képminõségben messze elmarad az integrált GeForce és Radeon mögött.
Az, hogy az Intel adja el a legtöbb integrált grafkarit ... hát finoman szólva semmi jót nem jelent, mert meglátszik, hogy az emberek az orruknál fogva vezethetõek. Egyszerûen nem néznek utána mit vesznek. Figyelmen kívül hagyják, hogy hasonló áron mérföldekkel jobb is vásárolható.
Az, hogy az Intel adja el a legtöbb integrált grafkarit ... hát finoman szólva semmi jót nem jelent, mert meglátszik, hogy az emberek az orruknál fogva vezethetõek. Egyszerûen nem néznek utána mit vesznek. Figyelmen kívül hagyják, hogy hasonló áron mérföldekkel jobb is vásárolható.
#21
google is your friend
Core i7-965 Extreme Edition, 12 GB DDR3, Gigabyte EX58-UD5, Intel X-25M 160 GB, Sapphire 5970 OC
#20
Még mindig az intel gyártja a legtöbb grafikus csipet.
Core i7-965 Extreme Edition, 12 GB DDR3, Gigabyte EX58-UD5, Intel X-25M 160 GB, Sapphire 5970 OC
#19
szánalmas X4500HD
Aki ilyet ír, annak fingja nincs mire való az integrált videokártya. Ez a cucc pont elég arra hogy a Vista Aero Glass felületét elbírja, meg HD filmeket hardveresen dekódoljon, több nem is kell. Ami viszont kell, az a minimális fogyasztás. 8-10 órát csak ilyennel bír elmenni egy noti, nem a 9800 GTX SLI kazánokkal. Azok mellé teljesen felesleges az aksi, csak percekben mérhetõ az üzemidõ.
Aki ilyet ír, annak fingja nincs mire való az integrált videokártya. Ez a cucc pont elég arra hogy a Vista Aero Glass felületét elbírja, meg HD filmeket hardveresen dekódoljon, több nem is kell. Ami viszont kell, az a minimális fogyasztás. 8-10 órát csak ilyennel bír elmenni egy noti, nem a 9800 GTX SLI kazánokkal. Azok mellé teljesen felesleges az aksi, csak percekben mérhetõ az üzemidõ.
Core i7-965 Extreme Edition, 12 GB DDR3, Gigabyte EX58-UD5, Intel X-25M 160 GB, Sapphire 5970 OC
#18
Mijaza RAYTRACING ??? 😄 Pls. magyaráz😄
Mondd, hogy nincs igazam :P http://www.hackthat.net/df/ddos/61410/index.hack
#17
Az intel meg a grafikus chip gyártás?! Na az ami nem lesz😊
#16
nemtom, de elég sok mag lesz benne. meg egy CPU-GPU összehasonlítás azért nem nyerõ, mert a GPU cél-csip. viszont ha x86 kompatiblis lesz, akkor pl simán lehet, hogy futasson bármiféle szoftvert GPGPU driverek meg környezetek nélkül. pl ha kell egy mag grafikázik (sima asztal) a másik x db meg winrar konvertáljon. meg én úgytom h intel ezt kifejezetten grafikára szánja, nem mint egy szánalmas X4500HD-t.
amúgy carmack is már raytracingre gyúr, és szerinte a larrabbee kiváló ugódeszka lesz a raytracing világába való átvezetéshez.
amúgy carmack is már raytracingre gyúr, és szerinte a larrabbee kiváló ugódeszka lesz a raytracing világába való átvezetéshez.
Gigabyte EP35-DS3R, Intel Core2 Duo E4500, Kingston HyperX DDR2 800MHz 2x1GiB, BFG[Tech] GeForce 9600GT OC2 512MiB, WesterenDigital Caviar SE16 320 GB, Corsair VX450 PSU, Coolermaster 690 ház,
#15
belegondoltam tómcsaaa <#guluszem1><#guluszem1><#wilting> a balzsebemben minimum 10 db "CPU 4 magos CPU " el fér!Nem semmi milyen kis helyen elfér! <#wilting><#guluszem1><#kocsog>
FX6300 4.5G " GTX1070 " DDR3 2000 CL9 " CTG 550W80P
#14
Esetleg Voxel? Mert 2015 elõtt bizony leeht az kezd el terjedni (mivel abban van leehtõség).
Örökzöld sláger lett a \"Hol a Start-menü?\", melyet a mai, informatikában dolgozó, az adófizetők pénzén kiképzett, magukat értelmiségnek nevező emberek költöttek. Ennyi konzervatív f@szt...
#13
Nem ugyanaz a kategória. Az intel más irányba akarja elvinni a grafikát mint amit most nyomatnak az nvidia-ati végek. Ez inkább a raytracing megoldásokhoz lesz nyerõ, arra meg a hagyományos cuccok nem jók.
Core i7-965 Extreme Edition, 12 GB DDR3, Gigabyte EX58-UD5, Intel X-25M 160 GB, Sapphire 5970 OC
#12
Jelenleg.
Core i7-965 Extreme Edition, 12 GB DDR3, Gigabyte EX58-UD5, Intel X-25M 160 GB, Sapphire 5970 OC
#11
Csak nehogy olyan über jó legyen a szoftver oldali támogatása, mint az i720/740 VGA driverek ... vagy az X3100 alig 12-14 hónapot késõ DX10 drivere.
#10
Lehet csak én emlékszem rosszul a magok számára. Várok még információkat.
Örökzöld sláger lett a \"Hol a Start-menü?\", melyet a mai, informatikában dolgozó, az adófizetők pénzén kiképzett, magukat értelmiségnek nevező emberek költöttek. Ennyi konzervatív f@szt...
#9
No, akkor az nemkõ'! Nagyon jól megvagyok az alaplapra integrált kártyámmal elégedve. Mindenre elég.
A szenvedés az az, amitől az ember jobbá válik. Csak túl kell élni.
#8
Amíg a DX futószalag az uralkodó addig 48 maggal illene kezdeni, persze csak ha nem a belépõszint van megcélozva. Bár a feltételezhetõ magméretbõl ítélve a csúcskatra mennek.
#7
Pontosabban több processzormag egy nyákra integrálva. Sok rá fér, gondoljunk bele, ohgy egy CPU 4 magos CPU milyen kis helyen is elfér. Szerintem erre a Larrabee-re ráfér 16 mag is.
Örökzöld sláger lett a \"Hol a Start-menü?\", melyet a mai, informatikában dolgozó, az adófizetők pénzén kiképzett, magukat értelmiségnek nevező emberek költöttek. Ennyi konzervatív f@szt...
#6
Olyan CPU, ami felépítésben elég közel áll a mostani GPU-khoz.
Volvo mëg SAAB. http://szomagyarito.hu
#5
Hát lehet, hogy ma még brutális lenne, de mire kijön olyan másfél év múlva (egy év múlva még mindig max. egy prototípusuk lesz...) addigra sztem megint csak sereghajtó lesz (bár ha az nvidia továbbra is csak átnevezett 9800Gt-ket dob piacra, akkor õt azért beérheti😄)
\"...lámák kíméljenek.\"
#4
Elsõsorban grafikus kártya, mely fõleg a szoftveres rendereléshez lesz igazítva.
#3
Az intel videocsipjei eddig is brutálisak voltak<#eplus2>
Histeria est magistra vitae. Ez nem trollkodás, ez online graffiti! ;) https://suno.com/@nexus65ongs
#2
én annyit vettem le hogy egy brutális videókártya lesz😄
Armin & Ayu fan
#1
Csak nehogy a terroristák kezébe kerüljön!!! <#violent>
Mellesleg ez mi ellen van? Mire jó? Mert ebbõl a sok halandzsából számomra pont a lényeg nem derült ki. Miféle "erõmû" ez?
Mellesleg ez mi ellen van? Mire jó? Mert ebbõl a sok halandzsából számomra pont a lényeg nem derült ki. Miféle "erõmû" ez?
A szenvedés az az, amitől az ember jobbá válik. Csak túl kell élni.