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

• gbors nagyúr

  #547

  #546 p87

  2013-04-04 13:24:51

  Új Válasz

  Ú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

  

  gbors

  nagyúr

  #546 p87

  #546 p87

  Nem akarok hülyeséget írni, mert ti sokkal jobban tudjátok ezt a témát mint én, de én arra gondoltam, hogy a Fraps-el mért értékeknek semmi köze a kártyához és driverhez mivel még jóval előttük kapcsolódik be folyamatba, ergo ezt nem lehet se NV-nek, se AMD-nek felróni ha valami furcsát látunk mert semmi közük hozzájuk.

  CF-et nem vitatom én sem.

  az igaz, hogy a Present() call után jön csak a képbe a teljes GPU miskulancia, de két dolgot nem árt ehhez tekintetbe venni:
  - ha a Present()-ek egyenletesen jönnek, és utána a a GPU-k összeb*****k az időzítést, akkor annak ugyanúgy ugráló hatása lesz (nagyon rossz esetben jönnek a sokat emlegetett runt frame-ek)
  - ha valamelyik frame kiszámolása nagyon sokáig tart, akkor az engine közben megtölti a saját framebufferét, és vár, amíg a GPU nem ürít. ilyenkor a Present()-ek között is jelentkezik egy hosszú frame - rosszabb esetben pedig utána néhány rövid, mert a GPU gyorsabban ürít, mint ahogy a motor számít rá, és akkor a motor is felgyorsít. ezért problémás, ha a két gyártó csudálatos power control megoldásai gyakran billegtetik az órajelet nagy mértékben.

  @SzlobiG: én egy kicsit sarkosabban fogalmaznék. teljesen sz*r, amit az AMD megoldása csinál, és ezt az input lagos rizsát csak utólagos magyarázkodásként hozták be. ha az input lagra figyelnének, akkor olyan ütemben tennék ki a frame-eket, ahogy a Present()-ek érkeznek.

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