- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Milyen egeret válasszak?
- OLED TV topic
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Publikálta a Microsoft az MS-DOS 4.0 forráskódját
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Hogy is néznek ki a gépeink?
- Milyen cserélhető objektíves gépet?
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- Amlogic S905, S912 processzoros készülékek
- TCL LCD és LED TV-k
Hirdetés
-
Agyi chipes gyártóba fektetett a kriptocég
it A Tether 200 millió dollárt fektet a Blackrock Neurotech agyi chipes vállalatba.
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
-
Xbox Game Pass [2024] - A májusi lista
gp Az elkövetkező időszakban többek között megkapjuk a Kona II Brume című játékot.
Új hozzászólás Aktív témák
-
-
Abu85
HÁZIGAZDA
válasz
HeavyToys
#16
üzenetére
Igen. A felsorolt programok új verziói Fusion optimalizációt kaptak/kapnak. Ez bármilyen Fusion rendszerre igaz, akár az E-350-re is. Persze nem lesz olyan gyors, mint a Llano, de heterogén módban futnak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A felsorolt programok mind Fusion optimalizációt kapnak, így a leggyorsabb feldolgozáshoz kell nekik a CPU device. Ezt mutogatják éppen az AFDS-en, hogy mennyit gyorsít rajtuk a heterogén mód a csak GPU-s kódhoz képest.
Természetesen ahol nem érhető el a CPU-s OpenCL device ott is fut majd a program, csak nem heterogén módban.Lesz olyan OpenCL program is, ami csak GPU-s OpenCL. Például a vReveal MotionDSP 3 is kint van, csak az nincs benne az AMD listájában, mert nem heterogén módon dolgozik. Hivatalosan nem is volt róla bemutató, csak megjegyezték, hogy létezik, GPU-s OpenCL és kész. [link] - szimplán ennyi volt a lényeg, hogy a Llano az SB-nél sokkal gyorsabb. Semmi extra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27
Abu85
HÁZIGAZDA
huskydog17
#22
Abu85
HÁZIGAZDA
válasz
huskydog17
#22
üzenetére
A fő szempont az OpenCL driver. Ez általában a GPU-ra fontos. Ha van az adott programhoz jó OpenCL driver, akkor elméletben működnie kell. Nyilván Radeonra az AMD driverét használd, míg GeForce-ra az NV-ét. Ha nem működik, akkor az lehet attól, hogy a driver még nem támogatja azt a kiterjesztést, amit a program használ, vagy szimplán valami hiba van.
Egyes programokat már heterogén módon írnak, így a GPU mellett a CPU-n is fut. Ilyenkor olyan driver kell, ami támogatja a CPU-dat és a GPU-dat is egyszerre. Ha ez nem áll fenn, akkor a program nem fog heterogén módon futni. Minden működni fog, ha megfelelő a driver, de nem biztos, hogy a leggyorsabban.Le lehet tölteni külön. Ott van az individual fülön belül. Ara kell ügyelni, hogy a 11.5-ös OpenCL driver a 11.5-ös Catalysttel tesztelt. A mixelés korlátozottan lehetséges.
Pontosan úgy működik. A dekódolást a fix hardver csinálja, míg a többit a programozható rész.
A heterogén mód a rendezvényen a sebesség szempontjából volt kihangsúlyozva. A gyorsulás teljes mértékben az adott program függvénye. Például a ViVu termékei esetében számottevően jobb eredményre volt képes egy APU, mint egy GPU önállóan.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Cool. Akkor az AMD rosszul magyarázta, mert ők tuti azt mondták, hogy ez csak GPU-s OpenCL. Mindenesetre a fejlesztő hitelesebb forrás, csak tudják már, hogy mit fejlesztettek, így heterogén lesz ez is. Betettem a hírbe. Thx a linket.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igazából a dedikált GPU teljesen lényegtelenné vált. A gyártóknak a VGA beépítése olyan költséges, hogy hallani sem akarnak róla. Ezt az elmúlt héten az AMD is ecsetelte, hogy májusban globálisan 30%-kal kevesebb GPU-t adtak el, mint áprilisban. Erről hoztam is egy kínai piacon mért felmérést, ahol a visszaesés 40-45%. [link] ... nyilván az AMD adata globális, így más országokban lehet, hogy kisebb volt a csökkenés, és így reális is a 30%. Egyszerűen a gyártók hozzáállása gáz. Látják, hogy egy dedikált VGA-t beépítve kisebb a terméken a haszon, és ezt elég nagy problémának élik meg.
Mivel a PC is úgy alakul, hogy előtérbe kerülnek az előre összeszerelt gépek, így a vásárlások zömét nem a legózó vásárlók teszik ki, vagyis az OEM gyártók akarata nagymértékben kihat a piacra. Innentől kezdve nincs Sandy Bridge+GPU és Llano. Van Sandy Bridge és Llano, a GPU kizárva a versenyből.Most valami óriási reform kell a VGA-knál, mert a piac igényei így nem megfelelőek, vagyis felesleges fenntartani a piacot.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#35
Abu85
HÁZIGAZDA
FireKeeper
#34
Abu85
HÁZIGAZDA
válasz
FireKeeper
#34
üzenetére
Nincs esély az 1.1-re. Nem alkalmas rá a hardver.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Teljesen mindegy, hogy mi miatt van. A baj az, hogy drasztikusan csökken, és a piac nem tudja eltartani magát. Az AMD-féle Dual Graphics sem valami elképesztően nagy ötlet arra, hogy az eladások legalább egy kis részét megtartsák. Ez a piac durván haldoklik sajnos. A Llano csak egy újabb tőr benne. Az AMD nyilván nem akarja a végét a VGA-piacnak, de ugyanakkor reagálniuk kell arra, hogy az OEM gyártók nem akarnak GPU-t építeni a termékekbe.
Majd kiderül, hogy mi lesz a jövőben. Ha egy gyártótól kell mindenképpen választani, akkor egy dolgot tudok, hogy nem az Intel grafikát választom.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#42
Abu85
HÁZIGAZDA
huskydog17
#39
Abu85
HÁZIGAZDA
válasz
huskydog17
#39
üzenetére
Igen oda kellene egy 10.12-es opencl driver. Akkor lesz OpenCL-es pipa is.
Ki kell próbálni a programot, hogy milyen terhelést mér a CPU-ra. Maga a post-process biztos, hogy a GPU-n dolgozik, azt hülyeség CPU-ra tolni.(#40) hugo chávez: Technikai akadálya nincs. Az adott program lehet akadály. A fejlesztők annyira nem rajonganak mostanában a fizika gyorsításáért. Annyi extrát ad, hogy a programban a fal 30 darab helyett 50 darabra törik. Ezt nem tartják túlzottan nagy extrának a játékélményben, hiszen vizuális effektusról van szó. A komplexebb, jobb lehetőségeket biztosító modellezéshez már saját fizikai motort kell írni, hiszen a licencelhető middleware-ek eléggé központosítottak. Úgymond alapszolgáltatásokat kínálnak, de az igazi innováció lehetősége nincs bennük. Függetlenül ettől a lehetőség adott az IGP használatára, de nem számítanék túlzottan sok ilyen programra még 2012-ben sem.
Ami az APU-k kapcsán előtérbe kerülhet az az AI áthelyezése az IGP-re. Főleg a stratégiai játékok húznának belőle előnyt.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Most éppen milyen tény felett akarunk elsiklani?
Nem mondtam, hogy holnap fognak eltűnni. A gond azonban már most érezhető. A VGA-k előállítási költsége pengeélen táncol. Ha esik az eladás, akkor az anyagilag is nagyon fáj. Semmi gond azzal, hogy az IGP nem nyomja le a combos GPU-t. Az a gond, hogy a combos GPU beépítése aránytalanul drága.
Igazából a PC-s piac már nem olyan, mint régen. Nem a legózás megy, hanem egyben vesznek az emberek notit, netbookot, nettopot, egybegépet, miközben elenyésző lett a kiskereskedelmi alkatrészekből összerakott termékek piaca. Pont azért gáz az OEM-ek hozzáállása. Ha raknának a fenti kelendőbb gépekbe VGA-t semmi gond nem lenne, de a mocskok nem raknak, inkább a saját hasznukat nézik, mint a júzer érdekét.Májusban a Sandy Bridge IGP-jétől esett 30%-ot az eladás. Nyilván értesz hozzá, és tudod, hogy a rendszer hány sebből vérzik egy Radeonhoz vagy egy GeForce-hoz képest, de mit csináljanak az emberek, amikor ott vannak az üzletekben az összerakott gépek Radeon és GeForce nélkül.
Itt nem a marketing segít. Itt arról van szó, hogy a kelendő gépek esetében fel sincs kínálva a Radeon vagy a GeForce. Ezen csak az segít, ha integrálsz és felkínálod, mert arra várhatsz, hogy az OEM-ek beépítsék a VGA-t. Nyilván az NV sem viccből döntött saját processzor tervezése mellett, nagyon kockázatos projekt és messze nem olcsó, de integrálni kell, különben csak a jelentéktelen rétegpiacokat szerezheted meg.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#48
Abu85
HÁZIGAZDA
hugo chávez
#47
Abu85
HÁZIGAZDA
válasz
hugo chávez
#47
üzenetére
Igen, készülnek a játékok Bullett motorral. Talán nem lesz gáz, ha megemlítem a Max Payne 3-at és a Luciust.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Llanohoz viszonyítva nem számítanak combosnak. A Sandy Bridge IGP-jéhez képest combosak. Persze a beépítés extra költsége még az SB-hez képest sem érné meg sajna.
Akkor a nép majd Intelt vesz Intel IGP-vel. Idővel majd rájönnek, hogy mit jelent egy GeForce vagy egy Radeon. Az AMD és az NV itt lesz egy-egy új generációs APU-val.
Addig abból lehet kiindulni, hogy ezen a fórumon, én vagy te, vagy más vajon miért nem használ Intel GPU-t. ![;]](//cdn.rios.hu/dl/s/v1.gif)
[ 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
Dr. Akula
#57
üzenetére
Az NV PhysX az a CUDA felületen működik. Senki sem támogatja a CUDA felületet az NV-n kívül. Az OpenCL-t minden gyártó támogatja. Az AMD-től nem hiszem, hogy el kellene várni, hogy teszteljék az Intel procikra a drivert, hiszen nem az Intel helyet akarják elvégezni a munkát. Az NV-től sem várja el senki, hogy a PhysX társkártya működését teszteljék Radeon mellett. Felajánlották anno az AMD-nek, hogy mehet a hivatalos társ-GPU, ha tesztelik a működést, de az AMD nyilván hülye lett volna belemenni ebbe.
Az AMD-nek most a célja, hogy valamilyen szinten működjön a driverük az Intel procikon, és használj APP SDK-t, ha OpenCL programot készítesz. Az AMD saját fejlesztőkörnyezete pedig biztos, hogy nem Intelre optimalizál. Hasonló a helyzet az Intel C fordítójához. Az sem AMD-re optimalizál. Most annyi a különbség, hogy a gyártók szerepe felcserélődött. Az Intel azért dolgozik olyan gyorsan az OpenCL SDK-n, mert a heterogén éra elkerülhetetlen, és tényleg fel kell mutatni valamit, különben az Ivy Bridge megjelenésére lesz egy csomó AMD-re optimalizált program. Ez nagyon nem jó dolog.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A minőség nem a CUDA vagy az OpenCL reszortja, hanem az algoritmusé. A CUDA-ra írt transzkódolók többsége azért annyira gyors mert feláldozza a minőséget, de meg lehet írni úgy, hogy a minőség legyen a szempont, csak akkor lassabb lesz. Az Arcsoft MediaConverter7 x86-on és OpenCL-en közel ugyanazt a minőséget kínálja. A CUDA a programon belül megmaradt gyorsnak gyenge minőséggel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Sajnos a konzumer alkalmazásoknál ez nem működik. Egyelőre a programok csak egy OpenCL driverrel futnak. Ezt persze jobb esetben ki lehet választani, de kettővel együtt csak a profi alkalmazások mennek. Rövidtávon ez nem is fog megváltozni. Hosszútávon opció. A fő probléma, hogy a gyártók a saját hardvereikre tesztelnek, és a konkurens megoldások itt hibákat eredményezhetnek. Persze a tesztelés a kulcskérdés. Ha sikerül ezt a részét megoldani, akkor működik a dolog. Amíg viszont ez nem megoldható, addig a program fejlesztőjére hárul egy komoly tesztelési feladat, amit nem sokan vállalnak be.
Egyelőre maga az OpenCL is egy kezdődő valami. Nem kevés hiba van benne. Mondjuk az 1.1 még, így is elég jó, de a későbbi OpenCL szabványoknál már bizonyos, hogy sokkal jobb lehet a helyzet.[ 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
Dr. Akula
#103
üzenetére
Az Integrált GMA-n eleve nem megy OpenCL-ben. Ahogy LordX mondja technikailag megoldható a két OpenCL driver használata, csak megnövelné a tesztelési fázis idejét, amire jelenleg a fejlesztők nem hajlandóak.
Az üzleti szempont, hogy az AMD nem hajlandó teszteli a driverét az Intel procikra. Maximális támogatáshoz az "igenis vegyél platformot elv érvényesül".[ 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
Dr. Akula
#109
üzenetére
Semmi gond azzal, hogy kitartasz az Intel mellett, ugyanakkor az Intel is csak a saját platformjaira fogja tesztelni az SDK-t és a drivert. Az NVIDIA is ugyanígy jár majd el. Mindegyik cégnek az az érdeke, hogy ne vegyél a másiktól hardvert. A mixelésnek a heterogén feldolgozás nagyon be fog tenni. Ez kivédhetetlen. Nem kötelező AMD-t venni, mert az Intel is kínál majd platformot, és 2013-tól az NVIDIA is fog. A lényeg, hogy a maximális támogatás platformra lesz biztosítva, álljanak a géped hardverei AMD/Intel/NVIDIA hardverekből. A cégek a szolgáltatásokkal ügyelnek majd arra, hogy ha vettél egy APU-t, akkor ne vegyél hozzá más gyártótól hardvert. Ezt ugyan nem fogják megakadályozni, mert teszem azt az NV APU-ja menni fog az AMD GPU-ja mellett is, de a legjobb támogatást, akkor kapod, ha mindkét hardver egy gyártótól származik.
[ 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
Dr. Akula
#111
üzenetére
Az OpenCL inkább arra való, hogy a munkát heterogén módon megossza a CPU és a GPU között. Ehhez elengedhetetlen a CPU oldali driver. Az Intel nyilván fog GPU oldali drivert is kínálni, amint lesz olyan korszerű IGP a lapkáikban, hogy ez lehetséges legyen.
[ 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
Dr. Akula
#113
üzenetére
Hol érdekelte valaha is a gyártókat a vásárló érdeke?
Mondtam semmi gond azzal, hogy az Intel procit veszel. Teljesen normális, ha neked az tetszik. Az Ivy Brdige már OpenCL képes GPU-t használ, az Intel biztos fog hozzá drivert is kínálni, és kész a platformszintű támogatás az Intelnél is. Ugyanez az NV-nél. 2013-ban már vehetsz tőlük Maxwellt, ami CPU és GPU egyben, vagy hívjuk APU-nak, ha már ennyire terjed ez a név. Szintén lesz normális platformszintű támogatás.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Dr. Akula
#115
üzenetére
Talán jobb lesz példákkal elemezni, mert nem biztos, hogy átjött ez az OpenCL működése dolog. Mindegy, elemezzük egyszerűen: Ha Radeon-Intel mixed van, akkor származhat a drivered egy gyártótól. Az AMD papíron támogatja az Intelt, de ha valami esetleg nem megy, akkor nem fognak sírva fakadni. Ez eddig gondolom vili volt. A másik lehetőség, hogy az AMD driverét csak a VGA-ra használod, és az Intelét rakod fel a CPU-ra (technikailag az AMD drivere is fent lesz a CPU-ra, de nem kötelező használni). Itt elméletben lehetséges az együttműködés az Intel CPU OpenCL és az AMD GPU OpenCL között, csak ezt a fejlesztőnek kell támogatnia, felvállalva azt, hogy esetlegesen probléma lesz a két külön gyártótól származó driverekkel.
Három dolog történhet a driverek esetében: A legjobb, ha minden frankó, és a progi fut mint atom. Nyilván ilyenkor a felhasználó örül.
Hibás működés lehetséges, hiszen mégis csak driverekről van szó, amelyek egy meglehetősen bonyolult API-t kezelnek. Előfordulhat, hogy az Intel CPU és AMD GPU driverrel nem lesz jó a program működése, amit természetesen jelezni kell a fejlesztő felé. Ilyenkor megkezdődik a kivizsgálás procedúrája, és a hiba megkeresése csak a két gyártó együttműködésével lehetséges. Nyilván ez egy konkrét hibánál meg fog történni, csak nem mindegy, hogy mikor kapod majd meg azokat a drivereket, amelyekkel az Intel és az AMD garantálja a jó működést. Ez akár hónapokat is igénybe vehet. A platformszintű támogatás mellett a hiba sokkal hamarabb orvosolható, hiszen egy gyártóval kvázi házon belül történik minden, ami jelentősen egyszerűbbé teszi a helyzetet. Ezért lesz előny a teljes platform. Természetesen az AMD VGA helyére rakhatsz NV-t is, de akkor is sokáig fog tartani a javítás, mert két gyártót kell bevonni. A legjobb támogatást platformmal kapod.Ezzel a helyzettel a gyártók sem tudnak mit kezdeni. Jelentős nehézség lenne, ha egymással kommunikálva, egységesen fejlesztenék a drivereket. A hibák még, így sem kerülhetőek el. Jelenleg a megszokod az új formát, vagy megszöksz elv fog érvényesülni. De tekintve, hogy ugyanez a helyzet fog lejátszódni minden piaci szegmensben nincs hova szöknöd, így muszáj a beletörődést választanod. Feltéve, ha fogsz még számítógépet vásárolni.
Fogd fel úgy, hogy mostantól az adott platformok összteljesítménye alapján vásárolsz majd. Egyébként mire ennek komoly jelentősége lesz, már 2013-at fogunk írni (feltéve, hogy a majáknak nem lesz igazuk a naptárukkal
). Addig sok dolog változhat.ABU-nak tényleg hívhatnánk, már perelném őket a névhasználatért.
[ 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
Dr. Akula
#117
üzenetére
Alapvetően olyasmi, csak sokkal bonyolultabban, hiszen a kód eltérő felépítésű hardvereken fut majd heterogén módban.
Nem a CPU driver a rendszer szerves rész. A CPU és a GPU közösen tud dolgozni egy feladaton. Ez még jelenleg nem igazán kihasznált, de úgy kell elképzelni, hogy a jól párhuzamosítható kódok mennének a GPU-nak, míg a késleltetésre érzékenyekre ott a CPU.
Az utasításkészlet egyezése itt nem olyan fontos, a hardver felépítésében eltérések vannak, és ez az optimalizálásban számít. Maga az AMD drivere pont azért működik az Intel procikon, mert az utasításrendszer megegyezik, de az optimalizálás nem az Intel CPU-kra történik meg.
Az nem járható, mert a gyártók CPU-inak felépítése eltérő. A közös driver még a fejlesztést és alapvetően a tesztelést is megnehezítené. Itt mindenkinek a saját hardveréről kell gondoskodnia, és kritikus jelentőségű, hogy a saját platformokon belül ne legyenek problémák.
Természetesen a heterogén lapkáknál az a cél, hogy az IGP erejét befogd általános számításra. Ez volt a célja az AMD-nek, és ez a célja az Intelnek az Ivy Bridge esetében. Sőt ez a célja az NV-nek is a Maxwellnél.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nekem mindegy, hogy C++ AMP vagy OpenCL, a programozó és a működés oldaláról nincs különbség a kettő között. Az OpenCL a felhasználó oldaláról jobb, mert teljesen nyílt, és biztos, hogy sose fogják a Windowshoz kötni. Ebből a szempontból nem tetszik a C++ AMP, ami úgymond még nyílt, aztán később ki tudja mi lesz vele.
Az AMD számára is totál mindegy, hogy C++ AMP vagy OpenCL. Mindkettőhöz ugyanúgy szükséges platformszintű driver támogatás, és természetesen ugyanazt játszák majd el, mint az OpenCL-nél. Az MS még előnyösebb is számukra, mert hatalmas anyagi tőke van Redmondban, és egy csomó holmijukat átírhatják C++ AMP-re, ezzel kihasználva az APU-k és a platformok erejét. Ráadásul a C++ AMP mögött hivatalosan az AMD biztosítja a többi operációs rendszerre a támogatást, és nem lennék meglepve, ha nem a konkurens hardverekre optimalizálják majd a fordítókat. Ez egy másik szempont ami nem tetszik. Szerencsére az MS nem zárja ki, hogy más is készítsen eszközöket, csak az AMD valamiért kiemelt szerepet kapott. Valószínűleg azért mert az MS-sel hasonló érdekeik vannak. Ettől függetlenül sosem jó, ha egy gyártó készít hivatalos támogatást egy adott oprendszerre. Talán az ARM is azért dörgölőzik mert érzik, hogy nagyon fontos, hogy az AMD ne csak a saját hardvereinek teljesítményét tartsa szem előtt a C++ AMP nem Windowsos környezetének kialakításánál.
Természetesen képes az OpenCL több GPU kihasználására. Úgy kell megírni a programot. A C++ AMP is képes lesz. Hasonlóan ott is úgy kell megírni a programot. Az MS és a Khronos felülete a működés tekintetében nem különbözik. A CPU/GPU/platform drivert is hasonló módon kell felépíteni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A jelenlegi driverek megfelelnek, valóban nagyon keveset kell rajtuk dolgozni.
Az AFDS-en az MS megjelölte az AMD-t, aki készíti a többi operációs rendszerre a C++ AMP támogatást (fordító/fejlesztőkörnyezet). Gyanítom, hogy ezzel arra akartak kitérni, hogy lesz Linuxra is. Tekintve, hogy a C++ AMP késésben van, így muszáj jelenleg az open hozzáállás, aztán majd később lezárják. Ahogy azt szokták.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Értem én ezt, de a kérdés az OpenCL-re vonatkozott. De köszi a kiegészítést.
Az AMD csak oda használja a CAL felületet, ahol nem oldható meg a probléma az OpenCL-lel. Nyilván az AMD is tudja, hogy a CAL csak a saját hardverein megy, így a jövőben halálra van ítélve.
Szvsz a Shogun 2 AI-ját is rossz ötlet volt CAL-ra írni, de OpenCL-ben nem volt megvalósítható. Mindenesetre az AMD nem is reklámozza, hogy a GPU-s AI számítás csak az aktuális Fusion APU-kon érhető el. Illetve a reklám csak annyit, hogy "extra scaling" a Fusion APU-ra, de nyilván nem lenne célszerű, ha elterjedne, hogy ez nem OpenCL, mivel a CAL az egy zárt szabvány. Az AMD open kommunikációja mellett ez nem a legjobb.[ 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
Dr. Akula
#133
üzenetére
Mit tud csinálni az NV vagy az AMD egy olyan motorral, ami nem támogatja az AFR-t? A CF és az SLI optimalizációs anyagokban világosan le van írva, hogy mit kell csinálni, ha AFR-t akarsz a programodra. A képkockák között a lehető legkevesebb adat legyen megosztva. Ha ezt a fejlesztő nem tartja be, akkor ennyi volt, a gyártó a driverből semmit sem tehet, max annyit, hogy letiltják a CF-et és az SLI-t.
Az OpenCL-nél is hasonló a dolog. A fejlesztő tudja megoldani a több eszköz kezelését. Pár extra sor a programkódban. Természetesen, ha ezt nem írják bele, akkor meszeltek a dolognak, és egy eszközön megy majd 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
Dr. Akula
#137
üzenetére
Gyanítom, hogy az egyik driverben kikapcsolták a CF-et, mert képhibákat eredményezett az AFR mód. Bekapcsolhatod vissza, ha átnevezed a program indítófájlját AFR-Friendly.exe-re. Ugyanez működik SLI mellett is.
A gyártók a hibátlan képminőségért is felelősek, nem csak a dupla sebességért. Ha az AFR nem működik hibátlanul, akkor abból AFR off lesz idővel.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Itt nem a marketing segít. Itt arról van szó, hogy a kelendő gépek esetében fel sincs kínálva a Radeon vagy a GeForce. Ezen csak az segít, ha integrálsz és felkínálod, mert arra várhatsz, hogy az OEM-ek beépítsék a VGA-t. Nyilván az NV sem viccből döntött saját processzor tervezése mellett, nagyon kockázatos projekt és messze nem olcsó, de integrálni kell, különben csak a jelentéktelen rétegpiacokat szerezheted meg.
Addig abból lehet kiindulni, hogy ezen a fórumon, én vagy te, vagy más vajon miért nem használ Intel GPU-t. ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
ph Úgy néz ki, hogy az áttörés nyáron megtörténik, így a grafikus vezérlők az általános számításokból is alaposan kivehetik részüket.
