Hirdetés
-
A TikTokon marakodik Trump és Biden
it Trump szerint ha betiltják a TikTokot, annak a felelőse Biden lesz. A betiltás Trump szerint csak a Metát tenné még gazdagabbá.
-
Engedélygyűjtésbe kezdett a Poco táblagépe
ma 33 wattos töltéssel és 8 megapixeles kamerákkal várható a Poco Pad.
-
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.
Új hozzászólás Aktív témák
-
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.
-
LordX
veterán
Persze, ha csak 1 kerneled van összesen, akkor nem is fog menni 2 driverrel. De ez ugyanaz, hogy az egy szálon futó program nem fog 2 processzort használni. Ha meg már van legalább 2 kerneled, akkor az a programozó, amelyik nem csinálta meg, hogy fusson 2 device-on, konkrétan egy balfax, mert kb. 1 sort hagyott ki a kódból..
-
Dr. Akula
nagyúr
Hát nemtom, Abu kifejezetten ezt aírta a cikkben: "az AMD külön kiemeli, hogy az OpenCL 1.1-es meghajtó működését csak a saját processzoraira teszteli, így ha egy program a driver hibájából nem, vagy hibásan, illetve esetlegesen lassan fut az Intel CPU-in, akkor ezzel kapcsolatban nem érdekeltek a javítás elkészítésében"
LordX:
Mond már meg, minek tesztelje az AMD a saját CPU-s OpenCL driverét, hogy ha az Intelnek van saját, CPU-n futó OpenCL drivere?
Mert sokaknak van Intel CPU + AMD Radeon, és akkor már nem az integrált GMA "erejét" akarná kihasználni, hanem a Radeonét. Sztem elég logikus.[ Szerkesztve ]
-
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.
-
lenox
veterán
Észrevetted már, hogy nagyon szereted kiforgatni a szavakat?
Nem, azt vettem eszre, hogy ha valami kifogasolni valot csinalsz, akkor rogton az ellenfelre fogod, hogy o csinalta, pl. most ram. Mert ugye nekem nem 'jott ki hogy az apu automatikusan mindenben gyorsabb', csak te allitod, szoval te probalsz szavakat kiforgatni.
példát is mondtam rá a ray-tracing képében
Van par opencl raytracer, szoval ez eleg hamar ki fog derulni, hogy igaz-e. Nezzuk majd meg.
Aham, csak kár, hogy ez hozzátartozik az összeintegráltsághoz, főleg ha még egy címterületen is dolgoznak majd... És mivel ez így van, amit te is jól tudsz, csak kibúvókat keresel, ezért tehát szerinted itt bukik az egész dolog. Én meg erre ugye azt mondom, már nem tudom, hányadszorra, hogy bizonyos feladatok esetén ez valóban bottlenecket képez, más feladatoknál meg nem.
Hehe, teljesen komolytalan, gondolom te keresel valamire kibuvot, es ram akarod fogni, dezz ervelestechnika (lopod a szovegemet, nincs sajat?
). De abban legalabb egyetertunk, hogy a lassu memoriarendszer bottleneck, bar nyilvan igen nehez lenne tagadni, anandektol sem veletlenul kertek a ddr3-1866 teszteket. -
dezz
nagyúr
Erm, bocs, ebben a sok félrebeszélésben valahogy elsiklottam a #99 aposztrofos részében az arra szócskán. Akkor nézzük így:
- Tagadod-e, hogy a CPU optimálisabb a komplikált, sok feltételes ugrást és random memóriaműveletet tartalmazó algoritmusok végrehajtására?
- Tagadod-e, hogy a GPU ezzel ellentétben kevésbé tolerálja az ugrásokat és a random memóriaműveleteket (könnyen elveszítheti ilyen körülmények között a számítási teljesítmény fölényét), így inkább a stream-feldolgozás jellegű feladatokra igazán alkalmas?
- Tagadod-e, hogy mindkét féle feladatot tartalmazó alkalmazásoknál előnyös lehet mind a CPU-t, mind a GPU-t igénybe venni?
- Tagadod-e, hogy lehet olyan eset, amikor ezek gyors egymásutánban követik egymást vagy akár teljesen összekeverednek, ami kulcsfontosságúvá teszi a kettő közötti gyors (kis késleltetésű és kellően sávszélességű) kommunikációt?
- Tagadod-e, hogy GPGPU-s alkalmazásnál jóval kisebb lehet a memóriasávszéligény, mint a megszokott grafikai műveleteknél és hogy ez általában így is van?"Nezzuk majd meg."
Nézzük! (Csak ne állítsd be úgy, mintha ez egy kőbe vésettnek vélt szabály lenne -- ez egy vélemény és fenntartom a tévedés jogát.)
"(lopod a szovegemet, nincs sajat? )."
Nem, b@szod, ez nem lopás, ezt úgy hívják: tükör...
"abban legalabb egyetertunk, hogy a lassu memoriarendszer bottleneck"
Már megint csak kiforgatod a szavakat a korrekt válasz helyett, mert éppen, hogy azt írtam, bizonyos esetekben az lehet, más esetekben meg NEM!
[ Szerkesztve ]
-
Dr. Akula
nagyúr
Maximális támogatáshoz az "igenis vegyél platformot elv érvényesül"
Az eladó részéről. De ezzel olyan dolgot feszegetnek, amivel nem biztos hogy megéri szórakozni. Mert ha az ember kitart az Intelnél, akkor lehet hogy inkább Nvidiát vesz videonak, ha az mondjuk támogatja.
Elhiszem hogy lehet 2 driver, meg mittudomén, annyira nincs kedvem belemélyedni a témában, de mivel azt írtad hogy az AMD nem teszteli, ebből szakmai hozzáértés nélkül is az jön le hogy kéne tesztelni, különben meg se kéne említeni a dolgot. Ha meg valami nincs, és kéne, az nyilván nem jó.
-
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.
-
Dr. Akula
nagyúr
A gyártónak lehet hogy érdeke, de nekünk vásárlóknak nem. Úgy fognak járni mint az Nvidia a Physx-el: Szép meg jó, de ezért nem fog senki feleolyan gyenge kártyát venni azonos pénzért. Inkább nem lesz kihasználva.
Én nem az Intel mellett tartok ki, hanem a jobbik mellett, ez pedig most az Intel. Volt már AMD-s procim is párszor, de akkor meg azok voltak jobbak (jó, a K6 az nem, azzal csak átvert az AMD).
-
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.
-
Dr. Akula
nagyúr
Azt azonban továbbra se értem minek kell 2 féle driver hozzá. Volt már itt MMX meg SSE, ott is meg volt oldva hogyha nem tudja a proci, akkor más utasításokat használ helyette, max lassabb lesz. Eleve nem értem minek egy JVM szerű valamit a CPU elé rakni, miért nem elég csak a GPU-s utasításokat kiszervezni egy egységes felületre (OpenCL), mert ott azért valóban nem ugyanazt nyújta az Nvidia mint az AMD, de procinál nincs ilyen lassítófelület közbeiktatásának igénye.
Hol érdekelte valaha is a gyártókat a vásárló érdeke?
Hát a pénztárnál. Mindent azért csinálnak. Mindent azért csinálnak hogy legyen kedvem megvenni, és pont az ő szajréjukat. Ellenkező esetben játszhatnának BSA/RIAA-t, és csak fenyegethetnének minket hogy ha nem náluk vásárolunk, akkor megyünk a sittre, de ők még nem a kommunizmusban élnek - szerencsére.vagy hívjuk APU-nak
Vagy ABU-nak.
Ezzel a platformmal csak az a baj hogy árukapcsolás, ami jobb helyeken tilos (az MS-t még megkúrták érte hogy az IE-t hozzákapcsolta a Windowshoz), de ami mégnagyobb probléma hogy nem a jót kapcsolják a jóhoz, hanem a szart. Mindegyik platform fele szar, azért kell kapcsolgatni. Az AMD prociban nincs sehol (az Nvidia meg pláne), az Intel meg GPU-ban. Nekem mindegyikből csak a jobbik fele kell, azért fizetek érte luxusárat.
[ Szerkesztve ]
-
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
![;]](//cdn.rios.hu/dl/s/v1.gif)
). 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.
-
Dr. Akula
nagyúr
Olyan lehet ez az OpenCL mint a DirectX, a programozó megírja a DX parancsot, aztán az alatta levő videokártya drivere meg olyan saját utasításokra szedi szét, amilyenre akarja. A programozó felel a DX kódért, a hardvergyártó a DX >> GPU kód konverzióért, és mindenki boldog.
Gondolom a CPU driver arra kell hogy ha nincs videokártya, akkor legyen mivel (CPU) emulálni azt. Mint a 3dfx korában a szoftveres renderelés, akinek nem volt pénze Hercules / Orchidra, csak Tseng ET6000-re. Nade itt minden (Intel + AMD) proci ugyanazt tudja, nincsenek külön utasítások, miért kell külön CPU driver, miért nem jó 1 általános CPU driver, amit mindenki szépen belepakol a saját GPU driverébe, és probléma megoldva? Netán az AMD ilyenkor a beépített "fosradeont" akarja munkára fogni, az Intel meg csak CPU-zik a GMA helyett?
-
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.
-
LordX
veterán
-
siriq
őstag
Pontosan. Ezert nem tetszik Abunak az MS AMP. Fagyi vissza nyal effektus lesz a vegen. Ertem en, hogy az AMD szeretne elore lepni de nem hulyek, hogy leragadjanak egy dolognal(opencl). Ott van az MS is. Latjak a fantaziat. (mert en szimpatizalok duma a valaszra nekem mar csak dedos mint a double face palm kep be linkelese amit paran meg is szoktak oldani). A nyavajgast meg el kell felejteni. Ez van. Tolni lehet az opencl szekeret csak erdemes kinezni is mogule. Lehet valaki eppen lehagy.
Mantras szoveget kerem hanyagolni ha lehet. Koszonom.
Amugy a mostani opencl tud tobb gpu-t kihasznalni?(nem apu es gpu-ra gondolok). 2-3 akar tobb gpu egyidejuleg valo kihasznalasara(mix-ve gondoltam de nem mixelve is jo lesz a valasz).[ Szerkesztve ]
Meg mindig nincs 1000 oras BF3 nev, kozben mar masok is erdeklodnek utana... Mar bevallottan nincs 1000 ora neki... Varjunk Dec 31-ig a Mantle-a.
-
lenox
veterán
Te most valamilyen inkvizitornak kepzeled magad? Bocs, de nyilvanvaloan csak belemkotni akarsz, a feluletes valaszok ezekre a kerdesekre tobbsegeben egyertelmuek, a maradek es a reszletek meg tulmutatnak azon a tudason, ami a fusion marketinganyagokbol megszerezheto, komolyabb gyakorlati tapasztalat meg nem mindenkinek all rendelkezesre... De ha megmutatod, hogy a kotozkodesen tul melyik miert erdekes egyaltalan, akkor esetleg lehet folytatni...
Nézzük! (Csak ne állítsd be úgy, mintha ez egy kőbe vésettnek vélt szabály lenne -- ez egy vélemény és fenntartom a tévedés jogát.)
Nekem eddig ugy tunt, hogy tenykent allitod, hogy az apu gyorsabb raytracingre, de ha velemeny, akkor oke.
Nem, b@szod, ez nem lopás, ezt úgy hívják: tükör...
En inkabb gyenge (mivel lopott) riposztnak hivnam...
-
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.
-
dezz
nagyúr
Csak azt szerettem volna elérni, hogy korrekt válaszokat adjál, de úgy látszik, képtelen vagy erre.
Tényként csak annyit állítottam, hogy pl. a ray-tracingben vannak olyan feladatok, amik jobban fekszenek egy CPU-nak és olyan is, amik megfelelőek egy GPU-nak is. Nyilván egy high-end GPU belassulás fennforgása esetén is nagy eséllyel lenyom bármilyen CPU-t -- csak pl. nem mindegy, mennyi áramot fogyaszt el közben.
Ha belenéznél abba a bizonyos tükörbe, meglátnád a gerendát a saját szemedben...
[ Szerkesztve ]
-
dabadab
titán
"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"
Mondjuk az AMP-hez önmagában nem kell külön támogatás, mert az DirectCompute-ot használ backendnek (ha meg megcsinálnák Linux alá, ott meg minden bizonnyal OpenCL-t használna). Igazából az AMP csak egy absztrakciós réteg a DC / OCL felett (és amit reakciókat láttam, az alapján kétséges, hogy mennyire használható ez az absztrakció, mert ha az ember normális teljesítményt akar, akkor kénytelen kézzel optimalizálni dolgokat.)
DRM is theft
-
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.
-
lenox
veterán
Természetesen képes az OpenCL több GPU kihasználására.
Nem tudom, ki hogy van vele, de szerintem valoszinuleg nem csak az a kerdes, hogy az OpenCL kezel-e tobb gpu-t, mert nyilvan ugy lett kitalalva, hogy kezel, hanem az a kerdes, hogy az implementaciok kezelnek-e. Szoval az nvidiat meg nem neztem, mert eleg, hogy a cuda kezel, az amd-t neztem, tavaly voltak gondok, most megneztem a forumokban, a dual gpu-s kartyak hivatalosan meg mindig csak egy gpu-val supportaljak az opencl-t, bar azt irtak, hogy sokminden megy rajtuk, a 2.4-es sdk-ban javitottak par dolgon, ha jol ertem, a single-gpu-s kartyak meg elvileg mukodnek.
Errol az jut meg eszembe, hogy az amd-nek is van cuda driver api jellegu api-ja cal neven, bar ezt nem szoktatok fikazni ugy, mint a cuda-t (pedig ahogy en latom tok hasonloan van kezelve, cuda/cal mindent tud, opencl meg mindig hatrebb van feature-okben), mindenesetre azzal pl. nem voltak ilyen gondok, meg tobb feature-t is supportalt, pl. a dma-s kommunikacio mindig is mukodott rajta, mig az opencl-nel tavaly ev vegeig nem mukodott.#124: Csak azt szerettem volna elérni, hogy korrekt válaszokat adjál, de úgy látszik, képtelen vagy erre.
Bocs, de a kerdeseid es a szandekod sem korrekt, a kotozkodesen tuli celjuk nem hinnem, hogy van, ugyhogy nem latom ertelmet foglalkozni veluk.
Ha belenéznél abba a bizonyos tükörbe, meglátnád a gerendát a saját szemedben...
Bagoly mondja...
-
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.
-
lenox
veterán
Mi azon az inkorrekt, hogy egyenes válaszokat próbálok kicsikarni belőled?
A szandek, hogy csak belemkotni akarsz. De mondtam, ha megmondod, hogy a kotozkodesen tul mi a celja, szivesen folytatom. De ha csak az a celja (es szerintem az), akkor bocs...
Rég rossz, ha valaki ennyire nem tudja elismerni a tévedését... Vitaképtelen.
Itt nyilvan a sajat tevedeseidre gondolsz
. En amugy meg azert is gondolnam, hogy nem korrekten vitazol, mert pl. tobbszor elofordul, hogy olyat allitasz, ami nem ugy, vagy mashogy volt, vagy egyaltalan nem is igaz, es az ellenfelet szidod erveles helyett. Nyilvan van, akinel mukodik.Baglyozz csak, de hiába nem nézel bele a tükörbe, attól mások még látnak.
Nem tudom miert olyan fontos neked 'masok' velemenye (itt a ph forumozokra gondolsz, feltetelezem), nekem van ennel sokkal erosebb terep szakmai elismeres kivivasara, nem olyan nagy problema, ha par sertodott forumozo hulyenek probal beallitani.
-
dezz
nagyúr
Én nem beléd kötöttem, hanem egy szakmai kérdést próbáltam megvitatni, és éppen, hogy tőled nem telt többre, mint kötekedésre, állandó félrebeszélésre, korrekt válaszok helyett.
Egy esetben volt olyan, hogy egy szócska elnézése miatt félreértettelek, amiért elnézést is kértem.
Csak olyankor "szídtalak", amikor korrekt válasz helyett süketelést kaptam. Tudod, arra nehéz észérvekkel reagálni.
-
siriq
őstag
Lehet neked szakerto modon volt elemezve de koran sem vagyok az. Sot talan itt senki sem az. Meg egy meg sem jelent(C++ AMP-rol is csevegunk) "dologrol" beszelunk, amirol meg nem tudjuk , hogy mekkora pontenciallal rendelkezik. Nem egesznap a gep elott ulok es olvasok a temarol. El is kell mennem melozni. Igy szerintem nem problema ha kerdez az ember. Ha valamit nem tudok kerdezek. Nalam igy szokott lenni.
Meg mindig nincs 1000 oras BF3 nev, kozben mar masok is erdeklodnek utana... Mar bevallottan nincs 1000 ora neki... Varjunk Dec 31-ig a Mantle-a.
-
-
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.
-
Dr. Akula
nagyúr
Ugyanannak a gyártónak (ATI) az előző generációs videokártyájával (5970, ami nem más mint egy downclockolt 5870 CF) nem volt ilyen probléma. A program közben nem változott. Miért nem tudja akkor ugyanazt a mutatványt az újabb generációs kártya? Tudtommal ugyanaz a felépítése, csak az ilyen-olyan részegységek számát növelték-csökkentették, aminél némi lassulást még elképzelhetőnek tartanék, ha a program épp a csökkentett számú egységet használja ezerrel, nade hogy totál semmi?
[ Szerkesztve ]
-
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.
). De abban legalabb egyetertunk, hogy a lassu memoriarendszer bottleneck, bar nyilvan igen nehez lenne tagadni, anandektol sem veletlenul kertek a ddr3-1866 teszteket.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
). Addig sok dolog változhat.
Ú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.
