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

• #6179 Whit3Rav3n senior tag

  Új Válasz 2013-06-21 12:40:28 #6179

  Ú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

  

  Whit3Rav3n

  senior tag

  A CPU limit és mikroszaggatás összefüggését úgy lehet elképzelni hogy a cpu dolgozik egy frame-en egy bizonyos ideig aztán továbadja a gpu-nak, Utána azonnal elkezdi a következö frame-et és továbbadj a másik gpu-nak. Innentöl egyszerü latni a problémát hogy ha a cpu sokkal gyorsabban dolgozik mint a gpu-k akkor egymás után kiad gyorsan 2 frame-et a gpu-knak aztán egy hosszabb várakozási ideje van amikor a gpu-kra vár. Ezzel meg is kapjuk az ismert egy rövid frametime egy hossu frametime mintát ami tipikus 2 gpu.nál. Itt egy képletes ábrázolás:

  

  Ha viszont a gpu-knak kell a cpu-ra várnia más a helyzet hiszen ott nincs afr-hez hasonlßo munkamegosztás, a cpu viszonylag egyenletes idökben lesz kész azonos helyzetben. Itt egy ábra a cpu limites helyzetröl:

  

  Itt a frametime-ok megint egyenletesek mert a cpu lassúsága miatt nem tudja elöbb átadni a feladatot a gpu-nak így nincs a váltakozó hosszú és rövid frametime. Szóval ennek bizonyítására az ember azt várja el hogy lassú cpu-val csökkenjen a mikroszaggatás. Erre több userteszt készült underclockolt meg oc-s proci összehasonlítással ugyanabban a game-ben ugyanzon a helyszínen ahol gyors cpu-val gpu limit van:

  

  

  A mérések igazolják a feltevést.

  Viszont nem kell cpu limit ahhoz hogy az ember ilyen módon eltüntesse a mikroszaggatást hiszen egy frame limiter megcsinálja ugyanezt a lassú cpu hátrányai nélkül.

  

  A helyzet itt ugyanaz mint cpu limitnél a limiter nem engedi hamarabb elkezdeni a második kártyát számolni (amennyiben azok a limit fölötti fps-t produkálnának) így megijntcsak megszünik a mikroszaggatást okozó frametime váltakozás.

  [ Szerkesztve ]

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