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

• #9985 gbors nagyúr Ren Hoek #9982

  Új Válasz 2015-09-07 10:45:40 #9985

  Ú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 Ren Hoek #9982 üzenetére

  Nem a compute queue-k száma az izgalmas kérdés, hanem (feltéve, hogy tényleg ekkora overhead a CS) a szükséges váltások száma. Ha pl. az összes compute queue scene-előkészítési feladatokat végez, amik mind lefuthatnak a grafikai taskok előtt, akkor nyugodtan lehet több queue, először azokat hajtja végre a GPU - aztán vált, és jöhet a grafika (mellesleg ez nagy előnye a félig szoftveres megoldásnak). Ennek persze előfeltétele, hogy a frame-re vonatkozó összes feladat meglegyen, amikor elkezdi a számítást - ezt nem tudom, hogy így van-e, ill. ha nincs, akkor megoldható-e egyáltalán. Ez egy második, ellenkező irányú nagy HA.

  Az önmagában nem gond, ha az adat ide-oda vándorol a compute és a grafikai queue-k között - miután ezek az architetktúrák erősen latency-állók, szerintem a GCN-en ez csak akkor gond, ha eszement mértéket ölt. Ami inkább kérdés, hogy a gyakorlatban mennyi értelme van ennek - nem vagyok grafikus programozó, úgyhogy erről inkább véleményt sem mondok.

  (#9983) HSM: kicsit túlpörögted azt az egy mondatot, nem? Nem a két szituációt hasonlítottam össze, csak annyit jegyeztem meg, hogy most már az AMD oldalon is van csodafegyver.

  Az, hogy a gyakorlatban mi lesz, attól még nagyon messze vagyunk. Egyrészt ott voltak sayinpety fórumtárs saját tapasztalatai, ahol a Maxwell is gyorsult az a-c hatására, tehát elvileg működésre lehet bírni a dolgot normálisan. Másrészt B megoldásként ott lesz a lehetőség, hogy mindent a gf queue-ba tesz a program, mint az AotS esetében - így az aszinkron sebességnyerés elmarad, de ez úgyis kisebb lett volna, mint a GCN esetében. Harmadrészt pedig, ki tudja, milyen meglepik jönnek még elő...

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