- Milyen videókártyát?
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- TCL LCD és LED TV-k
- Hobby elektronika
- Blu-ray lejátszók
- Soundbar, soundplate, hangprojektor
- Fejhallgató erősítő és DAC topik
- Milyen processzort vegyek?
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Intel Arc Battlemage B570/B580
Új hozzászólás Aktív témák
-
#2
huskydog17
addikt
huskydog17
addikt
Akkor ha jól tudom akkor AMD fronton az Evergreen vonaltól felfelé lesz támogatás. Javítson ki valaki ha tévednék!
Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ
-
#3
Abu85
HÁZIGAZDA
huskydog17
#2
Abu85
HÁZIGAZDA
válasz
huskydog17
#2
üzenetére
A speckók szerint igen. Minden hardver, ami tud OpenCL 1.1-et, annak tudnia kell 1.2-őt is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
szabi80sz
tag
1. Az OpenCl inicializálása (csak az inicializálása!) olyan lassú, hogy ez alatt a Cudában megírt program, ami egy Ion-on fut (integrált videokártya, ha jól emlékszem: 16 számoló egységgel), 20* végez a két kancsós probléma kiszámításával (egy 5 és egy 3 literes kancsóba lehet vizet tölteni, 4 liternek kell lennie az 5 literesben, de nem lehet mérni a víz mennyiségét). Az ellenfél egy firepro v4800 volt, 400 stream processzorral.A cuda inicializálása: 0 ms.
2. Futáskor fordul le a kernel, ami nagyon belassít. (Cuda esetében fordításkor történik egy előfordítás, ami miatt ugyan lassabb a fordítás, de a futás során nem lassít annyit).
3. Szekvenciálisnak kell lennie a megírt program felépítésének. Ez alatt azt értem, hogy mindent kötött sorrendben lehet csak megírni. Pl. Cudánál videomemóriát inicializálás alatt, egy másik szálban is le lehet foglalni, függetlenül a kerneltől vagy az inicializálástól.
4+. Kernel: vagy egy fájlból, vagy egy sztringből kerül betöltésre. A fájl használata nem a leggyorsabb, a sztring nagyon kényelmetlen. Arról már nem is írok, hogy a saját típus használata esetén, azt kétszer kell definiálni: egyszer a programomnak, egyszer a kernelnek. (Hopp! Mégis írtam róla.
) A mutató aritmetikát nem támogatja az OpenCl (azért ez nem akkora probléma, mert meg lehet oldani másképp). A double típus használata a programban veszélyes, mert csak a felső kategóriás videokártyák támogatják hardveresen (egy professzionális videokártya, nem biztos, hogy felső kategóriás: pl a v4800-as nem támogatja a double típust). Cuda esetében nem probléma, ha a hardver nem támogatja (pontosan nem tudom, hogy vagy simán átkonvertálja float típussá, vagy megpróbál kicsit trükközni, ami miatt nagyon belassul a program nem felső kategóriás videokártyákon, de legalább lefut és eredményt ad).
5. OpenCl-t ma elsősorban csak az Amd videokártyák támogatása miatt használnak (később nyilván az Intelesek támogatása is szempont lehet). Amd: videomemória korlátolt feldolgozást tesz lehetővé a következő 1 évben mindenképpen, azzal, hogy elhatárolódik a PCI-E 3-tól. Nvidia: virtuális memória bevezetését tervezi (ehhez kell a PCI-E 3). Ha szükséges a sok memória, akkor Nvidia, ha Nvidia, akkor Cuda... (Ha kell még egyéb hiányosság: az Amd, stb által nem támogatott rekurziónál -amit az nvidia régóta támogat- érdemes szétnézni.
)
6. Milyen szép lenne az élet, ha lefordítom az OpenCl programot és az fut Nvidia és Amd kártyákon is. Na az élet nem ilyen szép... Ha Amd sdk-val fordítok, akkor nem fut az Ion-on (de az Ion-t látja), ha Nvidia sdk-val fordítok, akkor az még csak nem is látja az Firepro-t. De azért ha fordítom egyikkel is, másikkal is, külön-külön exe fájlt készítve, akkor az egyik futni fog Amd alatt, és a másik Nvidia alatt.
7. De kell-e nekem az, hogy az Amd-s kártyán fusson, ha a programom sok memóriát használhat, meg jól jönne a rekurzió is, +a double típus használata. Tudom: most jön, hogy ilyen programok úgy sem lesznek egy darabig: igen nem lesznek, de csak ezért nem, mert az Amd elzárkózik. (Vagy csak nem mennek náluk olyan jól a fejlesztések?) Vagy mégis csak lesznek, de Nvidián fog mind futni Cudával?
8. Remélem: elég informatív voltam. Ha valamiben tévednék, akkor megfelelő alátámasztással várom az indoklást. Örülnék neki, ha valaki tudna trükköket, amikkel ezeket a problémákat, hiányosságokat gyorsan és egyszerűen ki lehetne küszöbölni OpenCl alatt. -
Abu85
HÁZIGAZDA
Nem kell a virtuális memóriához PCI Express 3.0. Jó az 1.0 is akár, csak nem gyors. A Keplernek I/O virtualizáció kell, mert az NV nem rendelkezik x86 licencel.
Az AMD GCN is támogatja a virtuális memóriát:
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
Egyelőre csak néhány ponthoz szólnék hozzá.
1.: na ja, a 0 ms-nél minden lassabb, de egy kicsit kevés az adat. Hány ms a lényegi kód és mennyi az OpenCL inicializálás? De végülis mindegy is, nem olyan feladatokat szoktak OpenCL-be ültetni, amiknél az utóbbi több, mint az előbbi...
És miért pont Ion? Szerintem egy CPU is gyorsabb annál, vagy nem?
2.: Érdekes, találkoztam pár OpenCL alapú programmal (mármint nem pár soros), amik 1 mp-en belül indulnak. Hacsak nem néhány mp az egész művelet, ez nem gond...
4., DP: ha fut is valahogy, nem megoldás...
5.: Meg azért, mert az OpenCL platformfüggetlen! (A PCIe-s dologra Abu már reagált.)
6.: Ez mondjuk nem csoda...[ Szerkesztve ]
-
szabi80sz
tag
1. Maga a számítási művelet 5ms (akkora tömbön, ami belefér az 1Gb videomemóriába, a műveletek pedig: szögfüggvények és egyéb lebegőpontos számítások: osztás, szorzás), míg a teljes lefutás 4000 ms felett van. "De végülis mindegy is, nem olyan feladatokat szoktak OpenCL-be ültetni, amiknél az utóbbi több, mint az előbbi..." bocs: de ez butaság. (nem indoklom: foglalkozz a témával írj kódot, aztán majd rájössz...)
Azért pont Ion, mert a FirePro az OpenCl miatt lassú volt és gondoltam megnézem mit tud a Cuda, mivel hihetetlenül gyorsabb volt (azon a gyenge integrált vackon), mint a FirePro+OpenCl: a végén Cudára írtam a kódot (nem bántam meg, mert egy normális karival még ennél is nagyobb sebesség érhető el a programok alatt).
2. A program indult 1mp-n belül és nem az init része. (Ha csak az sdk-kat töltöd le és kipróbálod a példaprogramokat, már akkor is érezheted a lomhaságot.)
4. De megoldás, mert nem valahogy fut, hanem értékelhető eredményt ad, márpedig a programokat azért írjuk/használjuk, mert az eredményekre vagyunk kíváncsiak.
5. A Cuda is platformfüggetlen.
+1: Azért futnak jól, mert sok munkát fektetnek bele, hogy fusson mind a két rendszeren. Amikor az erre fordított idő majdnem akkora, mint a feladat lekódolása, akkor az elég problémás (szerintem) és nem az OpenCl lesz kártyafüggetlen, hanem a szoftver, mert extra időráfordítást eredményez a különböző platformokon történő futtatás lehetőségének beépítése.
A témától kicsit elkanyarodtunk, hiszen az eredeti hozzászólásom:
"Sajnos a Cuda-hoz képest továbbra is le van maradva. Bár ezen a vackon szerintem csak egy teljesen, az alapoktól történő újraírás segíthet..." Ezt továbbra is tartom, mert lehet toldozgatni, foltozgatni a kódokat, hogy valamennyire kiküszöböljük a hátrányokat, de attól még a tény tény marad: nagyon le van maradva az OpenCl és így ahogy van elég gyengus.X+: A PCI-E 3 rengeteget gyorsítana a rendszeren (még akkor is, ha nem függ a virtuális memória tőle), márpedig az Amd nem nagyon foglalkozik a PCI-E 3-mal..
[ Szerkesztve ]
-
-
dezz
nagyúr
válasz
szabi80sz
#12
üzenetére
1.a.: Ha 5ms az egész, azt eleve nem érdemes GPU-ra ültetni... Hacsak nem sokszor fog lefutni, de akkor meg nem kell minden alkalommal fordítás, ami itt a lassú. Az egyes műveletek előtti inicializálás ehhez képest kvázi elhanyagolható. Nem tudom, mi ebben a butaság... Ha mégis úgy gondolod, írd le légyszi, miért.
1.b.: Nem lehet, hogy valamit rosszul csináltál, hogy lassabb FirePron, mint Ionon?
2.: Nem, maga az OpenCL-es számítások. Itt vannak pl. lenox OpenCL-es programjai. 1 mp-en belül megy is a ray-trace, stb. Ja, és teljesen jól fut mindkét platformon. Néztem az SDK programocskáit is, illetve az Nvidia programjait is, hasonló a helyzet.
4. Ha kimondottan DP-re van szükség, ami speciális esetekben fordul elő (a hétköznapokban csak pl. mandelbrotnál jött volna jól nagyobb zoomokhoz), amúgy is érdemes megfelelő kártyát használni. Ha máshonnan ollózol át kódot, amiben van double, de nincs rá igazán szükség, le lehet cserélni floatra.
5. Jó, akkor mondjuk úgy, hogy gyártó-függő. Csak Nvidia hw-en működik. (A platform-függetlenbe általában beleértik a gyártó- és hw-függetlenséget is.)
+1: Ez nem feltétlen igaz. Pl. lenox Nvidián írt kódjai is teljesen jól futnak Radeonon is, különösebb időráfordítás nélkül.
Ezt írta erről: "Ionon es firepro-n nem probaltam, nekem eddig ugy altalaban futottak mindenhol, beleertve intel procit es fusion aput az nv (geforce, quadro, tesla) es amd (radeon) videokartyak mellett. Probaltam az amd sdk-val is es az nv sdk-val is, eddig nem jott ki kulonbseg. Illetve olyan kulonbseg azert volt, hogy a work itemeket az nv driver mindig szepen kiosztotta, az amd meg neha elbaszta, ugyhogy azt explicite be kellett allitani, hogy multiprocesszoronkent mennyi thread legyen, es ugy mar ment mindketton."
Ja, és 7.: a rekurzió amúgy is lassú, bár nyilván kényelmes."X+: A PCI-E 3 rengeteget gyorsítana a rendszeren (még akkor is, ha nem függ a virtuális memória tőle)"
Gyorsít, de közel sem annyit (legalábbis latencyben), mint amikor egymás mellett van a CPU és a GPU, tehát a PCIe teljesen kimarad és csak egy memcopy az egész. Nem beszélve arról, amikor erre sem lesz szükség.
"márpedig az Amd nem nagyon foglalkozik a PCI-E 3-mal.."
Nem-e? A GCN támogatja. A jövőre megjelenő Sepang és Terramar CPU-k is támogatják. Igaz, ezek Opteronok, de aki ugye "komolyan gondolja", annak belefér. Arról az AMD egyelőre nem beszél, hogy a Trinity támogatja-e, de ha a Sepang és a Terramar igen, akkor ez miért ne tenné? Az AM3+ marad 2.0 (2.1?). (Az eredeti tervek szerint ennek is átvette volna a helyét az FM2. Bár nincs kizárva, hogy 2012H2-ben erre is kijön egy 4+ modulos Piledriver, amikor az AM3+ már a végét járja).
[ Szerkesztve ]
-
szabi80sz
tag
Egy értékes észrevételed volt: ez pedig a kompatibilitásra vonatkozott, a többi (saját) állításoddal nem érdemes foglalkoznom: Albert Einstein sem a kukásbácsival vitatkozott a relativitás elméletről, így én sem veled fogok vitatkozni a GPU programozásról.
(Aki hozzáértő és találkozott a problémával, az kb. érti, hogy miről írtam, a többiek pedig vagy elhiszik, vagy nem: ez az ő dolguk...) -
szabi80sz
tag
Sajnos hiába nem kell hozzá PCI-E 3: A viruális memória miatt meg fog nőni bizonyos alkalmazások alatt az adatforgalom a PCI-E sinen, így néha még a PCI-E 3 lehet a rendszer szűk keresztmetszete (a nagyobb sebesség ellenére, főleg azokban a kódokban, amiket én írok, így számomra a PCI-E 3.0 elég nagy jelentőséggel bír majd a virtuális mem. miatt (is) ).
-
Abu85
HÁZIGAZDA
válasz
szabi80sz
#16
üzenetére
Az a baj, hogy egy külső buszra alapozni nagyon nem jó, mert a külső fizikai összeköttetés mindig lassú. Nem is a throughputban kapod a nagy büntit, hanem a késleltetésben. A fejlesztőknek figyelni kell arra, hogy a PCI Expressnek komoly határai vannak. Persze a GPU általi x86 virtuális memória támogatásának még ennél is nagyobb határa, hogy egyelőre nem támogatja egyetlen OS sem. A Win 8 lesz valamennyire erre felkészítve. 2012-ben nem sok esélyt látok, hogy ebből a konzumer szint profitáljon. 2013-ban is csak elvétve. 2014-ben már beindulhat a nagyüzem, és a PCI Express sem jelent hátrányt, mert az NV és az AMD is komoly integráláson dolgozik. Ezzel a CPU és a GPU rész lapkán belül kommunikál, ami minden külső linknél jelentősen gyorsabb. Ha minden jól megy, akkor 2015-re a Skylake-kel csatlakozik a bulihoz az Intel is, és az ARM is hasonló elképzeléssel fejleszt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
szabi80sz
tag
Hát igen: senki sem mondta, hogy egyszerű lesz (főleg az elején), de nyilván ha megjelenik, akkor valamilyen szintű támogatást fognak barkácsolni a videokártya gyártók. Kérdés, hogy ez nekem mennyire lesz megfelelő. Jelenleg is tudnék olyat csinálni, hogy a device-on lévő adatokat particionálom és ami éppen nem kell azt kirakom a hostra (ott meg az oprendszer ott tárolja, ahol akarja), majd szépen be/visszatöltögetem a szükséges adatokat és kimentegetem az éppen nem használtakat (ekkor a PCI-E elég intenzíven lesz használva, de ez sajnos másképp nem megy). "egy külső buszra alapozni nagyon nem jó, mert a külső fizikai összeköttetés mindig lassú." : néha ezzel kell élni, de intenzívebb használat esetén a késleltetések ellenére még mindig jobb a gyorsabb (hogy a gyakorlatban ez mennyit jelent: majd elválik).
Kérdések lehetnek: az én megoldásom lenne-e számomra a kedvezőbb, vagy a virtuális memória (azaz optimálisabb eredményt ad-e a használata, vagy szidni fogom azt is és visszasírom majd a virt.mem. előtti időket. ), a virtuális memória pontosan milyen módon fog működni, kell-e nekem valami többletet programozni (főleg az elején). Idővel ezek majd kiderülnek.
) A mutató aritmetikát nem támogatja az OpenCl (azért ez nem akkora probléma, mert meg lehet oldani másképp). A double típus használata a programban veszélyes, mert csak a felső kategóriás videokártyák támogatják hardveresen (egy professzionális videokártya, nem biztos, hogy felső kategóriás: pl a v4800-as nem támogatja a double típust). Cuda esetében nem probléma, ha a hardver nem támogatja (pontosan nem tudom, hogy vagy simán átkonvertálja float típussá, vagy megpróbál kicsit trükközni, ami miatt nagyon belassul a program nem felső kategóriás videokártyákon, de legalább lefut és eredményt ad).
)
Új hozzászólás Aktív témák
Hirdetés
ph A Khronos Group előállt a rendszer 1.2-es verziójával.
- BestBuy topik
- Direct One (műholdas és online TV)
- Energiaital topic
- PlayStation 5
- Milyen videókártyát?
- Vodafone mobilszolgáltatások
- Bugok, problémák a PROHARDVER lapcsaládon
- A fociról könnyedén, egy baráti társaságban
- Politika
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- További aktív témák...
- Asus rog strix 1080 ti oc
- BESZÁMÍTÁS! ASUS DUAL OC RX 6750 XT 12GB videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! Gigabyte Gaming OC RX 6750 XT 12GB videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! nVidia Founders RTX 3070 Ti 8GB videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! Sapphire Nitro+ RX 6900 XT 16GB videokártya garanciával hibátlan működéssel
Állásajánlatok
Cég: Axon Labs Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest