Hirdetés
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Japános és zombis lett az új AMD Software
- 3D nyomtatás
- Mini-ITX
- Milyen processzort vegyek?
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- AMD Navi Radeon™ RX 6xxx sorozat
- Megmenti a kevés VRAM-mal rendelkező VGA-kat a Sampler Feedback?
- AMD Navi Radeon™ RX 9xxx sorozat
Új hozzászólás Aktív témák
-
siwok1
tag
És lőn világosság!
Komolyan nézne ki egy olyan gép ahol egy CPU van ás többi express foglalatba belel lehetne helyezni Kártyás procikat jelenleg max 7-8 foglalat áll rendelkezésre. Oda bezsufolni ilyen egységeket. összehangolni és CF/SLI nél magasabb teljesítmény növekedés érhető el mert minden egységben van cpu is, és aNV meg ashatja a physXt. : LOL
-
dezz
nagyúr
Lehet, de ennél fontosabb, hogy azok azért használgatják, akik olyan programokat írnak, ahol ennek különösebb jelentősége van. Ezeket a teljesítményigényesebb, spécibb programokat nem kezdő/harmadrangú programozók írták általában.
Visszatérve a GPGPU-ra, ami ellen először megszólaltál, nos ott pl. az OpenCL elég jó kompromisszum a hw-közeli programozástól való mentesség és a jó teljesítmény között. A HSA pedig a hatékonyságnövelés és a lehetőségek kiterjesztése mellett nem kicsit egyszerűsíti tovább az egészet.
Az Intel - mivel nagyteljesítményű GPU fejlesztésben nincs túl sok tapasztalatuk - is azzal próbálkozik már évek óta (eleddig nem sok sikerrel), hogy alaposan leegyszerűsített, ugyanakkor széles SIMD feldolgozással bíró magokból pakol többtízet egymás mellé. (Később állítólag az mai IGP-jük helyét is ilyen komplexum fogja átvenni a hibrid chipekben, a néhány hagyományos CPU mag mellett.)
Már elhangzott, miért elkerülhetetlen mindez: a sima CPU magoknak sokkal rosszabb az energiahatékonysága (telj./watt). Ez ott válik kritikussá, hogy hiába csökkentik a csíkszélességet, a fogyasztás nem csökken a kellő arányban ahhoz, hogy a teljes chipterületet ilyen magokkal szórhassák be.
-
dezz
nagyúr
Senki sem mondta, hogy a SIMD-esítés (és párhuzamosítás) a legkényelmesebb programozási forma... Az adatstruktúrát célszerű előre eltervezni. Ennek jelentősége nyilván attól is függ, hogy mennyit is kell "tökölni" a procin belül az adatokkal. Ha jó sokat nem túl sok adattal, akkor a műveletek előtti átrendezés is bőven beleférhet.
(#129) ddekany: Valószínűsíthető. Plusz a meglévő kódbázis viszonylag egyszerű alkalmazhatóságát is próbálják komoly versenyelőnnyé alakítani. Ez nyilván kevésbé hatékony, mint mondjuk egy jól megírt HSA kód, de ezt a gyártástechnológiai előnyükkel és erre építve az egyre több maggal próbálják majd ellensúlyozni (bár ez egyre kevésbé működik, ahogy lassan fő tényezővé válik az energiahatékonyság), emellett az üzleti befolyásukat is latba vetik.
-
#131
Ł-IceRocK-Ł
veterán
Ł-IceRocK-Ł
veterán
Kiváncsi leszek a tesztekre.
-
ddekany
veterán
"A Larrabee alapú megoldás valószínűleg kisebb teljesítményű és nagyobb fogyasztású lesz, de nem kizárt, hogy összetettebb feladatokban esetleg jobban teljesíthet"
Nem lehet, hogy az Intelt egyszerűen a műszaki racionalitás rovására erőlteti a x86-ot? Mert akkor majd úgy kell nekik, ha megint beégnek...
-
Pikari
addikt
ez egy kicsit erős kifejezés, hogy hülye lenne. a coder általában igyekszik olyan jellegű kódstruktúrát kialakítani, ami kényelmesen kezelhető, algoritmikailag könnyen átlátható, ebbe csak úgy simán nem vághatsz bele egy SIMD utasítást kézzel, ennek számos oka lehet, például hogy nem is úgy következnek a feladatok az algoritmusban egymás után, hogy triviálisan, ránézésre lehessen SIMD-et használni, a másik pedig, hogy az adatok nem megfelelően alignáltak (mert miért lennének azok).ha az ember SIMD-et akar a szoftverben, akkor azt bizony úgy kell szó szerint belefosni, (persze tekintsünk el ezesetben a fordítóprogram autómatikus SIMDesítésétől, ami általában - pont ugyanezen okok miatt - szintén nem is túl hatékony)
-
Pikari
addikt
mert a hasamra ütöttem. és gyaníthatólag még mindig közelebb van a valósághoz, mint neked akármilyen más hosszas számításod lenne
azt még azért tegyük hozzá annak, aki még nem látott ilyet, hogy az adott művelet elvégzéséhez szűkséges adatok memóriában és kódban lévő reprezentációja általában nem is teszi lehetővé azt, hogy közvetlenül SIMD utasításokkal lehessen őket bojgatni, hanem át kell másolgatni őket. így sokszor az is előfordul, hogy amit az ember nyer a vámon, azt elbukja a postán.
-
dezz
nagyúr
Vagy 20 vagy akármennyi. Megint a hasadra ütöttél... Különben sem az számít, hogy a teljes kód mekkora része SIMD, hanem hogy a futásidő mekkora részét teszi ki, illetve mennyivel gyorsítja a műveletet. Egyébként pedig a kérdésben benne volt, hogy jól párhuzamosítható. (Más kérdés, hogy van egy ésszerű határa a SIMD szélesítésének, lévén egy valós kód nem csak alap- és egyéb számítási műveletekből áll.)
-
Pikari
addikt
válasz
#95904256
#122
üzenetére
,,A GPU-k is rengeteg magot használnak jól párhuzamosítható műveletekre, de miért? Miért nem a sok ezer bit széles feldolgozók alakultak ki?''
mert nekik volt eszük. SIMD-el csak bizonyos típusú műveletek gyorsíthatók, amik jó, ha 5%-át kiteszik a teljes kódnak (persze ez feladattól is függ, van, ahol 0). több mag esetén pedig azt dobsz szét, amit csak akarsz.
-
dezz
nagyúr
Találó párhuzam.
"inkább egy-egy teljes modult válhat ki egy-egy CU."
Minden bizonnyal. (Egyébként egyes dokumentumokban az AMD a Bulldozer modulokat is CU-nak nevezi.) Bár ez nem zárja ki, hogy az sima modulon belüli FPU is combosabbá váljon előbb-utóbb, ha már úgyis moduláris felépítésűek maguk a modulok is.
(#121) Abu85: Igen, magam is írtam az energiahatékonyságot korábban.
Az Intel persze azzal versenyez, amije van. A Larrabee alapú megoldás valószínűleg kisebb teljesítményű és nagyobb fogyasztású lesz, de nem kizárt, hogy összetettebb feladatokban esetleg jobban teljesíthet (legalábbis a saját peakjéhez képest), mint az AMD-féle, ami nagyobb teljesítményű (peak) és energiahatékonyabb lehet, de ezt talán a nem túl komplex számításoknál tudhatja igazán kamatoztatni. Persze az is lehet, hogy az utóbbi mindkettőben jó lesz, ha a CPU és GPU jellegű CU-k hatékonyan össze tudnak dolgozni.
Nos, ezt Johan Andersson nélkül is tudjuk...
(#122) akosf: CU-nként egy branch unit van... Márpedig feltételes ugrásoknál adott esetben érvénytelenné válhat a teljes aktuális SIMD-es eredmény, az adott CU-ban. Egy bizonyos szinten túl egyre többször nem növeli, hanem csökkenti a teljesítményt a szélesítés.
-
#95904256
törölt tag
Abu! Mi a véleményed arról amit dezz említett a #118-asban?
"Ami párhuzamosítható, az legtöbbször SIMD-esíthető is... Ezek után hol ésszerűbb a sok-sok CPU mag?"A GPU-k is rengeteg magot használnak jól párhuzamosítható műveletekre, de miért? Miért nem a sok ezer bit széles feldolgozók alakultak ki?
Energiafelhasználás szempontjából előnyösebbnek tűnik a sok-sok műveletvégzőt kevesebb CPU maggal etetni. Ráadásul a kevesebb magot jobban "ki lehet gyúrni" ( nagyobb órajel, nagyobb cache, stb. ) az egyéb számításokra.
-
Abu85
HÁZIGAZDA
Két részre kell bontani a kérdést. El lehet érni így is a megfelelő throughput teljesítményt ilyen homogén iránnyal, de csak akkor, ha a fogyasztást másodlagos tényezőként kezelik (szerverekben tolják is ki a TDP limiteket már a következő generációnál). Ha a mobil irányt ide vesszük, akkor egységnyi fogyasztás mellett semmi esélye olyan throughputot elérnie egy ilyen rendszernek, amilyenekkel az IGP-k dolgoznak. A felét talán lehet hozni, de akkor is az Intel homogén megvalósításának lesz a legnagyobb fogyasztása, beleszámolva két node előnyt (persze a Dennard Scaling hanyatlásával ez egyre kevesebbet ér). Ez a koncepció akkor érne valamit, ha az NTV technológiák már most bevethetők lennének, de egyelőre még kísérleti fázisban van.
Az AVX-1024-re inkább logikai szempontok szerint lenne érdemes gondolni. Már 512 bitre ki van terjesztve a Larrabee-ben. A következő lépcső az 1024 bit. Na most nem kötelező ám 1024 bites AVX utasításokat ilyen széles feldolgozókon végrehajtani. Lehet akár 256 biteseken is. Az látszik a Larrabee-n, hogy az Intel Pollack szabályát veszi figyelembe, ami ugyanolyan gyógyír a Dennard Scaling hanyatlására, mint a GPGPU.
Az Intelnek a rendszerszintű integrációja az olyasmi lehet, hogy megvan a gyűrűs busz alapnak, amire ott az LLC. A tárat le kell cserélni egy SRAM-nál jobb sűrűséget adó megoldásra. eDRAM is jó, ha az FBC nem jön be. A lapkában meg lesznek a magokhoz való szeletek, a gyűrűs busz, és azokra fel lesz fűzve x CPU-mag és "jóval több mint x" Larrabee mag. A Larrabee Pollack szabályára építkezik, míg a CPU-magokat meg kell tartani az értékelhető egyszálú teljesítményért. Az AVX támogatást egységesíteni lehet a két mag között, vagyis a Larrabee kaphat 1024 bites feldolgozókat, míg a CPU-magok képesek lehetnek 256 bites feldolgozókkal dolgozni, de ugyanúgy támogathatók az 1024 bites utasítások. És persze a CPU-magok más órajelen kell, hogy fussanak, mint a Larrabee magok, de ez a legegyszerűbb gond amit meg kell oldani a koncepcióban. Én ezt raknám össze, hogy versenyképes maradjak. Nyilván sok a buktatója, és sok a kockázat is, de most ezt fel kell vállalni.A HSA-t szerintem mindenképpen támogatni kell. Vagy, ha azt nem, akkor egy másik hasonló koncepciót. A fejlesztői nyomás itt most óriási lett, ahogy az AMD megmutatta mit tud egy ilyen rendszer. Johan Andersson már kiállt, hogy nem pont a HSA érdekli, hanem az a koncepció, amit az infrastruktúra felkínál a fejlesztőknek. Szerinte ez a jövő, és felszólította az összes gyártót, hogy álljon be mögé, vagy ha nem, akkor egyezzenek meg egy másik hasonló megoldásról, amit tényleg mindenki támogat. Erre egyébként az Intel kivételével szerintem mindenki hajlandó lenne, hiszen ellenérvet nehéz felhozni ellene. Az Intelnek az a baja, hogy a HSA, vagy a HSA-hoz hasonló koncepcióval teljesen bukó a felépített monopóliumuk. Gyakorlatilag az x86 mint jelenlegi erős érték szart sem fog érni.
A HSA azért opció, mert annak már kész van az 1.0-s draft specifikációja, és az úgy van kialakítva, hogy könnyű legyen támogatni a hardver oldaláról. Emellett a HSA-nál nyíltabb alternatíva aligha lesz. Minden alapító besorolású tag egységes anyagi támogatást ad, egységes a szavazati jog, egységes a beleszólás, egységes a marketing, szóval akár csinálnak mellé még egy másik alternatívát ennél egységesebb formai működést az sem tud majd felmutatni. -
P.H.
senior tag
Ez több szempontból is nehéz kérdés:
- egyrészt azért, mert nem vagyok jós
- másrészt azért, mert ez az ábra valószínűleg nem véletlenül zárul az Excavator-ral
A Bulldozer-vonallal és ezzel a képpel úgy vagyok, mintha az Intel fejlődése lenne felgyorsítva:
+ Bulldozer = Pentium Pro: az alap, elsősorban szerver-orientált; egyik sem váltotta meg a desktop-világot
+ Piledriver = Pentium 2/3: elsősorban órajel-fejlesztések (ha nem is akkora boost, mint a Coppermine volt), mobil területre betörés
+ Steamroller = Pentium M: az egyik legnagyobb kerékkötő, a decode látványos fejlesztése (Intelnél a micro-fusion volt ez), ezzel igen hatékony mobil alternatívává tétele
+ Feltételesen a folytatás: Excavator = Core2? Ha behozzák végre az AGLU-kat, akkor nagyot erősödik az utasításvégrehajtás (~ a szélesség), beérne végre a teljes vonal.- harmadrészt ezt az ábrát nézve
nem biztos, hogy az FPU lesz lecserélve GCN-re; inkább egy-egy teljes modult válhat ki egy-egy CU. Egy 16 Kb 4-utas write-through L1D-vel és 16 utas L2-vel felszerelt CU-t GLC=1 állásban nem tud semmilyen más egység kívülről megkülönböztetni egy CPU-modultól és a CU-k a jelenlegi 512 bites vektor-egység mellett (a GPU-khoz képest) jól fejlett - és eléggé x86-közeli - skalár/fixpontos/integer egységgel is fel vannak szerelve.
Ha az Intel majdan egy gyűrűre felfűz néhány CPU-mag mellé pár Larrabee-magot (amik mindegyike x86-alapú), akkor az AMD miért ne tenné meg ugyanezt a felfűzést (a HSA-ra mint vISA-ra alapozva) néhány CPU-modul + tetszőleges számú CU felállásban? -
dezz
nagyúr
Vajon labdába rúghat ez vagy az (512/1024 bit) pl. a CGN-féle CU-k mellett? Főleg, ha abból egy bekerül majd az FPU helyére is? Illetve a HSA-féle "átszervezés" után/közepette?
(#115) Pikari: Igenis, ősapánk...!
Komolyan, te véletlenül nem egy a '90-es években nyugdíjazott számtechtanár vagy? Hogy a mai GPGPU-s metódust kritizálod, az egy dolog, de hogy még a SIMD elvet is...Számos területen meghatározó szerepe van! -
Pikari
addikt
,,Intel-nél hamarosan 512 illetve 1024''
elképzeltelek, ahogy húzkodod majd magad után az új procit, mint ovodás a bilit, és örömködsz, hogy ,,jaj, mostmár 64 floatot tudok egyszerre összeadni 5 (sic) órajel alatt''. már érzem is az 1% gyorsulást azokon a programokon, ahol az intel kikönyörgi, hogy próbáljanak találni valami helyet, ahol felhasználható lesz majd az az új feature. cpu fiaim, diszappojntálódni vagyok kénytelen bennetek. -
P.H.
senior tag
#110 és #111: Ez csak szórakozás volt, sikerült kihozni megint az igazi 'Geri'-t.
ON:
Ez egy igazi tock lesz (kívülről nem nagyon látható, de teljesen átdolgozott belsővel): a Core2 kapott utoljára plusz végrehajtó egységeket és az FMA 5 órajeles késleltetése (ami megegyezik az egyszerű szorzás időigényével) azt sejteti, hogy a belső RISC műveletek mostmár tényleg 2 helyett 3 forrásregiszterrel bírnak (eddig 2 volt, minden jel szerint PPro óta, tehát ez egy elég radikális váltás), mint eddig az AMD-ké.
Ez náluk egy új út kezdete, mint kb. a Bulldozer. Az AVX kimondottan ki lesz bővítve az Intel-nél hamarosan 512 illetve 1024 bitre (nem az IPG veszi át ezt a szerepet), csodálnám, ha az AMD közvetlenül követné 1024 bitre őket; ezzel látható, mivel akar versenyezni az Intel. -
#95904256
törölt tag
Valóban szórakoztató.
Pongyolán foglamaz, rengeteget személyeskedik és egy csomó mindenről halvány lila fogalma sincs, csak dobálózik velük. A "szakmai halandzsa" találó. Pl. "...a gyökvonást és az osztást kötegeli egybe...". A mögötte lévő összefüggések, itt pl. az, hogy a gyökvonás reciprokát kiszámító algoritmus sokkal gyorsabb iterál, teljesen lényegtelen a számára. Szó sincs semmiféle kötegelésről, egyszerűen hamarabb ad eredményt.
-
-
-
Pikari
addikt
Beismerem, tévedtem! valójában nincs is olyan adattípus már vagy 15 éve, hogy long double, csak most találtam ki! a lebegőpontos számokat AMD64 óta valójában nem is SSE2+aboveval számolják, tehát nyilván ezeket sem! a processzormagban nincs több pipeline, se elágazásbecslés! minden dekódolás egyfázisú, tehát a képet, amit belinkeltem, most hamisítottam paintban, és lefizettem az arstechnica rendszergazdáját, hogy töltse fel, csak azért, hogy szivassalak, és összezavarjam a megkérdőjelezhetetlen tudásod. Minden annyi órajel, amennyit az intel ráír, és RSQRTF sincs x86on! Soha életemben nem írtam még assembly kódot, éppen ezért találhattam ki azt, hogy azt hazudom, hogy van RSQRTF, pedig valójában NINCS! De téged nem lehet átverni, hisz te tudod, hogy nincs. http://asm.inightmare.org/opcodelst/index.php?op=RSQRTSS ezt a linket is csak most hamisítottam, aztán meg a microsoftot is lefizettem, hogy kamuzzák be az msdnre http://msdn.microsoft.com/en-us/library/2h228y72%28v=vs.80%29.aspx ! NINCS RSQRTF!
NEKED VAN IGAZAD! Te egy hős vagy, tudásod immár megkérdőjelezhetetlen.
én pedig egy tré tróger ember vagyok, aki hazudtam mindenről...
hazudtam reggel, délben, és este. minden az én hibám! én vagyok a hülye! én vagyok az, aki nem ért hozzá!summa summarum, az én kurva anyámat!
-
P.H.
senior tag
Sejtettem: a sizeof(long double) csak játék a fordító részéről (align miatt), 128 bitet foglal le neki, de az adattartalom csupán 80 bit. Ilyesmit már a 90-es évek óta csinálnak a fordítók.
Szerinted mindegy, amúgy nem, nincs helye "is" szónak, a SIMD nem arra való.
RSQRTF nincs az x86-on, az nVidiánál van CUDA-ban.
A VLIW megint teljesen más.Az 2-3-4-whatever ugye vicc?. Ezek gépek, terv szerint működnek, minden előre tudható (már csak azért is, mert le kell teszteni, validálni a CPU-t). Valamint egy processzor két dologra jó: kitenni egy vitrinbe, ha már elég öreg, illetve programokat futtatni rajta; mindkét esetben mi értelme lenne elhallgatnia a gyártónak, hogy mi az adott CPU-n a legjobb programok, az optimalizáció és végső soron a működésének titka? Üzleti érdeke is, hogy az övén fussanak leggyorsabban a programok, amit mások csinálnak.
Ha írnál kézzel assembly kódot, akkor tudnád, hogy a megadott értékek igazak; úgy, hogy közted van egy fordító vagy egy/több köztesréteg, elveszett a talaj, a számokra nem alapozhatsz. De attól még azok a számok igazak maradnak, csak már nem tapasztalhatóak a valóságban, mert nem tudod, mi (és a fordító által mennyivel több minden) is történik valójában, mint amit akartál.
-
Pikari
addikt
na látom, normálisabb hangnemre álltál, tehát beszélgethetünk értelmesebb hangnemben is.
,,Azt, hogy a long double 128 bites, mire alapozod?''
a sizeof(long double)-re szokás alapozni,,FMA'',
az most mindegy.
http://en.wikipedia.org/wiki/FMA_instruction_set
van az FMA nevű utasítás, aztán van egy ilyen simd utasításkészlet, a lényege, hogy ezt a KÉT műveletet (szorzás és összeadás) végezd el. a simd lényege nem csak az, hogy tömbökön végezhess el monolitikus feladatokat, ugyanúgy a lényege az is, hogy az utasításokat összevonják olyan módon, hogy például egyszerre ezt a két műveletet meg tudd csinálni több számon. te kategorikusan letagadtad ezt, amikor azt mondtad, hogy a simd nem egymást követő utasítások kötegelésére való. De. erre IS való. a simd lényege az, hogy megspórold az utasítások kiadását. ennek az egyik módja az adattömbök kötelegelése, a másik módja pedig az utasítások kötegelése, mint az FMA instruction set esetében. de ez nem újkeletű dolog, van pl az SSE1-ben RSQRTF, ami a gyökvonást és az osztást kötegeli egybe. hogy ez mostmár inkább kezd közeledni VLIW -hez, vagy inkább még SIMD. az már egy másik ideológiai kérdés, mindenesetre x86on az SSE része lett.a kép, és a többi:
mondhatni igen. a lényege igazából az, hogy ebből nem egy van, mint ahogy ezt talán említetted is, hanem van belőle mindjárt procitól függően magonként 2-3-4-whatever. éppen ezért egy valódi kódban sosem tudhatod, hogy mennyi lesz az utasításod végrehajtásának ideje, még az adott procin sem, hanem függ az előtte és mögötte kiadott utasításoktól, és ezen utasítások számától is. üresjáratban pörgetni nincs értelme. persze van, ha az ember benchmarkolni akar, de valódi felhasználás számára ez inkább csak egyfajta tájékoztató jellegű dolog. a 40-et hasraütésre mondtam, igazából fogalmam sincs, én szélsőséges esetekben ehhez hasonló extrém értékekkel szoktam találkozni - szerencsétlenségemre főleg olyan helyeken, ahol igazán kéne a teljesítmény. nem lehet megjósolni, hogy az adott utasítás hány órajelet fog megzabálni. egy sima integer reg+=reg összeadásra lehet azt mondani, hogy nagyjából kijön 0.5-3 órajelből minden körülmények között, de a komolyabbakra sajnos már nem igazán. a simd utasítások valódi felhasználás során pedig rengeteget kajálnak, nekem ez a tapasztalatom. -
P.H.
senior tag
A 40 órajeles tipped mire alapozod?
Azt, hogy a long double 128 bites, mire alapozod?
Az FMA nem SIMD, csak egy művelet, mint az összeadás vagy az osztás: van skalár formája (pl. VFMADDSS), ami csak 1 számpárt szoroz össze és hozzáad egy harmadikat, és van SIMD formája (pl. VFMADDPS), ami több számpárt szoroz össze egyszerre, majd a eredményekhez hozzáad egy-egy harmadik számot, így több eredmény lesz ugyanannyi idő alatt.
Mint írtam a végén, bármit linkelhetsz, nem kell az én linkjeimre hagyatkozni.
A kép egy pipelined execution unit végrehajtás-idődiagramja, amely fél órajelenként 1 utasítást küld tovább (double-pumped); nincs ebben semmi szokatlan vagy érdekes (csak nem érted, mi van rajta): a gyártók által megadott latency-k az Execute lépcsőre vonatkoznak (az állhat utasítástól függően változó számú lépcsőből*), az meg lemaradt az ábráról; már csak ott kapcsolódunk be, hogy a lefutás után kiírja az eredményt (Data1/Data2/Tag Ch./Write).
*itt a K7 (Athlon XP, Barton pl.) pipeline-ja:
Az integer (egész számos SISD) utasításoknak egyetlen lépcsője van (Ex) a Sched (=ütemezés után; az Addr és DC lépcső a cache-hozzáféréshez kell csak), le is fut mind 1 órajel alatt, a lebegőpontos számoknak 5 (FReg, FX0-FX3); viszont tudjuk a gyártói információkból és a mérésekból, hogy nem mindegyiknek kell végigmennie mind a 5-en, van, amely 2 órajel alatt eredményt ad. A write-back lépcsői ezen nincsenek rajta, mivel nem szükségesek a következő függő utasítás indításához.
Ezen (Atom pipeline) viszont rajta vannak (itt pedig a több EX-lépcső nem szerepel, pedig van):
-
Pikari
addikt
,,mikor ennyi?''
ezt is max az intel tudná neked megmondani.,,mennyi a maximum?''
azt én nem tudom neked megmondani, max az intel. én max egy elnagyolt tippet tudok adni: 40 (de fogadni azért nem fogadnék rá),,Kérlek mondj olyan utasítást, amely 128 vagy 256 bites lebegőpontos számokkal dolgozik; vagy innen olyan adattípust!''
nemtom megnyitni a dokumentumot. NEM TUDOM, hogy van -e rá utasítás az általad linkelt dokumentumban, vagy leírás arra, hogy hogyan használhatod fel, vagy hogyan kell konvertálgatni, hogy felhasználhasd, de a long double pl 128 bites (i386 archon 80 bites, compiler függő) az kb 15 éve működő félig meddig processzor szintű, félig meddig szoftveres szintű feature...
,,hanem hogy n elemű tömb(ök)re ugyanannyi műveletből álló for-jellegű ciklus n helyett - adattípustól függően - csak n/2, n/4, ..., n/32 alkalommal fusson le''
megint csak makes no sense.
akkor gondolom nálad az FMA sem SIMD, hanem a gerinchúrosok körébe tartozik,,AIDA-mérésben''
az aida nem releváns ilyen kérdésekben, soha nem is volt az. fogd meg szépen az intel hivatalos MIPS értékeit, majd hasonlítsd össze a magok számával és az órajellel. meg fogsz lepődni. örömteli, hogy elkezdted legalább a lebegőpontos számok működését tanulmányozni, mielőtt ilyen pointless vitákba vágsz bele, de akár a processzorok felépítésének is utánanézhetnél.,,Mutatsz ebben az AIDA-mérésben''
mi az hogy *ebben*? ki vagy te, hogy meghatározod, hogy én honnét mutathatok mit? egy kissé el vagy tévedve szerintem,,Adhatsz linkeket, hivatkozásokat bőven, gondolom, nem magadtól találod ki ezeket.''
gondolom erről a képről sem látod azonnal, hogy vajon mi lehet annak az oka, hogy miért nem tudod megmondani, hogy egy utasítás hány órajel alatt fut le.
szerintem a beszélgetésünk itt befejeződött, mr mutasdmeginnét level 5 -
P.H.
senior tag
Tehát minimum 5; (mennyi a maximum? mikor ennyi? amikor előtte össze kell kapnia magát a CPU-nak?) és legyen minimum 0 vagy 1. A Cell FMA-ja minimum 6 órajel, még rosszabb?
Kérlek mondj olyan utasítást, amely 128 vagy 256 bites lebegőpontos számokkal dolgozik; vagy innen olyan adattípust!
Nem, nem ez a SIMD lényege, (az a CISC-be hajló bonyolultabb utasításoké, pl. POPCNT, PCLMULQDQ), hanem hogy n elemű tömb(ök)re ugyanannyi műveletből álló for-jellegű ciklus n helyett - adattípustól függően - csak n/2, n/4, ..., n/32 alkalommal fusson le, vagy ne is kelljen ciklus egyáltalán; így a CPU által végrehajtott utasítások száma feleződik, negyedőlik, ..., 32-edelődik, vagy 1-re csökken (maga a for is jópár utasítás).
Mutatsz ebben az AIDA-mérésben olyan utasítást, amely 0 órajel alatt fut le? Ezt mondja az AMD ugyanerre (Appendix C Instruction Latencies).
Regiszterek ide-oda másolgatásából vagy nullázásából nemigen lehet programot írni.Adhatsz linkeket, hivatkozásokat bőven, gondolom, nem magadtól találod ki ezeket.
-
Pikari
addikt
én sem, egészen addig, amíg el nem olvastam a tiedet
,,hanem az utasítás végrehajtásának'' ... ,,ennyi idő alatt van készen egy művelet''
nem, ez nem 5 órajelbe fog kerülni, hanem MINIMUM 5-be. óriási különbség!,,A 256 bites lebegőpontos végrehajtók NEM 256 bites számokon dolgoznak''
hanem 32 biteseken, 64 biteseken, 80 biteseken, 128 biteseken, vagy 256 biteseken...,,A SIMD nem egymást követő utasítások kötegelésére való''
a SIMD egyetlen lényege hogy kevesebb utasításból tudj megcsinálni bizonyos műveleteket. definíció szerint: ,,single instruction, multiple data rövidítése'',,hanem egymást követő adatokéra''
ez makes no sense,,Minden utasításnak - a legegyszerűbbnek is, mint két egész szám összeadása - legalább 1 ciklus a késleltetése''
nem, nem igaz az, hogy minden utasítás szűkségszerűen legalább 1 ciklust elvenne,,szakmai''... ,,szakmaian hangzó köntös''
mi bánt ennyire? szakmaiság, hmm. vajon mi lehet ez? szóval ezzel kapcsolatban vannak neked hiányosságaid, és negatív tapasztalataid múltban. esetleg az érvényesülés tekintetében, és ezt kompenzálod a bizonyos szakmaiságra való törekvéssel. remélem, hamar sikerül megoldanod, és teljes életet élhetsz majd -
dezz
nagyúr
Hűha, most nézem csak én is, tulajdonképpen miket is írt ott.
A #81-est félkómásan írtam éjszaka. A "256-bites FP" részt olvasva (átfutva) arra gondoltam: "az nem lehet, hogy tényleg így érti..." A ciklusokkal kapcsolatban azt hittem, az a gondja, hogy annyi idő alatt hajtódik végre, mintha sima elemi utasítások sorát hajtanánk végre. -
P.H.
senior tag
A 256 bites lebegőpontos végrehajtók NEM 256 bites számokon dolgoznak, hanem egymást követő 8 db 32 bites vagy 4 db 64 bites számon (=vektor). Ilyenek már a Sandy és Ivy Bridge-ben is vannak, itt most csak átszervezték őket (+FMA), a nagyobb újdonság az, hogy az integer (fixpontos) ALU-k is 256 bitesek lettek; ezek eddig 128 bitesek voltak, így képesek egyszerre 32 byte-on, 16 word-ön, 8 duplaszón vagy 4 db 64 bites értéken dolgozni.
A SIMD nem egymást követő utasítások kötegelésére való, hanem egymást követő adatokéra; ez is a neve: Single Instruction Multiple Data (képes olvasnivaló még az AVX1-ről).A Haswell-ben mind fixpontos, mind lebegőpontos 256 bites végrehajtóból 3-3 van, utóbbiból 2 képes az FMA-műveletekre, továbbá az egyik az osztásra/szorzásra, a másik összeadásra/kivonásra/összehasonlításra, a 3. csak a vektorelemek átrendezésére.
A késleltetés nem valami kényszeredett várakozás, hanem az utasítás végrehajtásának ideje (az angol latency szó tükörfordítása lappangás), ennyi idő alatt van készen egy művelet. Minden utasításnak - a legegyszerűbbnek is, mint két egész szám összeadása - legalább 1 ciklus a késleltetése, a lebegőpontos számok műveletei tovább tartanak:
Core2/Nehalem/Sandy/Ivy/Haswell: az összeadás 3, a szorzás 5 órajel
Bulldozer: összeadás és szorzás is 5-6 órajel
K10: összeadás és szorzás is 4 órajel (példa; L=latency T=throughput)
Az, hogy "pont 5-tel több, mint kellene" olyan, mint számonkérni egy 12 ms elérési idejű HDD-n, hogy ez pont 12-vel több, mint amennyinek kéne lennie; vagy legyen 1 ms, különben semmit se ér Nagyon szakmai...A gather-utasítások memóriaolvasó utasítások, paraméterben kapják meg, hogy milyen címekről olvassanak, majd ezeket az értékeket megfelelően sorba állítva egy vektort képeznek. Semmi közük a műveletekhez, a TMU-hoz, sem "bedrótozva" nincs beléjük a címek távolsága.
Sosem láttam még olyan hozzászólást, ami 100%-ban szakmaian hangzó köntösbe (köntös... bikini) bújtatott halandzsa.
-
dezz
nagyúr
"Én úgy értettem az itt a cél (hosszú távon), hogy a GPU-s kód is ugyan abban a címtér + privilegitási szint fusson, mint az alkalmazás CPU-s kódja."
Így van. És nagy lépésekkel haladnak is ebbe az irányba.
"Te meg lényegében azt mondod, hogy na ja, csak ezt büdös életben meg nem oldják, csak hülyítik a népet ezzel az ígérettel? Én ezt végül is nem tudhatom, mert a GPU-k lelki világát nem ismerem. De konkrétan miért lenne ezt lehetetlen megoldani, hogy a GPU is beilleszkedjen ebbe a rendszerbe?"
Az általam linkelt anyagokban be van mutatva a mai helyzet és a megoldás is.
-
ddekany
veterán
Én úgy értettem az itt a cél (hosszú távon), hogy a GPU-s kód is ugyan abban a címtér + privilegitási szint fusson, mint az alkalmazás CPU-s kódja. Te meg lényegében azt mondod, hogy na ja, csak ezt büdös életben meg nem oldják, csak hülyítik a népet ezzel az ígérettel? Én ezt végül is nem tudhatom, mert a GPU-k lelki világát nem ismerem. De konkrétan miért lenne ezt lehetetlen megoldani, hogy a GPU is beilleszkedjen ebbe a rendszerbe? (Ettől persze még lehet, hogy mondjuk a mostani DirectX/OpenGL cuccok külön címtérben futnak, meg főleg, másolgatnak, hogy ne hányják össze egymás adatstruktúráit a hagyományos alkalmazással.)
-
dezz
nagyúr
A HSA részben éppen arról szól, hogy az egészet megreformálják és a GPU-t beemelik a CPU(+FPU)+MMU kis közösségébe. Légy üdvözölve egy új galaxisban (itt még FSA-ként hivatkoztak rá):
The Programmer's Guide to the APU Galaxy
Plusz vess 1-2 pillantást ennek a cikknek a végén lévő két slide-ra.
"vélemény: nem kell gpgpu. egy erős, sok magos, jó processzor kell, ami el tudja látni a gpu feladatát is."
Na persze, 10x akkora szilícium területtel és 100x akkora fogyasztással... (Már ha egy chipen megvalósítható lenne, de nem lehet a hőtermelés miatt.)
-
Pikari
addikt
nem igazán lehet megoldani másolás nélkül.
ahhoz, hogy a memóriaterületeket átpasszold a gpunak:
-át kell copyzni a szűkséges memóriacímen lévő adatokat user módból (copy_from_user). ehhez a kernel segítsége kell, ugyanis:
-az user módban futó program - az egy user módban futó program. hogy mit csinál, az az ő dolga. a kernel segítségével kezeli a memóriát, ő önmagában nem rendelkezik hardveres szempontból memóriakezelő funkciókkal. szépen mallocol, reallocol, freeli a memóriaterületeket, ahogy ő akarja. hogy az ő memóriaterületei hol vannak, azt igazából senki se tudja (persze azt tudni, hogy mi van hozzá rendelve a programhoz, de hogy azon belül mi/hogy van kialakítva, az a rendszer számára már homály)
-a kernel sem tudja, maga az opreációs rendszer sem, nemhogy a gpu drivere.
-tehát ahhoz, hogy megkaphassa a driver ezeket, úgy a kliens driveren keresztül át kell passzolni a szűkséges memóriaterületet a kernel módú drivernek (amihez vissza kell kapcsolni a processzort valós módba), aztán a driver a kernel segítségével (természetesen az adott szoftver utasítására, az adott szoftver közreműködésével) a megadott pointeren keresztül kihúzza az adott hosszúságú memóriaterületet, átmásolva a driver egy SAJÁT, máshogyan címzett memóriarekeszébe (amihez előtte kell egy kernel módú memóriafoglalás, majd a legvégén persze egy törlés).
-ha ott van, akkor kezelni kell magát a hardvert, egy kvázi gépikód szerű adattömegről van szó, amelyet a gpun akarunk futtatni, ahhoz több száz- ezer-tízezer órajeles latencyvel bíró ormótlan hívásokat kell benyalatni a hardverrel. ilyen nyalánkságról nem is beszélve, hogy memóriát kell neki foglalni a grafikus hardveren belül, be kell bootolni egy pár százezer kódsoros mini operációs rendszert (!) a grafikus kártyában, azon belül az ütemezőre fel kell fűzni a futtatni kívánt gpgpu kódot a gpu ütemezőjére, törölni kell az összes regisztert, meg kell öntözni a virágokat, etc etc etc
-a gpu külön memóriájába való belemásolás már jobbára megspórolható innentől már, ha egy ramon vannak, persze, csak innentől meg remélem érzi mindenki, hogy ez igazából már rég mindegy...
-az eszköz elvégezte a feladatát. ki kell transferelni az előbb betöltött memóriamennyiséget valós módból user módba, megint csak a kernel segítségével
-felszabadítani a memóriát, aztán return
a teljesítménynek olyan 80%-a megy a pocsékba, mint overhead.
nem, nem lehet vele mit csinálni, kivéve ha teljesen új processzort tervezünk a nulláról, se az arm-al nem lehet máshogy, se az x86-aé, se a mips-el, se semmi mással, ami user módban futtatja a programokat. Na jó, DOS 6.22-ből meg lehetne csinálni
vélemény: nem kell gpgpu. egy erős, sok magos, jó processzor kell, ami el tudja látni a gpu feladatát is.
-
i-sti
senior tag
válasz
#31342592
#86
üzenetére
Pontosan.
Ebben a forum reszben is 2 Q9550 tulaj (koztuk en is), jeleztuk, hogy arra szeretnenk cserelni.
Ez azert van, mert a mi Q9550-unk, addig meg siman "versenyben" marad.
Meg egy fontos ok, hogy a Skylake fogja elsonek tamogatni a DDR4-et. (ugy tudom, hogy a Broadwell sem fogja meg). -
Abu85
HÁZIGAZDA
válasz
Chriss745
#87
üzenetére
A GPGPU az sokat gyorsít a specializált feladatokon. Ezért használják. Az általánosabb feladatokhoz közelebb kell vinni a CPU-hoz a GPU-t, vagyis integrálni kell. Ezért születnek olyan OpenCL programok, mint a WinZip (GPU-s gyorsításra), mert az integráció lehetővé teszi, hogy valamennyire eltávolodjunk a specializált feladatoktól. Itt is gond azonban az adatmásolás, mert a CPU és a GPU hiába van fizikailag egy lapkán, attól még különálló memóriaterületet használnak, ahogy a CPU és a dedikált GPU. És az adatmásolás problémája jelentős, mert amit megnyert a GPU-s gyorsítással, azt az adatok másolásán elvesztheted. A következő lépcső tehát az, hogy a CPU és az integrált GPU közös címteret és megosztott memóriát használjon. Ilyenkor adatmásolásra nincs szükség.
A másik gond, hogy ha a hardver adott lesz, akkor felmerül a programozok szemszögéből az a probléma, hogy van egy rakás eltérő rendszer, teljesen különböző fizikai ISA-kkal, és ezeket nehéz programozni. Erre kell majd egy teljes infrastruktúra, mely bevezet egy mindenki által támogatható virtuális ISA-t. Például HSA.Az új dolgok mindig lassan terjedtek, ezen nincs semmi meglepő.
-
Chriss745
tag
Egyet mondjatok mar meg nekem legyszives. Evek ota hallgatjuk, hogy igy GPU-s altalanos gyorsitas, meg ugy GPU altalanos gyorsitas. Aztan mi van? Semmi. Mondjon mar valaki egy valos eletben is hasznalt, ismetlem, valos eletben is hasznalt alkalmasazt, ahol erezhetoen gyorsabb a program mert egy integralt vagy dedikalt videokartyaval van gyorsitva es nem csak CPU-n fut.
Az egyetlen egy dolog ahol en latom az ertelmet az a DXVA, de azt mar manapsag minden integralt GPU is tudja. Azon kivul mi?!
Megmondom oszinten van egy GTX680-asom, megvan jo par honapja mar, de en jatekon kivul masra meg nem tudtam hasznalni. Jott az nVidia is a NVENC-el, de 3 honapja nem kepes senki kiadni egy NVENC-el gyorsitott videokodolot, nevetseges.
Tegye fel a kezet akinek pl. ketszeresere gyorsult egy program, mert bekapcsolta a GPU gyorsitast (es itt nem beszelek a CUDA alapu video kodolasrol, mert az egy szep nagy csalas, azon a minsoegen ahogy a CUDA encodol a proci is tudja azt a sebesseget). En valahogy nagyon marketing bullshitnek erzem ezt az egeszet. Benchmark-ban uber jo, de igaazabol semmire sem lehet kihasznalni az uj featureokat. Csak belerakjak, azt mondjak huu, ez kell neked. Kulonben miert cserelne az ember procit?! Masik jo pelda az AVX. Hogy jott az intel az SB kiadasanal, hogy AVX, woow, aztan mi hasznalja ki az AVX-et majdnem ket evvel a kiadasa utan? Benchmark, oszt csokolom!
-
Abu85
HÁZIGAZDA
A hardver elméleti képességeiről beszéltem. Szoftverben még mindig fényévekre vannak. Amiről 'Geri' ír az az OpenGL driver, ami tényleg rém gyenge az Intelnél.
A hardver tempóját tekintve persze jóval lassabb a HD Graphics 4000, mint a leggyorsabb Trinity-s Radeon IGP (akár mobil, akár asztali), és ez főleg akkor jön elő, ha magas részletességet állít be a user a programnak, ahol a HD 4000 elfogy. Jellemzően médium szintig bírja. Ezek nyilván abból erednek, hogy az AMD jóval erősebb setup részt használ, hiszen órajelenként feldolgoz egy háromszöget, ami az Intelnek négy órajel, vagy a textúrázóblokk az valóban képes Gather4-et használni, ami pokoli előny DX10./11 alatt, hiszen minden ilyen játék támogatja. Az Intel tök logikátlanul csinálja, mert egy csatornán csak egy mintavételező van, míg az AMD-nél egy csatornához négy tartozik. A Gather4 utasítás az logikus. Egy helyet egyszerre négy mintavétel legyen, ehhez négy mintavételező kell, ahogy az AMD csinálja. Az Intel megoldása formálisan képes támogatni, de úgy, hogy négy órajelig csak a mintavételezéssel törődik az adott textúrázó csatorna. Ez a megoldás még lassabb is lehet, mint Gather4 nélkül, hiszen 3 kötelező üres ciklust fut a szűrő és a címző. Bárki találta ezt ki az Intelnél, az remélhetőleg már nem dolgozik ott (a jövőre való tekintettel persze, semmi személyes
). Szerencsére a Haswell IGP-je már valós Gather4 támogatást kap. A kisebb-nagyobb gyenge pontok mellett azért a Gen7 architektúra már elég jó. Gyakorlatilag a Gather4 para az egyetlen, ami komoly gond. Persze az LLC-be mentő stream out sem a legjobb, de az még benne van az elfogadható kategóriában. Ami viszont elég jó az a compute hatékonyság, és ez első nekifutásra dicséretes. Ha igazak a feldolgozók számáról érkező pletykák, akkor ez a Haswellben is javulni fog valamennyit. Persze a GCN ellen kell is.
Összességében a Gen7 architektúra tényleg nem rossz. Ami jelentősen visszafogja bizonyos szituációkban az a driver, és erre az Intel még mindig nem fordít kellő figyelmet.A WinZip és a VLC egy vitában merült fel. Nem azért, mert a legjobb példák az elérhető gyorsulásra, hanem azért, mert csak AMD-s OpenCL driverrel működő funkciókat tartalmaznak. Ez úgy jön le, hogy az AMD kisajátít egy szabványt, de valójában csak a fejlesztők nem engedik, hogy fusson a funkció Intel és NV driveren, amíg nem tudják garantálni a sebességelőnyt, vagy a megfelelő működést.
-
dezz
nagyúr
"a hardver elméleti képességeit figyelembe véve az Ivy Bridge is beérte az AMD-t"
Hááát, ebből számomra egyátalán nem ez derül ki...
(#42) Egon: Valójában nem sokat változott a meglévő működési állapotok fogyasztása (kvázi u.a. uarch és gyártástech), csak bejött egy új, amiről az itteni cikk is említést tett. Mint a HWSW-s cikk is írja (kissé körmönfontan), az üzemidő kitolása az új, félig alvó állapot bevezetése mellett annak is köszönhető, hogy bekerült a tokba a déli híd is, miáltal jóval kisebb lehet az alaplap és nagyobb az akksi... (Megjegyzem, az AMD már korábban beszélt arról, hogy integrálni akarja a déli hidat.)
(#47): Ezzel csak azt mondtad el, hogy a tizedét sem érted az "agymenéseinek"...
Azt mondjuk én sem tudom, hogy miért pont a WinZIP-pel és a VLC-vel példálózott, amikor vannak náluk sokkal fontosabb és jelentősebb gyorsulásokat elérő GPGPU-sított programok. [link]
(#63) Pikari: Nos, régóta tudjuk, hogy az Intelnél a prociarchitekrúra fejlesztésében a marketing is igen fontos szempont...
-
" Azon csak az segít, ha az Intel kifizeti a licencet az NV-nek." ujjajaj, attól tartok, ez nem ebben az évezredben fog bekövetkezni
(ill. ha az nvidiának esze lenne, és menteni akarná a diszkrét noti-bizniszét, akkor vmi apróságért cserébe/ingyen odaadják az intelnek a licenszet) -
Igen, az nvidiának kéne lépnie egy megfelelő driverrel... Gyakorlatilag az összes nvidiás laptop optimussal jön
(ami nem, azt meg csillagászati árakon árulják) -
Abu85
HÁZIGAZDA
válasz
t72killer
#72
üzenetére
Már most is van 120 Hz támogatás a driverekben. A Sandy Bridge óta. A 3D Vision viszont zárt rendszer, vagyis optimussal nem üzemképes. Csak olyan noti lehet 3D Visionös, ahol az IGP inaktív és a dedikált GPU-ra van kötve a kijelző.
Bármelyik optimusos noti kiesik ebből, mert kijelzőt nem köthetsz közvetlenül a dedikált GPU-ra. Vagy optimus, vagy 3D Vision. A kettő együtt nem lehetséges. -
Kérdés - amire egyelőre gondolom nincs válasz:
Tudni fogja az új igp a 1080p120Hz-et? (szemenkénti 60Hz 3D-ben) Azért kérdem, mert ez kéne az nvidia 3D vision használatához optimus rendszeren. (no meg persze megfelelő driverek nvidia ÉS intel részről)#hogyha a kép/számítási minőségen is javítanak (=driver) akkor 1etértek, az intel igp végre utoléri a jelenkort
. (elég nonszensz volt már, h a SB igp-k sem tudják a standard 23,976Hz-es blurayt lejátszani) -
#71
MCBASSTION
aktív tag
MCBASSTION
aktív tag
"Ráadásul a Haswell jövőre a Kaveri APU-t kapja a nyakába az AMD-től, melynek IGP-je már az új generációs GCN architektúrára épül."
lolwut? végre intel prociban is lesz normális igp
-
#67
FireKeeper
nagyúr
mrhitoshi
#66
FireKeeper
nagyúr
válasz
mrhitoshi
#66
üzenetére
hát az ivy biztos toc volt, de mivel se CPU se IGP fronton nem lesz nagyon radikális változás, ezt is toc-nak mondanám. bár új foglalat lesz hozzá, meg mintha úgy rémlene, hogy a VRM egyes részei be lesznek építve, de lehet rosszul emlékszem, és most óriási hülyeséget mondtam
-
jbush
tag
Én nem bánom, hogy ilyesmiket írogatnak tagok, amikről jelen esetben szó van. Nem bánom, mert Ti erre reagáltok; olyan tényeket, apróságokat is leírva, amelyek a cikkekben nem vagy nem ebben a formában kerültek be. Szóval én ezeket a hozzászólásokat szeretem olvasni - azaz a Tieiteket ebből főként -, mert elég sokat lehet belőle tanulni :-)
-
Pikari
addikt
A legfontosabb változás mégis az AVX2 utasításkészlet bevezetése, mely új 256 bites lebegőpontos feldolgozókat is kapott.
micsoda előrelépés!
(nem, nem az, életemben kb 1x láttam 80 bites lebegőpontos számokat forráskódban, az is inkább csak elírás lehetett, mint valódi szűkséglet. a 64 bit bőven elég.)Egy Haswell processzormag két darab 256 bites vektorfeldolgozót alkalmaz, amelyek összesen 16 darab FMA operációt végezhetnek egy órajel alatt
ennek nincs értelme, ennyit nem lehet kötegelni. egy szoftverben tipikusan különböző típusú műveletek jönnek egymás után, és nem ennyi ugyanolyan. talán a mátrixszorzáson (oda a 16 kevés, ezért kettőt kell indítani, ami önmagában már 2x5 órajeles késleltetés lesz, plusz amíg összekotorja magát) és az egymás után pakolt interpolálásokon (oda a 16 sok) segíthet.(az FMA késleltetése öt ciklus).
pont 5 ciklussal több, mint amekkorának lennie kéne az effektív felhasználhatósághoz.
és akkor ezzel a jelentősen gyorsabb mátrixtranszformáció szerű felhasználást pont ki is nyírtuk szépen.imho ezt az egységet szét kellett volna szedni kétfelé, és úgy megcsinálni, hogy ne legyen késleltetése (vagy ha igen, akkor 1 órajelnél semmiképp se több)
ez így önmagában értelmetlen, de talán majd egyszer, ha jelentősen gyorsítják, több értelme lesz.
mely az adatpárhuzamos processzorok esetében egy hatékony rendszer a memória kezelésére, mivel egyszerre több memóriacímről olvas
a különböző típusú műveletekhez mind különböző, egymással távoli rokonságban sem álló gather szerű műveletek kellenének, egy TMU algot fog is vagy 5%-ban fog gyorsítani.
erre is kár volt a tranyókat pazarolni.Az Intel bevallása szerint a setup motort teljesítménye kétszeresére nő
akkor talán a terrain kirajzolás mostantól akár a radeon 8500 szintjének a felét is elérheti.Ez lehetővé teszi, hogy a webkamera által közvetített adat dekódolása a korábbinál energiahatékonyabb legyen
az jó, mert a linuxos drivereket elnézve minden webkamera saját formátumban adja a képet, amit aztán már algoritmikusan kell ide-oda kódolgatni. a beérkező kamerakép dekódolása meg annyi féle, ahány csevegőszolgáltatás van...Az Intel szerint ez a jól megírt programok számára transzparens
legyünk őszinték: szarul van megtervezve, és a programok egy része el fog tőle durranni. -
#62
i-sti
senior tag
Neovenator
#61
i-sti
senior tag
válasz
Neovenator
#61
üzenetére
"szallithatosag miatt" ?
Ezt nem ertem -
-
Abu85
HÁZIGAZDA
Ha egy program feldolgozása valamitől gyorsul, jelen esetben a GPU-s feldolgozástól, és az számodra nem fontos, attól még másnak nem lehet az? Valaki szeretne gyorsabban betömöríteni egy fájlt ... például.
Elfogadható, hogy nem veszel új gépet, mert nem akarsz gyorsabbat, de ezt nem biztos, hogy érdemes általánosítani.A VLC AMD-exkluzív implementációja nem a sebességre hat, hanem a képminőségre. A sebességre az OpenCL scaling szolgáltatás hat, de az univerzális, vagyis nincs az AMD driveréhez kötve. Az OpenCL open platform, vagyis mindenki támogatja. Ha az Intel és az NVIDIA driverein is megfelelő az adott funkció működése, akkor természetesen nincs oka a fejlesztőnek letiltani azt. Éppen ezért a VLC a gyorsított scalingot nem is korlátozza az AMD OpenCL driverére.
A Corel is megmondta, hogy amint sikerül megoldani az Intel és NVIDIA termékeken tapasztalt gondokat engedélyezik. Ehhez egyrészt a fejlesztőknek kell tovább optimalizálni, másrészt a drivereket is hozzá kell igazítani ehhez. Ergo a WinZip gyorsított tömörítése sem marad örökre AMD-exkluzív.Állítottam valaha, hogy CPU-ban erősebb az AMD? Itt most tudtommal APU-król beszélünk. Legalábbis az OpenCL igazi célja a heterogén módon történő programfuttatás.
-
Egon
nagyúr
Nah, ma utoljára.
Ahhoz képest, hogy pár hónapja (ismét) vérig sértődtél, és azt mondtad, hogy soha többet nem lépsz be ide, szépen osztod ismét az oldalt.
Mese habbal. Linket plíz, mert nem emlékszem hogy ilyet írtam volna. Szerintem Löncsivel keversz.
Ha ennyire nem bírsz elviselni minket és a munkánkat, akkor tényleg nem kell belépni és fikázni, mert lépten-nyomon csak a flame és az OFF lesz belőle.
Hadd döntsem már el, hogy mikor miket írok be ide. Ha nem tetszik, moderáld vagy moderáltasd. Az nagyon megy amúgy is (mint múltkor az nV-s topicban, ahol egy tucat hsz-en keresztül offoltál, és amikor erre felhívtam a figyelmet, még én lettem kitiltva). Saját szemedben a gerenda megtalálása meg nagyon nem.
#52) Abu85 :
Tehát alapvetően azzal a ténnyel van gondod, hogy a Corel és a VideoLan nem készített támogatást az Intel termékekhez, mert nem értékelték megfelelő minőségűre az OpenCL meghajtójukat.LOL. Na igen, a csúsztatás nagymestere vagy nem is vitás. Benned legalább fél tucat politikus veszett el, ha nem több.
Nem ez a baj, ezt te is pontosan olyan jól tudod, mint én. Ezt a "nagggyonfontos" (gy.k. azért az idézőjel, mert irónia, mielőtt ezt is szándékosan félreérted) fícsört, az emberek 99,99999999999%-a lesz*rja. Mert baromira nem fontos. Még csak nem is lényeges. Mivel nem tömörít senki sem (max. kitömörít, amit letorrentezett; az meg általában csak darabolt, így a szűk keresztmetszet a háttértár, már évek óta, egy a maiaknál jóval gyengébb procin is), pláne nem WinZip-pel. A VLC haználata pedig a júzerek közel 100%-ánál kimerül abban, hogy lejátszik vele valamilyen tartalmat, ami OpenCL támogatás nélkül is remekül megy. Osztán mégis annyit emlegeted, mintha ez lenne a Szent Grál, a számítógépes felhasználás Mekkája, alfája és omegája meg ilyenek. Holott egy olyannyira lényegtelen fícsör, hogy - a híren kívül, amiben megjelent - kb. szót sem érdemelne. Ennyi.
Persze valahogy oldani kell a frusztrációt, amit az okoz, hogy tisztán CPU-fronton már évek óta labdába sem tud rúgni az AMD az Intel mellett (és ezen a loldozer megjelenése sem változtatott), ezt nem vitatom...![;]](//cdn.rios.hu/dl/s/v1.gif)
-
-
Abu85
HÁZIGAZDA
Tehát alapvetően azzal a ténnyel van gondod, hogy a Corel és a VideoLan nem készített támogatást az Intel termékekhez, mert nem értékelték megfelelő minőségűre az OpenCL meghajtójukat. Már bocs, de ez legkevésbé az én hibám. Az Intelnek kell írni, hogy vegyenek fel több rendszerprogramozót, adjanak nagyobb anyagi támogatást a szoftverfejlesztőknek, illetve fejlesszék gyorsabban az OpenCL SDK-jukat. Ha ezeket megteszik, akkor nem lesz a jövőben olyan dolog, hogy ez meg az a funkció csak AMD hardverrel üzemképes.
-
Oliverda
félisten
Ahhoz képest, hogy pár hónapja (ismét) vérig sértődtél, és azt mondtad, hogy soha többet nem lépsz be ide, szépen osztod ismét az oldalt.
Ha ennyire nem bírsz elviselni minket és a munkánkat, akkor tényleg nem kell belépni és fikázni, mert lépten-nyomon csak a flame és az OFF lesz belőle.
-
#47
Egon
nagyúr
fatallerror
#46
Egon
nagyúr
válasz
fatallerror
#46
üzenetére
Nagyjából-egészéből kezdek leszokni a ph-ról, csak viszonylag ritkán olvasok cikkeket (inkább megyek az objektívebb, nem fanboykodó konkurenciához (bár Abu képes ott is megjelenni a fórumon AMD-fankodni: tök gáz hogy mindenhol az agymenéseibe botlok, mint pl. a naggggyonfontos WinZip és VLC gyorsítás - szerintem erre már valami makrót használ, annyiszor leírta mindenhová)), illetve külföldi oldalakra). A fórumot meg zömében akkor használom, ha konkrét infót gyűjtök valamiről).
Mit ne mondjak, tettek érte, hogy így tegyek. Ennyi. -
Abu85
HÁZIGAZDA
"Végül változás érte az energiamenedzsmentet is. Az Intel a készenléti módban bekapcsoló energiagazdálkodási állapotok mellett bevezet egy hasonlóan takarékos aktív állapotot. Ez lényegében arra jó, hogy az adott notebook készenlét helyett aktív állapotban maradjon, vagyis függetlenül attól, hogy nem használja a felhasználó, képes legyen fogadni az üzeneteket például. Az Intel szerint ez a jól megírt programok számára transzparens, vagyis elméletben nem lehet gond, ha a készenlét helyett a felhasználó az új aktív állapotnak szavaz bizalmat. Persze amint használatba lesz véve a mobil termék, azonnal bekapcsol a szokásos aktív idle állapot."
Köszönjük
... de a tényekkel látom te sem szállsz vitába, mert az nagybetűs tény, hogy képminőségben van mit faragni a hátrányból. A felvezető előadásba nem kötöttem bele, csak langyos volt. Nem azért, mert nem volt izgalmas, hanem azért, mert azt a jövőképet vázolta fel az Intel, amit az ARM és az AMD már 2010-ben megtett, és az Intel a Sandy Bridge németországi bemutatóján közölte rá, hogy nem kivitelezhető ... talán 10 év múlva. Ez így langyos, mert innovatívként mutatták be, azt amit más két évvel hamarabb felvázolt.
-
Egon
nagyúr
Én inkább úgy közelíteném meg a kérdést, hogy fölöttébb érdekes az, hogy a ph-s hírből kimaradt az új generációs Intel procik egyik legfontosabb (ha nem a legfontosabb) előnye: a fogyasztás... Nyilván véletlenül. Mint ahogy az AMD fényezése, egy Intel termékről szóló cikkben is csak puszta sajtóhiba (még a felvezető előadásba is sikerült belekötni. Ehhez csak gratulálni tudok.).
Mondjuk megszoktuk már.(#43) fatallerror nem, az origós cikkben szereplő üzemidős adatra.
-
Begi
senior tag
Huhh mennyi válasz. Pedig csak félkomolyan irtam, csak a smile maradt le, sry.
leszo6: Az sem segit az OP rendszer hülyeségein.
Oliverda: Ne legyen igazad, bár én inkább 100 évet mondanék. Igazából akárhogy is nézzük forradalmi újitás, ami megváltoztatta volna a PC-t nem volt az elmúlt 20 évben. Csak a technológia fejlődik/csiszolódik. ( Még mielőtt megszólnátok hozzáteszem, szerintem )
ddekany:
nyerek01: Természetesen, mivel magát a kérést is x idő alatt dolgozza fel a rendszer. Az azonnalt inkább az értelmetlen várakozások kiiktatására értettem. Mert az tény hogy vannak fizikai korlátok, amiket nem lehet átlépni. -
i-sti
senior tag
-
Abu85
HÁZIGAZDA
-
-
Abu85
HÁZIGAZDA
Bár az Intel sosem beszélt róla, de a gyártóktól tudom, hogy a Larrabee-t az Intel eredetileg a Haswellbe szánta. De mivel a Knights Ferry nem működött, így erről letettek. Ez ugye logikus, mert egy nem működő architektúrával nincs kisegítve az Intel. Ezért is Gen7.5 az IGP, mert a Larrabee elkaszálása miatt továbbfejlesztéssel kell operálni a reformok helyett. Ebből viszont látszik, hogy az Intel is tartotta volna a lépést a Kaveri APU rendszerszintű integrációjával, legalábbis a tervekben így volt, és a Larrabee-vel még jobb is lett volna az integráció. Most ez a terv 2015-re csúszott a Skylake APU-ra. Abban igaza van az Intelnek, hogy a fővonalbeli termék nem ideális kísérletezésre, mert azzal kivégezhetik az eladást. Túl nagy a kockázata, hogy rossz lesz.
A Kaverinek a közös címtérből és a teljesen koherens megosztott memóriából igazi előnye a felhős kiszolgálókban lesz. A GPU-ra kirakott memcached rendszert alkalmazza a YouTube, a Facebook, a Twitter, a Flickr, illetve a többi nagyobb hasonló portál, de a PCI Expressen keresztüli adatmásolás eléggé korlátozó, vagyis ahhoz, hogy előnyt lássanak belőle brutálgyors GPU kell, ami viszont durván fogyaszt. Ezeknek a cégeknek egy Kaveri APU Opteronban igazi főnyeremény, mert tökéletes az IGP a memcached rendszerre, és nincs adatmásolás, hiszen közös a memória. Nyilván nem véletlenül tűnt fel a 2013-as útitervben az Opteron APU. Beledobva az új SeaMicro SM15k rendszerbe, gyakorlatilag megvan az ultimate kiszolgáló a YouTube, Facebook, Twitter, Flickr négyesnek, de még a többieknek is. A Hadoopot használó szerverek szintén nagyon sokat profitálnak a Kaveri integrációjából. Szóval ahol a Kaverinek nagy haszna lesz az újításokból, azok a felhős kiszolgálók, a mikroszerverek, de a HPC is elég komoly opció.
A konzumer szinten a játékok láthatják a Kaveri integrációjának előnyét. A fizika állandóan előkerül, de mindig gond lesz, hogy ha hat a játékmenetre, akkor nem skálázható, vagyis nem lehet eldurvulni, hiába az elérhető számítási kapacitás. Ugyanez a gond a processzor oldalán is. Ott is főleg SSE2-re építenek még a fejlesztők, mert a skálázhatóság korlátozza a továbblépést. Egyszer meglépjük, de nem ma, és nem a közeljövőben. Szóval a fizika gyorsítása az marad az eye-candy részre (részecskeszimuláció), amit persze lehet fizikának hívni, de lényegében grafika.
Amit már több fejlesztő is felvetett, mint valóban használható alternatíva az a frustum és az occlusion culling. Előbbi rengeteg vektoros számítást használ, míg utóbbi gyakorlatilag egy előrenderelés nagyon egyszerű objektumokkal. Ezek nagyon ideálisak egy IGP-nek. A sorting is nagyon értékes terep, és baromira az IGP a legjobb rá. Itt tényleg nagyon előnyös a közös címtér. Ott a tartalomkikódolás is, amivel jobb lehet a streamelés. A játékok mennek afelé, hogy ne legyen töltőképernyő, tehát valós időben kell streamelni, és ez valós idejű tartalomkikódolásért kiállt. Például az agyontömörített textúrákat ki kell kódolni a GPU számára emészthető formátumba, ha megatextúrát használ a játék. Az útkeresés is elég jó opció az IGP számára egy stratégiai játéknál.Amire az AMD még nagyon figyel az a hang-, gesztus- és mozgásfelismerés. Mindegyik nagyon illik az IGP-hez. Főleg a gesztus és a mozgás, mert alapvetően képkocka lesz a beviteli adat. Ezek már ma is léteznek csak nem elég pontosak, és a pontosságot a ma elérhető számítási kapacitás korlátozza. Az IGP-vel gyorsítva ez új szintre emelhető.
Biometrikus azonosítás a biztonság szempontjából nagyon jól gyorsítható terület. Nincs pontosabb azonosítás a retinaszkennelésnél, de zabálja a teljesítményt.Nagyjából ezek lehetnek a tényleges felhasználási módok, plusz a mostaniak gyorsulhatnak.
(#25) Jim Tonic: Az a Piledriver lesz. Jönni fog októberben-novemberben.
-
ddekany
veterán
Mi lesz, mikor AMD kijön a Kaverivel? Mikor lesz Inteléknék közös címtért a CPU-nak és a GPU-nak, hétköznapi gépekbe szánt APU-kban? Aztán persze lehet hogy kutyát nem érdekli ez, amíg az Intel nem támogatja, mivel leghamarabb is csak onnantól kezdi majd ezt elvárni (értsd anélkül szarul fut) némely halandóknak szánt alkalmazás...
-
#22
Mr President
senior tag
Mr President
senior tag
Én a mobil Haswell procikat várom, erre már cserélni fogom a jó öreg t7700as notim.
-
arn
félisten
a sb nagyobb ugrasnak tunt... de en is total okafogyotta erzem az egesz hwfejlesztgetosdit, egyszeruen nincs hova. tavaly ev elejen felturboztam a gepet (i7, ssd, gtx560), ezt majd egy olyan masinara cserelem le, amit majd felcsavarozok a monitor hatuljara. az is eleg lesz.
htpc is negy eves lesz, de tokeletesen fut rajta az xbmc...
sokkal erdekesebb a mobilpiac... absz alkalmi jatekos vagyok, es hiaba itt az asztali hw, kb ev elejen jatszottam utoljara pcn, inkabb a mobilkutyuket nyomkodom.
-
Abu85
HÁZIGAZDA
Tisztán technikai tudásban már az Ivy Bridge is beérte őket. Az AMD-t azért támogatják jobban és hatékonyabban (vagy esetenként azért futnak) a GPU-val gyorsítható programok, mert két fejlesztési fázissal az Intel előtt járnak a fejlesztőkörnyezetek tekintetében, és a driver is jelentősen jobb. A hardver csak akkor ér valamit, ha raksz elé egy drivert. De az a tény vitathatatlan, hogy a hardver elméleti képességeit figyelembe véve az Ivy Bridge is beérte az AMD-t.
-
#7
i-sti
senior tag
fatallerror
#5
i-sti
senior tag
válasz
fatallerror
#5
üzenetére
En a Skylake-et varom. Eddig ugy allok hozza, hogy a jelenlegi Q9550@3.0GHz-at a Skylake-re cserelem, habar meg nem tudom, hogy a Tic vagy a Toc szeriára cseréljem.
A Tick az még nagyon új lesz (kiforratlan).
A Tock az már a V2.0 (majdnem), de egy évbe se fog kerülni s intel bácsi már piacra fogja dobni a következő architekturáját.*Lehet, hogy a Tick-Tock forditva van, nem tudom, hogy az intel hogy nevezgeti oket.
A #81-est félkómásan írtam éjszaka. A "256-bites FP" részt olvasva (átfutva) arra gondoltam: "az nem lehet, hogy tényleg így érti..." A ciklusokkal kapcsolatban azt hittem, az a gondja, hogy annyi idő alatt hajtódik végre, mintha sima elemi utasítások sorát hajtanánk végre.
(ill. ha az nvidiának esze lenne, és menteni akarná a diszkrét noti-bizniszét, akkor vmi apróságért cserébe/ingyen odaadják az intelnek a licenszet)
(ami nem, azt meg csillagászati árakon árulják)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Érzésem szerint Abu minden csak nem pártatlan, én még embert nem láttam aki ennyire nyomatja az amd-t.
Még valamikor augusztus végén keresgéltem/olvasgattam a híreket a témában, azóta ez a cikk valahogy kimaradt. Köszönöm mindkettőtöknek.
Új hozzászólás Aktív témák
Hirdetés
ph Az új generációs architektúra lényegében az IGP szempontjából fejlődött, de az AVX2 utasításkészlet is hasznos.
- iPhone 16e - ellenvetésem lenne
- Sütés, főzés és konyhai praktikák
- Star Trek
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Formula-1
- Alkoholista nevelde
- Casco és kötelező gépjármű felelősségbiztosítás
- alza vélemények - tapasztalatok
- Abarth, Alfa Romeo, Fiat, Lancia topik
- Luck Dragon: MárkaLánc
- További aktív témák...
- DELL PowerEdge R730xd 12LFF 48TB+400GB rack szerver - 2xE5-2680v3,128GB RAM,2x10G NET,H730p RAID
- Bomba ár! Lenovo ThinkPad X395 - AMD Ryzen PRO 5 I 8GB I 512GB SSD I 13,3" FHD I Cam I W11 I Gari!
- AKCIÓ! ASUS PRIME Z370 i7 9700E 16GB DDR4 512GB SSD RX 6600 8GB GDDR6 CM 690 III Corsair 550W
- ÁRGARANCIA!Épített KomPhone Ryzen 5 5500 16/32/64GB RAM RTX 4060 8GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! DELL OptiPlex 3050 asztali számítógép - i5 7600 16GB RAM 256GB SSD GTX 1650 4GB GDDR5
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest