- Microsoft Excel topic
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Proxmox VE
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- Milyen routert?
- Letartóztatták a bitcoin-Jézust
- ASUS routerek
- Facebook és Messenger
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Az AMD definíciója szerint az UVD önmagában APU-vá teszi a rendszert. Nekik ez jó, de nekem szerencsére nem kell a marketingtrükköket követnem.
Az alig abból a szempontból érdekes, hogy hol lehet jelenleg a GPGPU-t kamatoztatni. A multimédiás programoknál biztos, és ezek nagyobb többsége támogatja is a GPGPU-t. Ahol nincs előnye még a GPGPU-nak ott még nem lesz program, de idén már lesz OpenCL-es WinZip is, tehát haladunk.
Szerintem maradjunk a földön és lássuk be, hogy az OpenGL shaderei nem éppen úgy vannak alakítva, hogy általánosan lehessen programozni az SB IGP-jét, pláne, hogy a GLSL verzió leragadt 1.40-nél. De majd meglátjuk, hogy írnak-e hozzá fájltömörítőt OpenGL-ben programozva. Ha megjelenik egyszer, akkor írok egy cikket, hogy tévedtem, és az SB mégis APU.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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. -
dezz
nagyúr
"Le van tiltva = nincs benne."
A sarki fűszeres számára bizonyára... Nekünk ez nem egyenlő, hiszen ott van a lapkán, csak le van tiltva, nem használható.
(#100) lenox: "A gpgpu-s programokat foleg nem a consumer piacra szanjak, igy alig van a consumer piacon gpgpu-s program."
Jelenleg! De az OpenCL/stb. képes cuccok elterjedése (amiben jelentős szerep jut majd az Ivy Bridge-nek is) megnyitja az utat a szélesebb körű consumer piaci alkalmazás előtt.
Egyébként, az elmélkedés helyett, inkább ki jellene próbálni néhány shaderes GPGPU kódot, fut-e egyátalán SB-n...
-
Abu85
HÁZIGAZDA
Lényegében nagyon kicsi esélyét látom annak, hogy lesz valaha, mondjuk olyan fájltömörítő, melynek OpenGL-ben lesz írva a GPGPU-s kódja. Ezt az API-t nagyon nem erre találták ki. Ez olyan dolog, hogy írhatsz egy szoftver rendert a CPU-ra, és ellátja azt a munkát amit a GPU. De ettől GPU lesz? Én nem hiszem. A lehetőség még nem tesz alkalmassá egy terméket az adott feladatkörre.
Az SB-re kétlem, hogy bármi normális születhet OpenGL-ben. Szegénykémnek olyan gyenge az OpenGL támogatása, hogy még a grafikai programokkal is baja van, pedig azok nem éppen egzotikus igények szerint születnek. A hardver technikailag megfelel az OpenGL 3.3-nak és támogathatná a GLSL 3.30-at is. A gond az, hogy az Intel nem lája értelmét. Ezért van csak OpenGL 3.1-es driver GLSL 1.40 támogatással. Túl kevés OpenGL-es játék születik, így ezzel a felülettel a cég annyira nem törődik.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
-
Abu85
HÁZIGAZDA
Nem fogadom el az AMD definícióját. A szememben egy UVD motor nem tesz egy rendszert APU-vá. Jó dolog, hogy benne van, de ez egy fix funkciós egység, ami nagyon jó egy dologra, de semmi másra nem, persze nincs is több elvárva tőle. Az APU-t lehessen heterogén módon programozni, de ne csak poénból írjanak rá programot. Erre jó az OpenCL és majd a C++ AMP, ami ugye a DirectCompute 5.0-ra épül. 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. A fájltömörítés csak egy példa, mert azt is lehet, de nincs értelme, mert az OpenGL API-t nem erre fejlesztették. Olyan limitációk vannak benne, amik brutálisan megnehezítik a munkát. Egy fejlesztő inkább használ OpenCL-t, vagy később C++ AMP-t. Ezek sem ultimate megoldások, de nagyságrendekkel kevesebb problémába fog ütközni például egy GPGPU-s fájltömörítő fejlesztése.
Az Intel az OpenCL-t eléggé tolja, későn kezdtek neki, de erősen fejlesztik. Nekik ez a felület a közhiedelemmel ellentétben nem rossz. Elég szép tanulmányokat írnak rá, hogy hol lehetne hasznosítani. Például engem nagyon meggyőzött az auralizácóval kapcsolatos ötlet, ami tényleg nagyon hasznos, hiszen beszélünk itt a jobbnál-jobb grafikáról, de a hang méltatlanul kevés figyelmet kap. Pedig eléggé fontos tényező. Az Intel az értékes felületeket támogatja. Az OpenGL csak azért van félvállról kezelve, mert kevés a lényegi értelme. Ezen persze lehet vitázni, de tény, hogy a PC-s játékok nagyon nagy többsége DX-et használ. Persze nem tagadom, hogy egy vállalatnak nem úgy kellene hozzáállni a témához, hogy ha valami nem elég elterjedt, vagy van rá jóval jobban kihasznált alternatíva, akkor arra a support is visszafogott.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
stratova
veterán
Már nem mai hír, de nem láttam még itt. Tudom extrém tuning, de miért ne
i7-3770K 7 GHz-en -
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.
-
Abu85
HÁZIGAZDA
Nem, az AMD-t sosem idéztem, mert ők egy cég. Tudom, hogy nekik van egy definíciójuk az APU-ra, de azt szándékosan úgy alakítják ki, hogy a saját termékekre illeszkedjen. Ez engem nem érdekel, mivel marketing az egész, és hagy ne vegyem át.
Akkor nem tekinted definíciónak. Köszönöm, hogy megosztottad velem. Azt kötve hiszem, hogy az industry standard definíció az OpenGL-t GPGPU-s felületnek tekinti. Tudtommal maga a Khronos is grafikus API-ként fejleszti. Egyébként hívhatod az SB-t is APU-nak, csak te megérted, hogy a rendszernek milyen technológiai korlátjai vannak a Llanóhoz, a Brazos platforhoz, az Ivy Bridge-hez, meg a Trinity-hez és még jó ég tudja, hogy a jövőben milyen lapkához képest. Egy felhasználó viszont lesni fog, hogy az APU ott van a médiában, mint olyan fogalom, ami gyorsítást jelent a GPGPU-s alkalmazásokban, de a megvásárolt SB-n már nem fut az IGP-n a vReveal MotionDSP, a Sony Vegas Pro, az ArcSoft Panorama Maker Pro, a Corel VideoStudio Pro, az eyeon Fusion, az ArcSoft TotalMedia Theatre, a Corel WinDVD, az ArcSoft ShowBiz, a Corel Digital Studio, a Cyberlink PowerDirector, a Sony Vegas Movie Studio HD, az ArcSoft MediaConverter, a Viewdle Uploader, az ArcSoft Webcam Companion, a Windows 7 drag&drop transcodere, a Cyberlink MediaEspresso, a Cyberlink PowerDVD, a Cyberlink MediaShow és nincs kedven folytatni.
Na most akkor melyik a jó? Elmondani az olvasónak, hogy az SB csak akkor programozható általánosan, ha a programozók egy grafikus API-t hackelnek úgy, hogy valamennyire működjön az egész, de erre nincs tényleges program, vagy egyszerűen látva a hihetetlenül kevés OpenGL-re írt GPGPU-s programot (hirtelen nem tudok mondani egyet sem, de lehet, hogy ha keresek egy óráig a neten, akkor találok egy fingást szimuláló sample-t) ... egyszerűen megelőzni a sok kérdést, hogy miért nem futnak az SB-n a fenti GPGPU-s alkalmazások.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
-
Abu85
HÁZIGAZDA
Inkább annak tekintem, különösen a poén rész miatt, mivel ha nem húznám meg ezt a határvonalat, akkor az olvasók jogosan érthetnék félre az APU lényegét, és jönnének a kérdéseket, hogy az SB-n - amellett, hogy APU-t csináltunk belőle - meg sem nyikkannak a GPGPU-s kódot tartalmazó felhasználói programok.
Ahogy te is leírtad az SB IGP-je buta mint a tök. Innentől kezdve ez egy óriási kavarás, amit te átlátsz, de egy átlag user már nem. Ők összekötik az APU-t azzal, hogy gyorsíthatja a fentebb leírt programokat. Az SB-re ez nem igaz, ezért nem lesz APU. Emellett az OpenGL támogatásról már ecseteltem a lényegi részt. Az az SB-n formálisan létező dolog. Valszeg ez az új Intel IGP-kkel sem változik meg, egyszerűen az Intel nem látja a jelentőségét. Én a technikai oldalról ezzel nem értek egyet, de az tényleg tény, hogy alig van OpenGL-t használó játék. Stratégiailag az Intelnek nem éri meg belekezdeni az OpenGL drivert jelentősen felzárkóztató fejlesztésekbe, vagy akár a teljes újraírásba. Olyan amilyen és kész, foltozgatják, hogy legalább az a kevés játék fusson, de többet nem adnak hozzá.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
staccato
tag
na ez most nem jó hir.
üdv
-
Jack@l
veterán
GLSL
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ó.
-
Abu85
HÁZIGAZDA
Repkednek a GLSL-ek, de felhasználói programot még nem láttunk. Persze az a lényeg, hogy a lehetőség megvan.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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ó.
-
Abu85
HÁZIGAZDA
Pedig, ha megfigyeled, akkor a Llano érkezésével lódult meg a szekér. Előtte nem volt sok program, de egy év alatt ezek száma a többszörösére nőtt. Most úgy 50-nél tartunk. Az OpenCL esetében még a Library-k hiánya a fő probléma, de erre lesz (illetve technikailag már van) az AML, ami megkönnyíti a médiaalkalmazások fejlesztését OpenCL-re. Amit még meg kell oldani, az a memóriára vonatkozik. Sajnos a GPU nem éri el a CPU memóriáját, és ez heterogén módon való programozás mellett egy erős korlátozás. Majd a jövőben érkező APU-k segítenek. A Trinity már vezet be erre egy alternatívát, de a tényleges megoldást a Kaveri hordozza, amikor a CPU és a GPU teljesen koherens memóriát oszt meg. Tudtommal az NV Maxwell is ugyanilyen lesz. Az Intelnél valszeg a Larrabee integrációja jelenti majd ezt a lépcsőt.
Pedig van felhasználási terület. Az említetteken kívül a legfontosabb, amit meg szoktak jegyezni a NUI. A Kinect például azért nem elég pontos, mert sok limitációt köt meg, a számítási teljesítmény érdekében. A GPU-nál kevés dolog alkalmasabb arra, hogy a képet elemezze, és kalkuláljon belőle, vagyis ez egy fontos fejlesztési irányzat. Az MS persze valószíni, hogy nem az OpenCL-t, hanem a C++ AMP-t fogja erre használni.
Nézd attól, hogy az Intel tolja auralizációt még lehet értékelhető fejlődési ágazat. Valóban nincs sok tapasztalatuk az OpenCL-ben, de látszik, hogy nagyon erősen ráfeküdtek. Nekik is fontos ez, mert ők sem tudják már skálázni a homogén többmagos processzorokat, ennek fizikai határai vannak. Egyelőre az OpenCL az egyetlen értékelhető alternatíva, amivel előre lehet lépni. Esetleg majd a C++ AMP, és tudtommal azt is erősen támogatják. Legalábbis az Ivy RC driverében már benne van az előzetes támogatás. Majd lesz végleges, ha kész lesz a felület.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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ó.
-
Abu85
HÁZIGAZDA
Felőlem nézhetjük. Bár furcsa, hogy ennyi véletlen van.
Persze, hogy ugyanazok a korlátjai, de ez is skálázható lesz egy darabig. Mindig beleütközünk majd a fizika korlátjaiba. Az egymagos processzorok után nem volt kérdés, hogy a homogén többmagos processzorok ideje is lejár majd. Ellenben ha megnézed, akkor több évig a piacon voltak, vagyis éveket adtak a hardvergyártók kezébe a skálázásra. Ugyanez lesz a heterogén többmagos lapkáknál. Időt nyerünk, amíg nem lesz valami alternatív, és jobb gyártástechnológia a chipek számára. Elvileg egy tíz éves ciklust tudunk a heterogén árával nyerni, ami egyelőre elég jónak tűnik. Addigra azért csak lesz valami alternatíva a chipgyártásra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
lenox
veterán
Hat sajna ez annyit nem er. A quick sync-et kiprobaltam, meg az opencl-t is az intel fele sdk-val, de ennek mar semmi ertelme nincs, ugyhogy kihagyom.
En filmes/videos utomunka szoftverben illetve orvosi szimulacios szoftverben hasznaltam, de mint irtam, ha rakeresel a siggraph papperekre, akkor megtalalod, hogy milyen otletek voltak, aztan azokbol meg lehet keresni, hogy mi valosult meg.
#120: Szerintem neked tudnod kene, hogy ezt elsosorban nem is consumer kategoriaban kellene keresni.
[ Szerkesztve ]
-
lenox
veterán
Nyilvan nem, altalaban irtam az opengl shader alapu gpgpu-ra. Lehet, amugy, hogy van olyan, ami sb-n is elfut, de a keresesere sajnalnam az idomet elpazarolni. Persze attol, hogy senki nem vallalta be 10 dollaros gpgpu szoftver irasat sb-re, attol meg elvi lehetoseg van ra, szoval egy definicional erre figyelni kell.
Amugy az vicces, hogy az Abu altal sorolt programok nagy reszet ugyan az sb opencl-lel nem gyorsitja, de quick sync-kel igen, szoval a Fusionnel egyutt azert ezt ongolnak tekintem. -
Abu85
HÁZIGAZDA
Maradjunk annyiban, hogy a felsorolt programok közül a QSV-t a Corel Digital Studio, a Cyberlink PowerDirector, az ArcSoft MediaConverter és a Cyberlink MediaEspresso támogatja. Ez kis túlzással sem nagy rész. És mint mondtam. Ilyen alapon a DXVA-gyorsítás is APU-vá tesz egy processzort. Pont az a lényeg, hogy az APU-t úgy értelmezzük, hogy az IGP-jét a programok általános számításra használják. Ha mindent egy kalap alá veszünk, akkor a potenciális vásárlók nem tudják megkülönböztetni a modern rendszert a butától, aztán majd néznek, hogy miért nem fut az OpenCL-es program az IGP-n, vagy miért nem tudják gyorsítani IGP-vel a Windows 7 drag&drop transzkódolóját.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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ó.
-
Abu85
HÁZIGAZDA
Kötve hiszem, hogy bárki GPGPU-ra optimalizált OpenCL kódot futtat majd CPU-n. Nincs értelme. Akkor már ott a natív kód.
A dGPU-nak mi köze az APU-hoz?
A Windows 7 tartalmaz d&d transzkódolót. Ez egy beépített fícsör. A Catalystban egy másik van, illetve az csak egy legacy felület marad az AML megfelejésével és a VCE támogatásával.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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ó.
-
Abu85
HÁZIGAZDA
Egyszerűbb, ha a felsoroltak közül leírom, hogy mi mire használ GPU-t. vReveal MotionDSP (videoszerkesztés: képstabilizálás, minőségi felskálázás, stb.), a Sony Vegas Pro (videoszerkesztés, transzkódolás), az ArcSoft Panorama Maker Pro (képszerkesztés, panoráma funkciók), a Corel VideoStudio Pro (videoszerkesztés, transzkódolás), az eyeon Fusion (képszerkesztés), az ArcSoft TotalMedia Theatre (videók valós idejű felskálázása), a Corel WinDVD (videók valós idejű felskálázása), az ArcSoft ShowBiz (videoszerkesztés, transzkódolás), a Corel Digital Studio (videoszerkesztés, transzkódolás), a Cyberlink PowerDirector (videoszerkesztés, transzkódolás), a Sony Vegas Movie Studio HD (videoszerkesztés, transzkódolás), az ArcSoft MediaConverter (videotranszkódolás), a Viewdle Uploader (arcfelismerés, és eszerint keresés), az ArcSoft Webcam Companion (beérkező anyag valós idejű felskálázása), a Windows 7 drag&drop transcodere (videotranszkódolás), a Cyberlink MediaEspresso (videotranszkódolás), a Cyberlink PowerDVD (videók valós idejű felskálázása), a Cyberlink MediaShow (videoszerkesztés: képstabilizálás, minőségi felskálázás, illetve arcfelismerési szolgáltatások).
Ha a CUDA-t bevesszük, akkor bevehető a Brook és a CTM is. Ezt az AMD már nem fejleszti, mert belátták, hogy ugyanaz lesz a vége ennek a harcnak mint korábban. A gyártófüggetlen szabványok kivégzik a zártakat. Ettől függetlenül az eddig elkészített támogatás megmaradt. Erre most hirtelen 30+ programot fel lehet sorolni. Ezek zöme sajnos nem teljesen a felhasználókat célozza, de akad kivétel is, mint mondjuk a Shogun 2, ami ha egy AMD APU van a gépben, akkor az AI számítását az IGP-n végzi (CTM-en keresztül). Ehhez persze feltétel, hogy ne legyen dGPU az APU mellett.
A tudást nézd. A sebesség másodlagos. Arra majd a tesztek választ adnak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az OpenCL lehetővé teszi a heterogén módon való programozást, ha nem GPGPU-ra találták volna ki, akkor ennek aligha lenne értelme.
A sebesség sokban függ a drivertől. Nekem fent van a procimhoz Intel és AMD driver is telepítve, de rendszerint az AMD-ét használóm, mert az Intel drivere lassabb. Mondjuk az én procim régi, így kevesebb optimalizálást kaphat. A luxrendert nem nézem. Én a felhasználók számára hasznos programokban hiszek.
Az elterjedtség nem is változik meg, amíg a programozást nem könnyítik meg. Erre már vannak elképzelések. A gyártók virtuális ISA-val szeretnének dolgozni. Ez egyszerűsíti a programozást, cserébe viszont a hardveres támogatás platformszintűvé válik.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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
-
Abu85
HÁZIGAZDA
Az lényegében semmi. Az NVIDIA próbálja életben tartani, de a gyártóknak nem az kell, hogy nyílt legyen, hanem, hogy a fejlesztést egy gyártófüggetlen szerv végezze. Ez legyen akár a Khronos, vagy egy olyan megalakuló konzorcium, amibe bárki beléphet, és a fejlesztésbe mindenkinek ugyanannyi beleszólása legyen.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ha az a cél, hogy a gyártók beálljanak támogatni, akkor arra ilyen feltételek mellett semmi esély. Amíg az NV zárva fejleszt, addig ez annyit jelent, hogy ha kifejlesztik az új CUDA verziót, akkor csinálnak rá hardvert, és akkor hirtelen odaadják a többi gyártónak a specifikációkat, akik egy, vagy két év múlva tudnak reagálni rá egy konkrét hardverrel. Ilyen feltételek mellett úgy gondolkodnak a gyártók, hogy nem állnak be támogatni, és hagyják, ahogy az OpenCL és a C++ AMP megteszi a hatását.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
zoltanz
nagyúr
-
Zeratul
addikt
Miért érné meg a Cudat támogatni? PC platformon ott az AMD és lassan Intel is a saját APUjával ami OpenCL, C++ AMP, WebCL/GL stb vele párhuzamosan az ARM fronton gyártók mindegyike felnőtt már az nV mellé saját SoCjával, az AMD meg várható ide. Egyszerűen nem éri meg fejleszteni egy gyártó platformjára amikor keresztplatformra fejlesztve sokkal több gyártó termékére el tudod adni a szoftot.
-
Jack@l
veterán
A sebesség és könnyebb programozás miatt per pillanat, legalábbis az utóbbi 1-2 évben ez volt a jellemző.
@Abu: Kinek mi a hasznos, én egy unbiased render engine-t elég hasznosnak tartok...
(mellesleg ő az egyik legrégebb óta fejlesztett opencl-es renderelő)[ 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ó.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest