- A pápa egyre jobban tart a romlott AI veszélyeitől
- Kínában túl sok az EV, fokozódik az árháború
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Az USA nem akarja visszafogni Kína növekedését
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Direct One (műholdas és online TV)
- Facebook és Messenger
- Ubiquiti hálózati eszközök
- Windows 11
- HBO Max & OD topic
Új hozzászólás Aktív témák
-
Szlovi
aktív tag
Ebben a cikkben említetted,hogy várhatóan meg fog változni a neve CPU-ról HPU-ra :
...". A pletykák szerint a CPU megjelölés is el lesz hagyva, és a Santa Clara-i óriáscég utalni fog arra, hogy az újdonság már heterogén módon is programozható. Várhatóan ez a HPU jelölést vonja maga után, ami a Heterogeneous Processing Unit rövidítése." ...
Esetleg meg tudod erősíteni,hogy HPU lesz a neve a "gyereknek" vagy marad az "APUzás"
#38 +1
[ Szerkesztve ]
-
Atom_Anti
senior tag
Nem tudom bevenni egyenlőre, talán idővel megszokom. APU számomra egy jelzés ami mögött (AMD) technika áll. Úgy mint TDI, DTI, JTD, DTI, CDI, D, jelzések dizel motorra utalnak de mind más technikát jelent és más teljesítményt nyújtanak. Intel is más technikát használ és teljesítményben is eltér, habár ugyanazt a célt szolgálja.
-
lenox
veterán
Amugy en azt a definiciot talaltam csak az apura, hogy olyan lapka, ami a cpu-n kivul plusz feldolgozasi lehetoseget is tartalmaz, pl. gpgpu-ra alkalmas gpu-t, fpga-t, vagy mast. A Sandy Bridge-en meg lehet opengl shaderekkel gpgpu-zni szerintem, szoval a definicio illik ra. Ettol persze nem fogjak ok maguk apu-nak hivni, mert nem csinalnak reklamot az amd-nek, de nekem ugy tunik, hogy opencl nelkul is lehet valami apu.
-
lenox
veterán
Hat eleg sok tudomanyos cikk szuletett shader alapon, nem hiszem, hogy le lehet az osszes szerzot kalandorozni. Felhasznaloi szempontbol is sokkal tobbet talalkozhatsz shader alapu gpgpu koddal, mint opencl alapuval pl., szoval nem tudom ertelmezni azt, hogy az opencl vallalhatobb lenne. Tudomanyos vagy ipari celokra jobb, de ezekre meg a shadereket is nagy eroval hasznaltak.
Szerintem van definialva az apu, nem biztos, hogy pl. a ph-nak kulon definicioja kell legyen (sot, szerintem nem kene). Filozofalni persze barkinek lehet. De pl. ha az uvd neked ide szamit, akkor a quick sync nem kellene szamitson?
-
Jack@l
veterán
Beírtam az id-jét és valid, csak nem published.
"This ID is valid, but not published"
[ Módosította: Oliverda ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
lenox
veterán
Az APU egy heterogén módon programozható processzor.
Az amd definicioja az heterogeneous computingra:
A system comprised of two or more compute engines with signficant structural differences
Ez nyilvanvaloan illik az sb-re is.
A GPGPU-s programok főleg OpenCL-t, vagy DirectCompute 5.0-t használnak. Ezért nem tudod a Sandy Bridge IGP-jét használni több multimédiás programban.
A gpgpu-s programokat foleg nem a consumer piacra szanjak, igy alig van a consumer piacon gpgpu-s program. Az lehet, hogy a gpgpu-s programok ezen kis hanyadabol a mai modern programok foleg opencl-t es directcompute-ot hasznalnak, de ebbol nem lehet kovetkeztetest levonni arra, hogy az eddig fejlesztett gpgpu programok milyen resze futna sb-n.
tudományos cikkekkel pedig a felhasználó nem sokra megy.
A nem kihasznalt opencl-lel sem megy semmire, meg nem is kell nekik semmire. Legalabbis majdnem semmire. De attol meg, hogy a user nem jut vele semmire, attol meg a hatterben sokan sokmindent fejlesztettek. De amugy ennek nincs akkora jelentosege, annyi a lenyeg, hogy vagy ki kell mondani, hogy opencl, directcompute, c++ amp, vagy akarmi kell ahhoz, hogy valami apu legyen, vagy nem, de akkor az sb-re is igaz a definicio. Az nem annyira elegans, hogy nem mondjuk ki, hogy pl. opencl kell hozza, de a masfajta (shaderes) gpgpu-ra azt mondjuk, hogy csak kalandorok hasznaltak, tehat az nem illik a definicioba.
-
lenox
veterán
Na jo, de akkor ezzel a gyakorlatban azt mondod, hogy hiaba lehet gpgpu-zni, ha nem opencl (vagy directcompute, vagy ...), akkor nem apu. Ha felsorolod, hogy melyik technologiat kell supportalni ahhoz, hogy apu legyen, az nyilvan oke.
Amugy egy csomo feature-t fejlesztettek opengl-ben is, ami konnyiti a gpgpu fejleszteseket, ha nagyon akarnek nyilvan tudnek filetomoritot is irni, csak ertelme nincsen, de attol meg lehet ilyet csinalni, szoval egy ezen (lehet, vagy nem lehet) alapuplo definico megint csak igaz lenne az sb-re is. -
lenox
veterán
Ilyet csak poenbol van ertelme csinalni, vagy masik oldalrol nezve nincs ertelme. De ha ugy definialod, hogy akkor apu, ha lehet ra gpgpu-s file tomoritot irni, akkor nem az a kerdes, hogy van-e ertelme, hanem lehet-e. Ha 100-szor lassabb is, mintha cpu-n futtatnad, attol meg lehetni lehet. Persze lehet mindenfele mas vitathato definiciot is gyartani, de szerintem nem erdemes, inkabb erdemes az iparagban elfogadott definiciot hasznalni, ami alapjan apu, vagy kimondani, hogy kell opencl, akkor meg nem az. Egyelore ha jol ertem, te az amd altal mondott definiciot fogadod el, ami alapjan apu, es kozben azt mondod, hogy nem apu, szoval ha jol ertem ezt az ellentmondast meg nem oldottad fel. Amugy egyre jobban hajlok arra, hogy ki kell mondani, attol apu, hogy a gpu-jan tud opencl kodot futtatni.
#103: Nem tudom, nekem az az erzesem, hogy az ivy opencl supportja sem lesz tul erdekes a consumer piacon.
-
lenox
veterán
Oke, en elhiszem, hogy nem fogadod el, de eddig pont oket idezted. Akkor melyik definiciot fogadod el? Ezt:
Az APU-t lehessen heterogén módon programozni, de ne csak poénból írjanak rá programot.
Ezt en nem tekintem definicionak a masodik tagmondat miatt. Amugy nem nyomatom az opengl-t, csak felhoztam azt a tenyt, hogy sb-re lehet gpgpu programot irni (opengl-lel). Pont azt nyomatom, hogy tul sok ertelme nincs, de ha ez a kriterium, akkor ennek az sb megfelel, tehat vagy erdemes elfogadni az industry standard definiciot, ami szerint az sb is apu, vagy akkor masikat kell keresni.
Bármennyire is próbálod ezt az OpenGL-t erőltetni, hidd el senki sem fog rá olyan programot írni, ami a GPU erejét általánosan kihasználja.
Mar irtak ra, ez nem a jovo, hanem a mult. Megjegyzem, van gpgpu-s patentem, amihez opengl shaderes a kod, siggraph pappereket is nezegettem eleget, szoval kb. ismerem a temat. Persze en cuda-t nyomattam, amikor mar volt, viszont volt olyan, hogy nem en dontottem el, viszont nekem az a hozzaallasom, hogy ezek (marmint opencl, cuda, opengl, stb...) eszkozok, es nem a celok. Ha az a feladat, en erre is meg arra is tudok fejleszteni. Azt lehet mondani, hogy az opengl szar gpgpu celra, meg hogy az sb igp-je is szar, csak akkor mondjal olyan definiciot, amivel ezek ki vannak zarva.
Ha tetszik az opencl, akkor vedd be a definiciodba, ezt mar eddig is javasoltam.
-
lenox
veterán
Jo, akkor nem idezted, csak nekem ugy tunt, hogy hasonlit a te definiciod az ovekre.
Akkor nem tekinted definíciónak. Köszönöm, hogy megosztottad velem.
Nincs mit, maskor is szivesen. Te amugy annak tekinted? Kulonosen azt a reszt, hogy ne csak poenbol irjanak ra programot? Nem hinnem...
Googlezz ra: 'gpgpu opengl'. Vagy nezd meg a gpgpu.org-ot. Esetleg a gpu gems sorozatot. Vagy esetleg keress egy par siggraph pappert. Viszonylag nehez lesz ezekkel vitatkozni.
Nyilvanvalo, hogy az a teny, hogy a felsorolt programok olyan apit hasznalnak, amit az sb nem tamogat, nem zarja ki az sb-t a gpgpu capable halmazbol. Vagy akkor ha mondok egy programot, ami cudat hasznal, akkor az kizarja az osszes amd aput is belole? Ugye, hogy nem.
Na most akkor melyik a jó?
A jo az, hogy ha azt allitod, hogy az sb nem apu, akkor ez kovetkezik a definiciodbol. Jelenleg ez nem all fenn, tehat nem jo. Szoval vagy a definicion vagy az allitason valtoztatni kellene.miért nem futnak az SB-n a fenti GPGPU-s alkalmazások.
Azert, mert nem tamogatja a megfelelo apikat. Nem azert, mert nem lehet heterogen modon programozni, mert azt lehet.
-
Jack@l
veterán
Az még a gf6600 sorozatban volt alternatíva az opencl előtt (meg talán még egy kicsit később is)
DE még nagyobb cumi, mit az opencl-re fejlesztés.
Viszont OpenCL évek óta van (4+), hardver is van alá, program viszont nagyon kevés. Nem az APU hiánya az oka, az biztos.
Hogy fog majd megsokszorozódni ez a közeljövőben? ( őszintén, még a 3d-s grafikán meg a videokódoláson, fizikán kívül nem is nagyon látok hirtelen felhasználási területet se)
Jó tudom az auraizé, amit igazából pár x-fi-s reverb -el simán meg lehet oldani emberi fülnek teljesen hihető módon játékokban.[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Jack@l
veterán
"Pedig, ha megfigyeled, akkor a Llano érkezésével lódult meg a szekér."
Nevezzük inkább az eltelt idő és érdeklődés véletlen egybeesésének, előtte 1-2-3 évvel is meglódulhatott volna, ha nem lenne olyan foghúzós/nehézkes rá fejleszteni, sok korláttal.
Igen, a képfeldolgozást valóban kihagytam véletlen, arra is nagyon jó.UI: a heterogén cuccnak is ugyanazok a fizikai korlájai, energia, hő, helyfoglalás (tranzisztorszám)
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Jack@l
veterán
Nemtom mért vitáztok a múlton.
Egyrészt opencl-es program futni fog még sandy-n is, mert natúr procival is elmegy.
De ha netán van aki olyan szerencsés, hogy a mai világban megengeddheti a dedigált gpu-t is , akkor meg pláne....
Az a drag and dropos transzkódoló meg egy trutyi (sokkal jobbak és gyorsabbak is vannak), legalábbis ha arra gondolsz ami a catalyst-al telepedik.A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
lenox
veterán
Szerintem eleg nagy resz, foleg, ha a gyartokat nezzuk, nyilvan egy panorama kepeket keszito szoftvert nem fog a quicksync gyorsitani.
Nade hadd kerdezzek. Hany olyan van a felsoroltak kozul, ami nem codec-et gyorsit (mert quicksync-es program is van jopar), viszont szignifikansan gyorsabb (szoval legalabb 2-szer, hogy ne legyek nagyravagyo, mert amugy 5-10-szerest varnek el) amd apu-n, mint egy hasonlo aru sb-n?
Amugy cuda-s program egy nagysagrenddel tobb van, nem? Szoval akik csodalkoznanak, hogy lam az sb nem sok mindent gyorsit, azok amd apu-n is csodalkozni fognak, hogy nem sok mindent gyorsit. Ezt arra az ervedre mondom, hogy szerinted amd apu-ra nem csak elmeletben vannak programok, mert szerintem altalaban is alig van gpgpu-s felhasznaloi program, nemhogy opencl-re. Nyilvan a trend szerint opencl-re tobb lesz, de ugye szerinted az sb azert nem apu, mert nincs ra eleg gpgpu-s felhasznaloi program (akar egy sem, a pontos szamot nem tartom lenyegesnek), es ezert ha apunak hivnad, akkor a userek szomorkodnanak, hogy lam megsem gyorsitja a sok programot, bezzeg amd apu-ra van egy csomo...
Persze, egyetertek, hogy nem erdemes egy kalap ala venni oket, egy llanos gep 2012-ben nem szamit fellabunak, mint egy diszkret vga nelkuli sb-s gep. Csak azzal a reszevel nem ertek egyet, hogy ez az altala gyorsitott programokon mulik, ivy bridge eseten is fellabu lesz a gep, ha a gyengebb igp lesz benne, hiaba tud opencl-t, persze ezt csak tippelem, aztan majd meglatjuk, mit tud a valosagban. -
Jack@l
veterán
Na most akko megváltozott az érvelés és mégis GPGPU-ra találták ki az opencl-t?
SZóval a nagy helyzet, hogy optimalizálásra mint olyanra opencl kódban elég kevés a mód realtime dolgoknál lehet játszani speciálisan kártyára és unitokra elosztani a párhuzamosítást, de! általában a kernelek az összes uniton futnak, ha az egyik kész, a queue-ból fogja a következő "szálat" és megcsinálja. Magyarul ha több szabad unitpd van több szálon dolgozik. Processsszornál is ugyanez a helyzet, ott kevesebb unit van ezért lassabb is, optimalizálást mint olyat javarészt max az opencl driverbe csinál a gyártó.
Nem, nem lassabb egyáltalán mint a natív kód(legalábbis amit eddig én láttam) sőt pl. LuxRenderbe(vagy LuxMark) gyorsabb is only cpu-n az opencl kód mint a natív cpu-val futtatva.
dGPU-nak az opencl-hez van köze, mert van aki arra játszik hogy gyorsan tudjon futtatni kódokat, és nem arra hogy APU-ja legyen.
Nagy jelentősége van az opencl-nek és a cuda-nak is, csak jelenleg még mindig gyerekcipőbe jár az elterjedtsége, főleg a közemberek körében.A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
zoltanz
nagyúr
Cuda fordítója nyilt viszont.
Az eddig megjelent driver verziókkal hibátlanúl működik is, kérdés, hogy nyitottak maradnak-e az új kidások és, hogy megfelelő irányba fejlesztik é tovább, valamint hibátlanúl is (ezekre sajna nincs ráhatása másnak).[ Szerkesztve ]
Manapság egy előnye van ha nem vagy szegény, színvonalasabb ellenségeid lehetnek
-
zoltanz
nagyúr
-
zoltanz
nagyúr
Viszont sztem a Cuda-t ehhez már nem kell fejleszteni, max vas kell neki.
A Cuda -hoz van telepítési útmutató MPC-hoz, magyar nyelven, és pofon egyszerű Win-el. (Valamint lehet kombinálni őket, DXVA -val megy a lejátszás és amire már nincs kapacítás azt Cuda-n keresztűl számolja)[ Szerkesztve ]
Manapság egy előnye van ha nem vagy szegény, színvonalasabb ellenségeid lehetnek
-
lenox
veterán
A szerkesztes alatt az effekteket, pluginokat erted? Ebbol amugy nem nagyon derul ki, hogy mennyire van ertelme, ugy ertem mekkora sebesseget lehet nyerni azzal, hogy ezek opencl-ben vannak. Csak mert eleg sok kepfeldolgozasi eljarashoz fontos a bandwidth, amibol apunal opencl-ben is ugyanannyi van, mint a cpu-nak, szoval kerdeses a gyorsitas merteke. Nade vegul is mindegy, az erveket elmondtuk.
Szerintem Brook-kal, ctm-mel, streammel egyutt is sokkal tobb cudas program van. Es osszesen is alig van felhasznaloi, ami nem erdekesseg, vagy nem transzkodolas. Ezt is kiveseztuk szerintem.
Ha a tudast nezem, tehat nem a sebesseget vagy az elerheto felhasznaloi programok szamat, akkor az sb-t az amd apuktol az opencl/directcompute kulonbozteti meg. Szoval ha a tudast nezem, muszaj a definicioba bevenni, hogy milyen technologiat kell tamogatni, mert meg veletlenul az sb is apu lesz.
Amugy a videok valos ideju felskalazasahoz minek opencl? Egyreszt shaderrel is megy, es akkor nem kell az opencl es a directx vagy opengl kozott interopolni, masreszt szokott lenni fix funkcios hardver ra, gondolom amd-nel is van. -
lenox
veterán
Probaltad a legujabb intelt? En meg nem, de az biztos, hogy nagy unnepelve kuldtek rola emailt egy par hete, hogy van szuper uj verzio, es most mar sokkal jobb.
Masik erdekesseg, hogy macen tobb kod is joval gyorsabb volt, mint windowson valamiert. Meg egy erdekesseg, mac-en quadro 4000-re nincs opencl driver. Kb. az egyetlen kombinacio, hogy mai vga-val nem megy az opencl. -
lenox
veterán
A felskálázáshoz gyorsabb algoritmus írható OpenCL-ben és DirectCompute 5.0-ban.
Miert is?
A képminőség javítására senki sem használ fix funkciós hardver.
Annyira nem kovetem, de ez a purevideo vagy purevideo hd-nak resze, nem? Szoval a legtobb szoftver tudna hasznalni, ami hasznal purevideot, az volt a benyomasom, hogy hasznalja is. Amugy annak idejen csesztettem is az nvidiat, hogy adjanak sdk-t hozza, hogy purevideon kivul is lehessen hasznalni, de nagyon huztak a szajukat, es vegul mast csinaltak, cserebe errol meg le kellett mondani. Mondjuk azota eleg sokat nott a gpu teljesitmeny, szoval mar nem erdekes, de pl. egy 8400 szintjen erdekes lehetett volna.
Az csak dekódolásra, illetve a deinterlace-re van
Meg pl. noise reduction-re.
-
lenox
veterán
Nade egy mitchell vagy lanczos filteres felnagyitasban egy gyengebb kartyan vagy egy apun gondolnam, hogy ugyis a bandwidth lenne a bottleneck, nem az, hogy az lds-bol gyorsabban jon-e az adat, mint a texture cache-bol, szoval nem lennek benne biztos, hogy ebben az esetben szamitana.
Nekem az nvidia elmondasa alapjan fix funkcios hardver remlik a scalingre, meg a purevideo oldalan is azt latom, hogy azt meg a leggagyibb is tudja (pl. nv 6200), szoval szerintem az nem shaderes.
-
lenox
veterán
Szerencsére nem. Elég jól elvan például a SimHD egy Brazos-on, vagy egy kisebb minimalisztikus GPU-n. Pedig az algoritmus ugyanaz.
Mi az, ami szerencsere nem? Nem a bandwidth a bottleneck? Hanem mi? Marmint ha a szamitasi teljesitmeny mindegy, abbol mi kovetkezik, hogy mi a bottleneck?
-
lenox
veterán
Egy HD kep 2 millio pixel, 24 fps-sel az kb. 50 millio pixel masodpercenkent. 200 MHz-en a Brazos 80 stream procija pixelenkent 320 muveletet tud vegezni. Egy jofele lanczos scaling ebbol egy parszor kijon, szoval nem hinnem, hogy ettol akadna, vagy akkor valami nem mukodik optimalisan.
-
-
Jack@l
veterán
Itt azért szó nincs erről, elvileg holnap már lehet is értemenni, én csak örülök ennek. Sőt sztem a -végre rendes procira vágyóknak- is jobb ez hogy előbb (időben) kikerültek, csak járjon erre még több kamion is.
Gyártással úgytom nincs gondjuk, csak az a fránya pénzsóvárság ami visszatartja a kiadást.A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
Új hozzászólás Aktív témák
- Poco X6 Pro - ötös alá
- Battlefield 2042
- A pápa egyre jobban tart a romlott AI veszélyeitől
- Renault, Dacia topik
- OLED TV topic
- Formula-1
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Micro Four Thirds
- HiFi műszaki szemmel - sztereó hangrendszerek
- 15 éves az első androidos Samsung telefon
- További aktív témák...