- Android alkalmazások - szoftver kibeszélő topik
- Profi EKG-s óra lett a Watch Fitből
- Honor 400 Pro - gép a képben
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Samsung Galaxy A54 - türelemjáték
- Milyen okostelefont vegyek?
- Telekom mobilszolgáltatások
- Apple iPhone 16 Pro - rutinvizsga
- India felől közelít egy 7550 mAh-s Redmi
Új hozzászólás Aktív témák
-
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. -
Dr. Akula
félisten
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?
-
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. -
-
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.
-
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.
-
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.
-
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.![;]](//cdn.rios.hu/dl/s/v1.gif)
-
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
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. -
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.)
-
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...
-
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.
-
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...
-
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). -
LordX
veterán
-
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. -
Dr. Akula
félisten
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
#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.
-
Dr. Akula
félisten
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.
-
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.
-
Dr. Akula
félisten
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
-
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.
-
Dr. Akula
félisten
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ó.
-
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!
-
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. -
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". -
Dr. Akula
félisten
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. -
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..
-
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. -
dezz
nagyúr
Abu szerint egy program egyszerre csak egyfélét használhat. [link] Bár ez nekem elég furcsa, szerintem megoldhatónak kell lennie, csak talán komplikáltabb.
(#99) lenox: Észrevetted már, hogy nagyon szereted kiforgatni a szavakat? (Uhh, 1000 bocs, ez most megint "az ellenfel fikazasa", csak hát, ez a helyzet.) Én mindösszesen arra kérdeztem rá, hogy elismered-e, hogy az említett esetben az APU a gyorsabb. Nyilvánvalóan ettől nem lesz automatikusan mindenben gyorsabb. Nem is értem, ez hogy jött ki neked. Vagy itt most a lenox-féle érveléstechnika csillant meg?
A #94-ben sem arra válaszoltál, hanem tereltél és kötözködtél.
"Ha jol ertem akkor nem tudsz peldat mondani, tehat akkor azt az allitast, hogy de te mar mondtal, azt minek nevezik?"
Ehh, újabb kiforgatás... (Pedig egyértelműen különbséget tettem az általános, a leszűkített és a programnév szinten konkrét példa között, direkt a kedvedért...) Nos, én az első kettőt teljesítettem: pontosan leírtam, milyen esetben jön ki az APU előnye, és példát is mondtam rá a ray-tracing képében. Csak hát te itt már programnevet követelsz, amivel valóban nem szolgálhatok, mint már írtam.
"nem az a lenyeg, hogy ossze van-e integralva a gpu a cpu-val, hanem hogy egy kozos lassu memoriarendszeren osztoznak-e."
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.
-
lenox
veterán
Bocs, de egy ilyen 'felteve hogy valamire az apu a leggyorsabb, tagadod-e, hogy arra az apu a leggyorsabb' kerdest nem gondoltam, hogy komoly kerdesnek tartasz, most sem gondolom. Mondjuk a #94-ben erre valaszoltam, hogy nem ertetted...
Ha jol ertem akkor nem tudsz peldat mondani, tehat akkor azt az allitast, hogy de te mar mondtal, azt minek nevezik? En tudom... Dezz ervelestechnika, masik fo motivum az ellenfel fikazasa mellet, lasd gerincesseg.Az utolsó bekezdésben önmagadnak mondasz ellent
Ez megint valami dezz logika lehet, mert en nem latok ellentmondast, bar amugy megint nem ertetted, hogy nem az a lenyeg, hogy ossze van-e integralva a gpu a cpu-val, hanem hogy egy kozos lassu memoriarendszeren osztoznak-e.#97 Cal-t hasznalnak, nem opencl-t.
-
LordX
veterán
-
dezz
nagyúr
válasz
Dr. Akula
#93
üzenetére
Szerintem tesztelik, csak az nem várható, hogy kimondottan rá is optimalizálják a CPU-s részt Intel procikra.
(#94) lenox: Ez nagyon gerinces, hogy folyamatosan a konkrét (mint program-cím) példán pattogsz, de messziről elkerülöd a válaszadást az idézett mondatrész folytatására... (Mellesleg 1-1 tévedésedet sem igyekszel elismerni.)
"Az integraltsag elonyet akarod bizonyitani meg mindig. Nyilvan akkor olyan rendszerhez kell hasonlitani, ami hasonlo tulajdonsagu, csak nem integralt."
Természetesen!
"Amugy a cpu magaban 21.6 MPix/s-et tudott, de ebbol csak 7.6 maradt meg... Nekem ugy tunik gatoltak egymast, de akkor magyarazd meg, ha nem."
Sajnos nem szerepel ott CPU + diszkrét GPU eredmény, hogy legyen mihez hasonlítani. De nyilván csökkenti a CPU teljesítményét, ha a GPU dolgoztatásával is foglalkoznia kell. Nem mintha ez itt megint egetrengető lassulást okozna...
"Nem gondolom ezt"
Akkor miért vonsz le ilyen irányú következtetést?
"ez a kozos memoria bottleneck tema, ami az integraltsag hatranya."
Hogyan bizonyítanád, hogy itt erről van szó?
Az utolsó bekezdésben önmagadnak mondasz ellent, mert pl. a Trinitynél is közös lesz a memóriavezérelő, így szerinted mindenképpen rosszabb választás, mint a különálló CPU és GPU, ami a teljesítményt (akár grafikus, akár GPGPU) illeti.
-
lenox
veterán
Olyan feladatoknál
Ird legyszi a konkret pelda alkalmazast. Ha nincs, akkor nincs. Amugy azt nem tudom hogy gondoltad, hogy diszkret gpu onmagaban. Bar ha a proci onmagaban reszt nezzuk azon is az latszik, hogy meg mindig nem erted, hogy az apu-nak egy diszkret vga + cpu parost kene lenyomnia ahhoz, hogy kideruljon, van elonye az elmeletben gyorsabb kommunikacionak.
Nyilván nem ez volt a lényeg...
Hanem mi? Az integraltsag elonyet akarod bizonyitani meg mindig. Nyilvan akkor olyan rendszerhez kell hasonlitani, ami hasonlo tulajdonsagu, csak nem integralt. Tehat ha az apu-s rendszerben 2 gpu van, akkor a nem apu-s rendszerben is 2 kell legyen, kulonben semmi ertelme az osszehasonlitasnak.
Már többször is meghatároztam, milyen esetekben tud döntő tényező lenni és példát is írtam.
Hol a pelda, melyik program, mik az eredmenyek?
Már ha a 348,4 és 356 közötti 7,5 GFLOPS neked semmi...
Amugy a cpu magaban 21.6 MPix/s-et tudott, de ebbol csak 7.6 maradt meg... Nekem ugy tunik gatoltak egymast, de akkor magyarazd meg, ha nem.
1. Szerintem mosd ki a szemed, mert belement valami...
Gondolom mindjart jon a hulyezes is...
2. Miből gondolod, hogy ebben a tesztben olyan feladat van, aminél kulcsfontosságú a kettő közötti kommunikáció?
Nem gondolom ezt, ha nem csak irnal, latnad, hogy ez a kozos memoria bottleneck tema, ami az integraltsag hatranya.
3. A Llano csak az első lépés ebben az irányban, de te az egész APU koncepció létjogosultságát kérdőjelezted meg.
Ez megint kepzelges, azt kerdojelezem meg, hogy a llano-ban az integraltsag gyakorlati teljesitmeny elonnyel jar a gyorsabb cpu-gpu kommunikacio okan, azt, hogy eddig nem lehetett heterogen programot irni, most meg lehet, ellenben allitom, hogy az integraltsag hatranya pl. a kozos memoriarendszeren valo osztozas.
-
Dr. Akula
félisten
Ez oké, de a vita abból indult ki, hogy az AMD nem teszteli más gyártók procijával a kompatibilitást (ez nyilván csak az Intelre vonatkozhat, más valós konkurrenciája nincsen). Tekintve az Intel vs AMD procik teljesítménykülönbségét és elterjedtségét, a többségnek Intel van. Főleg ahol van pénz komolyabb videokártyára is. Így pont a csúcskategóriás Radeont vásárlókat szopatja az AMD, mert azoknak nagy valószínűséggel futja Intel procira is, és nem azért vettek csúcsradeont hogy prociból ne a csúcsot vegyék.Ilyen szempontból sztem öngól. Bár tudom hogy a legnagyobb eladások az alsókategóriában vannak, de a legkisebb haszon is azokon van. Aki AMD procit vesz, az csúcsradeon helyett beéri középkategóriával is. ez nemtom miért jó nekik. Engem konkrétan érint(ene, ha használná vmi az OpenCL-t) a dolog, és nem szívesen vennék AMD procit. Persze ha a Bulldozer tud majd annyit mint az SB, akkor simán váltok, de az Athlon 1 óta nem ez a helyzet, és ilyen értelmű előrejelzést se nagyon láttam még (leszámítva az AMD marketinget, de az nem mérvadó).
-
dezz
nagyúr
Olyan feladatoknál, ahol a CPU és a GPU gyors interakciója és a kellő számítási teljesítmény ugyanolyan fontos, előnyösebb egy APU, mint egy diszkrét GPU vagy a proci önmagában, AVX-es kóddal. Ezt csak nem tagadod...!? Az már más kérdés, hogy milyen alkalmazásban fordul elő ilyen feladat.
"Hat igen, ha ket gpu van a rendszerben, az gyorsabb lehet, mint ha egy."
Nyilván nem ez volt a lényeg...
"Teljesen lenyegtelen, hogy abbol az egyik a cpu-val egy lapra van integralva"
A fenti esetben nem -- ha kellően gyors (kis késleltetésű és elegendő sávszélességű) a CPU és a GPU közötti kommunikáció.
"Legyszi ird le a peldakat, amikor vgaval nem megy, ellenben apuval igen."
Már többször is meghatároztam, milyen esetekben tud döntő tényező lenni és példát is írtam.
"Melyik is volt az?"
#56?
"Amikor a llano csak gpu-val kb. ugyananolyan eredmenyt ert el, mint cpu+gpu-val"
Már ha a 348,4 és 356 közötti 7,5 GFLOPS neked semmi...
"de mindketto alatta volt az ugyanannyi sp-t tartalmazo, ugyanolyan sebesseggel jaro diszkret vga-s eredmenynek?"
Milyen érdekes, hogy az előzővel ellentétben a 356 és 359,9 közötti 3,9 GFLOPS itt mekkora jelentőségűvé válik... Hát tudod, itt most számszerűen kijött, hogy nem ugyanazzal a mérleggel méred a neked tetsző és nem tetsző dolgokat...
BTW, a 348,4 és 359,9 közötti, ~3%-os különbség sem nevezhető éppen egetrengetőnek...
"Ezt nem inkabb neked kene tudomasul venni, hogy hoppa, semmilyen elonnyel nem jar, ha osszeintegralod oket?"
1. Szerintem mosd ki a szemed, mert belement valami...
2. Miből gondolod, hogy ebben a tesztben olyan feladat van, aminél kulcsfontosságú a kettő közötti kommunikáció?
3. A Llano csak az első lépés ebben az irányban, de te az egész APU koncepció létjogosultságát kérdőjelezted meg. -
lenox
veterán
Most viszont úgy próbálod beállítani, hogy mintha a Llanonál egész más lenne a helyzet (GPGPU-s felhasználást illetően is), pedig teszteredmény bizonyítja, hogy egálban lehet a neki megfelelő diszkrét változattal.
Mirol beszelsz? Azt probalod bizonyitani, hogy van elonye a cpu es gpu kozotti gyors kommunikacionak. SP processing bottleneckes feladatnal egalban lehet a megfelelo diszkret valtozattal a llano, igen. Ebben az esetben semmi jelentosege, hogy gyorsabb-e a komminikacio, mint pcie eseteben. Tehat ezzel nem tudod bizonyitani, hogy elonye lenne, akkor miert erdekes ez az eset?
adott esetben igen sokat dobhat a teljesítményen, ha egy sok-SP-s GPU mellé tesznek egy ilyen APU-t
Hat igen, ha ket gpu van a rendszerben, az gyorsabb lehet, mint ha egy. Teljesen lenyegtelen, hogy abbol az egyik a cpu-val egy lapra van integralva, vagy nem, tehat lehet siman ket diszkret vga. Mint ahogy mar volt is, lasd physics tarskartya, vagy sli, vagy cf. Pont ezt mondom, semmi vilagmegvaltas, ilyen mar volt eddig is.
Csak nem mindig sikerül...
Legyszi ird le a peldakat, amikor vgaval nem megy, ellenben apuval igen.
Egyelőre itt én hoztam fel teszteredményt, ami éppen hogy az ellenkezőjét mutatta.
Melyik is volt az? Amikor a llano csak gpu-val kb. ugyananolyan eredmenyt ert el, mint cpu+gpu-val, de mindketto alatta volt az ugyanannyi sp-t tartalmazo, ugyanolyan sebesseggel jaro diszkret vga-s eredmenynek? Ezt nem inkabb neked kene tudomasul venni, hogy hoppa, semmilyen elonnyel nem jar, ha osszeintegralod oket?
-
dezz
nagyúr
válasz
Dr. Akula
#89
üzenetére
Az Intel OpenCL drivere egyelőre CPU-n fut.
Nem ismerem az OpenCL-t töviről-hegyire, de csodálkoznék, ha nem lehetne minden cuccnak saját OpenCL drivere. Tehát, ha pl. csak akkor működhetne együtt Nvidia és AMD GPU (vagy épp Intel CPU + AMD GPU), ha mindkettőnek ugyanazt a drivert használja (amilyen nyilván nem lesz, ami az első esetet illeti)...
Szerintem az APU-knál arról van szó, hogy adott esetben előnyösebb az összegyúrt driver (ami a GPU-t és a CPU-t egyben kezeli), mint a különállók.
-
dezz
nagyúr
Nézd, a SandyB esetén én fejeztem ki kételyemet a számítási teljesítményhez képesti fele olvasási és negyede írási L1D sávszélességgel kapcsolatban, akkor ti gyorsan megmagyaráztátok és végülis bizonyítottátok (legalábbis az olvasást illetően), hogy ez nem gond.
Most viszont úgy próbálod beállítani, hogy mintha a Llanonál egész más lenne a helyzet (GPGPU-s felhasználást illetően is), pedig teszteredmény bizonyítja, hogy egálban lehet a neki megfelelő diszkrét változattal. (Figyelmedbe ajánlanám, hogy az IGP-ben lévő cache ugyanolyan sávszélekkel rendelkezik, mint a diszkrét változat esetén.)
Az lehetséges, hogy egy jóval több SP-s GPU-val nem tud versenyre kelni, azonban adott esetben igen sokat dobhat a teljesítményen, ha egy sok-SP-s GPU mellé tesznek egy ilyen APU-t, ami bizonyos feladatokon a CPU-val közelebbi együttműködésben dolgozik.
Mindez desktopon -- mobil volalon nagyon sok esetben nem lesz diszkrét GPU.
"azt allitottam, hogy a kommunikacio esetleges gyorsasagat nemigen fogja tudni semmi kihasznalni (mivel a cpu - pcie - gpu rendszerben is mindig probalja az ember elfedni)"
Csak nem mindig sikerül...
"tehat csak az a hatrany fog kijonni, hogy a cpu es gpu kozos lassu memorian osztozik. Es lam a tesztek is pont ezt mutatjak, milyen meglepo."
Egyelőre itt én hoztam fel teszteredményt, ami éppen hogy az ellenkezőjét mutatta. A meglepő az, hogy nem veszed tudomásul...
-
Pietrosz
addikt
-
-
lenox
veterán
Az elejet meg egyszer vegiggondolhatnad, mielott bennem keresed a hibat, leven hogy nem az a kerdes, hogy lehet-e cpu es gpu kozott feladatot megosztani, hanem az, hogy hol lenne ebben az apunak valos alkalmazasban az elonye egy hagyomanyos cpu - pcie bus - gpu megoldashoz kepest. A hatranyat (kozos memoriarendszer) latom, azt jo sok helyen ki lehet mutatni, de hol az elonye? Szerinted a raytracingnel? Akkor mutass peldat olyan tesztre, ahol Athlon x4 + 800 sp vga teljesitmenyet eleri a llano, mert akkor az kezzelfoghato elony. De amig annyi a magyarazkodas, hogy de hat kb akkora a teljesitmenye, mint az ugyanolyan orajelen mukodo ugyanannyi sp-t tartalmazo gpu-s renszere (lasd amit #79-ben irtal), akkor az pont azt jelenti, hogy semmilyen elonye nincs.
Az avx-et ugye arra a helyzetre javasoltam, amikor az ido nagy resze kommunikaciora megy el, tehat nem fog az igp 500 GFLOP-ot nyomni masodpercenkent logikus modon.
Ezt a cache dolgot mar korabban is leirtam mas topikban is, szerintem eleg konzisztensen. Nem ertetted ezek szerint, az apu koncepciot nem ertelmetlennek tartottam sosem, hanem azt allitottam, hogy a kommunikacio esetleges gyorsasagat nemigen fogja tudni semmi kihasznalni (mivel a cpu - pcie - gpu rendszerben is mindig probalja az ember elfedni), tehat csak az a hatrany fog kijonni, hogy a cpu es gpu kozos lassu memorian osztozik. Es lam a tesztek is pont ezt mutatjak, milyen meglepo. Ha javitod ezt a bottlenecket nagy savszelessegu memoriaval, vagy nagy cache-sel, egybol no az apu teljesitmenye. Ez meg ma nincs, ha majd lesz, jo lesz, nyilvan amugy egy gpu ha beindul, akkor rettento mennyisegben ontja az adatot, lasd sb level3 cache problemai, szoval ez nem trivialis feladat, de kb. ezen all vagy bukik a dolog, mert nem hinnem, hogy 200 GB/sec sebessegu memoriarendszert akarna valaki alaplapra integralni (mert ha igen, az akkor grafkartya).
Ugyhogy lehet, hogy a marketing azt nyomatja, hogy vilagmegvaltas, de szerintem meg egy lapra integralt cpu+gpu, semmi kulonos, arazastol fuggoen jo vagy rossz vetel.
-
Pietrosz
addikt
A Xilisoft is gyenge minőséget csinál, most próbáltam. Amd app nélkül még elmegy, de ha bekapcsolom, igaz gyors lesz, de legalább ronda. De ez így kinek jó? Amd miért adja pl a nevét hozzá? Egy részről ott van a minőségre törekvés, egyre jobb AA, AF módok, stb, másik oldalról meg leszarják, csak gyors legyen?
Most vagy a fejlesztők is hülyének nézik az embert, vagy ez a technika tényleg nem a minőségről szól, csak én éltem álomvilágban -
dezz
nagyúr
Ejj, ejj, mintha nem tudnád, hogy a GPU-k (maiak sem) nem igazán szeretik az ugrásokat, amik a CPU-knak viszont meg sem kottyannak... Ennek kihasználásához mindössze olyan feladatok kellenek, amiknek egyes lépései komplikáltabb algoritmusok, más lépései pedig egyszerűbb, de számításigényesebbek. Ne mondd már, hogy ez annyira egzotikus dolog lenne!
Nem is kell messzire menni, vegyük pl. a a ray-tracinget: van benne rengeteg adaton, de egyszerűbb és jóval kisebb adathalmon, de jóval bonyolultabb számítási feladat is. (De szerintem ezt nem kell neked magyarázni.
Vagy ha mégis, később majd meglátod, ha továbbfejleszted esetleg azt a kis OpenCL-es ray-tracert...)Az AVX-ből, mint megbeszéltük, ilyen 200 GFLOPS körüli (vagy alatti) értékeket lehet kihozni SandyB-n és az IvyB sem lesz sokkal előrrébb. Ehhez képest a Llano IGP-je 4-500 GFLOPS-os, ami azért mégis csak 2-2,5x annyi. Bár még nem derült ki, milyen gyors lehet a kommunikáció a CPU és a GPU között.
"ugyhogy pontosan akkor lehet majd ebbol igazi elonyt kovacsolni, amikor az integralt cpu es gpu kozos cache-sel fog rendelkezni. Az meg nem most van."
Nocsak, nocsak! Eddig az egész APU koncepciót értelmetlennek mondtad (és még a mondat első fele alapján sem ilyen befejezésre számítana az ember
), ehhez képest előrelépés, hogy bizonyos feltétekkel már tulajdonítasz neki némi létjogosultságot. Mindegy, ezek csak az első lépések, a jövő a sokkal komolyabb integrálás, összegyúrás, közös regiszterkészlettel, stb.
-
#81
hugo chávez
aktív tag
lenox
#80
hugo chávez
aktív tag
"ugyhogy pontosan akkor lehet majd ebbol igazi elonyt kovacsolni, amikor az integralt cpu es gpu kozos cache-sel fog rendelkezni. Az meg nem most van."
Hát, a Sandy Bridge-nél közösen használhatják az L3 cache-t a procimagok és az IGP, de, tudomásom szerint, ott meg pont az a gond, hogy, ha az IGP "teleszemeteli", akkor ezzel a CPU részt lassítja.
-
lenox
veterán
Nem hiszem, hogy ne tudnál elképzelni olyan helyzetet, amikor nem optimális a nagyobb csomagok cseréje a CPU és a GPU között, hanem kisebb csomagok jóval gyorsabb cseréjére van szükség.
Ertem, hogy ez marketing bullshitnek jo, pont ezert kerdezem, hogy tudsz-e valos alkalmazasrol, mert gondolnam, hogy nem tudsz, pont azert, mert ezt marketing bullshitnek tartom. Mar tobbszor leirtam, hogy en max benchmarkot tudok elkepzelni, amiben ezzel villantani lehet, de nem feltetlenul jut eszembe minden problema a vilagon, szoval ha valaki tud ilyet, batran adja elo. Csak mert sarkitva vagy a kommunikacio a bottleneck, vagy a processing. Ha a kommunikacio, akkor az sse, avx regiszterek joval gyorsabban elerhetoek, ha a processing, akkor egy kozepes grafkartya joval nagyobb teljesitmenyre kepes, ugyhogy pontosan akkor lehet majd ebbol igazi elonyt kovacsolni, amikor az integralt cpu es gpu kozos cache-sel fog rendelkezni. Az meg nem most van.
Előtte is, utána is láttam több-GPU-s eredményeket, szal szerintem átmeneti bug lehetett.
En is, opengl-lel, cudaval meg cal-lal, de nem opencl-lel. Szoval tuti, hogy opencl volt?
-
dezz
nagyúr
+Raymond:
1. Az A8-3500M egy mobil chip, 1,5 GHz CPU és 444 MHz GPU órajellel. Így talán nem csoda, hogy az ugyanannyi s.p.-vel rendelkező HD5570 444 MHz-en van egálban vele... Később majd lesznek tesztek desktop A8-3800/3850-nel is, szerintem igen közel lesz az 5570-hez OpenCL-ben.
2. Tisztázni kellene, mi a gyenge közepes. Szerintem nem kapásból HD5xxx-en belül kellene nézni, mert a piacon van még rengeteg korábbi generációs kártya is, ahol is a középosztály alja lejjebb volt még.
"Erre mondj mar legyszi egy valos peldat, mert mindig felhozzatok, de a gyakorlatban valahogy en meg nem lattam ilyet, csak a fusion marketing szovegben."
Nem hiszem, hogy ne tudnál elképzelni olyan helyzetet, amikor nem optimális a nagyobb csomagok cseréje a CPU és a GPU között, hanem kisebb csomagok jóval gyorsabb cseréjére van szükség.
(#64): Előtte is, utána is láttam több-GPU-s eredményeket, szal szerintem átmeneti bug lehetett.
-
lenox
veterán
Probald meg mainconcepttel. Bar az interaktiv alkalmazasban nem tudom, mennyi lehetoseg van, a low level apiban ugyanazt lehet csinalni, mint az x86 verzioban.
Az x264 amugy meg eleg jo, szoval minosegben jobb nemigen lesz, csak gyorsabb. A mainconcept 1080p-t 50 fps felett tud max minoseggel, de ossze meg sosem hasonlitottam. -
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.
-
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. -
lenox
veterán
Ha egy program fel van rá készítve, hogy több GPU device-t használjon
Megy mar amd-n a tobb gpu device? Utoljara mikor neztem meg azon szomorkodtak, hogy barmelyik gpu device-t valasztod, mindig a 0-st hasznalja, vagyis nem megy tobb gpu-n egyszerre. Ez mondjuk ha jol emlekszem decemberben volt, szoval akar mehet is azota, de amugy erdekes, nvidian mar tobb mint 5 eve mennek a tobb gpu-s kodok.
-
lenox
veterán
??? Igen, gondolom, miert, neked mit jelent az, hogy egy downclockolt ddr3-as 5570 teljesitmenyet hozza egy szintetikus tesztben? Nekem azt, hogy egy low end vga-val van egalban. Ugyhogy egy gyenge kozepestol (pl 6570/6670) mar kikap. Ez amugy benne van a korabban linkelt anandos vagy vreveal-es eredmenyekben is. Es ha jol emlekszem atlagban meg egy 6450 teljesitmenyet tudja, az meg 160 sp-s.
És vannak olyan feladatok is, ahol a CPU és a GPU közötti gyors kapcsolat is kiemelten fontos.
Erre mondj mar legyszi egy valos peldat, mert mindig felhozzatok, de a gyakorlatban valahogy en meg nem lattam ilyet, csak a fusion marketing szovegben.
-
Raymond
titán
Gondolod?
A kep amit linkeltel bizonyitja hogy van oka ra amiert azt gondolja (vagy inkabb tudja). Az 5570 egy 444Mhz lejebb huzott valtozata latszik rajta es ezzel mutat egyenlo teljesitmenyt a tesztben szereplo Llano. Az 5570 alapbol 650Mhz-en jar es messze nem a "gyenge kozepes" kartya, per pillanat ez a masodik legszarabb amit az AMD kinal az 5450 utan.
-
dezz
nagyúr
válasz
Dr. Akula
#57
üzenetére
Azt a részt én egy kicsit erősnek tartom. Nyilván nem fogják a végletekig optimizálni Intel CPU-kra, de szerintem abban nem érdekeltek, hogy egyátalán ne fusson, mert az az OpenCL-nek is keresztbe tenne és az ő nimbuszukat sem növelné. Azt sem árt szem előtt tartaniuk, hogy egyelőre mégis csak az Intel a domináns CPU fronton, és még mindig jobb, ha AMD VGA-t tesznek mellé.
De amúgy is botorság, hogy csak annyit érne, hiszen az OpenCL nyílt szabvány, nincs az AMD-hez kötve, előbb-utóbb az Nvidia és az Intel is előáll a hivatalos, nem beta 1.1-es drivereivel. (Már ami az x86(-64) platformot illeti, mert máshol is van OpenCL.)
"Ismerve a jelenlegi AMD procik "csodálatos" teljesítményét az Intelhez képest"
Ne zavarjon, hogy ezzel az előző gen. Intelt is lesimfölted. Fölösleges állandóan ilyen bicskanyitogatóan fogalmaznod. Már ha nem ebben leled minden örömödet -- akkor csak rajta, nem akarom ez is elvenni tőled...
-
Dr. Akula
félisten
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.
Akkor ez is csak annyit ér mint az nvidia only physx. Szart se. Pedig jó ötletnek tűnt. Ismerve a jelenlegi AMD procik "csodálatos" teljesítményét az Intelhez képest, nyilván nem fogok ezért AMD-re butítani. Meg gondolom sokan mások se.
-
dezz
nagyúr
Ha egy program fel van rá készítve, hogy több GPU device-t használjon, akkor több GPU-t fog egyszerre kihasználni. Bár remélem, valahogy meg lehet különböztetni az APU-t a diszkrét GPU-tól, mert ugye komoly előnye tud lenni a shared memóriának.
(#31) lenox: "Szoval opencl-ben megveri a llano az sb-t, de egy gyenge kozepes grafkartyatol mar kikap."
Gondolod?
Nyilván a 400 s.p.-jével nehezen lenne erősebb egy 800 s.p.-snél. Ez persze feladatfüggő is, valahova a max. throughput kell (kevés számolás -- sok memóriaművelet), máshol meg a számítási teljesítmény dominál. És vannak olyan feladatok is, ahol a CPU és a GPU közötti gyors kapcsolat is kiemelten fontos.
Eléggé nem mellékes, hogy eddig a legtöbb átlagos gépben ez a teljesítmény és feltételrendszer sem volt adott. A Llano remélhetőleg jelentősen hozzá fog járulni ezen arány javulásához, ami elősegíti az erre épülő szoftverek mind nagyobb számban való megjelenését, ill. a meglévők "feltorbózását".
-
Donor
tag
A felsorolt programok közül a NASTRAN az egy véges elem szoftver.pl ezt lehet vele csinákolni http://www.youtube.com/user/Constantinrender#p/a/u/2/v9D9XCHtcK8
Cserébe viszont baromi sok memória kell ha egy fickósabb modellen sűrű rácsozással szeretnél számolgatni.Ott egy darabig marad a cluster...... .Ja és nem NASTRAN hanem ANSYS... .
-
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. -
-
#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.
-
#47
hugo chávez
aktív tag
eziskamu
#41
hugo chávez
aktív tag
Na igen, de, ha Intel cpu-t vennék, ahhoz már akkor inkább NV vga-t, mint AMD-t, persze, amennyiben valaki AMD cpu-t vesz, akkor ahhoz nyilván vga-ból is érdemes (és a jövőben egyre inkább érdemesebb lesz) AMD-t vennie
(#42) Abu85:
"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."
Ez sajnos valószínű, bár ott van pl. a Bullet, amit, ha jól tudom, bárki ingyen beépíthetne, de tulajdonképpen csak arra voltam kíváncsi, hogy ilyen esetekben az NV drivere esetleg nem kavarna-e be, de akkor ezek szerint, csak a játékfejlesztőkön múlik, hogy mehet-e a fizikai móka IGP+cpu-n.
-
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. -
lenox
veterán
Marmint akkor mindegy, ha el akarunk siklani a tenyek felett
. Majd nezz vissza egy par topikot egyszer.
Egyebkent szerintem megint felreertelmezed a dolgot. Haldoklik a piac, de az nem azt jelenti, hogy a mar kifejlesztett termekek holnap megszunnek. Egyelore meg sok ido, amig nem lesz diszkret vga, es az is sok ido, ha lesz egyaltalan, hogy apuval lenyomnak a diszkret vga-kat. Addig meg mindegy milyen procit veszel, mindben gyenge az integralt vga, elkel melle egy diszkret vga. Es kb. mindegy, hogy intel/amd/nvidia. Mezei felhasznalasra meg az integraltak is jok, bar az amd jobb. Kerdes, mennyit er a marketing, tapasztalat szerint sokat. -
zörbi
csendes tag
Én nem is bánom ha bedől a diszkrét vga piac. Ha a legtöbb embernek mainstream VGA/integrált cucca lesz a játék gyártók legalább kénytelenek lesznek PC-re jobban optimalizálni. Ne adj isten előtérbe kerül a játékélmény a grafika helyett. A (ha jól tudom) 2006-os Company of Heroes óta nem fogott meg játék igazán. A szép grafika nálam csak 1-2 óra ámuldozásra elég, ha meg jó a játék tökmindegy a grafika. Akik játszottak anno a C64-es, 286-os időkben, tudják miről beszélek, nem kell szuperüber grafika hogy a gép elé ragassza az embert
RTS-t pedig muszály PC-re írni konzolon egy szenvedés ez a műfaj. -
#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. -
#41
eziskamu
addikt
hugo chávez
#40
eziskamu
addikt
válasz
hugo chávez
#40
üzenetére
Akkor viszont minek az nVidia
, Full AMD-vel tudnál tutira menni. -
#40
hugo chávez
aktív tag
Abu85
#17
hugo chávez
aktív tag
Abu, én arra lennék kíváncsi, hogy, ha lesz mondjuk egy gépem, amiben Ivy cpu és diszkrét NV videókártya van és van egy játék, amiben OpenCL-es fizikai motor van, akkor lesz-e annak akadálya, hogy (természetesen, amikor majd az Intel OpenCL drivere támogatni fogja az Ivy IGP-jét is) heterogén módon az Ivy cpu-ján és IGP-jén menjen a fizika?
-
#39
huskydog17
addikt
Abu85
#27
huskydog17
addikt
Köszi szépen a választ!
Amúgy nálam most 10.12 hajtja a kis Radeon HD 5470-et, de a GPU-Z azt mondja, hogy nincs OpenCL támogatás, csak DirectCompute 5.0. Ez gondolom az OpenCL driver hiányából fakad.
Vegyünk egy konkrét példát: a legújabb WinDVD (benne van a cikkben lévő listában) támogatja az OpenCL-t. Ez ennél a szoftvernél azt jelenti, hogy a Post Process effektek már a GPU-n zajlanak, igaz? Ha igen, akkor ennélfogva a CPU terhelés nem fog nőni (vagy nagyon minimális, elhanyagolható mértékben) ha bekapcsolom ezeket a képjavító funkciókat. A legjobb az volna, ha a Trimension is így futna (elvileg interpolációs technológia, hasonló, mint a Splash Pro-nál a Motion). Csak hogy míg a Splash Pro a Motion esetében hatalmas CPU terhelést generál, addig a WinDVD elvileg klasszisokkal alacsonyabb CPU terhelés mellett képes erre ha jól gondolom.
Javítsatok ki ha túl nagy hülyeséget mondtam!#26: Neked is köszönöm, főleg a linket!
-
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. -
lenox
veterán
-
#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.
-
#34
FireKeeper
nagyúr
FireKeeper
nagyúr
radeon hd4000 esetében van esély az 1.1 támogatásra, vagy hardveresen nem tudja?
-
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.
-
lenox
veterán
Arra mondjuk kivancsi lennek, hogy cpu device kell nekik, vagy van cpu-s kod is. Pl. a mainconceptnek eleg husszu ideje van cpu-s kodja, szerintem a cpu-ra irt kodjuk gyorsabb a cpu device-on futtatott opencl kodnal, csak mert par eve mar van optimalizalva. Ez kulonben altalaban is igaz.
Kulonben lassan egyre kezzelfoghatobban latszik, hogy dedikalt gyors memoria nelkul eleg gyenge teljesitmenyt nyujt a gpu vagy apu, ahogy egy paran mar mondogattuk jo ideje. Szoval opencl-ben megveri a llano az sb-t, de egy gyenge kozepes grafkartyatol mar kikap. Na mind1, mint egy masik topikban is irtam, lassuk a teljes palettat arakkal, meg legyenek tesztek, aztan kiderul, hogy minek hol a helye. Mindenesetre felrevezetesnek erzem, amikor az a mondas, hogy Llano-val verjuk az SB-t, de egy par eves olcso cpu+vga kombo veri mindkettot ugyanabban. Pl. vreveal, azt ugye nem irtak oda, hogy a cudat mar regota tamogatjak, es diszkret vga-val sokkal gyorsabb
. -
-
#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. -
#26
FireGL
aktív tag
huskydog17
#22
FireGL
aktív tag
válasz
huskydog17
#22
üzenetére
Amíg az OpenCL-ben írt programoknak ez lenne a lényege, addig a működésükhöz szükséges driver(ek) gyártófüggőek. Ez is le is van írva a cikkben, és már rohadt sokszor volt erről szó.
Az AMD-től tudsz olyan olyan Catalyst drivert is letölteni amiben benne van, tudsz olyat is amiben nincs, és magát az OpenCL drivert is külön le tudod tölteni ha kell.
http://sites.amd.com/us/game/downloads/Pages/radeon_win7-64.aspx#2
-
#24
vinibali
őstag
huskydog17
#22
vinibali
őstag
válasz
huskydog17
#22
üzenetére
van APP-s és nem APP-s AMD driver, szerintem csak úgy magában nem lehet leszedni, értelme sincsen nagyon
mindenesetre nagyon erősnek hangzik az AMD "előnye", legalábbis nagyon jó dolog hogy már kiadtak egy olyan komplett platformot ami támogatja. viszont nagy csend van az Intelnél, szerintem nagy bombát készítenek -
#22
huskydog17
addikt
Abu85
#21
huskydog17
addikt
Nekem az OpenCL körüli mizéria nekem nem teljesen világos, így remélem megengedsz néhány kérdést ezzel kapcsolatban.
Maga a programnyelv gyártófüggetlen, vagyis minden OpenCL-t támogató grafikus processzoron működniük kell az ebben a nyelvben írt szoftvereknek. Eddig világos. Akkor hogy lehetséges az, hogy egy ilyen szoftver egy OpenCL-t támogató GPU-n nem, vagy csak korlátozott mértékben működik? Nem az volna a programnyelv lényege, hogy az ebben írt programok minden támogatott GPU-n ugyanolyan jól működjenek?Az OpenCL driver az AMD esetében magában a Catalyst meghajtóban van elhelyezve vagy esetleg külön is le lehet tölteni és telepíteni?
Egy OpenCL-t támogató videolejátszó úgy működne, hogy a film dekódolását az UVD/VP motor végzi és a Post Process effekteket pedig a GPU stream processzorai végzik?
Annak, hogy egy OpenCL szoftver heterogén módon üzemel, pontosan mik az előnyei a gyakorlatban?Elnézést kérek a sok kérdésért, de szeretném tisztázni magamban ezt a dolgot!
-
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.
-
HeavyToys
senior tag
Persze, ezt gondoltam. De ennél a kis teljesítményű rendszernél, sokat segíthet, például filmvágásnál, vagy bármilyen számítás igényes műveletnél, ha plusz számítási kapacitás áll így rendelkezésre. Talán még jobban észrevehető, mint egy amúgy is lényegesen erősebb CPU-résszel rendelkező egységnél.
-
Harlek
tag
"... az viszont biztos, hogy az NVIDIA nem fogja támogatni az AMD és az Intel processzorokat a meghajtóin keresztül."
Elnézést kérek az értetlenkedésért, de itt most az AMD és az Intel GPU-iról van szó, vagy CPU-iról? Mert ha GPU, azt tökéletesen megértem, de ha egy OpenCL Driver nem hajlandó biztosítani az AMD/Intel CPU és Nvidia GPU közötti munkát, akkor mi értelme a dolognak? Meg nem mintha lenne túl sok alternatíva CPU tekintetében.
-
#12
KevinMulder
tag
Ringman
#4
KevinMulder
tag
Igen. Az OpenCL főleg arra jó, amikor ugyanazon műveletet kell elvégezni egy adott memóriablokk elemein. Pl add össze az n és az m tömbök tartalmát,
z=n(i)+m(i) ahol i=0..255
Egy órajel alatt 256 összeadás, stb.OpenCL nem nagyon tolerálja az elágazásokat, mert a magoknak egyszerre kell futniuk. Ilyenkor az egyes ágak egymásra várnak.
-
#8
Petike1007
tag
Petike1007
tag
Jó ez...csak élhetné már a fénykorát
-
Stirlitz
senior tag
Örülök, hogy megjelent pár új program, de ez még mindig kevés. Fájdalmassan lassan terjed a technológia. Szakértőket kérdezném, elképzelhető-e az idővel, hogy diszkrét vga mellett, a prociba integrált vga mondjuk bonyolultabb fizikai modellt számoljon egy játékban pl?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Most vagy a fejlesztők is hülyének nézik az embert, vagy ez a technika tényleg nem a minőségről szól, csak én éltem álomvilágban 
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.
Remekbe-szabott cikk 
Új hozzászólás Aktív témák
Hirdetés
- Xbox Series X|S
- One otthoni szolgáltatások (TV, internet, telefon)
- Delta Force (2024)
- Sütés, főzés és konyhai praktikák
- lezso6: Nem látszik a kurzor Chrome alatt a beviteli mezőkben?
- Call of Duty: Black Ops 6
- Autós topik látogatók beszélgetős, offolós topikja
- Vezetékes FEJhallgatók
- Windows 11
- Xbox tulajok OFF topicja
- További aktív témák...
- Csere-Beszámítás! MSI Gaming X RTX 4060Ti 16GB GDRR6 Videokártya!
- Bomba ár! HP ProBook 430 G5 - i5-8GEN I 8GB I 256GB SSD I HDMI I 13,3" I Cam I W11 I Garancia!
- Prémium PC házak akár 20-40% kedvezménnyel eladók garanciával, számlával!
- PlayStation Network Card (PSN) ajándékkártyák, egyenesen a Sony-tól!
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060Ti 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest