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

• #190 Abu85 HÁZIGAZDA namaste #189

  Új Válasz 2017-05-28 08:28:47 #190

  Ú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 namaste #189 üzenetére

  Nézd a teszteket attól a patch-től, amivel az AGS4.0 támogatást belerakták. A legújabb programverzióban már látszik az eltérő kód. [link] - másképp nem lenne a 980 Ti nyakán a quiet BIOS-os 580.

  (#188) b. : Ez nagyon függ attól, hogy milyen jelenetet mérsz. Bele kell futtatni a hardvert a limitációba.

  [ Szerkesztve ]

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

• #191 gbors nagyúr namaste #189

  Új Válasz 2017-05-28 09:02:37 #191

  Ú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

  válasz namaste #189 üzenetére

  Ebbe másszunk bele kicsit jobban, mert az én fejemben van több kérdéses pont ezzel kapcsolatban. Szerintem az alábbi állítás a gyakorlatban lehet jellemzően igaz, de egyáltalán nem szükségszerű:
  "Ami felül bemegy, annál több nem jöhet ki alul."

  Ahogy én értem a folyamatot nagy vonalakban: a raszterizáló fogja az összes háromszöget, ami a tesszeláció és a láthatósági szűrés után megmarad, és a célfelbontásnak megfelelően pixelekre képzi őket, azaz a raszterizáló teljes munkája a megmaradó háromszögek összes pixele. Ezután futnak a shaderek, amiknek az eredménye lesz ROP-művelet. Amiért a fenti állítás nem szükségszerű:
  - Nem minden pixelt fog fedni háromszög, viszont azokhoz is tartozik legalább egy ROP-művelet (= több jön ki, mint ami bemegy)
  - Lesz olyan pixel, amit több háromszög is fed (= kevesebb jön ki, mint ami bemegy)
  - Lehet MSAA is, ami többször "megtapogatja" a pixeleket (= több jön ki, mint ami bemegy)
  Ezeknek az átlaga akár lehet 1:1 is, de nyilván számos dologtól függ.

  A kérdések, amik a fenti egyensúlyt nagyban befolyásolják:
  - Biztosított-e, hogy a raszterizáló minden háromszögön csak egyszer megy keresztül?
  - Mikor történik a ROP művelet? Minden shader lefutása után egyszer? (ezt nehezen hiszem, mert akkor a világ összes ROP-ja nem lenne elég egy komplex motorban) Az összes shader lefutása után minden pixelre egyszer? (ezt is nehezen hiszem, itt a cache / memória lenne a gond) Ha a kettő között, akkor jellemzően hányszor nyúl a motor egy pixelhez? Ebből milyen arányban van a színezés és a blending? (nVidia oldalon a blending az INT8 kivételével felezett sebességgel megy)
  - Vannak olyan postprocess műveletek, amik totálisan a shaderes fázis mögé vannak rakva, újabb ROP-műveletet generálva minden pixelre? Az FXAA / SMAA szerintem ilyen, van-e további?

  Ha ezekre a kérdésekre van válaszod (vagy bárkinek, aki olvassa), azt nagy örömmel venném. Az 1060-asnál pedig olyan teszteket kellene látni, ahol nehezen magyarázható módon lemarad a 980-tól.

  (#187) Abu85: ha ugyanaz a képminőség jön ki, akkor felőlem tizedannyi munkával is dolgozhat az AMD, összehasonlítható lesz az eredmény.

  [ Szerkesztve ]

  Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

• #206 gbors nagyúr namaste #205

  Új Válasz 2017-05-29 09:36:22 #206

  Ú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

  válasz namaste #205 üzenetére

  OK, akkor még egy adag kérdés

  A kép rajzolás képbuffer törléssel kezdődik: (...) nem kell ROP hozzá. Amely pixelre nem kerül háromszög, az marad háttérszínű.

  Nem elsősorban erre gondoltam. Mi a helyzet a GPU által generált részecske-effektekkel - köd, füst, stb.?

  Ha a kirajzolandó háromszög pixele
  - takarja a már kirajzoltat, akkor felülírja, vagy ha átlátszó akkor színkeverés történik,
  - takarásban van, akkor nem lesz új ROP művelet.

  No de akkor mit csinál tulajdonképpen a ROP? Ebből a szakaszból úgy tűnik, hogy a Z-tesztet sem ő végzi, akkor gyakorlatilag csak színez, szükség esetén blendinggel együtt?

  MSAA

  Nagyon meglep, amit írsz, ahol eddig foglalkoztak a raszter : ROP aránnyal, mindenhol az MSAA-t emelték ki, mint a több ROP haszonélvezőjét. Ez biztosan így van?

  Miután lefut a pixel shader, minél hamarabb.

  Egy komplexebb motorban, jelenetben jópár shader lefut egy pixelre. Szerinted megoldható az, hogy az összes shader lefut egy pixelre, és csak utána van ROP-művelet?

  Postprocess

  OK, értem. Ez akkor egy teljesen külön kör, amiben a képet végigzavarja a teljes pipeline-on?

  Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

• #210 gbors nagyúr namaste #207

  Új Válasz 2017-06-03 09:31:17 #210

  Ú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

  válasz namaste #207 üzenetére

  Ezeket textúrával, pontokkal, apró háromszögekkel is meg lehet valósítani.
  Persze, anno rövid ideig divatos volt ilyeneket geometry shaderrel csinálni, viszont ha rögtön screen space-be dolgoznak, akkor szvsz nem kell hozzájuk raszter - ROP viszont igen.

  MSAA
  Hmmm, igazad lehet - én a coverage vizsgálatot máshová képzeltem.

  Minden megoldható, de ahhoz tárolók kellenének, vagy cache, vagy memóriába kiírni. De hát ezt csinálja a ROP is ...
  Pont ide akarok kilyukadni - nekem az tűnik logikusnak, hogy a "bonyolultabb" pontokon több ROP-művelet van, mert egy pass-ban nem tud minden shader lefutni rajtuk.

  Postprocess
  OK, de gondolom, ha compute shader csinálja, akkor nem kell sem raszterizáció, sem ROP.

  Összességében oda lyukadtam ki, hogy jóval kevesebb helyen lehet több ROP / pixel művelet, mint eddig gondoltam, de valamennyit továbbra is látok. Nyilván ez a kérdés egyre inkább akadémikus, mert ha a raszter : ROP arány mondjuk 1:1.07, akkor ugyanúgy egyenlú számú kell belőlük, mintha 1:1 lenne. nVidiáéknál meg ettől függetlenül lehet értelme a több ROP-nak, mert a blending az INT8 formátum kivételével felezett sebességű, így pl. FP16-tal szélső esetben egy 8-as raszter 16 ROP-ot tud etetni.

  Ja, és közben az jutott eszembe, hogy az nVidiának kellene, hogy legyen olyan unitja, ami órajelenként 8 pixelt raszterizál, mert a Kepler GPC-kben olyan volt.

  Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

• #213 gbors nagyúr namaste #211

  Új Válasz 2017-06-15 08:15:37 #213

  Ú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

  válasz namaste #211 üzenetére

  Tudnál olyan példát mondani, ahol nincs grafikus primitív (pont, vonal, háromszög), nincs raszterizálás, de van pixel shader és ROP művelet?

  A lentiek alapján nehezen. Nekem erre az MSAA és a pixel shaderes post process effektek voltak a tippjeim, de ha az előbbinél a fedettségvizsgálatot a raszterizáló csinálja, az utóbbiak pedig egy bazi nagy háromszögön keresztül dolgoznak, akkor egyik sem nyert.
  Még egy tippnek ott van a screen space-ben csinált részecske-effekt - ha van ilyen egyáltalán

  Az a kérdés, milyen gyakran használják az INT8-tól eltérő képformátumokat színkeveréssel.

  Ezt én is nagyon szeretném tudni...

  A GTX 1060 több ROP egysége inkább kivétel, mint szabály.

  Most már igen - anno a Fermi és a Kepler generációban a legnagyobb chipekben kevesebb volt a raszter, mint a ROP.

  Ha a GT 1030 egy felezett GTX 1050 Ti, akkor van 1 GPC órajelenként 16 pixelre képes raszterizálóval és két darab órajelenként 8 pixel sebességű ROP blokk.

  Persze - a kérdés csak az, hogy nem buheráltak-e rajta valamit. Valahonnan jönni kellett a konfúziónak, hogy 8 vagy 16 ROP. Abu emlegetett pixel throughput tesztje ugyan nem bizonyíték semmire, de jelezni az is jelez valamit.

  Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

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