Keresés

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

  • sb

    veterán

    válasz Petykemano #114 üzenetére

    Értem, hogy ARM, lentebb én magam írtam példaként. Ellenpéldaként, mert tök fordítva működik az a piac, szóval hülyeség erre hivatkozni szerintem.

    Azért van 8-10 magos ARM proci, mert 5Ft-ból megcsinálják és abba az energiahatékony dizájnba ez illik is. Részben ezért is 5Ft.

    PC-n meg tök fordítva: 6-8 magot lóf*szra se tudsz használni retail piacon ellenben egy zsák pénzért tudják/akarják csak adni. Egyetlen kivétel a proci piac aki ki tudja használni és pengetni is a pénzt érte. De nekik meg nem 35-55W-os 8-12 magos cucc kell, hanem minél erősebb 90-180W TDP-ig.

    Szóval ez így PC-re totál értelmetlen továbbra is. 500-1000USD-s procikról van szó. Halandó nem veszi meg se kicsi se nagy házban, a profi meg csúcsteljesítményre veszi, tehát kiesik az SFF.
    Ha netezős gép ársávba levágják az áraikat tizedére akkor van értelme méreten gondolkodni. Netezős gépért biztos, hogy az SFF tetszene a sok átlagjózsinak.

    3GHz/4GHz egyszálas max boost @ 35w tdp szerintem tök szuper. Én például szeretnék egy minipct a nappaliba.
    Nekem van nappali PC-m. Mire használnád ki a 35W TDP-t? Miért kéne 4 (vagy akár 2) mag helyett 6-8 mag, 12-16 szál neked 35W-ra nappaliba? Komolyan kérdezem. :F

    szerk: Egyébként Abu is írta, hogy nincs igény, csak nyomják a magic world first... számokat a gyártók mert azt hiszik ez viszi majd az eladásokat. Abban egyetértünk, hogy nincs tudatos fogyasztás, de árérzékenység van. Szvsz a telefonoknál se nézi már a kutya se, hogy 6, 8 vagy 10 mag. Iphone-ban mennyi van? ;) Ezt most kb. onnan vezették le a marketingesek, de kb. annyi értelme van, mintha most előhúznának egy másik 10 éves varázskifejezést és azzal próbálnák eladni azt ami rég nem érdekes adott szegmensben.

    [ Szerkesztve ]

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #215 üzenetére

    Nem. Ezekre a megoldást úgy hívják, hogy aszinkron compute.

    Jelenleg már számos programban dolgoznak a régi CPU-s szimulációk átvitelén GPU-ra, mert az aszinkron compute-tal a képszámítással párhuzamosan meg lehet csinálni. Hamarosan így fog működni a Nitrous terepszimulációja, ami klasszikus formában CPU-s megoldás, de mivel minimum hat magot igényel az AotS-ben a nagy pályáknál, ezért átviszik aszinkron compute-ra, és így már elég lesz a négy mag is, ha a GPU képes futtatni a párhuzamos feladatszámítást.

    Többen beszéltek erről a modellről a SIGGRAPH Asia rendezvényen. Főleg a Khornos támogatja, mivel a SPIR-V ehhez nagyon jó alap, de a Microsoft is hozza a DXIL-t hozzá.

    Persze a legnagyobb gond a konzol. Ott az a baj, hogy nagyon kevés a CPU-ban lévő SIMD számítási teljesítmény, tehát az új motorokat muszáj erre az aszinkron compute modellre felépíteni. A PC pedig ennek a portját kapja meg és kész.

    Aztán egyébként az API-k számára tulajdonképpen mindegy, hogy melyik GPU-n futtatod a számítást. Akár megteheted az IGP-n is, csak arra kell küldeni a feladatot. A DirectX 12 kezeli ezt már ma, és a Vulkan 1.1 is fogja még idén. De itt van egy kis ellenérdek a gyártók részéről, mert az AMD most inkább azt akarja, hogy ezek a feladatok fussanak a dedikált GPU-n, mert nagyon erősek a Radeonok aszinkron compute-ban. Az NV és az Intel akarja azt, hogy legyenek inkább az IGP-k használva. Az Intel azért, mert nekik van egy csomó eladott is kihasználatlan IGP-jük, és ezzel mondjuk egy jó lehetőséget adnak a fejlesztőknek, hogy ne a minimum magszámra vonatkozó igényt növeljék, míg az NV azért, mert szar az architektúrájuk aszinkron compute-ban.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Fiery

    veterán

    válasz Petykemano #227 üzenetére

    Alapveto kulonbseg van a x86/x64 vonal es a GPGPU vonal kozott. x86-on ha egyszer, veres veritekkel optimalizalod a kododat -- adott esetben assembly betetekkel -- SSE/AVX1/AVX2/AVX-512-re, onnantol minden, ezeket az utasitaskeszlet kiegesziteseket tamogato processzoron hibatlanul fog futni a kodod, modositas es bibelodes nelkul. A jelenlegi es jovobeni ilyen processzorokkal sem lesz, nem lehet gond. A kodod, az elkeszitett szoftvered ezzel "future proof".

    GPGPU vonalon viszont 2 lehetoseged van. Vagy CUDA, es az NVCC-vel binarist forditasz adott compute capability-t celozva. Ez tok jo, csak ugye ha jon egy uj GPU generacio (pl. Pascal), akkor ahhoz forditanod kell (marmint celszeru megtenni) uj binarist, tehat nem tudsz altalanos ervenyu binaris kodot kesziteni, ami minden jovobeni nVIDIA GPU-n is egyforman remekul fog futni. Vagy CUDA+OpenCL vonalon tudsz kernel source-ot szallitani a szoftvereddel, de akkor meg on-the-fly kell forditani, kiteve magad annak a problemanak, ami mar 10 eve nincs megoldva, azaz hogy a CUDA/OpenCL fordito lehet, hogy lefagy, crash-el vagy csak ugy altalaban sz*r binarist fordit az adott vason, amin epp futtatjak a szoftvered. Tehat az x86/SSE/AVX binarissal ellentetben, az on-the-fly forditott GPGPU kod futasa es az eredmeny helyessege abszolut nincs garantalva. Hasonlo, mint az orosz rulett, csak nem hal bele senki :)

    [ Szerkesztve ]

  • ukornel

    aktív tag

    válasz Petykemano #250 üzenetére

    Bár nem én lettem megszólítva, de ezt nem egy másik topikba (VEGA, APU, HSA, mittomén) kellett volna inkább? :)

  • ukornel

    aktív tag

    válasz Petykemano #254 üzenetére

    Most hogy újra belegondoltam, az általad belinkelt eszmefuttatás jó korrelál az AMD régebben belengetett Fastforward HPC APU-jánál vázolt kétszintes memóriarendszerrel. Ott biztosan van értelme.

    [ Szerkesztve ]

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