2. Fórumok
  3. Videokártyák
  4. Inkább program oldalról támogatná a primitive shadert az AMD
Keresés

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

  • #71 namaste tag Petykemano #70
    Új Válasz #71
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    namaste

    tag

    válasz Petykemano #70 üzenetére

    Csak a saját véleményem, szerintem tudatos döntés. Lásd most a Vega M-et, 20/24 CU és 32/64 ROP, kíváncsi vagyok mennyi különbség lesz köztük. Ha akartak volna, korában is kihozhattak volna valami hasonlót.

  • #63 con_di_B tag Petykemano #61
    Új Válasz #63
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    con_di_B

    tag

    válasz Petykemano #61 üzenetére

    Megfeszulni es meg mindig alul maradni meg marketing szempontbol is sokkal kevesbe ertelmes, mint legalabb egy valamiben optimalisnak lenni.

    Igy arrol beszelgetunk, hogy az NVIDIA technologiaja sokkal jobb. Ugy meg arrol beszelgetnenk, hogy masban jok.

    Persze most is sokan szeretnenek utobbirol beszelgetni, csak nem nagyon all meg a laban. MAR nem jobb a GCN compute-ban sem.

  • #60 gbors nagyúr Petykemano #53
    Új Válasz #60
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    gbors

    nagyúr

    LOGOUT blog

    válasz Petykemano #53 üzenetére

    Nem a fogyasztásra gondoltam, hanem arra, hogy az x80Ti GPU-knak papíron (egységek számai + órajelek) 40%-kal többet kellene tudiuk, mint az x80-aknak, aztán csak 30%-kal tudnak többet.

    A frekvenciával majdnem lineárisan nő a teljesítmény - feltéve, hogy a memória-frekvencia megy ugyanolyan ütemben felfelé. A Pascalban még lehetett növelni az ALU-k számát, mert bírta mind az infrastruktúra, mind a backend. A Volta 7 SM-jében már nem vagyok biztos, hogy annyira fasza lesz - de erre még várni kell.

    (#55) Abu85: izoláltan teljesen érdektelenek ezek az adatok. Na jó, nem teljesen, de max. csak futó érdekességek. Az számít, hogy mennyit profitál a megspórolt sávszélességből a Vega, és a Battlefield 4-ben látott FPS-ek alapján egészen pontosan semmit (az előbb azt hittem, BF1-ről van szó, ott legalább valami minimális extra van az RX580-hoz képest - a 4-esben még az sem).

  • #57 con_di_B tag Petykemano #53
    Új Válasz #57
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    con_di_B

    tag

    válasz Petykemano #53 üzenetére

    A nagy vonalakban lehet sejteni, hogy hol kiegyensulyozatlan a rendszer:
    https://www.techpowerup.com/gpudb/2839/geforce-gtx-1080
    https://www.techpowerup.com/gpudb/2871/radeon-rx-vega-64
    https://www.techpowerup.com/gpudb/2877/geforce-gtx-1080-ti

    a Vega ALU fronton meg az 1080 TI-nel is erosebb, raadasul ezek az ALU-k mint altalanos szamitasi egyszegek eleg popecul optimalizalva is vannak (nem veletlenul szeretnek veluk banyaszni), raadasul mostanra a texture mintavetelezesi teljesitmeny is korrekt, viszont a ROP backend teljesitmenye meg a sima 1080-et sem eri el. Gondolom ezt akarna jelenteni a pixel throughput.

    Es akkor ez meg csak egy nagyon high-level nezopont volt, es nem mentunk bele, hogy ha a tranzisztorszama ekkora a Vega 64-nek es meg HBM2-vel is van sulyosbitva, akkor dragabb lehet gyartani, mint az 1080 Ti-t, az meg nem annyira effektiv, ha cserebe nem tudod ugyanannyiert vagy dragabban adni.

    Low-level meg az van, hogy ha normalisan megirsz egy compute programot (na erre nem fogok tudni public benchmarkot mutatni most gyorsan) OpenCL-ben akkor ugyanezek a kartyak inkabb ALU alapjan skalazodnak, es az NVIDIA-nak nincsen semmifele varazslatos elonye, szoval a kulonbsegnek teljes mertekben a rendereleshez kotodo reszekbol kell eloallnia - vagy a TMU a ROP es a CU-k nem tul hatekony egyuttmukodesebol, de valahol mindenesetre el van asva a kutya.

    Egyebkent ha mar valamiert muszaj lenne ragaszkodnia az AMD-nek ezekhez a high-level aranyokhoz, akkor meg kiserletezhetnenek olyasmivel mint amit anno a Kepler csinalt, csak ellentetes elojellel, hogy a CU-k jarhatnanak kulon orajelen, ami lehetne LASSABB mint a rendszer tobbi resze. Ez azert se volna rossz, mert akkor az ALU-kat nem volna muszaj speed racerre tervezni, "csak" a specialisan grafikai celu reszegysegeket. Ebbol aztan lehetne egy olyan rendszer, ami compute terheles alatt kellemes teljesitmenyt nyujt eros fogyasztas mellett, grafika alatt meg relative tobbet zabal, de legalabb nem bottleneck-eli az ALU-kat.

  • #54 con_di_B tag Petykemano #50
    Új Válasz #54
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    con_di_B

    tag

    válasz Petykemano #50 üzenetére

    Grafikaban DX11-ben semekkora elonyt nem is tud jelenteni, DX12-ben meg akkor tudna, hogy ugy lenne megtervezve az engine, de ez techdemokon kivul nem hiszem, hogy akar meg manapsag is elfordul. De azokban a techdemokban tenyleg tok jol muzsikal!

    Compute-ban tud ertelme lenne, mert ha eppen raerez a fordito akkor ki tud szervezni olyan muveleteket is amik az osszes lane-en ugyanazt adnak, pl. index kalkulaciok egy resze (van egy bazis ami ugyanaz, es az offset ter el) stb. Ezeken elmeletben lehet fogni nehany Joule-et, ami aztan a gyakorlatban abban mutatkozik meg, hogy tovabb birja a turbo-t, mert egyebkent kb. gyarilag tulhajtott parameterekkel jon minden GCN-es kartya. Ezert talalsz annyi hirt arrol, amikor alulfeszelve (nem feltetlenul underclockolva!) meg gyorsul is a kartya.

    Amit meg leirtal tortenetnek, igen, pontosan ugyanigy kepzelem en is.

    Ez a tortenet elegge tipikus egyebkent, torvenyszeruen ilyesmik tortennek minden cegnel ahol eroltetik az agile-t az R&D-re is. A jelentos ugrasok, amikre szukseg lenne, messze vannak, ezt a mernokok tudjak, de ha azzal allnak elo, hogy "ki kene vagni a mostani architekturat a kukaba", akkor az megkapja, hogy ez nagyon draganak es kockazatosnak hangzik, es visszazavarjak oket a tervezoasztalhoz, hogy inkabb csiszolgassak a mostani architekturat, hiszen "amikor kijott a GCN azt azert finansziroztuk, mert azt mondtatok, h ez annyira modern, h 10 evig megelunk belole, szoval hajra, csinaljatok tovabb".

    Aztan amikor egy ideje ez lesz, akkor a mernokok elkezdenek alkalmazkodni, es rajonnek, h lehet ezt ugyis csinalni, h csak azert is megcsinaljuk amit akartunk, de lepesenkent, es akkor az egyes iteraciok kozott lehet amortizalni a koltseget, es akkor maris nem lesz olyan ijeszto, ezt meg a managerek is kepesek lesznek felfogni agyilag (akik persze nem eleg kepzettek, h egynel tobb fejlesztesi modszertant ismerjenek).

    Aztan ebbol lesznek az ilyen semmire se jo oszvermegoldasok, mint a Vega. Ennek a fajta alkalmazkodasnak viszont az a nagy problemaja, h mivel a nagy terv valojaban nem feltetlenul volt soha kimondva meg cegen belul sem, eleg elmennie par kulcsembernek, akik ertettek, hogy mi miert van, es akkor csak az oszver marad a nyakukon, de a perspektiva eltunik.

    Es akkor most imadkozzunk egyutt az AMD reszvenyeseiert, hogy ez az ember ne Raja Koduri legyen.

  • #51 gbors nagyúr Petykemano #47
    Új Válasz #51
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    gbors

    nagyúr

    LOGOUT blog

    válasz Petykemano #47 üzenetére

    Mind az IPC növelésének, mind a skálázódásnak megvannak a maga nehézségei, amivel mindkét gyártó küszködik. A Fiji (és ugyanúgy a Vega) több faktornak is áldozata, mert hasonló arányokkal rendelkezik, mint a Tahiti és a Tonga, ezért örökli azok kiegyensúlyozatlanságát, és ezt még a skálázási gond is tetőzi. Megjegyzem, a 980Ti és az 1080Ti sem frenetikus a skálázódást terén, csak abban a szerencsés helyzetben vannak, hogy nem kell hová kapaszkodniuk.
    A Pascal 4-5%-kal jobb "IPC"-ben, mint a Maxwell - teszt. A Maxwell kb. 10-15% előremozdulás volt a Keplerhez képest, ezt teljesen jól kimérni nem lehet, de több kártya összevetéséből kb. ennyi esik ki.

    Az pedig aligha van rendben, hogy a Vega még azt az architektúrális előnyt sem mutatja a Fijivel szemben, mint a Polaris a Tongával szemben. Akkor OK lenne, ha ez egy Prescott-jellegű órajelbooster architektúra lenne, de láthatóan nem az. Tele van jó ötletekkel, amik valamiért nem működnek.

    (#49) Abu85: most őszintén, szerinted kit érdekel, hogy mennyi memóriasávszélességet spórol meg a BF1? Mi ez, valami diákolimpia takarékoskodásból? ;] Az az érdekes, hogy hogyan hasznosul a felszabadított sávszélesség. Erre van kimutatás?
    Ez megint olyan, mint amikor a rapid packed math-tal egyetlen játékban egyetlen algoritmus 50%-ot (vagy mennyit) gyorsult. És az egész képkockára levetítve ez kiadott 1.5-2%-ot...

  • #35 Abu85 HÁZIGAZDA Petykemano #34
    Új Válasz #35
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Petykemano #34 üzenetére

    a) Szerintem az NGG helyére jó a GPGPU culling aszinkron compute-tal és az RPM-mel. Látszik a Wolf 2-ben, hogy működik, a Far Cry 5 is ilyet használ. Az NGG-vel szemben mindenképp az az előnye ennek a megoldásnak, hogy nem csak a Vega GPU-kon fut, hanem mindenen, mert szabványos compute shaderekrúl van szó. Ergo lehet, hogy több munkát kell belefektetni, de megéri, mert a Vega GPU-k mellett minden más hardver profitál az eredményből. Konkrét mérések nincsenek, de nem lepődnék meg rajta, ha egy ilyen GPGPU culling pipeline async compute és RPM mellett gyorsabb lenne, mint az NGG maga. Öszvér megoldás, de sebességben jobb és szabványos. A piac ezen nyer.

    b) A konzolok nem támogatják a primitive shadert. A PS4 Proban van superstencil, erre épülhetnek olyan effektek, amelyeket normális sebességgel csak primitive shaderre lehet átültetni.

  • #32 Abu85 HÁZIGAZDA Petykemano #30
    Új Válasz #32
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Petykemano #30 üzenetére

    Az algorimusért. Ha valaki integrálni akarja, akkor az pénzbe kerül. Azért ilyen rendszert nem két perc kidolgozni, amit most látsz a Radeon Software-ben, az nagyjából négy év munka eredménye. De a többség bele sem fog, mert az AMD-nél vannak olyan szabadalmak, amelyekkel betámadható egy Chill-másolat.
    A fejlesztőknek azért érné meg a programba való integrálás, hogy a Chill ne csak Radeonon működjön, de ehhez ki kellene fizetni az AMD-nek a licencet, vagy ha saját rendszert írnak, akkor a kapcsolódó szabadalmakról kell megegyezni.
    Igen, azért fizet az Intel. Egyelőre csak a Kaby Lake-G-re. De igazából maga a rendszer üzemképes lenne Intel IGP-vel is, ha hajlandó a cég megfizetni.

  • #31 smc addikt Petykemano #30
    Új Válasz #31
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    smc

    addikt

    válasz Petykemano #30 üzenetére

    De. :)

    A fejlesztők nem fizetnek a Chillért. És szinte biztos, hogy ha az AMD nem maga kezelné a Chill-t, akkor egy játékban se lenne beépítve. Lehet mondani, hogy de nem, de igen.

  • #28 Abu85 HÁZIGAZDA Petykemano #27
    Új Válasz #28
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Petykemano #27 üzenetére

    A Chillnek simán lenne támogatottsága. Sokkal bonyolultabb AMD-only dolgokat beraknak a mai játékokba, lásd shader intrinsics, ami konkrétan alternatív shadereket igényel, vagy RPM, amihez specialis header kell. Itt a probléma tényleg a licenc lehet, mert amíg a shader intrinsics eszközei GPUOpen-en elérhető MIT licences megoldások, addig a Chillért keményen fizetni kell. Jól jelzi, hogy eddig erre csak az Intel volt hajlandó. A HiAlgo felvásárlásával ugye a szabadalmak is az AMD-hez vándoroltak, tehát lemásolni sem könnyű.

  • #25 Abu85 HÁZIGAZDA Petykemano #24
    Új Válasz #25
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Petykemano #24 üzenetére

    Nem csak ez a lényege. A Chill nagyon bonyolult rendszer. Igazából olyan, mint a frame pacing a multi-GPU-knál, csak itt scene pacingről van szó. Egyszerűen a hardvert vezérlő szoftver még elég sok OS funkciót megpróbál befolyásolni, hogy maguk a jelenetek kontrollálva, egyenletesen érkezzenek meg a GPU számára. A kontrollt ugye maga az input befolyásolja. Ha akció van, akkor a jelenetszámítás nincs korlátozva, míg ha csak nézel előre, vagy maga az input látszólag lassú, akkor a jelenetszámítás vissza lesz fogva. Ez igazából több előnnyel jár. Egyrészt az a tapasztalat, hogy a játék során követik egymást a lassú és gyors részek, és a lassú részeknél nincs szükség 100 fps-re. Itt spórol a hardver. A scene pacinggel járó alacsonyabb késleltetés igazából csak egy mellékterméke a működésnek, mivel valahogy muszáj szabályozni a terhelést, és az az ideális, ha a jelenet számítása lesz kontrollálva. Mivel ez nagyon egyenletessé teszi a GPU számára is a terhelést, így minden inputhoz tartozó kép gyorsabban megérkezik a kijelzőre, mint a klasszikus, nem szabályozott dupla vagy tripla pufferes koncepcióval. Ezért szeretik az eSportolók, de ez tényleg csak az algoritmus mellékhatása, valójában nem volt cél a késleltetés minimalizálása.

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

Hirdetés