Keresés

Hirdetés

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

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

    [ Szerkesztve ]

    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