2. Fórumok
  3. Videokártyák
  4. Minden, amit a DirectX 11.1-ről tudni kell
Keresés

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

  • #58 #00137984 törölt tag kisfurko #53
    Új Válasz #58
    Ú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

    #00137984

    törölt tag

    válasz kisfurko #53 üzenetére

    A kijelzők amik a 4K felbontást is kezelnek elég magas áron 12 bites feldolgozó egységgel rendelkeznek.

  • #56 #00137984 törölt tag kisfurko #53
    Új Válasz #56
    Ú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

    #00137984

    törölt tag

    válasz kisfurko #53 üzenetére

    A fejlődés a technológiákban követhető. DVD formátum maximum 8 bit (XP DirectX10, Vista DirectX10.1). Blu-Ray 8 bit (standard kódolás) - 16 bit (elméleti maximum) (Windows 7 DirectX11, Windows 8 DirectX11.1). 4K Ultra HD 12-xx bit (Windows 8 DirectX1x.x). Windows 8 és a Linux már kezeli a 4K videokat. A Windows 7-en nem tudom, hogy a 3840x2160 (4096x2160) felbontás megjeleníthető egy arra alkalmas kijelzőn.

  • #55 #00137984 törölt tag kisfurko #53
    Új Válasz #55
    Ú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

    #00137984

    törölt tag

    válasz kisfurko #53 üzenetére

    Köszönet, hogy pontosítod az adatokat. A WikiPedián és a Videopraktika oldalán találtam a számokat, lehet ők sem hibátlanok. Ez igy még húzósabb értékek, akkor igazak lesznek az információk a 128 bites Windows készültéről. Eddig valószínűbbnek találtam a 96 bites változatot, a 32 bites program kompatibilitás megtartása mellett. Ez valószínűleg már DirectX 12-vel megvalósítható. Nem kell majd Quad SLI, 32 GB RAM és 12 magos CPU, hogy megmozduljon egy játék vagy maga a rendszer.

  • #54 Pikari veterán kisfurko #52
    Új Válasz #54
    Ú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

    Pikari

    veterán

    válasz kisfurko #52 üzenetére

    nos, nekem az ati radeon 9800 hajlamos volt ilyen 20 pixelnyi blokk nagyságú árnyékartifactokat csinálni, az meg azért eléggé feltűnő, ocsmány, és lehangoló.

    a szoftveres renderert meg meg kell írni - egyszer. utána viszont tetszőlegesen skálázhatod, ha az effektekről van szó, nem vagy idegen grafikus pipelinere kényszerítve. a raszterizálás elhagyása nem ekvivalens azzal, hogy processzoron számolunk, elvégre nem csak ray tracelni, hanem raszterizálni is lehet cpu-n. a cpu-ra nagyon szép és gyors raszteres renderert lehetne írni, de én nem raszterezésben utazom már, és nem is a szép grafikában (hanem a gyorsban). a d3d-ben meg az opengl-ben konkrétan az a nem jó, hogy implementálnak egy olyan grafikus pipelinet, amire amúgy nincs is szűkségünk: azonos sziliciummennyiség mellett egy fejlesztő az önmagának fejlesztett, és/vagy célspecifikus, célirányos rendererje nagyságrendekkel gyorsabb, mint egy előre bespecifikált, túlmisztifikált, túlbonyolított, vagy épp szétspórolt api, mint amilyen az opengl, vagy direct3d bármely derivációja. in my oppinion.

    (privátban tudok erről több paramétert adni, ha dobsz egy skype címet.)

  • #43 Pikari veterán kisfurko #32
    Új Válasz #43
    Ú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

    Pikari

    veterán

    válasz kisfurko #32 üzenetére

    Már miért lenne baromság? Olyan rosszul nézett ki az, amit a 9700-es ATI produkált?
    ja

    Kevesebb bittel való számolás kevesebb energiafogyasztást jelent. Mobil eszköznél ez nem elhanyagolható dolog.

    ja, kb 0,1%-al

    Ezeket alá is tudod támasztani? Kíváncsi lennék.
    természetesen. számold ki, hogy hány kódsorba telik megírni benne egy soft távolság és felbontás-independens árnyékolást, egy fénytörést refractionnal, hdr-el, animáció-támogatással, mondjuk úgy, hogy játszhatóan menjen vele legalább 100 millió polygon, legalább kezdetnek mondjuk 100 ezer fényforrásra (ami értelemszerűen nem világítja be mind az egész pályát, csak helszíneket), amelyen mind tetszőlegesen dinamikusak (ez nem jelenti azt, hogy mind mozog, hanem azt, hogy bármikor tetszőlegesen mozoghatnak az enginedben), mindezt körültekintően úgy, hogy képes legyen a kódod leskálázni az előző évtized első harmadában megjelent hardverekhez oly módon, hogy ezeken a hardveren is el tudd indítani úgy, hogy meg is mozduljon néha a kép

    aztán számold ki, hogy mennyi kódsorba kerül ugyanez mondjuk egy saját szoftveres renderereddel (nyilván csak feltételezve azt, hogy meg tudsz egy ilyet írni)

    majd hasonlítsd össze a két produktum végeredményét teljesítményben, minőségben, kompatibilitásban, és hasonlítsd össze a belefektetett időt, és energiát (vagy közvetlenül szólva: pénzt) mindkét esetben

    és lepődj meg nagyon.

  • #35 #00137984 törölt tag kisfurko #33
    Új Válasz #35
    Ú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

    #00137984

    törölt tag

    válasz kisfurko #33 üzenetére

    16 millió színt amelyik monitor nem képes megjeleníteni, panel típustól függetlenül, az nem felel meg az alap elvárásoknak. Az MPC HC-vel a 10 bites RGB kimenetet használva jelentősen nagyobb élmény megnézni a filmeket.

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

Hirdetés