Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz Televan74 #35958 üzenetére

    Eleve a FreeSync 2 nem abból a szempontból vizsgálja a monitort, mint a DisplayHDR. Az rendben van, hogy vannak bizonyos minimum követelmények, de a FreeSync 2 HDR olyan dolgokat specifikál elsődlegesen, amiket a VESA nem is néz. Ilyen például a közvetlen HDR transport, ami VESA-ban nem létezik. Valószínűleg később sem fog létezni, hacsak az API-kat fejlesztő érintettek fel nem karolják a kijelzőoldali tone mapping problémáját, és nem kínálnak egy megoldást rá, amit egyébként lehet, de azzal meg az a probléma, hogy az addig kialakított HDR pipeline-okkal nem kompatibilis. Az AMD azért csinálja, mert ők írtak maguknak egy saját HDR pipeline-t, arra biztosítottak az API-kra kiegészítéseket, így azt közvetlenül elérhetik a fejlesztők. Ilyen formában a HDR-ben a fejlesztő nem csak egy utazó a HDR transport mögött, hanem szoftverben megírhatják a HDR transport feltételeit. Ezért is kell API szinten kezelni az FreeSync 2 HDR-t, mert ehhez le kell kérdezni a kijelző adatait. Na most lényegében ezeket az adatokat specifikálja az AMD, és a kompatibilis monitorgyártóknak kötelező az információt bejuttatni a rendszerbe, amivel már a program számolhat is.
    A szabványos HDR pipeline-ok ennél jóval egyszerűbbek. Nincs lényegi információ a kijelzőről, így gyakorlatilag a HDR transport mögött már csak utazik a kép, vagyis az utolsó tone mapping fázis a számítógép felől befolyásolhatatlan.

    Nagyon egyszerűen megfogalmazva a mai HDR szabványokkal a teljes pipeline-on a HDR transportig befolyásolható a kép a program oldaláról. Utána már nem, és lesz is egy olyan lépcső, ami gyakorlatilag befolyásolhatatlan. A FreeSync 2 HDR csak annyit csinál, hogy ezt az utolsó lépcsőt kivágja, és az egyel korábbi lépcsőre osztja vissza a feladatait, ami a program oldaláról még befolyásolható lépcső.

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