Hirdetés
- Plazma TV topic
- A HBM helyére HBF-et kínálna a SanDisk
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- AMD Navi Radeon™ RX 7xxx sorozat
- Fejhallgató erősítő és DAC topik
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Házimozi belépő szinten
- Milyen billentyűzetet vegyek?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Fujifilm X
Új hozzászólás Aktív témák
-
Cooley18
aktív tag
Majd egyszer talán lesz Frame Pacing DG-re. Gondolom először a fontosabbakat csinálják meg. Bár még úgy alapvetően van mit javítani a Frame Pacing-en, de legalább már használható szintet produkál.
Nem lenne amúgy hülyeség, de én személy szerint több fantáziát és kevesebb problémát látok abban, hogy az IGP besegít az általános számításokba, míg a dVGA csak a grafikára koncentrál. -
Kroni1
veterán
válasz
Cooley18
#307
üzenetére
Persze, csak azt akartam mondani h ez igy nem az igazi! A ddr5-öt is az árak tarthatósága miatt vetették el.. A jelenlegi tesztek szerint sok értelme nincs a Dula Graphicsnak, mert hiába magasabb az fps, de sok a laggolás, magasak a frametime-ok, érdemesebb a dVGA-t külön dolgoztatni..
[ Szerkesztve ]
-
Cooley18
aktív tag
És akkor milyen vezérlő fogja vezérelni a vram chipeket az IGP számára?
Talán ha a GPU memóriavezérlőit érné el valahogy az IGP, ami szerintem jelenleg nem kivitelezhető, viszont akkor feleződne a sávszél és a vram mennyisége is, szóval ott vagyunk, ahol a part szakad... Dedikált GDDR5-ös chipek kellenek az IGP-nek, amiről volt is szó, de aztán eltűnt a süllyesztőben. A 4 csatornás memóriavezérlő társítva DDR4-es modulokkal lenne az igazi! 
[ Szerkesztve ]
-
Szerintem aminek több értelme lesz az az aszinkron együttműködés a dVGA és az IGP között. (előbbi grafikázik, utóbbi tehermentesíti a cpu részt bizonyos dolgok átvállalásával, fizika, stb.) Remélem hamarosan kiderül, hogy mit lehet ettől várni Mantle alatt.
DG sosem volt az igazi, ahogy olvasom és talán nem is lesz. Gondolom elég nehéz driverből összehangolni a különböző erősségű igp-t és vga-t, hogy ne legyenek fura akadások benne.
-
Kroni1
veterán
Ha megnézed az előző hsz-emben a linket, ott pont ez van! Csináltak DG tesztet a (6800k-val) 6670-es és 7750-es VGA mellett is, és tényleg gyorsult is, csak engem a videokon látható akadozás, és magas frametime-ok eléggé megilyesztettek, úgy látszik ez a DualGraphics sem az igazi még..
Lehet úgy kéne, (nem tudom AMD hogy csinálja, lehet h igy is van) hogy ha raksz mellé dVGA-t akkor a lassú rendszermemória kiessen a képből, mert szerintem ez a hiba oka, és ha mondjuk egy 2GB GDDR5-ös memóval szerelt 7750-es dVGA-t teszel mellé akkor a rendszermemo maradna a gépnek, és a VGA-n lévő az meg elég lenne a 2 GPU-nak..
-
Kroni1
veterán
Na ezt jó tudni, én is valami ilyesmire gondoltam.. Kiváncsi leszek mit fog majd tudni a Kaveri DG-ben, a PH tesztben már a Trinity is egész jól skálázódott, de a tomshardware tesztben kevésbé volt látható az előnye, sőt igen magas frametime-ról meg ilyesmiről írnak.. Az még fura nekem, hogy 7750-el is csináltak DG tesztet és gyorsult tőle a 6800k..
Ezek szerint akkor már ez is megy a 7750-el csak nincs rajta a hivatalosan támogatott VGA-k listáján? [ Szerkesztve ]
-
Kroni1
veterán
Van már róla esetleg valami biztos infó hogy melyik dVGA-val fog a Kaveri menni Dual Graphics módban? Lehet volt, csak én nem találtam..
Valaki írta, hogy úgy tudja ez is csak a 6670/7670-et támogatja majd csak maximum, ami eléggé elkeserítő lenne szerintem. Tudom, h teljesítményben nem rossz, de én egy ilyen nagyjából ~7750 szintű GCN-es IGP-vel rendelkező, 28nm-es APU mellé szívesebben tennék egy szintén 28nm-es GCN-es 7750-et, vagy akár nagyobbat mintsem egy 40nm-es 6670-et..
-
korcsi
veterán
Az első oldal táblázatával kapcsolatban:
A Richland-ben helyenként fellelhető információ szerint 24 textúrázó van nálatok 48, Trinity-re a gpuz szintén 48-at ír, de szerintem ez nem pontos, vagy rosszul tudom. Illetve számomra kérdéses még, hogy tényleg lesz e 16 ROP a Kaveribe?
-
stratova
veterán
válasz
pakriksz
#292
üzenetére
Azért 4 magot egyre több program használta ki és mivel 2 modul ~1.6 mag teljesítményét hozta, szvsz az FX-6000 szériának volt/van leginkább létjogosultsága.
Egyébként tiszta sor, hogy AMD arra a vonalra akarja átterelni a terhelést (GPU), amiben erősebb. Csak kicsit rizikósnak tűnik ez átmenet nélkül. Pl. nem kapna Steamroller magokat az FX széria, de Piledriver 32 nm frissítést igen. Ha az Opteronok kapnak, ez még csak nem is külön fejlesztési költség asztali vonalra.[ Szerkesztve ]
-
bayarena
aktív tag
válasz
Oliverda
#289
üzenetére
Ez igaz, de ha nem folytatják az fx szériáját, akkor azért el tudnék képzelni egy ilyen 8 magosat, mondjuk 140w-al, ami még nem olyan nagyon sok, főleg nem az 5GHz-es fx-ek fogyasztásához képest.
A "sima" 4 magosak meg persze kisebb TDP-vel lennének.
Bár az is lehet, hogy nem akarnak a megmaradt fx-nek konkurenciát állítani házon belül. Ez is egy szempont. -
M@trixfan
addikt
Komponensekből épített gaming PC továbbra is kell. Egyetértek az előttem szólókkal akik szerint ez nagyon kevés. Nagyon nehéz dolog ez, mert a legtöbben alkalmi játékosok vagyunk már igazából az egyébb kötelességek miatt. Azonban ez korántsem azt jelenti, hogy gyenge minőségben, esetleg flash játékokkal szeretné az ember eltölteni a játékra szánt időt. Épp ellenkezőleg, tökéletes élményre vágyom, minél jobban szeretném maximalizálni a ráfordított időt. Én annyyira a fogyasztástól sem vagyok elájulva, megdöbbentően keveset fogyaszt üresjáraton egy i5 konfig. Ha meg már dVGA kell akkor meg simán kiesik nálam az AMD processzor. Megterhelve +100W nem szimpatikus és még nem is teljesít olyan jól. Még egy dedikált HTPC-be el tudnám képzelni, de ott mindenek felett az dönt hogy mennyire helyes a 23.976.
-
Abu85
HÁZIGAZDA
És ettől a tudattól mitől lesz jobb? Már bejelentette a támogatását az EA-től a DICE, Bioware, Visceral Games, PopCap, Ghost és Criterion Games fejlesztőbázis, illetve a Rebellion, az RSI, az Oxide és a Nixxes. Ez azt jelenti, hogy nagyjából 20+ jelenleg fejlesztett játék biztosan kezeli. És akkor még lehet, hogy nem tudunk mindenkiről.
Ekkora fejlesztői hátszelet én rég láttam bármi mögött. Talán a 3dfx esetében az első Glide tudta így megmozdítani a fejlesztők fantáziáját.
Ha nincs reakció a Mantle-re és a támogatására sincs szándék, akkor egy nagyon logikus út a felhőbe menni.[ Szerkesztve ]
-
#276
martonx
veterán
BlueAthlon
#24
martonx
veterán
válasz
BlueAthlon
#24
üzenetére
"Nagyjából nagyságrendileg mennyi előny realizálható belőle így 3D-s szórakoztató célú alkalmazások esetén ?" - ha egycélprogram direkt ezeknek az APU-knak a kihajtására optimalizálódik, akkor akár 10-100X-os előnye is lehet. Ha valami viszont szimpla DirectX-re, vagy OpenGL-re íródik, akkor semmi. A Mantle érdekesen megbolygathatja ezt, mert ezzel megoldható lesz, hogy valami DirectX-el is jól menjen, miközben AMD APU-n 3X olyan jól fusson.
-
Abu85
HÁZIGAZDA
Semmiképp. Azért az senkinek sem jó, ha a PC-n is előkerül az abszolút exkluzivitás. Vagy bárki úgy gondolja, hogy a többiek beállnak Mantle-t támogatni? Előbb építenek ki többezer szervert a világban felhős játékra.
[link] - Itt Repi ad egy kis extra adatot a Mantle-ről. Lesznek olyan játékok, ahol csak a teljesítménynövelésre mennek rá, lesz ahol a grafikára, és lesznek olyanok is, amelyek új dolgokat tesznek lehetővé.
[ Szerkesztve ]
-
-
mzso
veterán
"Persze, lehet ilyet csinalni, csak azt nem latom, hogy mennyire eri meg, ugy ertem eleg kis resze lehet a usereknek akik amd apu + amd dvga komboval nyomulnak."
Tyúk/tojás. Ha az AMD egy pár egyébként konzol exklúzív fejlesztő alá tol egy kis pénzt, hogy ugyan már egyúttal portolják PC/mantle/hsa-ra is a kódot és megszaporodnak az ilyen címek akkor az AMD APU+VGA PC-k száma is megugorhat. Aztán vagy portolják DX-re is a fejlesztők vagy nem.
Én legalább is így járnék el az AMD helyében. (Amellett hogy jól összehaverkodnék a Valve-val a Steam Box ürügyén)
-
-
Zoli0726
aktív tag
Nem, egyelőre csak ő kritizál engem, egy olyan kódról ami rossz, bár sosem látta
Peak/peak nem jön ki? Kész, mivel minden kód pont ugyanazokat a műveleteket hajtja végre, mint a peak számolás, float összeadást + szorzást, ezért lehetetlen, hogy ennél jobb arányt kapjak.
Tény, hogy az opencl-es kód megkérdőjelezhetően optimális cpu-n, viszont semmiképp sem érzem úgy, hogy irreleváns dolgot mondtam volna, tekintve, hogy a linkelt algoritmusokban is volt 33x-os gyorsulás is.
Egyszerűen azok a feladatok a gpu-nak feküdtek, ha annyira, hát annyria. Ha baki lett volna benne, már rég észrevették volna, mivel amint mondtam, mi nem aknakeresőt írunk. Ezzel együtt nem kicsit nagyképűen azt állítod, hogy az velem együtt az összes munkatársam is béna, és te mennyivel jobb vagy csak azért, mert a gpu egy feladatban, aminek sem az elméletét sem az implementációját nem ismered, el tudott húzni ennyivel. Ezzel együtt leszarozod a computebench dolgozóit is, mert nekik 33x-os teljesítménytöbblet is kijött, amiben ha másfélszeres overhead van, még úgy is kijön amiről beszéltem.
Ezzel én ezt a latolgatást befejeztem, amint az látható úgy sem fogunk megegyezni.Azt, hogy nem láttál gpu-t egyáltalán nem neked szántam. Nem te írtad, hogy egy corei7-t sosem lehet gyorsabb mint egy kaveri. Az oda volt címezve, de ezt már mondtam egyébként is.
[ Szerkesztve ]
-
lenox
veterán
Nem, valoban nem tudunk, de ez egy felesleges irany, nyilvan azt kifogasolom, ha azzal jon valaki, hogy nem lattam meg gput. Az a resze, hogy milyen speedupot erdemes varni cpu vs gpu viszonylatban, milyen bottleneckek lehetnek, es ott melyik milyen gyors az szerintem kevesbe felesleges.
-
lenox
veterán
Hat ha mar programozo versenyt akarna valaki, akkor en pl. ezt ajanlanam:
http://projecteuler.net/
Sokkal tobb ertelme van, mint egy feladaton szarakodni, legalabbis magam reszerol sokkal ertekesebbnak tartom, ha valaki 3 clock sporolas helyett algoritmikusan tud jot csinalni sokfele problemara.
-
-
lenox
veterán
válasz
Zoli0726
#248
üzenetére
írni nem írok,
Nyilvan a local mem-be iras soran kerul adat, errol az irasrol beszeltem. Amikor mar benne van es mindenki csak olvassa nem kell szinkronizalni. Amikor eloszor masolod globalbol localba akkor kell.
Egyébként én nagyon úgy érzem, hogy elkanyarodtunk arról, hogy nem csak a cpu/gpu peak a lényeg, hanem az adathozzáférés, ami gpu esetében jobb.
Lehet errol is beszelni. Cpu-nal alapvetoen a regiszterekben levo adatokbol kellene dolgozni, ahol nem kell az adatra varni, tehat ez megy pl. full 4 GHz-cel. Nyilvan van, hogy level1 cache-t kell elerni, akkor van kulonbseg, de azert van 16 xmm register, hogy ne minden egyes utasitasnak kelljen level1 cachet olvasni. Szoval szerintem egy jol megirt kodban altalaban nem fog kijonni ide 2-szeres szorzo. Amugy valoban sp floatokat tekintve nehalemnel 4 byte/clock az olvasasi sebesseg egy feldolgozora vetitve, mig pl. 7750-nel 8 byte/clock. Ebbol azt hihetned, hogy valoban szorozni kell kettovel, csakhogy a valosagban ez nem igy mukodik. Ha valoban ez a sebesseg a bottleneck, akkor a nehalem vs 7750m eseten (figyelembe veve, hogy az i7 3.33 GHz-en a 7750m meg 575 MHz-en megy, 3330/575=5.8) az arany (512feldolgozo * 8 byte )/( 4core * 4feldolgozo * 4byte * 5.8)=11, szoval kb. ugyanaz az arany, mint a peak gflopsnal.
-
Zoli0726
aktív tag
Csak olvasok, írni nem írok, miféle hülyeség lenne már, hogy 2 work-item ugyanarra a helyre írja az eredményét. Természetesen az olvasás is úgy van megoldva, hogy eltoltan olvassák a work-itemek a tömböt, hogy ne legyen adathozzáférési probléma. Az eredmény elfér egy változóban is. Szinkronizálva nincs, de kb 0 az esélye, hogy ugyanabban az időben ugyanazt az adatot próbálná meg olvasni két work-item. Annyira azért nem gyakoriak az olvasások a sok számolás miatt. Ahhoz valakinek a 256 közül nagyon be kellene gyorsítani. Nem vizsgáltam ilyen szempontból a dolgokat, de ha 1-2 fennakadás még lenne memória olvasás miatt, annyit a szink is rontana.
Egyébként én nagyon úgy érzem, hogy elkanyarodtunk arról, hogy nem csak a cpu/gpu peak a lényeg, hanem az adathozzáférés, ami gpu esetében jobb.[ Szerkesztve ]
-
lenox
veterán
válasz
Zoli0726
#244
üzenetére
De erre az a bevett szokas, hogy mondjuk van 4096 adatod, 256 threaded, mindegyik thread beolvas 16 adatot, utana szink, es maris elerheto mindenkinek mind a 4096. Szink nelkul nem tudom, hogy lehet ilyet csinalni, illetve olyat nyilvan lehet, hogy minden thread mind a 4096-ot olvassa es irja a local mem-be, csak nem tudom miert lenne jo igy csinalni.
A cpu kód meg természetesen nem akkor optimális mint a gpu, de senkit nem érdekel, mikor optimális az opencl kód cpu-n ha úgyis a gpu-n akarom futtatni.
Ezt csak amiatt irtam, hogy a linkelt eredmenyek ertelmezesenel erdemes figyelembe venni, hogy egy cpu optimalis kod joval gyorsabb az ott mert sebessegnel. Termeszetesen ha van olyan opcio, hogy gpun futtatsz, akkor a cpu kodot felesleges gyurni, amugy is sokkal idoigenyesebb. Csak erdemes tudni, hogy esetleg egy sok alkalommal hasznalt szoftver eseteben (mint pl. egy jatekmotor) azert van valoszinusege, hogy lesz aki megcsinalja.
-
Zoli0726
aktív tag
Tényleg nem érted, de lehet, hogy én fogalmaztam érthetetlenül.
Vannak adataim, minden work-item-nek végig kell magát zongorázni rajtuk. Egyszerűen, csak annyit csinálok, hogy a globálisból a lokálisba másolom, és ott zongoráztatok, mivel belefér. Bekerülnek lokális tömbökbe. Tehát a teljes tömbön végig kell menni minden work-itemnek. Viszont ahhoz túl nagy, hogy minden work-itemnek odamásoljam a teljes tömböt, egy köztes megoldás az, hogy akkor a lokálisba másolom, bár közösködni kell, de onnan mégiscsak gyorsabb az elérés, mint a globálisból. A cpu kód meg természetesen nem akkor optimális mint a gpu, de senkit nem érdekel, mikor optimális az opencl kód cpu-n ha úgyis a gpu-n akarom futtatni. A feldolgozásnál ettől függetlenül nem befolyásolják egymást a work-itemek, így értem a függetlenséget, tehát nincs szükség szinkronizációra. Remélem így már világos. -
lenox
veterán
válasz
Zoli0726
#242
üzenetére
Tovabbra sem ertem. Az elobb azt irtad, hogy az adatok fuggetlenek, nem osztoznak rajta a work itemek, most meg megis osztoznak? Ha osztoznak, akkor kene szinkronizalni. Ha nem osztoznak, akkor hasznalhatnad a regiszterfilet. Amugy az vilagos, hogy van olyan implementacio, ahol a local memory akar 6-szor lassabb a regisztereknel?
[ Szerkesztve ]
-
-
Zoli0726
aktív tag
Nagyon egyszerűen. Szinkronizációra nincs szükség, az adatok egymástól teljesen függetlenek. Ahogy az eredmények is. Lokális memóriát úgy használok, hogy az adatokat a globálisból a lokálisba másolom, és attól kezdve local id-val idexelek. Illetve a változók is lokális memórában tömbök, így függetlenül elérhetik őket a work itemek. Szerencsére belefértek a keretbe. Ez egy bevett szokás:
http://www.openclblog.com/2011/03/is-your-local-memory-really-local.html?m=1 -
lenox
veterán
válasz
Zoli0726
#236
üzenetére
Hogy hasznaltal local memoryt szinkronizacio nelkul? Nyilvan nem ugyanaz a kod optimalis cpun es gpun, szoval azert mert a local memory hasznalata eseten a linkeden sokkal gyorsabb a gpu, az nem jelenti azt, hogy ez a leggyorsabb kod cpun. De amugy a sajat programod eseten is lassabb volt az opencl cpun, mint a c kod, szoval ez nem kellene ujdonsag legyen.
Inkább nekem kellene a te kódjaidat megnéni, ha számodra ezek az, eredmények Ennyire hihetetlenek. Persze nvidia openclben le van maradva mint a borravaló, a cuda meg király, de kevésbé gyors.
Nyilvan lenne mit tanulni belole
. Biztos nehez kikovetkeztetni, de az amd miatt openclezek elsosorban.#237:
Persze, lehet ilyet csinalni, csak azt nem latom, hogy mennyire eri meg, ugy ertem eleg kis resze lehet a usereknek akik amd apu + amd dvga komboval nyomulnak.
[ Szerkesztve ]
-
mzso
veterán
Ez alól kivétel lehet az AMD pénzelt konzol port. Az lehet eredetileg közös mem címtérre optimalizált, meg eleve valami Mantle szerű API-ra készül.
Gondolom viszonylag egyszerűen, kevés energiával lehetne protolni desktop APU-kra és mantle API-ra (És opcionálisan a grafika részét dVGA-n (is) számítani). Ahhoz képest, hogy újra kéne írni az egészet Directx-re és csak CPU-n futó algoritmusokra. -
Zoli0726
aktív tag
Nem azt jelenti, hogy így össze kell szorozni, hanem azt, hogy valszeg nálam ennyit jelentett, de igazoltam is, mennyit jelent a lokális memória használata a fenti linkben, amiből az következik, hogy sokat, tehát elérhető Velük az a teljesítmény amiről itt szó van. Tehát nem minden a gpu peak/cpu peak. Azzal a CPU kóddal meg az égvilágon semmi baj nincs, hidd el ülnek még mellettem a munkahelyen olyanok, akik már akkor,programoztak, amikor én még csak a kallofdjutit ismertem a gépen, nem találtak benne kivetnivalót. Nem mentem át assembly-be optimalizálni,de logikailag korrektül volt felépítve, azóta meg ha csak lehet gpu-zunk. Inkább nekem kellene a te kódjaidat megnéni, ha számodra ezek az, eredmények Ennyire hihetetlenek. Persze nvidia openclben le van maradva mint a borravaló, a cuda meg király, de kevésbé gyors.
[ Szerkesztve ]
-
lenox
veterán
válasz
Zoli0726
#234
üzenetére
Ez eleg erdekes megkozelites, szoval a savszelesseg es a peak performance-ok hanyadosat ossze kell szorozni? Vagyis ha duplara novelem a memoria savszelesseget es mondjuk megketszerezem a feldolgozok szamat, akkor a varhato teljesitmeny negyszeresere no, jol ertem?
Mint mondtam, ha konkrétan alá tudod,támasztani, hogy amit mondtam kivitelezhetetlen, akkor hallgatlak, addig viszont a trollkodásodra nem figyelek tovább.
Biztos nagyon nehezen erthetoen fogalmaztam, megprobalom mashogy. A cpu kododnal nagy valoszinuseggel lehet gyorsabbat irni. Ha esetleg van kedved privatban elkuldheted, ha lesz ra idom, megnezem.
-
Zoli0726
aktív tag
Csak a te kedvedért:
https://compubench.com/compare.jsp?config_0=13875409&config_1=13503874
Egyébként te mint gpu programozó tudhatnád, hogy nem csak számítási teljesítményben erősek a gpuk, hanem az adat elérésében.
Ez is nagyons sokat jelent. Gpu\cpu 10x +adatelérés 2,5, meg is van, amit a fenti link is,igazol.
Nem is értem miért próbálod azt mondani, hogy csak a gpu számít, és mindegy lenne ha 7970 mellett ddr3 van. A memória sávszélességét és késleltetését vedd figyelembe.
De te egyébként mindent csak megcáfolsz, a saját szabadon kívül meg semmit nem tudsz alátámasztani. Mint mondtam, ha konkrétan alá tudod,támasztani, hogy amit mondtam kivitelezhetetlen, akkor hallgatlak, addig viszont a trollkodásodra nem figyelek tovább.[ Szerkesztve ]
-
lenox
veterán
válasz
Zoli0726
#229
üzenetére
Sikerült egy jó gpu-s kódot írni, és még én vagyok a béna, biztos elrontottam valamit
,Ez mar a sokadik ferdites, pont a gpus kododra nem mondtam meg semmit. A peak performance es az altalad linkelt szamok alapjan is nyilvanvalo kene legyen, hogy a cpus kodod hatekonysaga kisebb, mint a gpus. Miert kene erre ramondjam, hogy optimalis, mikor gyanus, hogy nem az?
-
Prof
addikt
válasz
SSJPiotr
#202
üzenetére
Es jol is tetted. Rengetegen nem birjak megerteni, hogy a PC jatek nem a fix 60 fps-rol es az aktualis 3-5 db hype techdemo jatekrol szol 4K eyefinity-vel 8X-os elsimitassal.
Ha konzolon eleg a HD felbontas, akkor a PC-n is. Plane annak aki nem akar egy vagyont a gepre kolteni.
Kb. a jatekok 2%-nak keves FullHD-ba az APU, azoknak pedig 1-2 darabja kb. annyiba kerul mint maga az APU.
Azt varni, hogy valami egi csoda folytan a 1kg-os feltegla VGA kartya hirtelen belefer egy CPU-val egyutt egy kis chipbe az nem csak naivitas, hanem hulyeseg
Az meg ne szidja az AMD APU-t aki veszi a draga PC-s hardvert a 10-15ezres aktualis Bf4 stb. hype DLC-t meg lewarezolja.
Az olyan, mint a szlovakrendszamos, Ferraris magyar zaszloval a visszapillanton, aki sose fizetett adot -> koztorvenyes bunozo.[ Szerkesztve ]
-
Zoli0726
aktív tag
Azt bizonyítja, hogy az opencl-es megvalósítás nem volt jobb, mint a c, mégis gyorsabban lefutott a gpu-n, igazából a kódrész szinte teljesen megegyezett, valszeg az optimalizáció nem tud olyan jó lenni opencl-ben mint a g++ -Ofast.
Igazad van, apu-nál már majdnem ugyanaz a zero copy, mint az egységes címtér. Ettől függetlenül a bemenő buffert akkor is létre kell hozni, csak mutatókból fog állni.
Miféle normál feladat nem lesz ilyen mértékű gyorsulás? Nem értelek. Mi a csuda az, hogy normál feladat? És ki beszélt itt normál feladatról? Úgy hangzott mintha én egy aknakeresőn próbáltam volna ki? Nem ott. Arról, hogy más környezetben mekkora lesz a gyorsulás egy szót sem mondtam, viszont azt elismertem, hogy feladat válogatja és az függvény szinte gpu-ra lett kitalálva.
Sikerült egy jó gpu-s kódot írni, és még én vagyok a béna, biztos elrontottam valamit , a 975/7750M elméleti teljesítménye, illetve a fentebb linkelt alogritmusok is azt bizonyítják, hogy igenis elérhető ilyen mértékű gyorsulás, ezek után vagy bizonyítsd be, hogy nem, nem érhető el, vagy akkor magadat minősítsd. -
lenox
veterán
válasz
Zoli0726
#227
üzenetére
Llanonal vram? Meg pci busz? Biztos tudod, mi a zero copy?
Nyilván mindenki szar, csak te vagy király, én meg abban lelem örömömet, hogy fórumokon összehazudozzak mindenfélét, meg szar c kódot írok. Nem birom az ilyet.
Hat a fentiek tekinteteben elgondolkoztato, de nem mondtam ilyet. De amugy nem te kezdted ugy, hogy nem lattam meg gpun futo kodot? Azt birtad?
Ugye tudod, hogy opencl-t cpu-n is lehet futtatni, gondolod nem próbáltam ki, de igen, kipróbáltam, és még rosszabb eredményt kaptam cpu-val.
Ez nem tudom mit bizonyitana vagy mit cafolna.
törődj bele, hogy más is lehet sikeres, nem csak te.
Ezt mar vegkepp nem ertem. Nagyon sok nalam sikeresebb ember van. Mondjuk ennek nincs koze ahhoz, hogy gpu-hoz ertenek-e, vagy cpu-ra gyors vagy lassu kodot irnak.
Egyébként meg naná hogy lehet 40+x-es gyorsulás, csak a 7750m helyére egy desktop gpu kerül. 7970-nel jóval több is.
Oke, de vannak akik cpura is eleg jo kodot tudnak irni. Sok feladat van, amikor gpu-ra konnyebb jo kodot irni, ez igaz. Olyan is van, amikor kb. csak peak power szamit. De azert egy atlagos feladatnal nincs ilyen speedup.
[ Szerkesztve ]
-
Zoli0726
aktív tag
Nyilván mindenki szar, csak te vagy király, én meg abban lelem örömömet, hogy fórumokon összehazudozzak mindenfélét, meg szar c kódot írok. Nem birom az ilyet. Mint ahogy szerinted a zero copy = azonos címtér, másolgassad csak a mutatóidat és hivatkozzál a ramba a pci buszon keresztül, mikor még az is drámai gyorsulást hoz, ha nem a vramot, hanem a lokális memóriát használod.
Ugye tudod, hogy opencl-t cpu-n is lehet futtatni, gondolod nem próbáltam ki, de igen, kipróbáltam, és még rosszabb eredményt kaptam cpu-val. Egyébként sem az a proci volt, amit belinkeltem, hanem egy i7 975 extreme, de gondoltam, ha lúd hát legyen kövér. Erre te elosztottad a 72-t 3mal..., törődj bele, hogy más is lehet sikeres, nem csak te.
Egyébként meg naná hogy lehet 40+x-es gyorsulás, csak a 7750m helyére egy desktop gpu kerül. 7970-nel jóval több is. -
lenox
veterán
válasz
Zoli0726
#218
üzenetére
Nem biztos, hogy ertem, bemondtal egy 24-szeres gyorsulast i7 extreme vs kis laptop gpu. Melyik linkelt eredmenyben volt a gpu 24-szer gyorsabb? Ja, hogy semmelyikben... Hat errol van szo... Mondjuk olyan szar c kodot nyilvan lehet irni, aminel 24-szer gyorsabb lesz egy 7750m, csak ez nem a cpu hibaja...
[ Szerkesztve ]
-
Zoli0726
aktív tag
[Link]
Aha, melyik algoritumsban is volt gyorsabb a core-i7 a szekvenciális kívül? Ja, hogy semelyikben
Az viszont tény, hogy az egy nagyon jól párhuzamosítható rész volt, 0 szinkronizálás, sok-sok szál.#216 Már megint ezzel jössz, fogd már fel, hogy nem csak az felhasználó, aki a gépe előtt a facebook-ot nézegeti. Az ilyen felhasználó nem fog belőle profitálni, ők a szuperszámítógépből, meg a cudá-ból meg a 64 bitből sem profitálnak, mégis megszülettek ezek a dolgok, és hasznosak és elterjedtek.
És már azt is leírtam 2 hozzászólással feljebb, hogy miért nem mindig jó a dvga, és lehet hatékonyabb egy huma-s apu
[ Szerkesztve ]
-
-
lenox
veterán
válasz
Zoli0726
#209
üzenetére
Az ezzel a baj, hogy mar a llano is gyorsabb. Es mondj egy peldat olyan algoritmusra, amit hasznalnak jatekban, es zero copyval nem oldhato meg, de majd a kaveri megoldja. Szoval ha akarta volna valaki mar evek ota hasznalhatna. Masreszt tovabbra is tartom, hogy nem fogja magat labonloni az amd azzal, hogy az i7 usereket beszopassa, szerintem nem erdekuk. Amugy is a dgpun is lehet azert sokmindent futtatni, szoval ha gpgpuzni akarnak az is megoldhato, plane egy amd gpuval.
I7 extreme vs kis laptop tema az azert gyanus, ilyen gyorsulas nem szokott lenni, szoval gyanus, hogy algoritmikusan is el volt cseszve valami az i7-en. Es szerintem van valamennyi tapasztalatom, 2003 ota gpguzok, 2007 ota cudazok, 2010 ota openclezek. Iden k6000 es k5000m marketing eventhez is hivott az nv, szoval ok is elhiszik, hogy ertek hozza, persze masnak ettol meg nem kell.#214 Mar reg kinyilt, zero copy, akit erdekelt mar akkor is hasznalta.
[ Szerkesztve ]
-
Zoli0726
aktív tag
A te gépeden
Aki gpgpu programozással foglalkozik annak meg egy újabb kapu nyílik ki, amit örömmel fog használni.
Ahhoz meg egyértelmű, hogy idő kell, hogy az első eredmények megszülessenek, emiatt senki sem hibás, így működik a világ. De biztos ezt akarod hallani: megéri kaveri aput venni ma egy mezei usernek? Az egységes címtér miatt biztosan nem, nincs a vagy nem lesz a közeljövőben olyan program, ami ki fogja használni.
Aki meg a maga hasznára fejleszt az meg fogja venni a fejlesztés elkezdéséhez.#213 Rendben, akkor ne vegyél játékra kaveri aput. Biztosan az összes motort pontosan azon az elven írták meg, amit te itt felvázoltál, és még csak véletlenül sem lehet másképp, nem egyet-kettőt, az összeset.
Az meg, hogy ezek a programok hány szálat használnak ki azt egy cpu skálázódásból jól lehet követni, ha egy 8 szálas fx meg tudja közelíteni a core-i5 ök teljesítményét, amitől szál/szál arányban jócskán lemarad, akkor igenis képes a motor a 8 szálra.[ Szerkesztve ]
-
Loha
veterán
válasz
Zoli0726
#209
üzenetére
Azért az is túlzás, hogy egyedül a bf használ ki négy magot Ott Dirt3 stb, vagy grid2, far cry, cryengine, tomb raider, asassins creed, metro.
Egyáltalán nem túlzás, de 4+ magra gondoltam a BF esetében. Amiket itt felsoroltál játékokat, azok főleg abba a kategóriába tartoznak, amiknél az AI-t, fizikát, hangot, stb. szétdobták külön szálakra, hogy a főszálnak jusson egy teljes CPU mag, de a játék nem képes egyenletesen kihasználni 4+ magot és azonnal CPU limitbe ütközik, amint a proci egyszálas teljesítménye nem elegendő. -
Zoli0726
aktív tag
Tény, viszon amint azt már említettem, kis feladatot nem éri meg dgpu-ra bízni még akkor sem ha párhuzamosítható, látsd:
ciklus 1000000x{
másolás
kernel hívás
visszamásolás
} ciklus végeilyenkor hiába hívod meg sokszor a műveletet mindig ott lesz az a toldalék, ami miatt már nem éri meg a gpu-t bevetni, viszont egy apunál, ahol a címtér egységes, csak a számolás marad. Kicsin kicsit nyersz, de ha sokszor kell megismételni akkor már számítani fog.
[ Szerkesztve ]
-
Zoli0726
aktív tag
"i7től szerintem a valós használatban sohasem lesz gyorsabb a Kaveri APUk bármelyike."
A személyes stílus erre vonatkozott.
A kaveri apu nagyobb számítási teljesítménnyel rendelkezik mint a leggyorsabb i7, ezt a programozó vagy kihasználja vagy nem, de ez már az ő sara.
Pont ez a hozzáállás ment anno a munkahelyemen. Sokrészecskés szimulációnál egy lépés tette ki a futási idő 95%-át. Futott is vagy 3 napig corei7 extreme-en. Én meg gondoltam egyet, és megírtam a függvényt opencl-ben, és a kis laptopomon elindítottam, láss csodát, 3 óra alatt megcsinálta. Ekkor mondta mindenki azt, hogy hoppá! Mégiscsak megérné kiszakadni a 10 éves programozási módszerek alól és valami újat tanulni.
Ezért érdemes akkor dobálózni az ilyesmivel, ha már kipróbálta valaki.
Nyilván mint minden, ez sem mindig jön be. Egyrészt vannak olyan esetek, amikor nem érdemes vele foglalkozni, pl word, total commander, nagyjából mindegy min fut, nem kell várakozni. Sok számolást igénylő dolgoknál viszont már fontosak ezek a dolgok, persze előfordul, hogy nem lehet párhuzamosításhoz nyúlni, de ilyenkor a készítők ezt már jól átgondolják, illetve a játék, ahol kritikus, hogy a képkocka időben a képernyőre kerüljön. Azért az is túlzás, hogy egyedül a bf használ ki négy magot Ott Dirt3 stb, vagy grid2, far cry, cryengine, tomb raider, asassins creed, metro. Az meg hogy van egy skyrim aminek őskori motorja van felcicomázva, vagy egy cod, ami őskori grafikát vonultat fel crysis3 gépigénnyel már nem az apu hibája. -
válasz
Zoli0726
#206
üzenetére
"a másik házon belül szeretné használni, a saját érdekei motiválják. tipikusan ilyen szerintem a pénzügy, ahol az elemzések és adatok feldolgozása nem kevés számítással jár, tehát bevett szokás gpgpu-n számítani ezeket, ezekre már rég megszülettek az implementációk."
Ezek mind rendkívül számításigényes feladatok, amikre külön dedikált VGA(kat) használnak.
-
Zoli0726
aktív tag
válasz
sad_Vamp
#205
üzenetére
2 féle program, vagy programozó létezik:
az egyik azért írja a programját, hogy eladhassa, tehát másnak készül, nem cégen belül lesz felhasználva.
a másik házon belül szeretné használni, a saját érdekei motiválják. tipikusan ilyen szerintem a pénzügy, ahol az elemzések és adatok feldolgozása nem kevés számítással jár, tehát bevett szokás gpgpu-n számítani ezeket, ezekre már rég megszülettek az implementációk. nyilván, sem te, sem én nem találkozunk konkrét megvalósítással, mivel egy ilyen elkészült alkalmazást nem eladni szeretnének, hanem használni, mást nem juttatunk előnyhöz a magunk kárára.
Tehát, míg az elsőnek az a lényeg, hogy minél többen megvegyék a programját, addig a másiknak az a lényeg, hogy minél jobb legyen a programja.
Na most, hogy minél többen megvegyék a programját kell marketing, meg a többi bullshit, és egy nagyon fontos dolog, hogy bárki használni tudja. Itt nem merik bekockáztatni azt, hogy olyan alapokon íródjon a program, amit csak kevesen ismernek, és tudnak használni, tehát maradnak a szokványos kódoknál. Ide hozható fel példának a mante vs dirextx. Melyik az a játék, ami csak mantle-re fog megíródni? Van egy sanda gyanúm, hogy kevesen vállalnak be ilyet, sőt, ha lesz mantle-s megvalósítás, az már csak utólag készül el, ha marad rá keret.
Aki viszont saját magának, vagy egy konkrét megrendelőnek készíti a programot, ott a hatékonyság a fő szempont, tehát bátrabban hozzányúlnak ezekhez a dolgokhoz, keresik az eszközöket, amivel jobbá tehető a saját rendszerük.
Ami miatt az emberek ezekkel nem találkoznak így világos, nem közhasznot szolgálnak, a nagy célközönségnek készült programok viszont túl általánosak kell, hogy legyenek.
Igy viszont igazad van, valószínüleg akkor fognak megjelenni az első olyan programok, amelyek bátran kihasználják az apuk számítási kapacitását, amikor már mindenkinek lesz rá megvalósítása, illetve olyan nagy nevek programjainál, akik megengedhetik maguknak, hogy mindkét megvalósítást elkészítsék. Ezektől függetlenül az APU értékéből ez mit sem von le, csak mezei usereknek kevésbé adatik meg a lehetőség, hogy olyan programmal találkozzanak, amelyik ilyen alapokon íródott. -
sad_Vamp
őstag
válasz
Zoli0726
#201
üzenetére
az a baj hogy szigorúan technikailag biztos hogy igazad van, hisz ezzel dolgozol. Sőt.
Viszont elfelejted a dolog üzleti oldalát. Sajnos tényleg az a helyzet, hogy a legtöbb progi és játék még a 2 magot sem tudja normálisan kihasználni az ezeréves gyorsitó utasitásokat sem... nem hogy majd ezt a totál új dolgot. Reménykedem én is benne hogy majd a nextgen miatt ez felgyorsul és felfut... de amint irtuk a konkurencia tűzzel vassal ellene lesz a dolognak, amíg nekik nem lesz saját megoldásuk rá.
[ Szerkesztve ]
-
Loha
veterán
válasz
Zoli0726
#201
üzenetére
a mai motorok már simán leterhelnek 4+ magot is, tehát van bennük párhuzamosítás bőven
Ez sajnos nem igaz, AAA játékok közül BF3, BF4, ami képes erre, aztán kb. ennyi, a többi játék csak arra képes, hogy egynél több procimagot használjon. Mióta vannak többmagos procik?A konzolok gpu-ját már most használhatják ilyen feladatokra a grafika számítása mellett
Ezzel az a gond, hogy ha grafika helyett a CPU kiváltása használod a GPU-t, akkor kevesebb jut a grafikára, és az már most is látszik, hogy a nextgen konzoloknál a teljes GPU -ra szükség lesz a natív 1080p-hez.Ahol meg egy átlagfelhasználó vár, ott már régesrég van gpu gyorsítás, lástd winrar, mindenféle videókódolók, photoshop.
Pl. videókódolásnál a GPU-val készült végtermék sokkal rosszabb minőségű mint a CPU-s, ha meg a CPU-sat GPU minőségre butítod nem is lassabb, szóval nagyon kezdetleges még ez a terület.[ Szerkesztve ]
-
SSJPiotr
csendes tag
Pár hónapja vettem a10 6700as konfigot GPU nélkül 8GB 1866os memóra társaságában. Napi 10++ órákat játszok/filmet nézek/dolgozok/stb gép előtt. 2x cryengine2 game fut ablakban mindig 1440x900ba/safe mode, mellettük simán végigtoltam dead space/batman sorozatot 1440x900 full képernyőn max részletességgel, de mentek full hd-be is (mediumon), miközben a gép fogyasztása (monitorral(24') 5.1 rendszerrel routerrel meg mindennel) 150W alatt van (fogyasztásmérővel mérve, terhelés alatt). Persze sem a CPU sem az IGP rész nem tartozik az élmezőnyhöz, én tökéletesen elvagyok vele.
Kaveri felhozatalt nagyon várom, valószínűleg váltás lesz ha mérséklődik az áruk. TrueAudio + konfigurálható TDP nagyon jól hangzik, mantle is nagy durranás lehet, a teljesítményt meg nem lehet behatárolni perpill SZVSZ -
Zoli0726
aktív tag
Nem értem, honnan szeditek azt, hogy apu = mantle, soha nem mondott ilyen senki.
Én nem hiszem ezt, meg nem hiszem azt, párhuzamosítottál már valaha egy for ciklust? Gondolom nem. Láttál már párhuzamosított kódot funi gpu-n? Gondolom nem. Miért mondom ezt? Mert ha így lenne, akkor tudnád, hogy simán állva hagyhantá a kaveri apu bármelyik corei7-et egy neki szabott feladatattal.
Mégis hogy? Úgy, hogy pl játékokban a gpu számítaná a fizikát, ai-t, a cpu meg a többit, ami nem párhuzamosítható. De a mai motorok már simán leterhelnek 4+ magot is, tehát van bennük párhuzamosítás bőven, tehát a kaveri apunál adja magát, hogy a párhuzamos kódot a gpu-n futtatom, ha már egyszer úgy is ott van.
A konzolok gpu-ját már most használhatják ilyen feladatokra a grafika számítása mellett, és ha majd portolni kell, akkor az apu gpu-jával a legegyszerűbb kiváltani ezt a funkciót.
És ameddig a xone és a ps4 fénykorukat élik, addig ilyen motorok fognak íródni, tehát elég esélytelen, hogy ezeket a módszereket nem viszik át pc-re.
Az egységes címteret előbb vagy utóbb meg fogja lépni az intel is, mivel az intel gpu-k sem rosszak általános számítások terén.
2013-ban úgy gondolni egy gpu csak játékra használható a tudatlanság jele.
Jönnek a kérdések, hogy de az átlagfelhasználó bla bla....
Melyik az az átlagfelhasználó aki elindít egy programot, és perceket vár a befejezésére?
Ettől függetlenül az összes mai modern böngésző gpu-val gyorsított, grafikus felület gpu-val gyorsított.
Ahol meg egy átlagfelhasználó vár, ott már régesrég van gpu gyorsítás, lástd winrar, mindenféle videókódolók, photoshop. Szuperszámítógép se kell, mert az átlagfelhasználónak nem íródott rá program.
Talán ha a GPU memóriavezérlőit érné el valahogy az IGP, ami szerintem jelenleg nem kivitelezhető, viszont akkor feleződne a sávszél és a vram mennyisége is, szóval ott vagyunk, ahol a part szakad... Dedikált GDDR5-ös chipek kellenek az IGP-nek, amiről volt is szó, de aztán eltűnt a süllyesztőben. A 4 csatornás memóriavezérlő társítva DDR4-es modulokkal lenne az igazi! 
Ezek szerint akkor már ez is megy a 7750-el csak nincs rajta a hivatalosan támogatott VGA-k listáján? 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Mindketten írtok egy példaprogramot a másiknak meg át kellene gyúrni, hogy gyorsabb legyen. Vagy mittomén, nem értek a lovakhoz 
,
Új hozzászólás Aktív témák
ph Megpróbáljuk kinyomozni, játékok alatt mire lehet majd képes a januárban érkező csúcs asztali APU.
