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

• #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...

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