- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Két Zen 5-ös dizájnjának mintáit is szállítja már az AMD
- A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
- OLED TV topic
- HiFi műszaki szemmel - sztereó hangrendszerek
- Kormányok / autós szimulátorok topicja
- E-book olvasók
- Vezeték nélküli fülhallgatók
- Apple notebookok
- Milyen processzort vegyek?
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- TCL LCD és LED TV-k
Hirdetés
-
Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
ph Megkezdődött az NPU-k elleni hadjárat, de egy fontos részletet nem említ a cég.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Az üzleti chatbot lehet az új fejőstehén
it Üzleti chatbotot indított az Anthropic, azt reméli, hogy sok pénz folyik majd be a cégektől.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Atom_Anti
#24
üzenetére
Mert egy heterogén módon programozható lapka lesz az Ivy Bridge, pont olyan, amilyen az AMD-nél a Zacate/Desna/Ontario, vagy a Llano, illetve az érkező APU-k. Kell valami egységes jelzés, mert ezek már nem egyszerű processzorok, hiszen az IGP OpenCL-lel, DirecCompute 5.0-val, vagy C++ AMP-vel aktívan befogható általános számításra. Az Intel egyelőre nem jelzi ezt külön, míg az AMD igen, és ezt jelenti az APU jelzés. Mivel ez már nagyon elterjedt, ezért egyszerűbb az APU-t leírni, mint több mondatban ecsetelni, hogy az Ivy Bridge már azt a koncepciót követi, amit az AMD az elmúlt évben elkezdett az integrációval. Hívhatjuk felőlem máshogy is, de legyen valami egységes jelzés, amivel tudod, hogy a termék programozható-e heterogén módon vagy sem.
Az APU egyébként már kezd általános elnevezéssé válni. Erről már tudja a többség, hogy mit takar, így nem kell több mondatban részletezni, hogy nem hagyományos processzorról van szó.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Technikailag az AMD kezdte az APU-t mint elnevezést. Igazából nincs levédetve, csak ugye különbséget akartak tenni a heterogén módon programozható processzorok és a homogén többmagos processzorok között. Lényegében az AMD találta ki az APU-t, mint elnevezést, ahogy a GPU-t például az NV találta ki. Idővel ezek általánossá vállnak, mert jóval egyszerűbb ráírni, hogy APU, mint magyarázni, hogy nem olyan processzor ez, mint a korábbi fejlesztések.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Atom_Anti
#33
üzenetére
Az A betű az APU-ban nem AMD-t jelent, hanem az Accelerated rövidítése.
Igazából pont az a lényeg, hogy közös legyen a jellemzés, mert mindkét rendszer ugyanolyan elvi felépítést alkalmaz, vagyis jellemezhető egy kategória alatt. Az APU itt a legelterjedtebb fogalom, és úgy gondolom, hogy már az is marad, hiszen az Intel nem szeretne bevezetni saját meghatározást. Ha hozok be egy minden szempontból definiálatlan jelölést, mint mondjuk az IPU, akkor pont a célt nem érem el, vagyis azt, hogy az olvasó megértse, hogy miről van szó. Az APU-t már sokan értik, hiszen nagyon sokszor írtunk a mögötte álló elvről.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyszer jelezték HPU-nak egy technikai doksiban. Utána semmi. Valószínűleg a marketinges részleg elvetette a HPU-t. Egy technikai doksi ebből a szempontból más. Az nem a médiának készül, hanem a partnereknek, akik úgy is látják, hogy mi történik. A médiában kétséges egy ilyet felvállalni, mert az jelezné, hogy az Ivy Bridge elvi szinten az AMD-t elképzelései után megy. Nyilván egy hozzáértőnek ez egyértelmű, de az embereknek nem, és ez az Intel számára most jó. Szimpla marketing és stratégia az egész, amivel mi úgy sem foglalkozunk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
A Sandy Bridge eleve nem APU, mert nem támogatja az IGP az OpenCL-t, a DirectCompute 5.0-t és a C++ AMP-t. Az Intel első APU-ja az Ivy Bridge lesz. A Sandy Bridge szimpla processzor IGP-vel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A GPGPU természetesen azóta létezik amióta shaderek vannak. De azért az nagyon ritka, hogy egy grafikus API-n keresztül általános számításra kihegyezett program fusson. 5-7 éve nem volt más lehetőség, így nyilván a kísérletező kedvű, úgymond kalandor programozók próbáltak trükközni, de abszolút nem általános dolog, mivel piszkosul nehéz így programozni. Igazi felhasználói alkalmazás nem is született. Az áttörést a tényleges GPGPU-s felületek hozták (OpenCL, DirectCompute 5.0, stb.). Ez már vállalható alternatívát képez, hiszen olyan szintre emelte a GPGPU-t, hogy nem csak a kalandor programozóknak számított kísérletnek. A multimédiás programok fejlesztői rá is repültek ezekre.
Jelenleg ennyit lehet elérni. Nyilván kell egy következő lépcső, ami még egyszerűbb programozhatóságot tesz lehetővé a tömegek számára. Ezen dolgoznak a cégek.Az APU-t én úgy definiálom, hogy egy olyan lapka, melyet heterogén módon lehet programozni. A kalandor programozókat ide nem veszem bele, mert az szimpla kísérletezés volt, aminek a felhasználói programok oldalán nincs igazi eredménye. Régen jó volt, ma már van jól működő alternatíva.
Az APU-t az AMD elég sajátosan értelmezi. Maga az Accelerated szó arra utal náluk, hogy valahogy gyorsítja az alkalmazást. Ezzel az AMD-nél az UVD motor használata is ide számít például. A FAD-on ismertették, hogy 200+ program használja már a rendszer valamely elemét gyorsításra. Én nem akarom ennyire sajátosan értelmezni. Egy cég megengedheti magának, sőt elvárható, hiszen az a jó, ha sok programot tudnak felmutatni. Nekem szerencsére nem kell ezzel törődnöm, így úgy értelmezhetem az APU-t, ahogy az valóban célszerű és lényeges.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pont azt írtam, hogy az UVD nekem nem számít ide. A gyártónak számít, de a PH-nak nem.
Az APU egy heterogén módon programozható processzor. A tudományos cikkekkel pedig a felhasználó nem sokra megy. 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. Az Ivy Bridge-ét már használni lehet.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Abu85
HÁZIGAZDA
Nem a CUDA miatt szar az encode minősége. A driverrel érkező enkódoló gyenge, a Mainconcept enkódolója például jó. Persze az nem is olyan gyors. De a lényeg, hogy nem a CUDA a szar, hanem az algoritmus.
(#153) zoltanz: Az OpenCL-nek is mindegy. Egyébként a DXVA-nak is. Az is egy fejleszthető API.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A legtöbb szerkesztőt nem próbáltam ki, de a Sony Vegasban az effektek renderelése van gyorsítva. A HD 5850 nálam 7x gyorsabban végzett a feladattal mint a Q9550. APU-t nem tudtam kipróbálni. Abból az AMD-től vannak mérések. App gyorsítással a Sony Vegas Pro 11 kétszer-háromszor gyorsabbak dolgozik függően az effekttől. Ezt egy Llano A8-3850-en 1866-os RAM-mal.
A felhasználói programok nagyon nagy többsége már OpenCL-re, vagy DirectCompute-ra váltott. A zárt felületek főleg olyan programoknak maradtak meg, amelyek nem éppen az átlagfelhasználóknak készültek. Annyi, hogy a felhasználói programoknál a CUDA, mint alternatíva megmaradt, de ez csak ideiglenes. Például az Arcsoft a következő körben már több programból kiveszi ennek a támogatását, és csak az OpenCL-re szavaznak. Erről már kérdeztem őket, és azt mondták, hogy egyszerűbb egy mindenki által támogatott felületre koncentrálni, mintsem megosztani az erőforrásokat. A dolog logikus a felhasználónak mindegy, hogy mivel gyorsít csak gyorsítson, és legyen jó az eredmény.
Pont a lényeg maradt ki az SB-ből, de ezt már korábban elmondtam. Te pontosan tudod, hogy hogyan működik az egész, de egy átlagfelhasználó csak lesi, hogy nincs gyorsítás SB-n, miközben le-APU-zzuk.
A felskálázáshoz gyorsabb algoritmus írható OpenCL-ben és DirectCompute 5.0-ban. A PowerDVD például DirectCpmpute 5.0-ra szavazott. Nem kötelező tehát az OpenCL. Valószínű, hogy az ArcSoft azért döntött az OpenCL mellett, mert így azok a VGA-k is felskálázhatnak, amelyek nem DX11-esek.
A képminőség javítására senki sem használ fix funkciós hardver. Az csak dekódolásra, illetve a deinterlace-re van (illetve újabban az enkódolásra is van kiegészítés). A képjavítást mindenki shaderekkel végzi, mármint amit a driverbe építenek funkciókat. Ezeket nyilván a fejlesztők kiválthatják egyéni megoldásokkal, mint a SimHD az Arcsoftnál.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mindig felrakom a legújabbat. A fő baj az, hogy régi a procim. Az Intel támogatása főleg az SB-re irányul. Ott egyébként valóban sokkal jobb, de én ezzel nem vagyok kisegítve a Q9550-en. Nekem jobb alternatíva így az AMD drivere.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Például ott a DirectCompute-ban az LDS. Ezzel a post-process effektek feldolgozás erősen felgyorsítható. Egy nagyobb VGA nyilván elbánna mindennel, de egy IGP már nem. Ezeknek az új API-k jelentik a sebességet.
A Purevideo az olyan, mint az UVD. Szimpla dekódolómotor. A képminőség javítása a shaderekből jön. Ezért vannak eltérő HQV 2.0 eredményei a különböző sebességű termékeknek. A Purevideo ugyanaz bennük, de a shaderes post-process már nem, mert egy kisebb GPU nem biztos, hogy elbírja. Ezt a gyártók driverben szabályozzák. Persze, ahogy láttam az NV és az AMD ezt felülbírálhatóvá teszi. Adnak egy alapértelmezett beállítást, amit úgy finomhangolsz, ahogy akarsz.
Igen a noise reduction is a része. Ennél viszont sokkal több van egy driverben. A Catalyst-ben például van: Smooth Video Playback, Dynamic Contrast, De-blocking, Mosquito Noise Reduction, De-noise, Edge-enhancment és Steady Video. Ezek mind shaderrel dolgozó eljárások. Hasonlóak vannak az Intel és az NVIDIA driverében is. Nem mind és nem ilyen néven, de a céljuk ugyanaz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
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.
A dekódolóhardver az nem sokat tud ebből a szempontból (de ez általános dolog). Ezt az egészet a Purevideo HD teszi teljessé a hozzá kapcsolódó minőségi post-processekkel. Ettől nem lesz teljesen fix funkciós a képjavítás. Egy része az, de jó része shaderes. Az persze igaz, hogy az NVIDIA nem kínál annyi beállítást a driverben, de ez nem a hardver miatt van. Ugyanazokat be tudnák építeni, amiket az AMD használ, és akkor jobb lenne a GeForce-ok HQV HD 2.0 eredménye is. Ezt csak el kell dönteni, hogy rágyúrnak-e erre a területre. Egyelőre nem érdeklő őket. Elégedettek a kínált minőséggel. Az Intelt így is verik.
Alapvetően ez a fő cél, hogy bekerüljenek az Intel IGP-s notikba. Az AMD ellen felesleges menni, mert még ha egy csomó munka árán el is kapnák a Radeonokat képminőségben, akkor sem sanszos, hogy a Dual Graphics helyett a gyártók GeForce-ot válasszanak.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A számítási teljesítmény az nem mindegy. Ha 200 MHz alá viszed a Brazos IGP órajelét, akkor már akadozgat. Ilyen Brazos nincs, mert 275 MHz a minimum, de mesterségesen ezt le lehet vinni 150-re. A bandwith az elég neki, már amit a mai mobil memóriák kínálnak ... DDR3 1066 MHz 64 biten.
Sajnos ezen a szinten túl nagy összehasonlítási alap nincs. Az Atom buta, míg az Iont nem gyártják már. De az Ion 1-gyel nem volt gond, amikor teszteltük.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem csak scalingot csinál a SimHD. Egy komplexebb szolgáltatás ez, összesen négy különböző egymáshoz szabott post-processzel. Ezek közül kettő kötelezően fut, míg kettő terméktől függően inaktív. Az AMD-nél például a driverből vett eljárást részesíti előnyben a program.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
zoleeno1
#173
üzenetére
Szokásos kínai szivárgás. Rengeteg ES termék van közkézen, párat becsomagolnak, és már kész is. Rendszerint Kínánál nem jut tovább, de most megtörtént. Majd az Intel elrendezi.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez nem egyedi esett. Korábban írtunk is erről, hogy történnek ilyenek. Ennél durvábbak is. Valaki felrakja az ES-t az eBay-re, és eladja egy rakás pénzért. Nehéz ezt kontrollálni, de majd az Intel elintézi, az ő bajuk ez nem a miénk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
zoleeno1
#179
üzenetére
Becsomagolt Ivy Bridge-et. Valszeg ezek már kiadásra jelölt verziók, legalábbis meglepne, ha nem azok lennének. A termékkel tudtommal nincs gond a gyártástechnológia felfuttatása halad lassabban a vártnál. Ez több selejtarányt eredményez. Nem nagy gond, de annyira elég, hogy csússzon egy picit a start. Azt tartom valószínűnek még, hogy ez nem jutott el mindenkihez, és elkezdték forgalmazni a már kész termékeket. Az eredeti start március vége, vagyis már küldözgetni kellene a holmikat az egyes országokba. Akik pedig kaptak értesítést, azok lelőtték a kiszállítást.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ennek az Intel nem örül, hogy idő előtt kikerült pár termék. Eleve a mai napon van az Ivy rendezvénye, ahol bemutatják, és elmondják, hogy mi mikor startol, de ez a cikkben már le van írva (Jim dátumai jók. Több gyártó is megerősítette.). A hivatalos NDA is később jár le.
David Kanter már mondta, hogy a gyártással van gond. Ezért jelentették be hivatalosan is a csúszást. Ez nem meglepő. Új gyártástechnológiánál nem mindig úgy alakul a felfuttatás, ahogy azt eredetileg várják. Az Intel is meghatározott egy minimum kihozatalt, ami mellett úgy gondolják, hogy ki tudják szolgálni az igényeket.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Persze az a lényeg, hogy a lehetőség megvan. 
Új hozzászólás Aktív témák
ph Sean Maloney megerősítette, hogy nyolc-tíz hetes csúszás várható az elemzők által prognosztizált áprilisi megjelenéshez képest.
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Luck Dragon: Asszociációs játék. :)
- A fociról könnyedén, egy baráti társaságban
- NBA és kosárlabda topic
- OLED TV topic
- HiFi műszaki szemmel - sztereó hangrendszerek
- Renault, Dacia topik
- Eredeti játékok OFF topik
- Fotók, videók mobillal
- Suzuki topik
- További aktív témák...
