- Samsung Galaxy A56 - megbízható középszerűség
- Vivo X200 Pro - a kétszázát!
- Yettel topik
- Telekom mobilszolgáltatások
- Samsung Galaxy S25 - végre van kicsi!
- Okosóra és okoskiegészítő topik
- Három Redmi 15 érkezett a lengyel piacra
- Android alkalmazások - szoftver kibeszélő topik
- One mobilszolgáltatások
- Samsung Galaxy Z Flip5 - ami kint, az van bent
Hirdetés
Ú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. -
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. -
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. -
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.
-
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.
-
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.
-
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". -
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.
-
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.
-
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. -
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...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
). Addig sok dolog változhat.
Új hozzászólás Aktív témák
Hirdetés
- Spórolós topik
- E-roller topik
- Samsung Galaxy A56 - megbízható középszerűség
- WoW avagy World of Warcraft -=MMORPG=-
- ASUS notebook topic
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Azonnali fotós kérdések órája
- LG LCD és LED TV-k
- Először égett le egy újságnál a GeForce RTX 5090
- Philips Hue – az okos lámpák királya
- További aktív témák...
- Eladó SAMSUNG Odyssey G3 LS24AG320NRXEN 24'' Sík FullHD 165 Hz 16:9 FreeSync VA LED Gamer monitor
- Csere-Beszámítás! Ajándék ROG Táska! Asus Rog Ally Z1 Extreme RC71L - 512GB SSD + 16GB LPDDR5
- HP EliteBook 840 G8 i5-1135G7 16GB 512GB 1 év garancia
- Eladó karcmentes Realme 7i 4/64GB / 12 hó jótállással
- Eredeti Microsoft Windows 10 / 11 Pro OEM licenc Akciós áron! 64/32 bit Azonnali kézbesítéssel
Állásajánlatok
Cég: FOTC
Város: Budapest