- VR topik (Oculus Rift, stb.)
- Egyelőre nem tarolja le a piacot a Vision Pro
- Fujifilm X
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Intel GPU-k jövője - amit tudni vélünk
- Kormányok / autós szimulátorok topicja
- Nyár közepén jön az AOC 540 Hz-es gaming monitora
- Házimozi haladó szinten
- Milyen joysticket vegyek?
- Melyik tápegységet vegyem?
Hirdetés
-
Lopják az LG akkutitkait
it Inkább licenceli ezentúl az akkumulátoros szabadalmait az LG Energy Solution, mert túl sok a jogsértés. Az LGES mellett az UMC is az autóipar egyre lassuló keresletére figyelmeztet.
-
Megjelenési dátumot végre a Men of War II (PC)
gp Többszöri halasztás után végre megkapjuk a régóta várt folytatást.
-
Szűkös készlettel indít az iPad Pro OLED?
ma Állítólag meggyűlt a Samsung baja az iPad képernyőkkel, az LG viszont a kívánt mennyiségben szállítja a paneleket.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Mert a SPIR-V egy bájtkód, így valamivel alacsonyabb az absztrakció szintje, ami jobb kompatibilitást jelent. Emellett az új felületek csak SPIR-V-t fogadnak el bemenetként. Ha rossz a SPIR-V bájtkód, akkor mindenkinek az lesz, ha pedig jó, akkor mindenkinek jó. A SPIR-V fordítást azonos fordítóval meg lehet oldani.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3
Meteorhead
aktív tag
#32839680
#1
Meteorhead
aktív tag
Továbbá OpenGL hibája is az volt, hogy túl laza volt a GLSL specifikációja, és lehetett így is és úgy is értelmezni. Sok esetben ezért eltérő volt a gyártók közötti viselkedés.
Ahogy Abu is mondta, alacsonyabb szinten kevesebb a félreértés. Az x86 már elég alacsony szintű, azt senki sem érti félre. Két regiszterben található érték összege elég egyértelmű. Egy emberi nyelven írott verset pedig elég sokféleképpen lehet értelmezni.
Egyébként lesz szabványos GLSL >> SPIR-V konverter is, hogy mindenki ugyanúgy értse félre a specifikációt. ;-)
-
LordX
veterán
Az OpenCL forditók közötti eltérés nem értelmezésbeli eltérés... Vagy szabványban megengedett implementációs különbségekről van szó, vagy bugról.
Bugok a SPIR-V finalizerek közt is fognak eltéréseket hozni, úgyhogy ezt a szálat most hagyjuk.
Az implementációs különbség meg olyan, hogy egyik esetben 64 szál lehet egy workgroupban, a másikban 256, a harmadiknál a legszélesebb használt adattipustól függően 4/8/16, hogy az egyikben 4k __local memory van, a másikban 32k, stb. Itt vagy megirod a kódod a legkisebb közös többszörösre, és mindenhol lassú leszel, vagy #ifdef __AMD__ #elif __INTEL__ #else #endif (vagy dinamikusan kéred le, effektive ugyanaz). És ezen a SPIR-V se segit semmit.
-
Fiery
veterán
"Az implementációs különbség meg olyan, hogy egyik esetben 64 szál lehet egy workgroupban, a másikban 256 ..."
Pontosan. A problema csupan az, hogy egyesek -- es itt nem akarok ujjal mutogatni -- azt gondoljak, hogy a GPU-kban levo rengeteg eroforrast olyan egyszeru kihasznalni, hogy radobsz egy bazinagy tömböt a GPU-ra, es majd az megoldja a rengeteg warppal meg rengeteg regiszterrel a kerdest. Ez a trivialis megkozelites, ami nyilvan egyszeru feladatoknal -- pl. egy szazmillio+ megapixeles foto konverzioja szinesrol fekete-feherre -- me'g mukodhet is. De amint valami igazan erdekeset kezd az ember csinalni a GPU-kkal, bejonnek az architekturalis sajatossagok (meg a compiler bugok), amikkel ha nem kezd az ember valamit, akkor bizony nem lesz olyan fantasztikus a gyorsulas egy jol optimalizalt x86 kodhoz kepest, mint az ember azt várná naivan. Es itt nem kell embertelenul komplex feladatokra gondolni. Pl. mar egy pofonegyszeru AES adat titkositasnal is bejonnek az architekturalis sajatossagok.
-
Egon
nagyúr
Idén sem jött be a heterogén mantra
Ütős cím, annyi szent...
![;]](//cdn.rios.hu/dl/s/v1.gif)
"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)
-
MaUser
addikt
Kb. ez az a kérdés, amit évek óta minden ilyen "juj de jó a gpugpu, ma is megváltja a világot valahogy egy újítással és az mindennél jobb" cikknél felteszek. Válasz viszont nincs. Szóval mire kell nekünk gpgpu, azon túl, hogy az AMd ebbe az irányba vergődött megfelelő r&d hiányában?
Nézzük, milyen esetek vannak ma:
- semmire nem kell több szál
- néha kéne több szál, de igazából ezt egy pár magos proci megoldja (pl. async műveletek -> bár ez igazából gy magon is elmegy jó fordítónál/sdk-nál és ma már a legtöbb architektúrára ilyen van)És ezzel kilőttük az esetek 99.99%-át. Mire kéne gpgpu? Ar-re? Hololensbe mi is van most?
Btw. tfh. képet szerkesztünk, videózunk, modellezünk és kellenek gyors mátrix műveletek konvolúcióhoz, sparse mátrixozáshoz, véges elem számításokhoz, stb. Ekkor adunk neki fix cuda supportot és kész. Övék a piac 75-90%-a consumer/profi szinten. Vagy csináljuk ocl-lel, ha nagyon szabványosodni akarunk (nem akarunk, mert előjönnek a cikkben említett problémák).
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
freeapro
senior tag
Abu! Már a sokadik cikkedet olvasom a témáról, amiben láthatóan jól otthon vagy és a cikkekbe is sok energiát fektettél de nem tartalmaz semmi konkrétumot. Az ilyen cikkeket programozók írják programozóknak és ez kód nélkül így üres. Lenne kedved guideline szerű cikket írni? Egy egyszerű probléma köré (mondjuk szabály alapú mintaillesztés) ahol konkrétan végigvezeted az olvasót, hogy mit töltsön le, hogy építse fel a kódot, milyen buktatókat kerüljünk el stb..
Tudom ezt a tudást a netről is össze lehet szedni, de ez min. 1 hónap lépésről-lépésre guglizást jelentene amit eddig egy egyszerű érdeklődés miatt nem volt kedvem bevállalni. -
nyunyu
félisten
Fennallo problemak athidalasara bevezetnek meg harom uj szabvanyt, aztan csodalkozni fognak, hogy meg kevesbe fog csokkenni a kaosz.
Mivel a nepeknek nem lesz kedve n helyett n+3 megoldast tamogatni.
Valamelyik korabbi Abu cikkbe belinkelt valaki errol egy jopofa kepregenyt, de nem talalom
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
MaUser
addikt
Van a cégnél egy HPC nV kártyákkal, ahogy a cégek 95%-nál ilyen van. Mi másra írja(na)k programot?
Consumer piacra szánt progiknál már biztos játszik a rossz szabványok miatti szívás, de alig van ilyen progi ma.
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
LordX
veterán
Hát, véleményem szerint az aktuális OpenCL-hez képest az aktuális CUDA szar.. 1.2-nél persze jobb a 3 éves CUDA is, csak azt már mindenki (lassan including mobil GPU) meghaladta az nVidiát kivéve.
Azért használja mindenki a CUDA-t, mert mindenki CUDA-t használ. Arra vannak hülyére optimalizált libek.
-
Nem az a kérdés, hogy mire kell több szál. A probléma, hogy megírod a programot, de egy kalap kaki lesz, mert egy CPU szálon a sebessége egy kalap túró / nem energiahatékony. Az egyszálas teljesítmény / fogyasztás arány (x86 vonalon) egy ideje alig javul, az utóbbi években igencsak lelassult. Az újabb gyártástechnológiákkal is vannak problémák (lásd 20nm), örökké nem lehet csíkszélt csökkenteni. A kérdés az, hogy hogyan lehetne sokkal jobb teljesítményt és energiahatékonyságot elérni?
Vannak már jó ideje masszív többszálasításra tervezett architektúrák, melyek már bizonyítottak (mindenhol van GPU), s energiahatékonyságban is igencsak jók egy CPU-hoz viszonyítva. Ezekre kéne felhasználás terén is valahogy építeni, masszívan. Már amit lehet, már ha van értelme, már ha lehet. Sok a ha és jelenleg baromi lassú a folyamat, HSA is nemrég lett szabványosítva, s az új konzolok se hoztak semmi megváltót.
Így egyelőre még csak próféciák vannak, komoly eredmények nélkül, de jelenleg egyszerűen nincs más út. A FPGA alig valahol, a SIMD kiterjesztések a kutyának sem kellenek, stb., GPU viszont már szinte mindenhol van. Ezzel kell kezdeni valamit. Hacsak nem valaki hirtelen jön valami jobb ötlettel.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
Bundyta
tag
hogy nem a fizikai utasításarchitektúrán fut a program, hanem előtte egy szoftveresen felhúzott rétegen.
Ez a lényeg. Egy kicsit olyan, mint 6510-es kódot x86-on futtatni. Magától nem megy, kell egy program hozzá.
Ezt hívják emulálásnak.
(De lehet, alaposan mellétrafáltam.)
A pénz nem boldogít. Pláne, ha nincs.
-
Fiery
veterán
"Az egyszálas teljesítmény / fogyasztás arány (x86 vonalon) egy ideje alig javul"
Ebben egeszen biztos vagy? Es a Carrizo? Meg egy csomo ULV Intel proci? Nem minden a 4+ GHz-es desktop procikrol szol, sot, ujabban mar semmi sem szol roluk...
"örökké nem lehet csíkszélt csökkenteni."
Egy jo darabig me'g lehet, 5 nm-ig megvannak a tervek. Az me'g kb. 10-12 ev, az pedig az informatikaban eleg hosszu tav.
"A FPGA alig valahol"
Na persze, ezert is fizetett ki az Alteraert 16,7 milliard dollart az Intel. Nyilvan sehol sincs az FPGA, ha ennyi penzt megert az Intelnek a ceg
"a SIMD kiterjesztések a kutyának sem kellenek"
Errol hol van konkret statisztika? A PH "hir"-eken kivul persze, amik nyilvan mindig reprezentativ statisztikai adatokon alapulnak.
"Hacsak nem valaki hirtelen jön valami jobb ötlettel"
Erre en szemely szerint sokkal tobb eselyt latok, mint hogy a GPU-k altalanos celu felhasznalasa vegre tomegesen is meginduljon. Mar szamtalanszor leirtam: 10 eve megy a **szkolodas a GPGPU temaban, es ennyi ido es elkoltott sok-sok milliard dollar (by AMD) sem volt eleg az attoresre. Egyesek szerint adni kell a dolognak me'g 10 evet -- hasonloan, mint az Itaniumnak?
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
De az a baj, hogy erről vita van. Ha a szabványban megengedett implementációs különbség meggátolja a programfuttatást magas szintű kód szállításával, akkor az rossz. És ezen nem segít az, hogy a Khronos szerint egyértelmű a specifikáció xy gyártók szerint pedig nem. Erre jött a SPIR-V.
Bugok vannak az összes fordítóban, ez nem lesz újdonság. De a problémák zöme a magas absztrakciós szinthez kapcsolódott, így ha azon segítünk, akkor a gondok mennyisége kezelhető szintre csökken.
A SPIR-V-nek nem célja a programozási problémák megoldása. Az a programozó feladata. A cél az, hogy ha megírtál egy szabványos kódot, akkor az tuti fusson. A kód sebességét nem fogja javítani.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ahogy a cikk is írja két lehetséges irány van a teljesítmény növelésére. Mindkettő előnyeit és hátrányait átvette.
Maxime egyébként az x86-os SIMD implementáció hibái mellé azt is leírta, hogy az ideális irány egy Cray-1-féle dizájn lenne modernizálva, mai mértékben jó sebességgel, de senki sem fog radikálisan újat építeni, mert nem épülne ki rá a szoftveres ökoszisztéma. Tehát ma ott tartunk, hogy az igazi megoldást senki sem támogatná, így a két félmegoldásból kell választani a jobbikat. A GPGPU azért reálisabb, mert szoftveresen megoldhatók a problémái, míg az AVX problémáit csak hardveresen lehet kezelni.
Jelenleg sokkal reálisabb azt elvárni, hogy az IL/IR-ekkel a GPGPU alternatíva lesz, mint azt, hogy az Intel kidobja az x86-ot, hogy az AVX működjön.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#32839680
#13
üzenetére
Boltzmann Initiative egy puccs semmi más. A SYCL 2.1 sokkal jobb alternatíva, mert full szabványos, és ugyanazt tudná, de az AMD le akarja zárni magának a piacot. A HIP nem lesz jobb, mint a CUDA. Mármint a piacra kifejtett káros hatása szempontjából. A HSA+ is egy olyan környezet, amelyet az AMD specifikál és nem része a HSA alapítványnak.
A HPC-s berkekben sem örülnek ennek a csomagnak. Az AMD ki akarja használni, hogy rajtuk kívül még senki más nem épített hatékony multiprecision ALU-t. És ennek az előnye kézzel fogható, mert a második leggyorsabb lapkájuk DP teljesítményét is csak két lapkával tudja megközelíteni az NV. A Boltzmann Initiative csak arra szolgál, hogy ezt kihasználva a saját CUDA-jukba zárják a piacot.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
MaUser
addikt
Nem az a kérdés, hogy mire kell több szál.
De, pontosan ez a fő kérdés. Jelenleg ugyanis kép- és videofeldolgozáson kívül szinte semmihez nem kell. Amihez máshoz kellhet, az meg GPU függő volt eddig is. És innentől kezdve el is jutottunk oda, hogy miért tarolt az intel a semmire sem jó GMA-kkal anno. Mert egyszerűen ha már van youtube gyorsításod, az elég a vevők 99,99%-ának. A maradék 99%-a meg gamer, a többi meg úgyis valami ws-t használ.
A probléma, hogy megírod a programot, de egy kalap kaki lesz, mert egy CPU szálon a sebessége egy kalap túró / nem energiahatékony.
Én nem ezt látom. Egy 2500k-val évek óta elvagyok és nem érzem lassúnak. Ahol az, ott meg célhw kell(ene).
Az egyszálas teljesítmény / fogyasztás arány (x86 vonalon) egy ideje alig javul, az utóbbi években igencsak lelassult.
Felső kategóriában lassult, de hát ennek főleg a konkurencia hiánya az oka, illetve, hogy nincs motiváció a felhasználók felé. (És már vissza is értünk oda, amit az elején kérdeztem, hogy minek gpgpu. Nincs rá program.) Alsó kategóriában viszont iszonyat a gyorsulás, az új atomok már igen jók és rácáfolnak mindenre amit az ember x86-tól elvárt volna.
Az újabb gyártástechnológiákkal is vannak problémák (lásd 20nm), örökké nem lehet csíkszélt csökkenteni.
Ezt minden évben elmondják, sőt én még egyetemen azt tanultam, hogy 20nm alá nem lehet fizikailag bemenni, aztán már alatta vagyunk.
A kérdés az, hogy hogyan lehetne sokkal jobb teljesítményt és energiahatékonyságot elérni?
Nem, a kérdés, hogy PC szinten akarunk-e jobbat elérni. Jelenleg úgy néz ki nincs rá komoly igény egyszerűen.
Vannak már jó ideje masszív többszálasításra tervezett architektúrák, melyek már bizonyítottak (mindenhol van GPU), s energiahatékonyságban is igencsak jók egy CPU-hoz viszonyítva.
Igen, csak ezek az architektúrákat célhw-ek. A kérdés, hogy célhw-re miért akarunk nem általános programot írni? Minek futtassak egy sima progit gpu-n, amikor nulla párhuzamosítható rész van benne?
.Ezekre kéne felhasználás terén is valahogy építeni, masszívan. Már amit lehet, már ha van értelme, már ha lehet.
Igen, csak jelenleg úgy néz ki, hogy nincs, mivel nincs ami kihasználná.
Így egyelőre még csak próféciák vannak, komoly eredmények nélkül, de jelenleg egyszerűen nincs más út. A FPGA alig valahol, a SIMD kiterjesztések a kutyának sem kellenek, stb., GPU viszont már szinte mindenhol van. Ezzel kell kezdeni valamit. Hacsak nem valaki hirtelen jön valami jobb ötlettel.
Ó dehogy nincs más út. Pl. rengeteg kis fab van, akik pl. a saját cégüknek gyártanak cél-asic-et. Valahol ez éri meg. Egy gpu soha nem lesz 0.5€, egy cél asic viszont röhögve (autóipar pl.).
SIMD egyébként baromi jó példa az igény hiányára. Ott a lehetőség (MMX-ek, stb.), elterjedtek és mégsem áll neki szinte senki. Jó esetben legalább a fordítónak engedélyezik a használatukat. Miért? Mert nincs rá igény és nem éri meg ráfordításban. Miért érne meg ez gpgpu-nál? Egyszerű pénzügyi kérdés. Egy jó swfejlesztő óránként 50-100€-ba fáj a cégnek, egy r&d-n dolgozó meg 100-500€-ba. Óránként. Ilyen árak mellett nagyon ritkán éri meg belemászni optimalizációba, ahelyett, hogy leakasztasz egy kész cuda-t vagy simán nem törődsz vele.
De ha már törődni kell, akkor meg minek gpgpu? Van ezer féle különböző cpu/gpu kombó, az eredmény kiszámíthatatlan. Akkor sokkal inkább már fpga irány. Lesz egy fix méretű, szabadon programozható fpga tömböd procinként és máris ismeret sebességed van legalább generáción belül és valóban gyors lehetsz. Fpga-ra pedig idővel amúgy is a compiler fog fordítani. Lesz egy #pragma-d és az adott lib-et, kódrészletet majd szépen a fordító megoldja opcionális kódpath-ként ami futhat fpga-n ha van (és valóban gyors lesz) vagy marad cpu-n/gpu-n ha nincs fpga. Itt már valóban lenne gyorsulás. Nyilván tématerülettől függ, de a sajátomon azt látom, hogy egy nagyságrendet lehet nyerni cpu többszálúsításával, kb. ugyanennyit gpu-val (ha mindkettő van, akkor is csak egy nagyságrendnél vagyunk!), még fpga-nál 2-3 nagyságrendet. A vicc egyébként hogy nem csak én vagyok ilyen "okos", nem véletlenül vette meg az Intel az egyik nagy fpga gyártót és éppen vásárolják fel a másikat is.
Egyébként fpga-cpu merge volt bőven korábban is, de az árak miatt buktak idővel (lsi, stb.). Egy xeon proci árázásába viszont bele fog ez már férni bőven. Idővel meg visszajtunk a transmeta-hoz, újrakonfigurálható perifériákkal. Ha kell jobb képfeldolgozás selfi-khez, kapsz rá egy fpga szeletet és kész. Ha kell jobb hang, akkor kapsz arra egyet, stb.
Szerk: vagyis az intel megcsinál(hat)ja azt az alterával, amit az amd akart az ati-val. Csak hát egy fpga ezerszer szélesebb körben használható, mint egy erősen kötött gpu. Cserébe nehezebb is a feladat, de intelnél van pénz. Ráadásul az fpga-k ára ma a gyárás miatt magas. Házon belüli fabok esetén a sok millió akár milliárd dolláros költségek könnyebben faraghatóak lesznek, főleg ha immár lesz gyártási darabszám is.
[ Szerkesztve ]
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
Abu85
HÁZIGAZDA
A heterogén irány sosem azt jelentette, hogy rakjanak a CPU mellé IGP-t, hanem azt, hogy a CPU-t egészítsék ki gyorsítók. Az, hogy ez GPGPU, DSP, ISP, FPGA, esetleg ASIC gyakorlatilag mindegy, a hangsúly a célirányos gyorsításon van. Akár mindet be lehet építeni, csak meg kell oldani, hogy mindegyik ugyanabba a virtuális címtérbe dolgozhasson. Az, hogy a GPGPU-val kezdődött meg az integráció elsősorban annak köszönhető, hogy a programozó számára a GPGPU-ba való belépő a legolcsóbb és a legkönnyebb. A heterogén irány azonban nem zár ki más gyorsítót, akár FPGA is jöhet, bár arányaiban ez a legdrágább és a legnehezebb a programozó nézőpontjából, de elméletben semmi akadálya.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Mindig szükség van a nagyobb teljesítményre. Desktopon, átlagfelhasználásra valóban alig kell már valami, de ezt lehet fordítva is magyarázni, azz azért vagy el a 2500K-val, mert újabban nem sokkal gyorsabbak a CPU-k. Nincs már az P4 vs Core 2 vs Core i7 ugrás, vagy mint AMD-nél a K7 és K8.
A GPU-k ma már nem célhardverek, pont ez a lényeg. Csak másképp kell programozni, erre jönnek ezek a "Java" jellegű IL cumók, melyekre a GPU-k terén jóval nagyobb szükség van (sokféle architektúra még családon belül is), mint CPU-nál, így lehet belőle profit, legalább programozni könnyebb lesz, a kompatibilitás garantált.
A 20nm-t azért hoztam példának, mert nem sikerült jól. Intelt azt ne vegyük ide szerintem, mert ő ebben nagyon elöl van, a többség szempontjából nem reprezentatív. Ezen a szinten 14 nm még csak most fog jönni, szóval nem vagyunk 20nm alatt.
FPGA az egy baromi jó iránynak tűnik, de ha még be is jön az intelnek, ezt azért fel kell futtatni, így ez most igen homályos prófécia, hogy mi lesz belőle.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
Alchemist
addikt
válasz
#32839680
#30
üzenetére
"ma sem áll már neki senki assemblyben kódolni a CPU-kat, pedig a legoptimálisabb az lenne"
Annak idején jópár programot írtam teljesen assembly-ben.
Viszont ma nemcsak a nehézkessége miatt nem éri meg, hanem pl. az Intel fordítói a megcélzott architektúrára (pipeline, cache, SIMD, multi-cpu figyelembe vételével) tudnak finomhangolva optimalizálni, egyszerre akár többre is.
Ha van rá igény, ez az, ami megéri.
Akár heterogén rendszer esetében is megérné...Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.
-
Fiery
veterán
válasz
#06658560
#32
üzenetére
Pont arra az 1%-ra kellene, hogy begyorsuljon a gep. Probalj meg pl. webezni egy lassu telefonon, aztan nyergelj at par perc mulva egy gyors telefonra. Mindketton az ido nagy reszet az viszi el, amig olvasod a tartalmat, megis sokkal gyorsabbnak erzodik az a keszulek, ami a weboldalt 1 masodperc alatt tolti be es rendereli le, mint amelyik 3 masodperc alatt. Nem veletlen az sem, hogy sokszor furgebbnek erzodik egy kevesebb magos de magasabb orajelu mobil SoC alapu keszulek, mint egy big.LITTLE SoC-os... Es az sem veletlen, hogy mar egy jo ideje veri az asztalt nehany iparagi szakerto, hogy legyen vegre kulonvalasztva a burst es a sustained teljesitmeny, marmint a mobil benchmarkokban.
[ Szerkesztve ]
-
Reggie0
félisten
válasz
#32839680
#30
üzenetére
Az azert nem igaz, hogy nem kellett kutyanak se, csak baromi kicsi a piaca. Ennek legfobb oka, hogy az fpga nem valo egy atlag szoftverfejleszotenk. Viszont az ARM+FPGA mindig is felmegoldas volt, mert ott a proci a gyengebbik elem, igy a processzorigenyesebb alkalmazasokat nem lehet megvalositani. Nem veletlen arultak tobbprocesszoros alaplapokhoz olyan fpga modult, ami a proci helyere berakhato. Ezeknel viszont a Quick-Path Interconnect vagy a HyperLink volt a szuk keresztmetszet.
[ Szerkesztve ]
-
Reggie0
félisten
válasz
#32839680
#36
üzenetére
Ezert jo, ha egybe van tokozva a procival, mert ott mar a memoriaval megegyezo vagy akar annal gyorsabban is lehet etetni, kerdes az, hogy az intel mennyire szorosan akarja integralni.
Azert a BRAM nem annyira viszi a helyet, mert dedikalt egyseg, nem a LUT-bol van kialakitva a distributeddel szemben. Persze a routingot megdobja. Mondjuk a series 7 xilinxekben mar igen jo sebessege van a bramnak is. Viszont pont ezert nem sajnalja az ember elkolteni pufferelesre, mert altalaban logikat nem eri meg bele tenni.
Viszont ezeket az eletben nem lehet jol programozni OpenCL-ben. Vagy legfeljebb annyi pragmaval, hogy akkor mar lehetne verilogot is irni. Esetleg SystemC-t, bar mar az sem az igazi HDL szempontbol.
[ Szerkesztve ]
-
MaUser
addikt
De azt mond már el, hogy miért kell egyáltalán GPU-val szenvedni átlag usernél, ami nem GPU specifikus egyébként? Mi az a terület, amihez kell a gpgpu átlag felhasználónál? Tovább megyek, mihez kell irodai szinten? Még tovább megyek, mihez kell akár fejlesztőmérnökként?
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
Abu85
HÁZIGAZDA
Irodai szempontból ott a LibreOffice. Pont a napokban néztük meg a legfrissebb verziót, mert ez lesz az egyik compute teszt az új GPU-s tesztcsomagban, és elképesztő, hogy mennyivel gyorsabb a Calc GPU-s gyorsítással. Gyakorlatilag CPU-val számolva percekig tart a tesztmakróink futtatása, de GPU-val ugyanaz másodpercek alatt megvan.
Bizonyos esetekben a megosztott memória is előnyös. Ilyen például a talajvíz tesztmakró. Itt sima CPU-val 7-8 perc a számítás, míg GPU-val ez levihető 5-6 percre, de például a Kaveri CPU+IGP-vel 15-20 másodperc alatt megvan ugyanaz az eredmény.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
MaUser
addikt
De ehhez tovabbra is boven eleg a cuda.
morgyi Macro helyett ma regen vannak .net beepulok amikkel joval gyorsabb vagy ha ma excel.
[ Szerkesztve ]
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
LordX
veterán
Egy példát mondj, amiről vita van. Max valami iszonyatosan speciális eset, amivel csak minden február 30.-án találkozik a programozó.
OpenCL-ben programoztam, ami majdnem az összes létező CPU-n és GPU-n futott: AMD GCN, nVidia Fermi+Maxwell, Intel Haswell+Skylake, Qualcomm Adreno 330, Mali T624, Mali T760 GPU-kon és x86 (Intel és AMD runtime-al), ARM CPU-kon teszteltem. Kizárólag PowerVR és FPGA-k alatt nem. Soha semmi olyan problémába nem futottam bele, hogy valamit egyik gyártó így értelmezett, a másik úgy. Ami szabványos kód, amit a Khronos SPIR fordító megevett, az mindenhol lefordult, ha nem számítom azt, ami nyilvánvalóan bug.
És mivel a legtöbb OpenCL implementáció frontendje CLang alapú, még a bugok is többnyire ugyanazok. Nem véletlenül az LLVM-IL volt az alapja a SPIR 1.2-nek.
A SPIR-nek meg marhára nem az volt a célja eredetileg, hogy a nem egyértelmű dolgokat megoldja, arra elég lett volna az, hogy módosítják a szabványt (ahogy egyébként ezt csinálják is, az OpenCL 1.2-nek van vagy 10 revíziója, némelyik az után jött, hogy már megvolt a nem-draft 2.0), hanem hogy ne kelljen forráskódot szállítani, ha nem akarsz binárist (és nem akarsz, mert az még gyártón belül se kompatibilis). Teljesen életszerűtlen és logikátlan az, amit mondasz, hogy van egy szabvány, ami itt meg ott nem egyértelmű, és a szabvány testülete ezeket nem javítja ki annak ellenére, hogy gőzerővel dolgoznak folyamatosan új verziókon, hanem behoznak egy teljesen új szabványt, hogy majd az megoldja.
[ Szerkesztve ]
-
válasz
#32839680
#41
üzenetére
A PgStrom egy elég vicc dolog. Hatalmas adatmennyiségből való lekérésre jó csak, amikor nem használhatsz indexet, mert nem éri meg. Ez elég ritka, pl a PH! adatbázisa semmit sem profitálna belőle. De amúgy ebben az irányban anno kicsit kutatgattam, s vicces, hogy itt nagyon jól jönne egy APU, mivel a PgStrom esetén az idő felét az veszi el, hogy átmásolja az adatokat a CPU memóriájából a GPU-jéba, PCIE-n.
Az lenne az igazi, ha egy index scan GPU-val működhetne. Nem ismerem annyira az adatbázisok B-tree indexét, de biztos meg lehet oldani több szálon a szkennelést / buildelést, így GPU-ra ültetve skálázódhatna. Ez real life hatalmas előrelépés lenne, mivel ezek az operációk viszik el az adatbázis CPU idejének jó részét.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
ph Egyre több IL érkezik a piacra, beleértve két szabványosat is, de a következő években még több jöhet.
- ASRock Radeon RX 6800 XT Phantom Gaming
- ZOTAC GeForce GTX 1080 AMP Edition 8GB GDDR5X 256bit
- 4070 Ti Aorus Master //KERESEM!!//
- Sziasztok! Eladó az alábbi videokártya, nagyobbra váltás miatt: - Zotac márka - nVidia GeForce RTX
- eMag GARANCIA! ZOTAC Trinity RTX 3080 10GB OC GDDR6X Videokártya! BeszámítOK