Keresés

Hirdetés

Új hozzászólás Aktív témák

  • dezz

    nagyúr

    Azt kellene megérteni, hogy már az Intel sem tud nagyot előrelépni CPU fronton saját magához képest. (Lassan elérünk a szilícium alapú technológia határaihoz.) Márpedig így nekik is visszaesnek az eladásaik. Ezért feküdt rá az Intel is az IGP fejlesztésére, OpenCL támogatással együtt. A GPU-ban, és úgy általában a párhuzamosításban még van potenciál. (Nagyobb, mint a sima CPU mag többszörözésben.)

    Eddig szerintem jópár szoftverfejlesztőt lefizettek, hogy hagyják figyelmen kívül az egész GPGPU-s témát, de most már nekik is az lesz az érdekük, hogy meginduljanak, pontosabban nagyobb lángra kapcsoljanak az ilyen irányú fejlesztések.

    (#18) a_n_d_r_e_w: "jatekhoz, tomoriteshez, vagashoz, kepfeldolgozashoz, forditashoz, mindenhez."

    Az első négyhez pont, hogy nagyon is igénybe lehet venni a GPU-t (IGP-t). Sokminden máshoz is.

    "Nekem nem kell a kaveribe integralt gyenge GPU"

    Grafikára gyenge (mondjuk jobb, mint egy belépőkat. VGA), GFLOPS-ra egy i7 CPU részét is a földbe döngöli.

    (#30): "nekem a fontos, hogy egy make -j8 minel gyorsabban fusson le, mellette azert tudjak jatszani is"

    Miért nem ezzel kezdted? Fordítás nem lesz egyhamar (legfeljebb Intel MIC-en), de a játékok terén be fog jönni a GPGPU-sítás, főleg a konzolok hatására.

    (#74) hibavissza: Hát neked sem ártana egy reality check.

    (#75): Lásd fentiek.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz dezz #76 üzenetére

    "szoftverfejlesztőt" -> mármint céget, illetve az említett közép-/felsővezetőket.

    Példa 1.: distributed computing client, orvosi kutatások. Csak CPU-n fut! Miközben kb. az összes többi átállt GPU-ra. Intel veri a mellét, mint szponzor... Példa 2.: Maxon (Cinema 4D, Cinebench), szponzor: Intel. De valószínű a fél szoftveripar a zsebükben van.

    Megjegyzem, egyelőre még jó az Intelnek, hogy nagyobb teljesítményigény esetén megveszik a többszázezres procijait. Szóval, ha csak rajtuk múlna, még néhány évig ez a helyzet maradna. Az AMD számára azonban nincs más választás, mint az előre menekülés, forradalmasítás. A sok APU eladása is előre tudja mozdítani a dolgokat valamennyire.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Jack@l #78 üzenetére

    Én itt valaki másnak az állandó, tudatlanságból eredő és/vagy alapvető ismereteket szándékosan figyelmen kívül hagyó erőlködését látom.

    (#80): Olyan nincs, hogy csak CPU-n megvalósítható (már a számítások terén, nem OS kernel futtatásban), legfeljebb kevéssé hatékony GPU-n, de még ezt sem hiszem, mert elég jól skálázodik sok magon.

    Melyik perpill legszebb path-tracing renderelő?

    (#79) a_n_d_r_e_w: Értem, amit mondasz, de úgy tűnik, te nem érted, amit mások mondanak: túl kevesen vennének meg egy ilyen procit, hogy megérje a ráfordítást. Már a 8xxx szériát is kevesen vették.

    Az egyedüli kitörési lehetőségük most az APU-k, a HSA, stb. Szponzorálnak is néhány fejlesztőt. Persze elég nagy szembeszélben vannak egyelőre. Az Intel könnyen rájuk tud licitálni, de már ők sem nyomhatják sokáig a CPU-only politikát.

    Nem vagyok biztos benne, hogy 8db 2 GHz-es Jaguar annyira lenyom 4db 4 GHz-es Steamroller magot. De még ha erősebbek is valamennyivel, az eltörpül a GPU számítási teljesítménye mellett.

  • dezz

    nagyúr

    válasz Cathulhu #83 üzenetére

    Nyilván megcsinálták volna, ha megérte volna a dolog. Azt is nagyon meggoldolják (még az Intel is), hogy kihozzanak-e egy új steppinget egy adott lapkából. Maga az is nagyon költséges, amíg egy chiptervből valós chip készül a gyártónál. Olyan van, hogy letiltanak részeket, de magukból a lapkákból kevés van. A Kaveriből is egy lapka van, Kabiniből is, stb.

  • dezz

    nagyúr

    válasz Jack@l #88 üzenetére

    Értettem, de jobb kijavítani a pontatlanságaidat, mielőtt megragad a fejekben.

    "tudniillik a gpu nem mindenható, hanem célhardver"

    Ma már sokkal kevésbé célhardver, mint korábban. A GCN-t kimondottan computingra fejlesztették (ami grafikai számításokra ugyanolyan jó). A Nvidia új generációs GPU-ival is hasonló a helyzet.

    "Még mindig több a csak cpu-n futó renderelő pl, mint a gpu-s"

    Lásd alább.

    "és gpu-sok általában feature/minőség terén gyengébbek."

    Szerintem kevered a OpenGL alapú leképzéssel, az más történet.

    "Viszont olyat még egy ember szájából se hallottam, hogy kivágom a dgpu+cpu párost a gépemből, mert apu-n jobban fut a cucc, szerinted mikor fogok ilyet tapasztalni/hallani a jövőben?"

    Most ugye csak tetteted a hülyeséget és beszélsz teljesen félre? Erről nincs szó. Arról van szó, hogy a CPU helyét az APU veszi át (számításigényes, eddig a CPU magokat terhelő feladatok átkerülnek az IGP-re), miközben a grafikára ott marad a dGPU. Vélhetően a PS4/XBO játékok egy részét (amik az említett gépeken kihasználják ezeket a lehetőségeket) is így fogják PC-re portolni. Ennél fogva könnyen felzárkózhat a Kaveri egy i7-eshez, adott esetben be is előzheti.

    "6-7éve lehet a dgpu-t is használni "mindenre", mégse használod, miért? 10-20-50x gyorsabban futnak rajta a dolgok mint sokmagos cpu-n."

    Látod, ez a nagy kérdés, amire már válaszoltam is: #76, #77.

    Erre a kérdésre viszont te elfelejtettél válaszolni: "Melyik perpill legszebb path-tracing renderelő?"

    Olyan kérdéseket teszel fel, amire már érkezett válasz, hozzád intézett kérdésekre viszont elfelejtesz válaszolni és közben jól félrebeszélsz. Ez számodra a konstruktív vita, vagy ez nem is célod egyátalán?

    (#108) Tomcat: Opteron vonalon sincs (még?) Steamroller alapú 8-magos. Csakis asztalra meg nem fognak "összedobni" egyet. Hiszen nem lenne versenyképes, teljesítményben még csak-csak, sokszálas alkalmazásban, de telj./fogy.-ban semmiképp és a kis volumen miatt árban sem. Túl kevesen lennének, akik így is megvennék.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Jack@l #116 üzenetére

    A szintén a legjobbak közé tartozó LuxRendert meg kimondottan GPU-ra fejlesztik. [link] Akkor hogy is van ez?

    Szerinted mást vagy magadat járatod le, ha konkrét érvekre korrekt válaszok helyett nekiállsz félrebeszélni és személyeskedni? Egyébként meg nem vagyok hívő, csak a tudásod fehér foltjaira azt hiszed, ott nincs is semmi.

    (#117): Nagyszerű, én meg speciel ASM-ben írtam ray-tracert még a '80-as évek végén, ami tudott olyat, amit az akkori legelső ray-tracerek még nem. És úgy vélem, egy APU IGP-je nagyon is be tud segíteni ray-/path-tracingnél is. Ez be is fog bizonyosodni, amint az Intel is letesz az asztalra használható megoldásokat.

    (#120) Abu85: Ezt bizonyára a dGPU-s megvalósításra írtad. APU-k esetén nincs ilyen gond. Legfeljebb olyan tekintetben, hogy jó lenne egy több GB-os belső cache/eDRAM - ami előbb-utóbb lesz is.

    (#122) Laja333: Vannak a hülye trollok, azokra simán rá lehet hagyni a hülyeségüket, mert mindenki átlátja, hogy hülyeséget beszélnek. Aztán vannak a körmönfontabbak. Ott nem árt rámutatni a valótlan állításokra. Utána úgyis leleplezik magukat és akkor már nem kell tovább foglalkozni velük.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Jack@l #126 üzenetére

    Mondja a Verolex. ;]

    És megint félrebeszélsz. Lásd amit Laja333 írt a #122-ben!

    Moderálva

    [ Módosította: crey ]

  • dezz

    nagyúr

    válasz Jack@l #130 üzenetére

    Ez inkább fogható a fiatal voltára és talán a fejlesztők sem a terület mesterei, mint a GPU-s gyorsításra. (Ne keverjük ide a GPU-k hw-es, fixfunkciós videoenkódereit, amik nem minőségre optimalizáltak.)

    De már megint kikerülöd a korrekt válaszadást.

    Moderálva

    [ Módosította: crey ]

  • dezz

    nagyúr

    válasz Jack@l #134 üzenetére

    Csak a következőket nem fogod fel:
    1. Egy mai GPU már nem az a GPU, mint évekkel ezelőtt volt. A mostaniak sokkal inkább computingra tervezettek.
    2. Egy APU-nál a CPU és a GPU szoros együttműködése is megvalósítható, hatékonyan. Eddig ennek a PCIe busz volt a gátja. Ez egész más eset, mint amikor GPU-only környezetben kellene jól teljesítenie valaminek.
    3. Abból, hogy ma milyen a CPU-only és GPGPU-s (alapvetően kétfelé bontott, CPU-only és GPU-only részekre, amik keveset kommunikálnak) szoftverek (akár pl. rendererek) aránya, nem következik, hogy ez így is marad.
    4. Eddig az Intel a CPU-only megoldásokban volt érdekelt és ismerjük az Intel érdekérvényesítő képességét. A fizikai törvényeket azonban még ők sem tudják felülírni, ezért ők is nyitottak a GPU-s computing felé, ma már az ő PC-s procijaik is lényegében APU-k, még ha nem is úgy nevezik. A Kavari új képességeit is igyekeznek átvenni. A továbbiakban ők is a GPU-val való gyorsítás elterjedésében lesznek érdekeltek, és ez meg is mutatkozik majd a sw-fejlesztésben.

    Mondj valós ellenérvet, ha tudsz, vagy maradj csöndben! Félrebeszéléssel ne rabold mások idejét!

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Jack@l #134 üzenetére

    "Lesz jó sok kontext switch, meg mégtöbb egymást blokkoló szál majd."

    Na nem ilyen badarságokra gondoltam.

  • dezz

    nagyúr

    válasz Jack@l #138 üzenetére

    Mi nem változik? Miről beszélsz egyátalán? Esetleg befejezhetnéd a megalapozatlan, se füle-se farka kijelentéseket, akkor nem ingerelnél másokat válaszadásra.

    Te magad írtad korábban, hogy bármilyen erős is egy GPU, nem minden feladatra optimális. Főleg önmagában. Ezért előbb-utóbb a nagy GPU-k mellé is integrálásra kerülnek CPU magok. Ez a konfiguráció olyan feladatokra megfelelő, ahol továbbra is a GPU végzi a munka oroszlánrészét, miközben a CPU magok olyan részfeladatokat látnak el, amiben ők a jobbak.

    Lassan nem lesz olyan proci sem, amiben ne lenne több-kevesebb parallel compute unit. Sok feladat van, ami összességében a CPU-n fut jobban, de részfeladatokat át tud venni a GPU, mégpedig sokkal gyorsabban elvégezve.

    Figyelmedbe ajánlanám, hogy ezek itt tényállítások. Ha mond ez a fogalom valamit, mert egyre inkább úgy érzem, hogy nem.

  • dezz

    nagyúr

    válasz Jack@l #145 üzenetére

    Na hát erre mondják, hogy "elmész a fenébe!". Ennyire sík hülye nem lehet valaki (tehát valójában te sem vagy az), hogy még csak itt tartson, ennyi szájtépés után és úgy egyátalán. Ergo most biztonyítottad be, hogy csak egy troll vagy, aki azt élvezi, ha másokat idegesíthet, húzhat, rabolhatja az idejüket, miközben a figyelem középpontjában van.

    Ez cseppet sem vicces, ugyanis:
    Itt a bizonyíték: a netes trollok pszichopaták

    Keress fel egy jó orvost, amíg nem késő!

    ui. és nem kompúter, hanem kompjúter, ha már így írod.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz #32839680 #155 üzenetére

    És a WinZIP nem is valami jó program. Vannak ilyen orosz ZIP/RAR jelszótörők, azok is kitömörítenek részeket és többszörös tempóban keresik a jelszót, mint akár egy komolyabb, többmagos CPU.

    Számomra már az a gyanús, mennyire nem álltak még rá a GPGPU-sításra ott sem, ahol ez kézenfekvő lenne...

    Érdekes módon, nem kommersz projektekben, ahol számítási teljesítményre van szükség és az Intel nem tudja rávenni a projektgazdákat, hogy inkább a drága CPU-it vegyék tucatszámra, jóval előrébb tartanak ezen a területen. Az AMD-t nem tudom, de az Nvidia jó üzletet csinál a Tesla szervereivel és munkaállomásaival. Az Intelnek is alkalmazkodnia kellett az igényekhez, így született meg a MIC alapú Xeon Phi, ami lényegében egy GPU szerű képződmény sok kis SIMD feldolgozásra kihegyezett CPU magból. A telj./fogy. előnyét csak az Intel gyártástechnológiai előnye tudja biztosítni, azonos technológiával a GPU-k lennének előnyben. (Kérdés, ez a jövőben hogy alakul majd, beéri-e a többi gyártó az Intelt gyártástechnológiában.) Mondani sem kell, a Teslák sem olcsók, de a Phik mégdrágábbak.

    PC fronton addig marad a mostani helyzet, amíg az AMD-nek számottevő előnye van ezen a területen az Intellel szemben és a támogatás helyzetbe hozná az AMD-t. Azaz, már nem sokáig. De szerintem azt nem kell majd megvárni, amíg az Intel GPU-ban is kimondottan fölényben lesz, éppen elég, ha egálban vannak vagy csak kicsivel rosszabb az Intel (amit némi borítékozással ki lehet egyenlíteni, ami a céges gépparkokat illeti, az egyszeri userek pedig amúgy is az Intelt részesítik előnyben, még ha az AMD kicsivel jobb is éppen).

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz #32839680 #157 üzenetére

    Amennyire teheti, az AMD is igyekszik jobb pozíciókat kiharcolni HPC vonalon is. FirePro kártyák sora tolong a vevők kegyeiért, amik természetesen OpenCL-lel programozhatók. Valószínű a HSA koncepcióból sem maradnak ki teljesen. Mindeközben az APU-knak is van FirePro változata (kibővített supporttal az asztali változathoz képest), de eszük ágában sincs kukázni a komolyabb FirePro kártyákat emiatt.

    Pl. AMD FirePro™ S10000

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Reggie0 #160 üzenetére

    Az lehet. Az OpenCL viszont platformfüggetlen. A HSA keretein belül pedig lehetőség lesz többek között C++-ban is programozni, vagy pl. C++ AMP-ban (később akár Javában is, bár ez nem feltétlen szempont a HPC-ben).

    Bizonyos feladatokra egy komoly dGPU a legjobb választás, másokra egy APU, megint másokra pedig a kettő együtt. Lehet majd választani.

  • dezz

    nagyúr

    válasz Reggie0 #162 üzenetére

    Legtöbbször nem számít, de előfordulnak más variációk is. Attól függően, rövidebb vagy hosszabb távú alkalmazásról van-e szó, stb.

    (#163) morgyi: Abból a szempontból hasonlítanak, mindkettő C/C++ alapú (illetve a CUDA-nak van Fortran változata is), annak kiterjesztése. A fejlesztői környezet kiépítettségében viszont a CUDA vezet, az tény.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Jack@l #168 üzenetére

    "Nem trollkodást kérek, válaszokat."

    :))

    Mondja ezt (az eddigiek mellett) egy olyan indítással, hogy "vagy teszemazt felhasználó programok mennyi részén használható az adatpárhuzamos implementáció.", amire nyilván azt a választ akarja hallani, hogy csak egy kisebb része. Ami igaz is, csakhogy ezek fontos programok. (Közben azt sem tudja, hogy nem "felhasználó programok", hanem felhasználói programok.)

    Fel kellene fogni, hogy egy APU sokkal több helyen alkalmazható, mint egy dGPU, aminek át kell tolni az adatokat egy relatíve lassú buszon, hogy aztán nekiállhasson (a mai rendszerben ez a nekiállás is lassú) szüttyögni vele, majd az eredményeket tolhatja vissza ugyanazon a buszon, és így tovább. Az APU-nál akár egy időben dolgozhat ugyanazokon az adatokon a kettő és nagyon gyorsan csereberélhetik az adatokat. Ennél mélyebbre nem megyek, úgysem értenéd (mint azt eddig bizonyítottad).

    Kb. mindazokban a programokban bevethető az APU, amik viszonylag jól skálázódnak több/sok CPU magra. Főleg, ha még eleve SIMD-esítettek is. Renderelés, tömörítés, videoszerkesztés és enkódolás, képszerkesztés és -feldolgozás, networking, víruskeresés, játékok (most csak úgy végigszaladtam a szokásos teszt-meneten).

    Ebben a teszt-cikkben láthatsz egy pár példát láthatsz arra, amikor már a Llano is sokkal gyorsabb volt (értsd: 20-50x gyorsulás!), mint ugyanazt CPU-ból elvégezve. (Némely esetben a mellé tett HD7950-nel sem teljesített jobban.) És hol volt ekkor még a HSA?

  • dezz

    nagyúr

    válasz Jack@l #174 üzenetére

    Kaptál tippeket, sőt még konkrét példákat is. A vezetőedzősködést hagyd másra.

    (#176) Abu85: "a jellemző GPU kihasználás nincs 40-60% felett"

    Ez ugye átlagértékként értendő? Azaz, pl. az idő 60%-ában 100%-on teker, egyébként meg pihen.

  • dezz

    nagyúr

    válasz Reggie0 #178 üzenetére

    Ez azért elég meglepő. A másikat el tudom képzelni, de ezt nem igazán. Mitől van ez?

    Mantle-vel jobb a helyzet? Vagy az is csak a CPU terhelést csökkenti, a GPU-kihasználást nem javítja? (Az egyidejű kihasználásra gondolok.)

  • dezz

    nagyúr

    válasz Abu85 #182 üzenetére

    (Az első két mondatban foglaltakat természetesen tudom.) Ha jól értem a harmadikat, nem optimális arányban jönnek a parancsok (v. feladatok), tehát amilyen arányban állnak egymással a különböző fajta egységek. Ez a shader compiler hiányossága vagy arról van szó, hogy pl. nem tudja az adott TMU kiszoltálni az összes hozzá tartozó CU-t?

    Olyanról nincs szó, hogy pl. nincsenek teljes szélességben kihasználva a SIMD egységek a CU-kban? Azaz, nem eléggé vektorizált a kód. Ami vagy szintén a shader compiler hibája, vagy elméletileg sem lehet jobb. Az utóbbi esetben nincs mit tenni, hiszen a kihasználatlan "rekeszek" (1-1 SIMD egységen belül) nem hajthatnak végre más utasítást.

  • dezz

    nagyúr

    válasz Jack@l #187 üzenetére

    Vedd észre, hogy az Intel iránya is ez a mainstreamben. Őket is szorongatja az energiatakarékosság és a fizika, így ők sem tudnak már túl sokat felmutatni a CPU erő növelésében. Pár százalék teljesítménytöbbletért senki sem vesz új procit, így ha nem akarnak visszaeső eladásokat, más irányban kell javítaniuk a teljesítményt, és ez a computing.

    Azt is vedd észre, hogy kétféle felhasználói program van: 1. aminek nem vagy alig számít a számítási teljesítmény, 2. aminek nagyon is. Az utóbbiak nagyobb része már ma is többszálúsított és/vagy SIMD-esített (SSEx/AVX), azaz párhuzamosítottak, így jelentős részüket át lehet vinni GPU-ra is.

    Azt értsd meg, hogy egy mai GPU nagy részét sok egyszerű processzor-mag teszi ki (GCN esetén Compute Unit - mellesleg az AMD a CPU modulokat is így hívja), széles SIMD egységekkel. (Mindez ki van egészítve pár célorientált egységgel és dGPU esetén több memóriavezérlővel.)

    Valami hasonló már egyszer megtörtént, amikor nem lehetett gazdaságosan nagyobb mértékben növelni az egyszálas teljesítményt, és ezért bevezették a több magot. De CPU magok számát sem érdemes sokáig növelni, akkor már jobb egy GPU.

  • dezz

    nagyúr

    válasz ukornel #190 üzenetére

    "grafikus számoló"

    Ne bizonytalanítsd el szegényt! :) A CU-k (Compute Unitok, esetünkben GCN alapú), mint nevük is mutatja, számító egységek. A grafikához annyi közük van, hogy a grafikai számítások általában jól párhuzamosíthatók (és persze az, hogy manapság még jobb híjján többnyire ezzel foglalkoznak), de bármi másra is használhatók, amire ugyanez (masszív párhuzamosíthatóság) jellemző. Ha nem lennének az IGP/GPU-ban olyan egységek, mint pl. a TMU (texture management unit), akkor valahogy úgy hívnánk, hogy vektor ko-processzor tömb.

    (#191) dfdfdf: Köszi, akkor ma már nem fórumoztam hiába. :) De az ilyesmit azért jobb lenne offba tenni.

    [ Szerkesztve ]

Új hozzászólás Aktív témák