- Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- Különösen rendezett beltér hozható össze a Cooler Master új házában
- A középkorra és a pokolra is gondolt az új AMD Software
- Új gyártástechnológiai útitervvel állt elő a TSMC
Hirdetés
-
Rossz üzlet az EV-kölcsönzés
it Küszködik az EV-kölcsönzés miatt a Hertz Global, még több EV-t adnak el.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
ph Az 50 wattos modellt beágyazott rendszerekbe, MI-vel kapcsolatos munkafolyamatokhoz és edge applikációkhoz szánták.
Új hozzászólás Aktív témák
-
julius666
addikt
A felhasználói interfészen belül az innovációt az OpenCL felület szolgáltatná, amelynek segítségével lehetővé válna számos új vezérlési forma, mint például a hang- és a gesztusfelismerés, illetve a kiterjesztett valóság.
Mi köze van az UI-nak az OpenCL-hez? Mert nagyon mást nem látok hogy lehetővé teszi a GPU-n számítást nagy a jól párhuzamosítható, GPU-n számítható feladatok terén, amivel esetleg lehetne hangfelismerést / gesztusfelismerést / mintafelismerést a kamera képéből a GPU-n is számítani...
[ Szerkesztve ]
-
julius666
addikt
Ok egyébként végre egy felhasználási terület ahol a szvsz messze túlspilázott heterogén programozásnak végre az átlaguser is hasznát fogja látni.
Ugyanis mindenki várja itt mint a messiást, de professzionális alkalmazásokon meg játékokon (fizika, újfajta effektek, raytracing elemek beépítése a raszteres motorokba) kívül még mindig nem látom hol fog ez áttörést hozni. -
julius666
addikt
Megoldani meg lehet, de hatékonyságban elmarad a klasszikus CPU-s megoldásokétól. Értsd: ugyanazon minőség/bitráta arány mellett a CPU-s kódolás gyorsabb és így energia-hatékonyabb is (CPU-k jellemzően kevesebbet esznek a GPU-knál). A GPU-k architektúrája egyszerűen nem ideális a videókodolási folyamat lépéseinek többségére.
Tehát CPU-s "szoftveres" tömörítők >>> GPU-s "hardveres" tömörítők. A marketingnek ne tessék felülni.
-
julius666
addikt
A CPU csak kismértékben határozza azután meg az internetes megjelenítés sebességét. Mint "Javascript leváltó" a WebCL ebben komolyan benne lesz. Legalábbis az ARM szerint.
Aha.
A WebCL az az OpenCL webes megfelelője, hasonlóan a WebGL <-> OpenGL-hez (gondolom hasonló butításokkal és korlátozásokkal). Pont ugyanannyit fog tudni (pontosabban csak még kevesebbet), mint az OpenCL. Tehát bizonyos feladatokat, amik alkalmasak rá (a GPU hatékonyan el tudja végezni őket, azaz kb. jól párhuzamosítható számítási feladatok), ki lehet vele zavarni GPU-ra. Az átlaguser szempontjából ez totál irreleváns, mert ő (játékokon kívül) semmi olyat nem használ ahol ilyesmire szükség lenne. Hogy a búbánatba segítene a WebCL ott ahol az OpenCL sem tudott? Nem azt mondom hogy semmi értelme ezeknek a dolgoknak, de a professzionális szakterületeken kívül messze nem lesz ez akkora durranás mint beharangozzátok. A cikkben említett területek az elsők ahol a játékokon kívül is látom valamiféle értelmét.
Az oldalrender hardveres gyorsításához meg eddig sem kellett OpenCL.
[ Szerkesztve ]
-
julius666
addikt
A hang- és gesztusfelismerést át lehet ültetni a weboldalakra is.
Csak nem a weblap motorja fogja feldolgozni a hangjeleket/egyebeket. Az már majd a feldolgozott anyagot (szöveg/gesztusfelismerésnél kész eventek) készen kapja, a feldolgozást a driver/oprendszer végzi, OpenCL-el/natív kóddal/akármivel amiben megírták. Tehát itt nem fog a WebCL egy büdös betűt sem csinálni.
Az IGP energiatakarékosabban dolgozza fel a webes tartalmakat.
Mi az hogy az IGP feldolgoz webes tartalmat? Az IGP nem dolgoz fel webes tartalmat, mivel nem alkalmas rá. Láncfűrésszel nem tudod kifesteni a lakást hiába nagy a teljesítménye.
Az IGP (vagy mondjunk inkább GPU-t) az gyönyörűen megcsinálja a layoutot meg a kirajzolást, de ehhez nem kell sem OpenCL, sem WebCL. Ez működött eddig is.DOM nodeokat kezelni/felépíteni, javascriptet futtatni nem fogsz GPU-n, az hétszáz.
-
julius666
addikt
Dehogynem alkalmas rá. A Youtubeon a videót ki nézi teljesen procival?
A videólejátszás gyorsítására igen, alkalmas. Ugyanúgy alkalmas a canvasos/WebGL-es animációk gyorsítására, értelemszerűen. De ennyi, és ehhez nem kell OpenCL/WebCL.
A WebCL másra kell, például a javascript helyébe léphet, az ARM szerinte erre nagy esély van.
Dehogy válthatja. Ez a kijelentés önmagában is nevetséges, mivel javascriptből kezeled az egész WebCL-es mizériát. Ha valami válthatná a javascriptet, az max a Chrome-féle natív kliens lehetne, amin natúr C-ből/C++ból fordított bináris kódokat lehet futtatni.
Itt csupán arról van szó, hogy ki lehet számításigényes feladatokat dobni a WebCL-motornak javascriptből (amiről már hsz-ek óta beszélek).
Ez nagyon klassz és hasznos, de a PH! ettől nem fog hamarabb betölteni, sem PH!-zás közben kevesebbet enni a vas fogyasztásban (nyilván mindenki azt helyettesít be oldalnak amit akar, az átlaguserek által naponta látogatott oldalakról beszélünk itt). Márpedig mindenki ezt várja tőle, majd "minden a GPU-n fut mer' az gyorsabb", a marketing is ezt tolja és én már nagyon unom.
Webalapú képszerkesztőket (a számításigényes dolgokat kidobva GPU-ra, ugye az pont alkalmas a "sok adatot ugyanúgy manipulálunk párhuzamosan" jellegű feladatokra) meg nagyon szép demókat lehet vele összepakolni, klassz fizikai számításokat végezni ami eddig esélytelen lett volna, de ennyi. Ebből az átlaguser max. a fotószerkesztőt ha látja.
-
julius666
addikt
Most hirtelen csak ezt találtam, 2008-as, de olyan nagyot nem javult a helyzet azóta: [link]
Ha jól értem, azért tartod túlspilázottnak, mert nem tudod elképzelni, mire is lehetne használni.
Már hogyne tudnám elképzelni. Olyat nem tudok elképzelni amiből az átlaguser jelentősen profitálna. Pontosabban de, de csak 1-1 területen (pl. az említett webes képszerkesztők).
Szerintem ez tévedés.
Szerintem meg nem.
Láttam rendes teszteket (nem a kamu megrendelt marketinganyagokat) és ~ugyanazon a minőségen az x264 pl. gyorsabb/közel ugyanolyan gyors volt mint a hardveres megoldások. Csak mellette sokkal jobban skálázható többek közt.FLOPS/W alapon nagyon nem így van!
És ki nem szarja le a FLOPS/W értéket? A Flops az csak egy szám, e-pénisz.
Az számít, tömörítésnél azonos minőségű tömörített kimenet mellett melyik zabál kevesebbet: mivel közel azonos idő alatt végeznek, a CPU pedig önmagában jellemzően kevesebbet zabál adott idő alatt, szerintem nem kell matematika professzornak lenni ahhoz hogy kitaláljuk összességében melyik a nyerő.Ezt kifejtenéd bővebben? Szerintem ez csak a korábbi GPU generációkra igaz, amiket megfektettek a feltételes ugrások. A maiak egyre jobban boldogulnak vele.
Igen, illetve a nagy latency sem vált az előnyükre (nyilván ez egyre csökken, de még továbbra sem az igazi), nehézkes threading modell, meg még vannak problémák.
Bizonyos részeire alkalmas lenne (pl. mozgásvektorok keresése), bizonyos részeire gyakorlatilag alkalmatlan (pl. entropy coding).
A jelenlegi GPU-gyorsított enkóderek mindenesetre nagyon ganék.Azt tudom hogy régebben az x264 fejlesztői nagyon kacsingattak a dolog felé, de az eredmény egyértelműen nem azóta is. GSOC-ra évek óta ki van írva a mozgásvektor-keresés GPU-gyorsítottra megírása, mindeddig sikertelenül.
-
julius666
addikt
Éppenséggel a Direct2D és a DirectDraw gyorsítás pont, hogy általánosan előnyös a fogyasztásban.
Persze, ezt említettem én is.
Minél több HTML5-ös oldal lesz, annál kevesebb fogyasztást fog igényelni azok megjelenítése, ha azokat GPU-val gyorsítod
Továbbra sincs semmi köze a HTML5-nek a hardveres gyorsításhoz, már párszor leírtam. Élmény veled vitatkozni.
-
-
julius666
addikt
Miből gondolod, hogy a jövőben emailen és chaten tartja majd a kapcsolatot egymással az átlagember?
Totál lényegtelen, érted mire gondoltam. Vagy szerinted fraktálokban fogunk 10 év múlva kommunikálni és azok megjelenítéséhez kell a kapacitás?
Azt sem értem, miért akarod mindenáron az OS-re vagy a browserre bízni az egészet?
Pl. azért, mert egy használhatóbb beszédfelismerő/mintafelismerő forráskódja sok(tíz)ezer sor. Már a beparse-olása is beszarás lenne. Meg nem látom értelmét hogy egy totál generikus feladathoz most minden oldal külön postáza le ugyan azt a rahedli kódot. Meg nem mellesleg oprendszerbe/driverbe építve akár le lehetne hardver-közelibben is kódolni a nagyobb teljesítmény érdekében.
A webes platform népszerűségének egyik oka amúgy is a könnyűsúlyúsága, hogy gyors implementációjú API-kból pikk-pakk össze lehet legózni egész komoly dolgokat egy magas szintű nyelven.
-
#67
julius666
addikt
Blindmouse
#65
julius666
addikt
válasz
Blindmouse
#65
üzenetére
Egyszerűen nincs értelme arról vitatkozni, hogy számítási teljesítményben mikor hagyja le az x86-ot. Ha kevés a teljesítmény, teszünk még oda magot, kész
Ez feladatfüggő mennyire használható módszer. Ha szálakba/processzekbe jól szétbontható a feladat ami miatt szükséged van rá, teljesen jó, és ilyen területeken az ARM könnyen lekörözheti az x86-ot. Onnantól fogva viszont hogy egy szálon kell magas számítási teljesítmény, dobálhatod mellé a magokat.
-
julius666
addikt
Hosszabb távon megjelenhet pl. a közvetlen agyak közötti kommunikáció, és lehet, hogy ehhez nem kevés asszisztencia is kel majd. Ki tudja, mit hoz a jövő...?
Ez 10 év múlva még mindig csak sci-fi lesz, ezt nyugodtan veheted készpénznek.
Addig amíg ilyesmiről realitásként beszélhetünk még le fog folyni pár programozói paradigma meg hardverarchitektúra a Dunán, erre felesleges már most felkészülni. Eleve kétlem hogy a jelenlegi architektúrák ilyesmire képesek lennének egyáltalán (pontosabban nyilván bármire képesek, csak az más kérdés milyen hatékonysággal).Hangvezéerlés, beszéd- és emóció-felismerés, tekintetkövetés, stb. stb.
Ez viszont realitás, ha elolvasod az első hozzászólásomat akkor ezt pont mint az átlaguser számára is értelmes GPU-kihasználási lehetőséget tartom.
Ez a flatness is elég unalmas már, akár OS, akár web szinten.
Unalmasnak lehet hogy unalmas, viszont nincs jobb. Egyébként ezzel a 3D-s UI-val már piszok régóta próbálkoznak, mindeddig abszolút sikertelenül. Sőt ha megnézed határozottan megfigyelhető trend az UI-k minimalizálódása mind design, mind egyéb téren. Az érintőképernyők terjedésével ez csak folytatódni fog (lásd Win8 csempés felülete). Egész egyszerűen a jelenlegi eszközeink mellett ez az optimális, illetve mi emberek sokkal könnyebben igazodunk el 2D-ben hiába 3D-s világban élünk. Ez van, nagy változásokra ilyen téren sem számítok az elkövetkezendő 10 évben. Max annyira hogy ha megjelennek normális 3D-s monitorok akkor ugyanazok a 2D-s felületek kapnak valami minimális mélységet is (kb. csak a csicsa, valódi funkcionalitás nélkül). Ehhez pedig 3D-s leíró nyelv meg driver kell, semmi más, ezek eddig is rendelkezésre álltak.
Azt nem értem, miért ne lehetne több-kevesebb WebGL és WebCL kód a lapokon.
Hol mondtam én hogy nem lehetne? Én csak annyit mondtam, az átlaguser nem fog sokat belőle profitálni, mert a játékokon meg képfiltereken kívül nem lesz normális felhasználási terület a számára. Hétköznapi feladatoknál (e-mail, hírolvasás, közösségi háló) egyszerűen nincs rá szükség.
Persze be lehet tenni trükkösebb transition-öket, animációkat meg ilyesmiket user input eventekhez, amit aztán ki lehet dobni GPU-ra, ami gyorsabban/hatékonyabban számolja ki a nagyszámú lebegőpontos műveletet, de ha már a fogyasztáson skótoskodunk, akkor lehet egyszerűbb lenne ezeket eleve mellőzni. Meg nem mellesleg ezek nem fogják jobbá tenni az user életét, ezek jellemzően 10 percig mókásak, utána egyre inkább zavaróak.
-
julius666
addikt
Már vagy 10 éve kapható olyan agyhullámvezérlésű joystick, ami egy fejre rakható pántból és egy elemző egységből áll.
Link? Remélem nem valami idióta sg.hu-s szar...
Viszont az OpenCL-lel nem tudom, mi a bajod, senki sem fog nekiállni mindezeket shader-asm-ben leprogramozni minden fajta GPU-ra.
Semmi, írtam hogy bajom lenne vele?
Lehet, hogy WebCL előbb fog megjelenni, mint az...
Azt nehezen tudnám elképzelni, mivel a WebCL az javascript bindig az OpenCL-hez, nem több.
Azt nem ismerem, viszont bejönnek az Andoid vagy az iPhone 3D-s UI megoldásai...
Kár hogy csak csicsa lényegében, a lényeg ugyan úgy 2D-s (hint: navigálni 2D-ben navigálsz).
Itt most a VRML-re gondolsz?
Akár, bár én OpenGL-re gondoltam konkrétan (csak késő volt és már fáradt voltam, grafikus API-t akartam írni).
-
julius666
addikt
Ilyen egyáltalán van már, ami megbízhatóan működik?
Nem, de jelenleg rendes procin elég esélytelennek tűnik az implementálása, nagy számításkapacitású GPU segítségével már sokkal reálisabb lehet kliensoldalon is.
Ettől függetlenül én is inkább azt mondom hogy ez felhőben fog menni, a Google-nek már van is rá konkrét API-ja, amit a weboldalak már felhasználhatnak tudtommal. Sajnos még messze nem tökéletes.Abba már bele sem megyek, hogy a JS nem egy olyan nyelv, amivel más nyelveket implementálni tanácsos
Ezt nem igazán értem.
Egyébként ha a Google próbálkozásai sikerrel járnak és elterjed, a jövőben natív kód (illetve próbálkoznak egy köztes nyelv használatával is) is futhat a böngészőben, nem csak javascript. -
julius666
addikt
Ilyesmi lenne a helyes út...
bár a natív kód elég szarul hangzik
Szarrá van sandboxolva meg ellenőrizve, így talán annyira nem.
A JS-dologhoz: így már értem mire gondoltál, az nem volt tiszta hogy mi akar lenni az a más nyelv implementálós dolog (bár egyébként vannak ilyenek - coffescript és tsai, amik JS-be fordulnak - de ezeket őszintén szólva nem tartom sokra és nincs tudomásom róla hogy különösebben elterjedt lenne). A JS nem rossz dolog egyáltalán, mindaddig amíg nem akarnak vele realtime nagy számításigényű dolgokat/bazinagy rendszereket csinálni, amire klasszikusan a típusos, statikus nyelvek valók. GUI-k logikájának összedrótozására, nagy funkcionalitású API-kkal mögötte különböző rövid feladatokkal operáló (nem blokkoló) eseményvezérelt alkalmazások készítésére tökéletes, abszolút felveszi a versenyt a konkurenciájával (a Node.js pl. nem hiába annyira felkapott). Csak komolyabb dolgokhoz (pl. komolyabb játékmotorokhoz, nagyobb üzleti rendszerekhez) alkalmatlan, de nem igazán értem ez miért akkora probléma, nem is erre találták ki, nem is próbálja senki ilyesmire használni. Egyáltalán nem értem a programozói társadalom negatív hozzáállását a nyelvhez (pontosabban de, őszintén szólva engem is zavar hogy OKJ-s "webfejlesztő" kóklerek programozónak nevezik magukat azzal hogy templatekből össze tudnak dobálni valamit ami úgy-ahogy működik, de ez elsősorban nem a nyelv hibája).
A WebCL-hez: a ... valami C-szerű forráskód ... nem egy-az-egyben OpenCL (esetleg korlátozásokkal)?
-
julius666
addikt
Csak kicsit furcsa, hogy míg Windows alkalmazásfejlesztés terén már rég elindult a trend a C++ (natív) leváltására C#-al (CLR), itt most megint totál natívról akarnak kezdeni.
Nem totál natívról akarnak kezdeni, ott a JavaScript.
A karbantarthatóság és IDE támogatás az ami miatt sokszor nem jó üzlet a dinamikusság.
Ebben egyetértünk, valóban siralmas a mai napig a js támogatás az IDE-kben (legalábbis amikkel eddig találkoztam, Eclipse Aptana pluginnal és Netbeans, de a VS-ről sem hallottam túl sok jót), kódkiegészítés lényegében nincs (van csak buta) és sorolhatnánk. Ez azonban nem hiszem hogy szükségszerű állapot, más dinamikus nyelvekhez (pl. python) ezek teljesen használhatóak, illetve már így is sokkal előrébb tartunk mint évekkel ezelőtt. Ez minden bizonnyal javulni fog, akár a közeljövőben már.
Karbantarthatóság/code management téren ott a CommonJS ami baromi nagy előrelépés (sajnos ez böngészővonalon nem létező dolog), illetve az ECMAScript 5 is hoz be újdonságokat ilyen szempontból. Szóval kétségtelenül vannak ilyen irányba törekvések, csak ezek nagy részét már évekkel ezelőtt meg kellett volna lépni. Sajnos most isszuk meg a levét a webszabványokat kidolgozó csoportulások inkompetenciájának meg hogy anno MS-ék meg a többi akkori nagy IT cég nem karolta fel rendesen az ügyet. Most már kínkeservesen fog csak átmenni minden apró változtatás.
A kliensoldal vastagodásához pedig csak annyit, hogy persze, az oldalak funkcióinak növekedésével meg a szirszar izgőmozgó designelemekkel/átmenetekkel meg tudnak szaladni a kódok, azonban ez még mindig egyszerű View réteg. A Modell ahová komoly karbantarthatóság kell az a szerveren marad. És nem igazán látom hogy ez megváltozna a jövőben, minden piaci szereplő a cloud meg SaaS irányba nyomul, a javascript csak megjelenítő oldalra kell. meg amúgy is komoly security problémákat vetne fel.
Ez alól egyedül a játékok (illetve esetleg képszerkesztők meg még egy-két célterület, ha normális UI reszponzivitást akarunk) a kivételek, annak nyilván a kliensél kell futnia.Na de ilyen nyelvi finomságokról kár is beszélgetni Web kapcsán, ahol is a programok 99%-át PHP-ban írják, ami nyelvtervezésileg egy hatalmas kupac inkompetencia némi káosszal nyakon öntve...
A JavaScript a rossz hírnevét pont annak köszönheti, mert hosszú éveken keresztül ezen emberek játszótere volt. Meg mert sok programozó szemében a mai napig JavaScript = valami gagyi typeless Java-klón és b*sznak megtanulni programozni benne, programoznak Java-ul. Ami működő dolog, csak nem hatékony.
Ugyanis mindenki várja itt mint a messiást, de professzionális alkalmazásokon meg játékokon (fizika, újfajta effektek, raytracing elemek beépítése a raszteres motorokba) kívül még mindig nem látom hol fog ez áttörést hozni.
Új hozzászólás Aktív témák
ph A vállalat 2013-ra ígéri az okostelefonok új generációját, más néven a „szupertelefonokat”.
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- i5-9600K , és i5-9400F processzor eladó!
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel
- Intel Core i7-11700K processzor (használt)
- Intel I7 13700K 16mag/24szál - Új, Tesztelt - Eladó! 128.000.-