- Minimalista külsejű, combosnak tűnő léghűtést tol ki a gyárkapun a Cooler Master
- Bizonyos ASUS alaplapok megrongálhatják a videokártyánkat
- A következő években válaszolna az Intel az AMD-féle 3D V-Cache-re
- Az Final Fantasy-re fókuszál a friss Arc meghajtó
- Méri még a legforróbb pontot az új GeForce generáció
- Milyen TV-t vegyek?
- OLED TV topic
- Minimalista külsejű, combosnak tűnő léghűtést tol ki a gyárkapun a Cooler Master
- Gaming notebook topik
- Apple notebookok
- Milyen széket vegyek?
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Gyorsan Snapdragonnal: Acer Swift 14 AI tapasztalatok
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kormányok / autós szimulátorok topikja
Új hozzászólás Aktív témák
-
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. -
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) ).
-
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
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 ]
-
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.
), 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.
Új hozzászólás Aktív témák
ph A Khronos Group előállt a rendszer 1.2-es verziójával.
Állásajánlatok
Cég: Marketing Budget
Város: Budapest