- Xiaomi AX3600 WiFi 6 AIoT Router
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- Az iPadOS-re írt appokra is díjat vet ki az Apple
- Letartóztatták a bitcoin-Jézust
- Hálózatokról alaposan
- ASUS routerek
- Asustor NAS
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- A pápa egyre jobban tart a romlott AI veszélyeitől
- Milyen program, ami...?
Új hozzászólás Aktív témák
-
Fiery
veterán
En abban ketelkedek, hogy ez a mostani modell mas esetekben is mukodokepes lehet. A dolgok normalis menete ugy nezne ki (egy idealis vilagban), hogy maga a szoftvergyarto irja meg a GPGPU kodot, altalanosan (ha mar van OpenCL, ami mindharom gyarto GPU-in hasznalhato), leteszteli, es szepen kiadja, hogy ez jo CPU-ra, es jo mindharom GPU-gyarto termekeire. Ezzel is biztositva azt, hogy nem reszrehajlo a ceg, nem egyik iranyba billenti a merleget.
A konkret esetben pedig -- megint csak egy idealis vilagban -- ugy nezne ki a dolog, hogy ha mar az AMD sutba dobta a sajat, properietary GPGPU interfeszet (Stream), es atallt a nyilt OpenCL-re, azt hangoztatva, hogy az mennyivel frankobb, es hogy milyen nyilt ceg ok maguk is, akkor egy ilyen esetben irjak meg az OpenCL kernelt, adjak oda a szoftvergyartonak, hogy "innentol a Te feladatod tovabbvinni", es majd a szoftvergyarto eldonti, hogy mit csinal vele. Ha lusta, nem ert hozza, nem akar molyolni vele, akkor kiadja ugy ahogy van, akkor is, ha nem fut vagy nem jol fut mas (Intel, nVIDIA) GPU-kon. Ha kicsit fogekony a szoftverfejleszto az OpenCL-re, akkor pedig kicsit megpatkolja az AMD GPU-khoz keszult OpenCL kernelt, hogy fusson Intelen es nVIDIA-n is szepen, es kiadja a cuccot. Nem kell kiadnia a kernel forrast, erre nincs szukseg, de ha nem is kapja azt meg az AMD-tol, akkor esely sincs arra, hogy mas GPU-gyarto termekein is fusson ugyanaz (vagy nemileg modositott formaban ugyanaz) a GPGPU kod.
Ebben a konkret esetben azonban nyilvanvaloan egyfajta egyezseg szuletett a szoftvergyarto es az egyik GPU-gyarto kozott: a GPU-gyarto megirja, zart modon a sajat termekeire a dekodert, csereben viszont mas GPU-gyartok termekeire nem adja ki -- legalabbis kezdetben -- a Strongene a GPGPU gyorsitott dekodert. En szemely szerint egyebkent ketlem, hogy a masik 2 gyarto ilyen szinten foglalkozna a kerdessel, a Strongene-nek pedig -- ugy tunik -- nincs kompetenciaja a GPGPU fejleszteshez, ugyhogy nem szamitanek arra, hogy mas GPU-kra is elkeszuljon a dekoder.
Az AMD reszerol azert is furcsa ez a fajta hozzaallas, mert me'g ha modositja is valaki az eredeti OpenCL kernelt, hogy fusson Intel es nVIDIA GPU-kon (mar ha egyaltalan modositani kellene oket, nem tudhatjuk, hiszen a kernelek nem elerhetoek), akkor is lenyegeben a teljes piaci szegmensben, APU-tol a high-end dGPU-kig az AMD-nek all a zaszlo. GPGPU-ban a GCN-ek jelen allas szerint verhetetlenek, tehat semmi szukseg nem lenne az ilyen exkluziv megoldasokra. Sot, me'g jot is tenne adott esetben az AMD-nek, ha le lehetne benchmarkolni, hogy pl. egy mobil Kaverin mennyivel durvabb teljesitmenyre kepes a dekoder, mint mondjuk egy Haswellen vagy akár Broadwellen.
"Benne van a cikkben, hogy később Intelre és Nvidiára is valószínűleg el fog készülni."
Akarcsak a WinZip eseteben. Gyanusan hasonlit a 2 eset egymasra... SZVSZ ezt a forgatokonyvet me'g latni fogjuk nehany esetben, plane mivel -- ha jol latom -- a HEVC dekoderben alkalmazott AMD GPGPU megoldas egy olyan motort hasznal, amit mas szoftverekben, mas algoritmusoknal is be lehet vetni. Vannak ehhez kapcsolodoan konkret informacioim is, de nem publikusak, sz'al maradjunk annyiban, hogy majd lehet figyelni a hireket, Abu be fog szamolni minden, ehhez az esethez kisertetiesen hasonlito fejlemenyrol, mas szoftverekkel kapcsolatosan.
---
Me'g annyit, hogy ha a HEVC dekoder CPU verzioja mondjuk AVX gyorsitast használna, es a Strongene olyan kodot adna ki, ami csak Intel processzorokon hasznalja ki az AVX-et, Te es me'g sokan masok is fel lennenek haborodva. Ez ugyanaz a tortenet lenne: egy szabvanyos, kvazi gyarto fuggetlen optimalizacios eljaras kihasznalasra az egyik gyarto termekein, mig ugyanannak a kodnak a szandekos nem hasznalata a tobbi gyarto termekein, ahol egyebkent ugyanugy meg lenne a lehetoseg az optimalizacio hasznalatara.
[ Szerkesztve ]
-
Fiery
veterán
"Értsd meg, hogy a Strongene HEVC dekódere egy zárt forrású, kommersz program. Attól, hogy OpenCL maga nyílt szabvány, még nincs előírva, hogy minden OpenCL kódnak nyílt forrásúnak kell lennie."
En megertem, termeszetesen, Te viszont azt nem erted, hogy ha az AMD nem binarisokat szallitott volna a Strongene reszere, es a Strongene fejlesztoi kozott lenne valaki, aki GPGPU/OpenCL temaban kicsit is jartas, akkor nem kellett volna kizarolag AMD-re limitalni az OpenCL tamogatast, hanem minden bizonnyal siman meg lehetett volna oldani mindharom GPU-gyarto termekehez is. Ez a baj a binaris megoldassal. Attol, hogy az AMD es a Strongene kozott nyilt forras lett volna az OpenCL kernel kapcsan, attol me'g nem lett volna kotelezo a Strongene-nek nyilvanossagra hozni a kernel forrast. Pl. a Sandra is kernel forrasbol dolgozik (pont azert, hogy minden GPU-gyarto termeken fusson a GPGPU kod), megsem latod magat a kernel forrast a szoftverben sehol, kulonosen nem a dokumentacioban.
"És légy szíves, ne állítsd be úgy, mintha az OpenCL valami olyan mágia lenne, amit csak az AMD szakemberei művelnek, más fejlesztők meg hozzá sem szagolnak. Itt a Ph!-n is többen vannak, akik ebben (is) programoznak."
Kar, hogy a gyakorlat mast mutat. Nyilvan van jo nehany fejleszto, aki OpenCL-ben es CUDA-ban is jol dolgozik, csak epp ha a "big picture"-t nezed, azaz a vilag osszes x86 PC-re dolgozo fejlesztojet, akkor azok kozt elenyeszo szamban vannak azok, akik kepesek lennenek egy x264 vagy HEVC dekodert, vagy epp egy WinZip-et portolni GPGPU-ra. Mas kerdes irni egy hello world appot OpenCL-ben (ertsd: egyszeru matrix szorzas vagy FFT), egy kicsivel nagyobb lepcso mondjuk fraktalokat szamolni OpenCL-ben, megint kicsivel nagyobb ugras mondjuk ray-trace engine-t irni, es ahogy megyunk egyre feljebb a komplexitas lepcsojen, ugy kopnak ki a magukat jo OpenCL fejlesztonek mondo programozok. Pedig mar indulasnak sincsenek sokan, az osszes lepcsot egybeveve
Vagy ha szerinted olyan baromi sok gyakorlott, tapasztalt, penge OpenCL/CUDA fejleszto van a vilagon, akkor miert nem terjed jobban/gyorsabban a GPGPU? Miert nem mindenki OpenCL/CUDA-val gyorsitott web bongeszot hasznal, miert nem a GPU szamit mindent, amit csak lehet? Ja, tudom, a HSA hianya, persze... A vegso, mindent megmagyarazo erv
"A WinZIP programozói amatőrök, ez látszik a WinZIP-en is (kevésbé hatékony és jóval lassabb, mint a versenytársai és még bumfordibb is az egész program). Nem csoda, hogy az AMD csinálta meg helyettük az OpenCL kódot. Ebből nem lehet túl messzemenő következtetéseket levonni."
En vonnék le mashonnan is kovetkeztetest, csak mit csinaljak, ha se a WinRAR, se a 7zip, se egyik masik fajl tomorito szoftver sem kerult OpenCL-re vagy CUDA-ra portolasra. Ez megint veletlen? Vagy csak az a gond, hogy mindenutt ugyanolyan fakezu programozok dolgoznak, akik csak a nyamvadek es ezerszer eltemetett x86-hoz ertenek?
"Tudsz mondani rá példát (az olyan tesztprogramokon kívül, mint az Everest és az AIDA), hogy más binárist adnak inteles AVX-hez, mint AMD-shez"
Felteteles modot hasznaltam, szerintem el kene olvasnod alaposabban, amit irtam...
"Azt viszont el tudom képzelni, hogy a különféle gyártók GPU-n némileg eltérő OpenCL kód fut a legjobban."
Ez abszolut igy van, csak epp kezdesnek kellene egy OpenCL kernel, amit aztan lehet tesztelgetni, profilozni a tobbi GPU architekturan. A Strongene-nel ez a lehetoseg nem adott.
"Az is benne van a pakliban, sőt talán ez a legvalószínűbb, hogy az AMD támogatta a fejlesztést, ezért cserébe átmenetileg csak AMD vason fut a GPGPU-s változat."
Es ez igy rendben van? Mert szerintem nem igy kellene ennek mukodnie. Az AMD GPU-val rendelkezo felhasznalok szempontjabol mindenkepp jo ez igy, csak ahogy fentebb is irtam, nem gondolom, hogy ez egy mukodokepes modell lehet. Az AMD-nek sincs annyi eroforrasa, hogy minden szoftverceg hozza outsource-olja a GPGPU fejleszteseket...
[ Szerkesztve ]
-
Fiery
veterán
"Te azt feltételezed, hogy azért, mert az AMD szállította az OpenCL-ből fordított binárisokat."
Azert feltelezem ezt, mert a HEVC dekoder felepitese egyertelmuen erre enged kovetkeztetni.
"Ez következetlenség a részedről, hiszen korábban sokat írtál arról, hogy sokszor ugyanaz a kód itt vagy ott hibásan fut."
Nem ertem, mi az osszefugges. En azt irtam mar sokszor, hogy az OpenCL-lel az az egyik gond, hogy az aktualis videodriverben levo aktualis OpenCL compiler bugjainak ki van teve az a fejleszto, aki OpenCL kernelt valosideju forditas utan futtat. Ezt a problemat -- legalabbis reszben -- nyilvan ki lehet kerulni azzal, hogy OpenCL binarist szallitasz a szoftvereddel, azonban ezzel egy adott architekturahoz lancolod a szoftvert. Ha pl. csak az AMD-nel maradunk, akkor is elvagod magad a jovobeni architekturak tamogatasatol a binaris modszerrel. A HEVC dekoder az Iceland, Hainan es Tonga architekturakhoz is tartalmaz binarisokat, ez egyreszrol valamennyire jovobemutato, hiszen ezek jovobeni architekturak; viszont az ezeken felul megjeleno architekturakat mar nem fogja ez a HEVC dekoder tamogatni. Mig, ha OpenCL kernelt hasznalnanak, akkor (az Intel es nVIDIA GPU-k tamogatasan felul) nyitva hagyhatnak a lehetoseget annak is, hogy egy jovobeni AMD architekturan is modositas nelkul fusson a dekoder jelenlegi verzioja. Persze kozben ott van a compiler problema is, nyilvan, de ezt meg at lehetne hidalni pl. egy hibrid megoldassal: az AMD binarisokon felul lehetne hasznalni kernelt is, es akkor a kecske is jollakna es a kaposzta is megmaradna. Vajon miert nem ezt az utat valasztotta a Strongene? Mert az AMD-nek nem allt volna erdekeben, ilyen egyszeru. Az Intel es nVIDIA GPU-val rendelkezo felhasznalok -- akik mellesleg a PC-felhasznalok tobbseget teszik ki -- meg le vannak ejtve...
"Azt sem zárnám ki, hogy némileg eltérő OpenCL kód kedvez az egyik vagy a másik GPU architektúrának."
Ez nyilvan igy van, csak nem ertem, mit akarsz ezzel mondani. De me'g ha nem is aldozna idot a Strongene arra, hogy kulon Intel, kulon nVIDIA optimalizalt OpenCL kernelt keszitsen, egy unified kernel is sokkal jobb megoldas lenne, mint CPU-val dekodolni a videokat...
"És itt van még az a lehetőség is, hogy az AMD anyagilag támogatta a céget a GPGPU-s változat elkészítése érdekében, amiért cserébe átmenetileg az csak az AMD-n fut."
Termeszetesen elkepzelheto, bar en nem latom ennek tul nagy eselyet. Az AMD-IL binarisok, plane ugy, hogy minden AMD GPU csaladra kulon binarist keszitettek, nagyon alapos, nagyon profi munkara utal. Olyan munkara, amit leginkabb csak az AMD maga akar es kepes megcsinalni. Ezzel nem lebecsulom a Strongene fejlesztoinek kepessegeit, sot. Csak epp egy akarmilyen szoftverceg nem allna neki ilyen szinten berhelni az AMD GPU-ival, hiszen -- normalis esetben -- az ebbe belefeccelt idot inkabb arra forditaná, hogy a masik 2 GPU gyarto termekein is fusson a cucc. Par %-kal alacsonyabb teljesitmeny egy regi VLIW-es AMD GPU-n szerintem megerne annyit, hogy Intel es nVIDIA GPU-n is szepen szaladjon a dekoder -- kiveve persze ugye ha eleve nem cel az, hogy barmin fusson, ami nem AMD.
Ez az egesz egyebkent a felig tele - felig ures pohar tipikus esete. Te mint AMD-vel szimpatizalo emberke azt latod, hogy a HEVC dekoder nagyon alapos, nagyon franko OpenCL optimalizaciot kapott AMD GPU-kra, es ennek orulsz, hiszen felig tele van a poharad. En meg abbol az iranybol kozelitem meg, hogy miert nem kapott Intel es nVIDIA GPU-ra is OpenCL optimalizaciot a dekoder, plane ugy, hogy a PC felhasznalok tobbsege pont e ket gyarto GPU-jat hasznalja? Nekem ez egy hianyos termek igy, egy rossz koncepcio eredmenye, egy felig ures pohar.
"Simán lehet, hogy nem vagy nem jól (lassan vagy hibásan) futott más gyártók GPU-in, ezért azokat egyelőre hanyagolták. Főleg, ha AMD finanszírozással készült."
Elkepzelheto, csak epp nem valoszinu. Ha az AMD keszitette az OpenCL binarisokat, es az OpenCL kernelt odaadta volna a Strongene-nek (miert tette volna, ha eleve nem volt cel, hogy nem-AMD GPU-n is fusson a dekoder?), akkor minden tisztesseges ceg legalabb megprobalta volna mukodesre birni azt mas architekturakon is. Az nVIDIA OpenCL compilere pedig az en szemelyes tapasztalatom szerint van annyira jo, hogy minden bizonnyal be lehetett volna roffenteni a cuccot minimalis modositassal. Az Intel mas teszta, az o compileruk sz*r, azon siman lehet, hogy nem megoldhato a dekoder portolasa, me'g kisebb compiler modositasokkal/patkolasokkal sem
A lassan futas pedig nem jo erv, hiszen me'g egy lassu GPU is gyorsabban dekodolja a HEVC-t, mint egy mainstream x86 CPU.
[ Szerkesztve ]
-
Fiery
veterán
"Tudsz mondani rá példát (az olyan tesztprogramokon kívül, mint az Everest és az AIDA), hogy más binárist adnak inteles AVX-hez, mint AMD-shez?"
Ahhoz, hogy erre egyertelmu valaszt lehessen adni egy adott szoftver eseteben, ismerni kellene a konkret kodot, ami fut a CPU-n. Mert a PR-anyagban maximum a benchmarkoknal (AIDA64, Sandra) reklamozzak a CPU generacio specifikus AVX optimalizaciokat, real-world applikacioknal erre nem szoktak kiterni. A reverse-engineering pedig nem olyasmi, amit etikus vagy legalis lenne hasznalni, ha ilyesmire vagy kivancsi
-
Fiery
veterán
"Nem vágnak el semmit, hiszen az újabb verziókban szállíthatnak binárisokat újabb/egyéb GPU generációkhoz/architektúrákhoz is."
Annak a lehetoseget azonban elvagjak, hogy a jelenlegi verzio futhasson egy most me'g nem tamogatott GPU-architekturan. Persze nem olyan nagy gond ez, ha folyamatosan frissitgeted a dekodert, csak mondjuk CPU vonalon ez nem megszokott. CPU-knal, ha mondjuk egy szoftver SSE-t tamogat, akkor nem szokas az, hogy jon egy uj, SSE-kepes CPU-generacio, es azon hirtelen nem fut egy meglevo, SSE-re optimalizalt szoftver.
"Ti sem OpenCL forráskódot adtok, hanem binárist. Akkor higgyem azt, hogy nektek is a cégek készítik el a GPGPU-s részeket? Egyébként ti külön binárist adtok a különféle GPU-khoz?"
Nem bantani akarlak, de ebbol a 3 mondatodbol tokeletesen latszodik, hogy nem ertesz az OpenCL temahoz, csak hozzaszolsz. Ez nem lenne gond, ha nem irnal olyan meggyozo(nek latszo) dolgokat
No offense. Sz'al a dolog ugy nez ki normalis esetben, hogy megirod az OpenCL kernelt (forraskodot), azt mellekeled a szoftverhez. Ha okos vagy, akkor nem sima TXT fajlkent (.CL kiterjesztessel szokas, de ez mindegy) mellekeled a szoftveredhez, mint az OpenCL sample-k eseteben (ld. pl. AMD APP SDK sample kollekcio), hanem letitkositod es eltarolod mondjuk resource-kent. Tehat a forraskodot mellekeled, de nem olvashato formatumban. Aztan, a szoftver futasa kozben a kernel forrast betoltod, dekriptalod, es atadod az OpenCL forditonak (clCreateProgramWithSource). Ennek a megoldasnak az a nagy elonye, hogy gyarto fuggetlen kodot tudsz mellekelni a szoftveredben, a hatranya pedig az, hogy a valosideju OpenCL forditas miatt ki van teve a kodod az OpenCL forditok esetleges benasagainak, bugjainak. En szemely szerint ugy gondolom, hogy ennek a megoldasnak tobb elonye van mint hatranya, ezert ez a preferalt pl. az AIDA64-ben is. De a Sandra is igy mukodik, meg me'g egy csomo mas szoftver is.A valos ideju forditas elonyei:
+ gyartofuggetlen
+ platformfuggetlen
+ future-proof (jovobeni GPU architekturakhoz is jo a kod)
+ jovobeni OpenCL compiler optimalizaciokkal a teljesitmeny a kod ill. a teljes szoftver modositasa nelkul is novelhetoA valos ideju forditas hatranyai:
- ki van teve az OpenCL forditok benasaganak
- ha valaki feltori a szoftvert, akkor viszonylag konnyen megszerezheti a kernel forrast es felhasznalhatja a sajat celjaira. De a binaris kodokat is vissza lehet fejteni, csak az kicsivel nagyobb melo. HSAIL-nel konnyebb lesz a binaris kodok visszafejtese, mert az egy nyilt specifikacio."BTW, éppen erre a problémára nyújt megoldást a HSA: a HSAIL bytecode nem forráskód, miközben többféle GPU-ra továbbfordítható."
Igy van, a HSAIL egy jo megoldas lesz erre a dilemmara, felteve persze hogy a HSAIL-t Intel es nVIDIA GPU-n is tudod majd futtatni. Ha nem, akkor alig lesz jobb, mint most az AMDIL
Tudom-tudom, a HSA Foundation-nek tagja a Qualcomm es a Samsung is, es a HSAIL-t majd jol tudod futtatni a mobiltelefonodon is, nem csak az AMD APU-s PC-den, de maradjunk most az x86-os PC-knel, ez a jelen rogvalosag.A HSA tamogatas azonban onmagaban is egy dilemma az AMD reszerol. Egyreszt ugye nincs kesz a HSA implementacio, nincsenek HSA compilerek, masreszrol pedig a HSA-t tamogato hardverek nagyon szuk kort kepviselnek (Kaveri, oszt annyi). Ha pedig csinalsz mondjuk egy HSA-s HEVC dekodert, es valahogy belehakkolod a Catalystba (mint a JPEG dekodert), akkor jon a sok dGPU-tulaj, ill. regebbi APU tulaj, hogy ok miert nem kapnak ebbol a josagbol
Ha viszont megcsinalnad HSA-ra is es OpenCL-re is, akkor meg az lenne a gond, hogy jo esellyel eltunne a HSA elonye, es az lenne az igazi PR-katasztrofa Mert arrol nem szolnak a hiradasok, Abu se gyakran emlegeti, hogy ha egy adott problemat meg tudsz oldani OpenCL-lel is, es HSA-val is, es egy adott vason mindketto hasznalhato, akkor nagyon keves olyan eset van, amikor a HSA nagyobb teljesitmenyt tud nyujtani. Mas teszta persze, ha OpenCL-lel keptelenseg megoldani normalisan a problemat, de a HEVC dekodolas ugy tunik, siman megy OpenCL-lel is..."Nincsenek leejtve az Nvidia és Intel felhasználók sem, csak ha egyszer az AMD finanszírozza a GPGPU-s változatot, akkor joggal kér cserébe némi előnyt a támogatásban."
Mar megbocsass, de en mint nVIDIA GPU tulaj (Intel procival) nem kaptam semmit az AMD-tol, se a Strongene-tol. En nagy ivben teszek arra, hogy a Strongene es az AMD mikent fekudtek ossze az OpenCL tamogatas kapcsan. Az en szempontombol csak annyit erzek, hogy le vagyok ejtve. Kaptam GPU-gyorsitott HEVC dekodert? Nem. Kapni fogok? Majd egyszer, talan. Na itt a baj. Egy felhasznalo szamara teljesen mindegy, hogy mi az oka annak, hogy kimaradt a "tutibol", a lenyeg az, hogy kihagytak. Szoftver fejlesztokent nekem nem lenne pofam ilyet csinalni, de teny, hogy en nagyon kis hal es egy abszolut amator, koca programozo vagyok az AMD-hez vagy a Strongene-hez kepest
"Azért érv, mert ha lassabban futna pl. Nvidián, mint elvárható lenne, azzal kitették volna magukat az Nvidia és/vagy Nvidia fanok támadásának, hogy ez biztos szándékos húzás, ami etikátlanabb, mint későbbre halasztani a támogatást"
Marpedig lassabban fut, mint elvarhato lenne. Az elvarhato az lenne, hogy ha OpenCL-t tamogat a szoftver, akkor GPU-n is futnia kene. nVIDIA-n is, Intelen is. Ergo, ha direkt nem hasznalhato az OpenCL optimalizacio a GPU-n, akkor ott az elvarhato teljesitmeny nincs meg. Es igen, szerintem szandekos volt ez az egesz, csak az nem vilagos, hogy pontosan mi van a szinfalak mogott.
"Korábban kérdezted, miért terjed olyan lassan az OpenCL alkalmazása? Nos, talán mert az Intel egyelőre inkább az SSE/AVX-es fejlesztést támogatja. Ezzel is valamilyen módon versenyeznie kell az AMD-nek."
Mi koze a kettonek egymashoz? Az nVIDIA-nal ott a CUDA, regebb ota nyomja, mint hogy egyaltalan OpenCL letezett volna. Megsem tolonganak a CUDA fejlesztok sem, es az OpenCL fejlesztok sem. Pedig az nVIDIA az OpenCL-t is tamogatja. Nem feltetlenul azt nyomjak, de nem is allnak az ember utjaba, ha az OpenCL-t valasztja es nem a CUDA-t. Plusz, a CUDA es az OpenCL kozott eleg durva atfedes van, ergo ha az egyikhez ertesz, a masik is menni fog siman. Tehat van AMD+OpenCL, Intel+OpenCL (lightosan), nVIDIA+CUDA, nVIDIA+OpenCL, es megsem terjed a dolog igazan szepen. Ennek azert kell hogy legyen oka, de persze ezt csak azok latjak igazan, akik konkretan fejlesztenek is GPGPU-ra valamilyen szinten, vagy legalabbis megprobaltak beletanulni. Meggyozodesem egyebkent, hogy rengeteg C/Delphi/Java/VB/.NET fejleszto megprobalkozott a GPGPU temaval, csak feladtak, meg tul neheznek, tul korulmenyesnek, tul elrugaszkodottnak talaltak azt a megszokott fejlesztoi kornyezetekhez, a megszokott nyelvekhez kepest legalabbis.
[ Szerkesztve ]
Új hozzászólás Aktív témák
ph A 2.0-s fejlesztés az alapcsomagot, illetve egy OpenCL-es opciót is kínál.
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Xiaomi AX3600 WiFi 6 AIoT Router
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Ukrajnai háború
- Óra topik
- Call of Duty: Modern Warfare III (2023)
- Luck Dragon: Asszociációs játék. :)
- Ennyibe kerülnek a Huawei Pura modellek Európában
- AMD GPU-k jövője - amit tudni vélünk
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- További aktív témák...
- EDIFIER R1700BTS hangfal pár makulátlan, új állapotban, 2 év hivatalos garanciával, alkalmi áron
- LG OLED55B23LA 2 Év GYÁRI GARANCIA
- Apple iPhone XR 128GB, Kártyafüggetlen, 1 Év Garanciával
- Gamer PC , i7 12700KF , RTX 3080 Ti , 64GB DDR5 , 960GB NVME , 1TB HDD
- Intel PC , i5 8500 , 1660 6GB , 32GB DDR4 , 512GB NVME , 500GB HDD
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen