Keresés

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

  • Abu85

    HÁZIGAZDA

    válasz vass1024 #10943 üzenetére

    Ugyanakkora az esélye. Írtam nemrég, hogy a VGA-k esetében a hibaarány 7%-ra nőtt. Ezzel nem lehet mit csinálni, manapság a gyártók visszafogták a minőség ellenőrzését, aminek az az átka, hogy nő a hibaarány. Cserébe a gyártók zsebében több pénz marad. Muszáj ezt meglépni, mert csökken a piaca a VGA-knak. Szerencsére nem drasztikusan, de 2012-ben főleg az volt a cél, hogy ha 30%-kal kisebb piacon is, de hozni tudják a 2010-es nyereségszintet. Ez sikerült is, sőt nő a nyereség, de nő a hibaarány is.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Rexcor #10946 üzenetére

    Sajnos ez a gyári hibás termék gyártótól független. Lehet a szuper márkában is gyári hibás. Én is három EVGA-t küldtem vissza zsinórban a 8800 GT-s érában. Pedig az márka.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Locutus #10949 üzenetére

    Best Buy. Gondolom a tapasztalataik alapján készítették.

    Ne viccelj már, most arról beszélünk, hogy a VGA hibásan kerül a dobozba. Ha azt állítod, hogy az NV-nél ez nem fordul elő, akkor egyértelműen nem vagy tisztában a gyártás folyamataival. Ugyanakkora lehetőség van erre minden gyártónál, mert mindenki ugyanúgy gyárt. Majd ha lesz olyan gyártó, aki dobozolás előtt két napig terheléstesztet futtat minden egyes piacra kerülő VGA-n, akkor beszélhetünk arról. hogy a gyárilag hibás termékeknek nincs esélye piacra kerülni.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Locutus #10953 üzenetére

    És te egy olyan fórumból indulsz ki, ami a vásárlóbázis talán 1-2%-át ha képviseli, és megkérdőjelezed azt a statisztikát, ami a teljes eladott mennyiséget vizsgálja.
    Egyébként nem értem, hogy mit akarsz elérni. Eddig is voltak hibásan csomagolt termékek. A jövőben is lesznek. Leírtam, hogy addig ez nem változik meg, amíg valaki nem teszteli az összes terméket csomagolás előtt.
    Egyébként a 7% sem a gyárilag hibásan csomagolt termékekből jön, hanem a meghibásodásokból. A gyárilag hibás termékek aránya a nem gyárilag tuningolt kártyák között elenyészően alacsony, szinte nem is mérhető. A gyári tuning viszi fel ezt 2,6%-ra, mert a lapkát az alapórajelre tesztelik, amit aztán az adott gyártó nagyobb órajellel helyettesít, de tesztelni már nem teszteli.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Locutus #10955 üzenetére

    Nem biztos, hogy a gyártókra lebontva ezt érdemes nézni, mert itt most arról beszélgetünk, hogy a termék egyszerűen nem adott képet. Ezzel a hibával kétlem, hogy más lenne az arány. Az NV-nél a gyárilag rossz termékek aránya nagyon torzított. Ugyanis az NV partnerei többször nyúlnak gyári tuninghoz. Ez a GPU Boost mellett tesztelés nélkül gond. Mivel a GPU Boost arra szolgál, hogy a különböző képességű GPU-kat is lehessen másképp specifikálni. [link] - írtunk is erről a problémáról. Ez jelentősen rontja az NV statisztikáját. Ha ez nem lenne, akkor nem hiszem, hogy a két nagy termékskála meghibásodási aránya között nagy különbség lenne.
    A fórumokkal az a baj, hogy mindig a vásárlóbázis egy apró töredékét képviselik, ráadásul akinek nincs panasza nem ír.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Locutus #10958 üzenetére

    Lebontották. DE! az NV a GPU Boost miatt ér el rosszabb statisztikát, mert rengeteg gyártó nem limitálja 4 binre a gyári tuningos kártyáit (ami nyilván nem az NV hibája). Ez fontos dolog, mert ha nem lenne a Boost vagy a nagyobb gyártókhoz hasonlóan limitálva lenne a BIOS, akkor az NV statisztikája sem lenne ennyire rossz (az EVGA, ASUS, MSI és Giga már limitálja a gyári tuning boostját). Ezért nem akarom ezt ide belekeverni, mert általánosan lenne rosszabbnak feltüntetve, amikor nem teljesen általános a probléma.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gainwardgs #11160 üzenetére

    Nyilván amellett, hogy nem tudom, hogy igaz-e. Mert ugye asse tom mi az a titán azért megjegyezném, hogy a teljesítményeredmények már ott sántítanak, hogy a Hitmanben a GTX 680 és a 7970 GHz között ilyen kevés a különbség. Nálunk a GTX 680 átlag fps-ben annyi, mint amennyi a HD 7970 GHz minimum fps-ben. Persze ez nem mond sokat, de számos programban reprodukálható ez a forma, mint a Sleeping Dogs-ban és a DiRT Showdownban (ami egyébként kapott egy brutál boost patch-et).

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz BeLucZ #11163 üzenetére

    Minden gyorsult. Nagyjából a duplájára. Valszeg a CES-en a Temash tablet is azért futtatta ezt a Showdownt olyan jól, mert az már a megpatch-elt verzió volt.

    (#11164) gainwardgs: Csak fel akartam hívni a figyelmed, hogy az a kép az arányokban sántít.
    313.96 bétával mértünk, ami lényegében a WHQL közvetlen elődje. Ezek a különbségek a hardverből jönnek.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gbors #11166 üzenetére

    Nekem a fejlesztők a King of China Town pályát ajánlották, mert az használja a legjobban a VGA-k modern képességeit. Egyébként majdnem mindegyik map jó. Egyedül a Run For Your Life pálya az, ami az effektek és a fényforrások szempontjából szegényes a többihez képest, így annyira nem terheli a VGA-k compute hatékonyságát, de a Nixxess szerint ez is használható mérésre.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gainwardgs #11477 üzenetére

    Igazából érdemes lenne elolvasni az oldalt és nem csak a képeket megnézni. Pont azt írják, hogy kihagyták a mérést, mert funkcionálisan rosszul működik. [link] - oldalt látható, hogy azt a kis lila előtti apró világoskék sávot alul frame-nek érzékeli. És ezért igen nagy a különbség a frame-ek között.
    Ugye erre rá kell jönni előbb, hogy ez miért van.
    Mivel a frame Rating capture megoldás amit használnak elemzésre, gyakorlatilag a kimeneti képet érzékeli (gyakorlatilag a kijelző és a VGA közé van bekötve), így a folyamatosságot képtelem meghatározni, ergó képtelen mérni a mikroakadást, mert fixen másodpercenként 60x vesz mintát (60 Hz-es frissítés mellett persze), ergo minden a kimeneti kép tekintetében minden termék ugyanolyan smooth ezzel a rendszerrel.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz BeLucZ #11482 üzenetére

    Igazából nem kelleme magyarázni, ha nem csak a képeket néznék az emberek. A PCPer leírta, hogy ez a rendszer hogyan működik. Ezzel mikroakadást képtelenség mérni, mert fix időközönként kirakott képkockákat elemez, függően a monitor frissítésétől. Gyakorlatilag a képtöréseket kell nézni.
    Ez akkor lenne érdekes, ha a hardver képes lenne elvonatkoztatni a monitortól. Ergo tulajdonképpen egy olyan capture kártya lenne a gépben, ami ahhoz igazodik, hogy a VGA mennyire gyorsan dolgozik, így vsync nélkül is képes lenne az összes teljes képkockát elfogadni. Ezeknek a beérkezési idejét lehetne mérni, és abból lehetne számolni. Persze ez a kijelző oldalán még mindig értelmetlen, mert az úgyis fix frissítéssel dolgozik, de belül már meghatározható, hogy miképp dolgozik a hardver.

    A legkézenfekvőbb megoldás a folyamatosság mérésére egy nagy sebességű kamera befogása. Az ugyanis azt látja, amit a felhasználó, és nem azt ami a gépen belül történik. Sajnos ez a legidőigényesebb, és nagyon költséges is. :U Többek között ezért maradtunk a szemmértéknél.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz TTomax #11484 üzenetére

    We aren't ready to show our full sets of results yet (soon!) but the problems lie in that AMD's CrossFire technology shows severe performance degradations when viewed under the Frame Rating microscope that do not show up nearly as dramatically under FRAPS.
    Ez funkcionálisan egy rossz működés eredménye. De már a koncepció is rossz, mert fix 60 képkocka elemzésére hagyatkoznak, vagyis a smooth mérésére nem jó, mert mindegyik hardverrel ugyanazt a fix 60 képkockát nézik, vagyis minden hardver ugyanabban az időben, ugyanúgy elküldi a számolt képet. Ergo mindegyik kép ugyanakkor jelenik meg. Ez úgy lenne működ, ha az elemzés nem fix képkockákra vonatkozna, hanem limittől mentesen a capture kártya mindig elfogadná a GPU által számolt teljes frame-t. Ezek idejét feljegyezné, és lehetne belőle számolni. Mivel azonban ez nem így működik már a számolás szintjén sem, így értelmetlen az egész.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gainwardgs #11486 üzenetére

    Van esetleg lehetőség nem 3 hónapos tesztet nézni? :)) És itt jellemzően újra gondolok, nem még régebbire. :D
    De amúgy remélem észrevetted, hogy a linkelt teszt fullra megcáfolja a PCPer eredményét, mert a Battlefield 3-at smoothabbnak hozták ki Radeonon.

    Egyébként ez megint off. Inkább menjünk át az erre létrehozott versus topikba, mielőtt valaki beszól nekünk. :)

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz TTomax #11488 üzenetére

    Nem. Ez a metódus képtelen ezt kimutatni, mert mint említettem, fix képkockákkal dolgozik. Mindig minden hardveren ugyanakkor lesz bevéve a képkocka. A képtöréseket nézi, ami nem egyenlő a stutterrel.
    A Fraps valamivel közelebb áll a valósághoz, mert az belső frame time-okat néz. Nyilván persze ez sem halálbiztos, de semmiképp sem kötött időközönként vesz mintát.
    A legjobb megoldás erre a nagy sebességű kamera.

    Szerk.: Nem az eredménnyel van Ryannek baja, hanem azzal, hogy ezt a számolt értékben jelentkező stuttert látnia kellene a valóságban. Gondolom rá akar jönni, hogy miért nem látja. Valamit ő rontott el, vagy szimplán nem jó tesztmódszert alkalmaz erre.

    Nekünk is vannak kihagyott tesztjeink, mert nem értjük az eredményt. Ezt először elemezzük és utána döntünk. Legutóbb is úgy döntöttünk, hogy két mérést kihagyunk a VGA tesztekből, mert az egyikkel 30 fps-sel sorakoznak egymás mögött a kártyák, vagyis értelmetlen, míg a másik játékkal hibás volt az egyik cég termékének a megjelenítése HDAO mellett. Mivel ezt mondták nekem, hogy inkább a program hibája, mint a driveré, így amíg nem jön erre javítás, addig jegelés van. Sajnos az Ubi beismerte, hogy elrontotta, mert csak a Radeonon tesztelték az effekt működését, ez tiszta amatőr dolog, hiszen úgy azért nem érdemes kiadni valamit, hogy a lehetséges hardvereken nem nézik meg működik-e. Elcsesztek az időmből közel 5 órát.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Tirexi #11775 üzenetére

    Nem. Ehhez nem kell annyira erős GPU. Meg eleve ez csak egy modell, vagyis csak ezt számolja a teszt.
    De ez a megvalósítás másképp működik, mint a TressFX. Jelentős különbség, hogy utóbbi OIT-t használ, ami nyilván nem egy finomkodó dolog a teljesítményigény szempontjából.

    (#11776) SzlobiG: A TressFX is tesszellál. Ez fontos, mert tesszellálás nélkül túl sok részre kellene bontani a hajszálat, ha nem akarod, hogy töredezett legyen. És ráadásul ezeket a részeket külön kell szimulálni. Hatékonyabb a megfelelő számú részre bontani, és azt tesszellálni.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz haddent #11778 üzenetére

    GeForce GTX 670-től jól fog menni. Radeon oldalon HD 7850 kell a jó sebességhez. De ha a többi grafikai elemet csökkented, akkor gyengébb hardver is elég lehet.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz SzlobiG #11781 üzenetére

    Sok dolgot nem írtam bele, mert akkor még nem láttam Takahiro Harada anyagait. Alapvetően ő volt az ötletgazda, és a tanulmányaiból kiderült, hogy ezt mindenképp tesszellálással érdemes megcsinálni. Nem azt mondom, hogy nem lehet tesszellálás nélkül, de rosszabbul jársz mint tesszellálással. Ez olyan mint az OIT/ODT. Mindkettővel működik, de ODT-vel rendezni kell, míg OIT-vel PPLL struktúrát kell csinálni. Utóbbi a sebességben kedvezőbb.

    (#11782) BeLucZ: Azt nem tudom pontosan. Sebességről még nem beszél a Nixxes. Azt mondták, hogy GTX 670 és HD 7850 mellett nem lesz gond.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz FLATRONW #11812 üzenetére

    A szintetikus tesztekben lehet erről beszélni. Ott tényleg vannak szituációk, amikor a Fermi jobban teljesít mind a Kepler. De ezek a tesztek egy specifikus szituációt néznek. Még ha a TressFX-re igaz is lesz ez, akkor is magában a játékban az effekt sok más számolással együtt jelenik meg, vagyis összességében a Kepler gyorsabb lesz.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz SzlobiG #12028 üzenetére

    Ez teljesen normális dolog, ha nincs benne olyan, ami -30%-ot adna NV-n. Nagymértékben a fejlesztők döntése, hogy hogyan írnak meg egy programot. A Crysis 3-nak talán azt lehet felróni, hogy el van vágva a DX10/DX10.1 kompatibilitás, de tekintve, hogy már a leggyengébb VGA-k is DX11-esek, így ez elfogadható döntés így 2013 elején.

    (#12033) Bull1: Nem teljesen. A GCN megjelenése után kereste fel a Crytek az AMD-t, azóta együtt dolgoznak. Az NV-vel sem szűnt meg a kapcsolat. Ez ilyen közös partnerprogramos fejlesztés. A különbség annyi, hogy az NV később levette a Crysis 3-at a reklámozandó játékok listájáról. Ezt nem értem miért, de az ő döntésük. Elvileg a szerződésük feljogosítja őket arra, hogy kirakják a progit a geforce.com-ra, egy darabig ott is volt. Valószínű, hogy nem akarnak ezekben a közösködésekben részt vállalni, inkább a saját irányukra koncentrálnak teljes erővel.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz subaruwrc #12100 üzenetére

    Ááá ... ezek a cégek nem amatőrök. Az exe átnevezése már nem ér semmit. :D A Furmarknak meg a többi powervírusnak az újabb VGA-kkal nincs értelme. Egyszerűen hardverben fel vannak a termékek készítve ezekre. Aztán ehhez lehet még nyomni szoftveres rásegítést.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    A burkolt warez is warez srácok. Aki keres az talál és ennyi. Peace. :R

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz TTomax #12256 üzenetére

    Ez így csalás. :))

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz TTomax #12276 üzenetére

    Az OC-re sokan panaszkodnak, hogy az eddig stabilnak hit órajelek mégsem stabilak. ;] Egyébként ebben lehet valami, mivel a terhelésszint Furmarkhoz közelít, de ugye itt a driver nem fogja vissza a hardvert.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    Jön majd a TR-hez egy új driver. Most beszéltem a Nixxesnél az egyik fejlesztővel. És tudják, hogy a TressFX megjelenítése valamiért rossz GeForce-on, és valóban homályosodik SSAA-nál, de ritkán. Érthetetlen módon össze vissza ugrál és a semmibe beakad a fizikai modellezés. A kód elvileg rendben van, mert Radeonon és HD Graphics 4000-en (ezzel is lehet, csak lassú) a hibás megjelenítést nem jelentkezik. Addig lehet használni, de ez jobb lesz később.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz haddent #12319 üzenetére

    Ezekért nem kell aggódni. Lehet, hogy a külvilág felé nincs kommunikálva, de az NVIDIA is ugyanazt képzeli el jövőképnek, amit az AMD (és az ARM, és a többiek), és ezzel ugyanazt, ami az új generációs konzolokban van. Az egyetlen különbség az AMD-hez képest csak annyi lesz, hogy nem x86/AMD64 procival oldják meg, hanem ARMv8-cal, mert erre van licencük. A játékokat le fogják fordítani ARM-ra is, szóval ezzel nem lesz gond.
    Az F2P és az MMO fókusz pedig stratégiai irány, akár be is jöhet. Egyelőre nehéz megállapítani, hogy rossz-e ez az irány vagy jó.

    (#12322) Sonja: De a tesszelláció csak egy felületfelbontás fixfunkciós hardverrel. Az működhet hibásan, de fagyást nem okozhat. :F

    Szerk.: Jó, látom már. A játék a tesszelláció pipával kapcsolja be a per-pixel DM-et is. Az valóban dobhat TDR-t. Mondjuk ezt tesszellálásnak nem nevezném, mert a felületet nem bontja fel, hanem egy shaderre hárítja a munkát. A végeredmény persze hasonló, csak a fixfunkciós tesszellátort kiveszik a képletből. Talán ezt illett volna külön aktiválhatóvá tenni.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz TTomax #12324 üzenetére

    Valószínű, hogy nem a szimpla tesszellálás a gond, hanem az, hogy a per-pixel DM is ehhez a pipához van kötve. Ez nem használja a tesszellátort, csak létrehozza a pixel shader futószalagon ugyanazt a hatást. Előnye, hogy nem kell felbontani a háromszögeket, így nem terhelődhet túl a raszter. Hátránya, hogy jelentősen magasabb számításigénnyel rendelkezik a shaderekre nézve. Ez valóban lehet oka az összeomlásnak.
    A tesszellátor az egy fixfunkciós hardver kap bemenetet lesz egy kimenete és kész. Mindig ugyanúgy dolgozik.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz haddent #12327 üzenetére

    Az APU-kra mindenképp szükség van, mert a PS4 és az új Box portok egy idő után igénylik majd, hogy a CPU és a GPU közös címtérbe dolgozzon. Csak CPU-val a szükséges teljesítményt hatékonyan nem lehet majd hozni. Igazából nem lesz itt sok változás. Ugyanúgy lesznek Intel és AMD procik, csak IGP-vel, amik általános dolgokat számítanak. Ezekhez lehet dedikált GPU-t venni, ha akarsz. Ami ebben jó lesz, hogy az ARM-os réteg is beugrik majd ide. Legalábbis ez logikusnak tűnik.
    Nem, a PC-s porthoz át kell írni mást is az OS-hez. Egy az egyben sosem fog menni, de a next-gen konzolok valóban nagyon megkönnyítik majd a PC-s portolást. Igazából az ARM port sem olyan nagy dolog. Eleve úgy kell írni a programokat, hogy az x86 mellé kell egy AMD64 port. Persze előbbi elhagyható, de valszeg nem mindenki fogja elhagyni. Szóval, ha ezt figyelembe véve írod az alkalmazást, akkor az ARM port innen egy nagyon egyszerű lépés. Vagy ott a HSA. Oda egy kódbázis kell, és fut mindenen módosítás nélkül.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz TTomax #12329 üzenetére

    Valószínű, hogy ők is észrevették, hiszen a TressFX problémájáról is tudnak. Minden bizonnyal már közölték az NV-vel, hogy mit kellene javítani. Vagy jön rá egy patch hamarosan.

    Szerk.: A TressFX biztos, mert azt megkérdeztem. A fagyás az lehet, hogy játékhiba. Na most ezeket is lehet driverből javítani. Ne feledjük, hogy per-pixel DM-et még senki sem használt játékban.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz haddent #12332 üzenetére

    Alapvetően a HSA nem feltétlen a több réteget erőlteti. Így is megvannak azok a rétegek a mai termékekben, csak a HSA ezeket egységesíti, így mindenki ugyanazt a vISA-t használná. A gyártóspecifikus layerek mennek a kukába, vagy maradhatnak a legacy kódok miatt.
    A legjobb példa erre a HSA-ra tényleg a JAVA. A HSA sokkal inkább a teljesítményt veszi figyelembe, de logikai működésben a JAVA-hoz nagyon hasonlít.

    Lara túl nagy hitboxot kapott. Ez okozza, hogy nem a testére tapad a haj, mert ugye az interakció a hitboxszal történik.. Lehet, hogy nagyobb csöcsöket terveztek neki, de később kisebbre szavaztak, ám a hitbox az maradt az eredeti méreten. :))

    (#12333) TTomax: Akkor izmosabb vállat akartak. :DD
    Ja egy Quasimodo modellből indultak ki. :DDD

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Tirexi #12365 üzenetére

    Túl közel megy a kamera Lara hajához. Ilyenkor túl nagy lesz a PPLL tartomány. Ezzel nem birkózik meg minden hardver.

    (#12367) Bull1: Nem. Azokra írták ezt az effektet. Számos különbség van a feldolgozásban a GCN és a többi hardver között. Elsősorban az, hogy a GCN tartalmaz az atomic counterre dedikált feldolgozókat, míg a többi architektúra nem, és egy alternatív megoldást használnak a számításra. Ez ugye nem követelménye a DX API-nak, mert nem írja elő, hogy hogyan kell megoldani az atomic counter kezelését, de azzal, hogy az AMD 32 egységet beépített minden LDS-be, egy ehhez szabott kódot brutálisan fel tud gyorsítani. És a PPLL/PTLL adatstruktúra bőven ilyen kód, főleg, ha a dedikált egységek számához szabják.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz keIdor #12416 üzenetére

    Mert túl nagy lesz a PPLL-hez kijelölt rész a képkockán. Ezt az effektet a GCN képességeihez igazították. Ez a többi architektúrának igen hátrányos. Minél több pixelre dolgozik, annál hátrányosabb.
    Ugyanaz játszódik le, mint a DiRT Showdown esetében, csak amíg annál a játéknál mozaikokra van listázás, és relatíve kevés a mozaik is, na meg a számuk állandó, addig itt pixelekre listáz, ami nagyobb terhelés továbbá a pixelekre a számítás dinamikusan változik, mert nő illetve csökken a kijelölés mérete, függően attól, hogy Lara feje mennyire van közel a kamerához.

    (#12417) SzlobiG: Pontosan. Ez minden hardveren lejátszódik, csak nem mindegy, hogy dedikált feldolgozók vannak atomicra vagy nem, illetve nem mindegy, hogy a rendezést a hardver mennyire tudja hatékonyan csinálni.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Bull1 #12419 üzenetére

    Ezt mindenkinek magában kell eldöntenie. A TressFX jó, mert az első GPU-s hajszimuláció, amit valaha játékba raktak, vagyis valaminek a kezdete. Rossz, mert erősen olyan architektúrát igényel az implementáció, ami igen nagy hatékonyságot követel bonyolult számítások során. Az AMD-nek ez megvan a GCN-nel, míg az NV inkább más utat választott. Innentől kezdve lehet az AMD-t hibáztatni, hogy szemét módon rájátszanak arra, amiben a Kepler gyenge, vagy az NV-t, hogy nem látta előre a fejlesztők igényeit a komplex compute shader effektekre, vagy látták, de szembe akartak vele menni, mert valami érdek ezt diktálta. Totál véleményes, de ha az AMD ezt a vonalat viszi tovább a játékfejlesztők felé, akkor az NV-nek nagyon hamar kell egy Maxwell.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz belinho #12422 üzenetére

    Kimaxolva mindenképp. Arra legalább HD 7850 kell (SSAA mellett az is kevés). A beállításokat némileg visszavéve viszont simán lehet TressFX-ezni még a HD 7700-on is. Elég sok beállítási lehetőséget kínál a játék, szóval nagyon jól paraméterezhető, hogy mi legyen aktív és mi nem.
    Egyébként a nagy akadásokon, amik tényleg lenyomják néha 1-9 fps-re a TressFX-es hajat GeForce-on nyilván lehet majd javítani. Ezzel nem kell foglalkozni, mert ez majdnem biztos, hogy driverhiba. Van egy szint, ami után valahogy elvágták a GeForce teljesítményét az aktuális kóddal. A terhelés növekedése lineáris, vagyis valójában nem omolhat ennyire össze a sebesség. Ez bug.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz SzlobiG #12483 üzenetére

    Known bug valóban. A Nixxes megerősítette. Patch work in progress.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gainwardgs #12495 üzenetére

    Geometry és vertex shaderben némileg gyengébb. Máshol erősebb, helyenként jelentősen. De a GCN egy új elvek szerint tervezett architektúra a feldolgozói CPU-sodtak. Emlékszel a Larrabee-re? Na kb. azt valósította meg a GCN, csak az AMD megoldása skálázódik. Egyébként sanszos, hogy az egész ötletet az AMD a Larrabee-ből emelte át, csak azt a héjat lerántották róla, amitől úgy gondolták, hogy nem működhet. Ennyi a GCN titka. A Larrabee alapötlete jól kivitelezve. Az Intel megspórolta az AMD-nek az R&D-t az irány vizsgálatánál. Ezért is rossz az a termékbejelentés, amit az Intel csinál, hogy évekkel előre megmutatják mit szeretnének. Ha nem jön be, akkor a jó ötleteket minden konkurens kilopja belőle.

    (#12497) gainwardgs: Ez sajnos jellemző. A TressFX valamiért nem jelenik meg jól NV-n. Beakadások, rossz és túlzott hajmozgás, néha el is tűnik a copf, vagy esetleg a homályosodás. Az Intel HD Graphics 2500/4000 és a DX11-es Radeonokra ez nem jellemző. Valami nincs rendben a kóddal, vagy a GeForce driverrel.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz krx21 #12507 üzenetére

    Fontos megérteni, hogy a GCN igazi előnyét a PPLL/PTLL gyorsítóstruktúrák adják. Ahogy a DiRT Showdownban. Ezt tudja az architektúra gyorsan, sokkal gyorsabban, mint a többi. Ez a Tomb Raider esetében nem állandó terhelés, mert csak a haj köré van vonva a listázás igénye. Az átlagos játékmenetben, amikor Lara előtted megy, akkor a haj nem vesz ki sok részt a képkockából. Ezzel kevés pixelre lesz listázás. Viszont ha a haj nagyon közel lesz a kamerához, akkor nagyon sok pixelre történik a listázás. [link] - itt látható, hogy ez mit jelent. A GCN sebessége kevésbé csökken, ha a hajhoz közelít a kamera, míg a többi architektúráé jobban, a GeForce-oké dedikált atomic counter nélkül sokkal jobban. A DiRT Showdown esetében ez az egész listázás állandó, mert minden képkockán ugyanannyi a mozaik, de itt minden képkockán más kiterjedésű a haj által elfoglalt terület.

    Egyébként ez a PPLL/PTLL gyorsítóstruktúra teszi lehetővé a forward+ rendert és a TressFX-et. Nélküle még ma sem lennének ezek ilyen minőségben a játékokba építve. Egyszerűen nem lenne meg hozzá a sebesség. Ilyen gyorsítóstruktúrát egyre több játék fog használni. A legfőbb kérdés, hogy miért csak az AMD látta, hogy ez erős fejlesztői igény.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz haddent #12514 üzenetére

    Mert egy terméksorozat bevezetése nem csak a fejlesztés, de a kivitelezés, tesztelés, logisztika szempontjából is sok pénzbe kerül. Az AMD egyrészt vissza akar állni az őszi frissítési ciklusra, ahogy az APU-kat vissza akarják rakni a tavaszira. Ez az egyik indok. A másikat Roy Taylor mondta, hogy az új széria év végi bevezetése felszabadítja az év elejére az anyagi erőforrásokat. Ezzel sokkal több játékhoz tudnak specifikusan fejleszteni különböző effekteket. Meg eleve játékot venni a hardverhez olcsóbb, mint új hardvert kiadni, és a sebesség szempontjából ugyanaz az eredmény. Roy Taylor rafkós ürge nem véletlenül vezette évekig az NV-nél a TWIMTBP programot.

    A PS4 ellen nem akarnak fellépni. Azt barátnak tekintik. Úgy nyilatkoznak, hogy van PC és konzol. Ezek barátok és nem ellenségek. Az AMD-nek nyilván nem, nekik a konzolpiac fontos.
    A PS4 hardverét biztos nem adják ki PC-n. Egy azonos tudású APU-t adnak ki Kaveri kódnéven. Ennek biztos elmarad a teljesítménye a PS4-ben található megoldástól, de az AMD szerintem a grafikát úgyis dGPU-val akarja csinálni, így pedig kiegyenlíthetők az erőviszonyok. Ami fontos, hogy a Kaveri APU funkcionálisan ugyanazt tudja, mint a PS4 hardvere.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gainwardgs #12518 üzenetére

    Az NV is tudja, hogy merre mennek a konzolok. A Maxwell is ilyen irányt vesz. Már csak abból a szempontból is, hogy ez lenne az az architektúra, amit az NV az ARMv8-as CPU-magjai mellé tervez. Gyakorlatilag ők is tudnak csinálni egy olyan funkcionalitású APU-t, amilyen a Kaveri, csak nem x86-64(AMD64), hanem ARMv8 alapokon. Innentől kezdve a igazából már nem sok lépcső választja el őket attól, hogy a PS4-ről PC-re portolt játékok ezen az APU-n fussanak. Az MS amúgy is összevonná a Win RT és 8 vonalat. Az RT ugyanolyan értékekkel rendelkező OS lenne, csak ARM-ra kellene telepíteni.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gainwardgs #12520 üzenetére

    De rakhatsz. Ugyanúgy ahogy a GCN-nél, a Maxwellből is lesz olyan verzió, amiben nem lesz procirész, vagyis dedikált GPU lesz. Persze az biztos, hogy az egységes címtér szempontjából a Maxwell az ARM-ot támogatja, mivel nincs x86-64 licence az NV-nek. A GCN fogja az Intel és az AMD procikat támogatni ezzel a fícsőrrel. Persze ez a funkció PCI Express interfészen keresztül nem sokat ér.
    Az új generációs konzolok annyira összeolvasztják a CPU és a GPU feldolgozását, hogy itt nem csak az lesz, hogy a jelenetszámítás végén megkapja az adatokat a GPU, amiből kiszámolja a képkockát. Ma ez egy egyszerű, egyirányú futószalag, mindenféle visszacsatolás nélkül. Az új konzolok lehetővé teszik azt, hogy a GPU aktívan kivegye a részét olyan feladatokból is, aminek az eredményét még visszaadja a CPU-nak. Ez a gyilkos fícsőr, ettől lesznek a gépek igen rugalmasak, és ettől alakul át a PC oda, hogy iszonyatosan nagy előny lesz platformszinten gondolkodni, még ha a gyártók mixelése lehetséges is marad. Még Radeon+Intel mellett sem kapod meg ugyanazt a tudásszintet, amit egy teljesen AMD-s vagy NV-s platformmal, ide az Intel is becsatlakozhat, de szerintem őket a dGPU-k törpepiaca annyira nem érdekli. GeForce+Intel pedig pláne limitált képességű lesz az NV ARM-os iránya mellett.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    Nem nézitek, hogy a driverekben vannak erre csúszkák? Én is sokkal jobban szeretem az AMD alapértelmezett beállításait, de egyszer ültem neki, és nagyjából be tudtam állítani ugyanazt NV-n is. Szóval ott a csúszka. Ha valami nem tetszik, akkor lehet tologatni. Azt nehéz elvárni, hogy két külön gyártó ugyanúgy állítsa be alapértelmezettre a rendszerét, de ezért adják meg a lehetőséget a beállítások megváltoztatására. Még csak nem is tologattam sokat az NV beállításait.

    (#12598) SzlobiG: Csak a CSAA-nál a számozást nem úgy kell értelmezni, mint az MSAA-nál, mert 16x-re is négy színmintát vesz, mint a 4x MSAA. :) Szóval a CSAA minősége sem rosszabb, csak a 4x mást jelent a két megoldásnál.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Bull1 #12601 üzenetére

    A színkomponensekkel speciel nincs para. Nekem az NV-n a túl gyenge szaturáció a gondom, illetve szerintem magas a gamma is, de előbbit feltolom, utóbbit le és happy vagyok. :DDD

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Bull1 #12606 üzenetére

    Nyilván nem ész nélkül kell a határra tolni. ;]
    Sok dolog másképp működik a Catalystben. A videókra tényleg felpakol alapértelmezetten egy csomó post-processt. Ezek egy rész hasznos, de a többi megy offra. :))
    A sima megjelenítésnél szimplán csak mások az AMD és az NV preferenciái. Mindkét cég úgy állítja be a hardverét ahogy jónak látja, és ez alapvetően szubjektív tesztekkel lesz kiértékelve. Éppen ezért lehetséges az, hogy az alapértelmezett színvilág esetleg nem olyan, amilyenre a user számít. Ez teljesen normális. Nem tudom azt mondani, hogy az AMD alapértelmezett beállítása jó, mert ez szerintem inkább megszokásból ered. De mindegy is. A lényeg, hogy ott vannak a csuszkák tologatni kell és egyszer jó lesz. Ha nagyon rossz, akkor meg egy gomb kérni az alapértelmezettet.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Bull1 #12611 üzenetére

    Nem, nem gyengébb. Csak mást jelent a szám előtte. A CSAA egy MSAA csak a színminták mellé fedettségmintát is vesz. Hülyén van számozva, ennyi. De ettől igen jó technika. Ugyanez az AMD-nél az EQAA. Ott is szimplán mást jelent a szám.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gbors #12644 üzenetére

    Az AMD a PhysX-et nem utasította vissza. Ugye az NV régóta ajánlgatja, de nem a PhysX-et, hanem a CUDA-t, amivel ugye lenne PhysX alapból. Az AMD a CUDA-ra mond nemet. A PhysX őket érdekli, csak a CUDA nélkül. Ha ez nem megoldható, akkor ennyi volt. Az a baj, hogy régen még volt egy pici esély megegyezni, de ma már az idő nagyon a CUDA ellen dolgozik. Az NV is folyamatosan azon dolgozik, hogy az OpenCL támogatást az új driverekbe leépítse. Nekik a CUDA a fontos, és ha az nem győzhet, akkor mindenki elmehet a fenébe. Kb. így állnak hozzá, gondolom érzékenyen érinti őket, hogy beleraktak egy rakás pénzt, és csak arra volt jó, hogy irányt mutasson a konkurenseknek és a nyílt szabványnak. Én is bosszús lennék. :) Amúgy jó lett volna ez stratégiai szinten, csak nem kellett volna kijönnie annak a Radeon HD 4000-5000-6000-7000-nek, ami kijött.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gbors #12921 üzenetére

    Nem a memória-sávszélesség a fő oka. Végre eredményre jutottam a kutatásomban, hogy mi az ami a GCN-nek megy és a többieknek nem. A Nixxes egyik embere mondta, hogy szimplán az történik, hogy vannak a DX11(.1)-ben opcionálisan kihasználható képességek, amiket nem kötelező támogatni, de megvan rá a lehetőség. Az AMD úgy építette a hardvert, hogy minden opcionális képességet támogassanak, míg az NV mindet megkerüli az alapvető támogatással, és ettől még jó a hardver az MS nézetében, mert az opcionális támogatás nem követelmény.
    Na most a fejlesztők ezeket az opciókat használják, és egyre több effektnél. Nyilván valamire egy dedikált hardver gyorsabb, mint a hagyományos út. És tényleg. Amelyik játékban sok a különbség a Kepler és a GCN között az egy-egy effekt bekapcsolásával dedikált atomi feldolgozókra felépített gyorsítóstruktúrát használ.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gbors #12924 üzenetére

    Azért a difi elég nagy. Talán nem a szokásos, de egyértelműen jól mérhető.
    Egyébként megvannak a különbségek. A Tomb Raiderbe, a Sniper Elite V2-be és a Sleeping Dogsba az AMD szállította a kódot. Az első kettő játék a DoF-től, míg az utóbbi a custom AA-tól zuhan be a hagyományos architektúrákon. És minő meglepetés mindegyik kód legmagasabb minőségi beállítása gyorsítóstruktúrát használ. A Nixxes azt mondta, hogy gondolkodtak azon a DOF-on, ami a Hitmanben van, de az AMD által kínált megoldás nem csak jobb minőségű, hanem minden hardveren gyorsabb is. Mondjuk így tényleg érthető, hogy ezt építik be.
    Én mondjuk ezt az opcionálisan támogatós dolgot annyira nem támogatom. Egyrészt megértem az MS-t, hogy nem szeretne minden DX funkció beépítésével az NV megfelelő hardverére várni, de az sem jó, ha túl nagy a szabadság. Most rendben van, hogy "csak" a sebességről van szó, de mi lesz ha később a képminőség is bele kerül ebbe a körbe. Jön vissza a DX9 caps bites így jártál rendszere?

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Locutus #12931 üzenetére

    Talán azért, mert az elmúlt évek egyik legjobb GTA klónja. :) Bárcsak ilyen szar portokat kapnánk mindig, ahol ennyire figyelnek a PC-s verzió felturbózására. Nincs ilyen szerencsénk sajnos. :(

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz kasa85 #13116 üzenetére

    Azokat a funkciókat, amelyek a future_level_11_1 szinthez vannak kötve nem támogatja. Az NV szerint ettől még DX11.1-es a hardver, mert futni fognak a DirectX 11.1-es programok, csak a future_level_11_1 szintet követelő effektek nem aktiválódnak. Mivel a DX11.1 lényegi újítása pont a future_level_11_1 szint, így a Kepler nem támogatja az API-t.

    A GCN és a Kepler között a DX viszonylatában egyszerű összegezni a különbségeket. Az alapvető dolgokat mindkét architektúra támogatja. A GCN a future_level_11_1 szinttel támogatja az UAV-ket az összes shader lépcsőn, és ezek száma 8 helyett 64 darab lehet. Emellett a GCN-ben van TIR és 16xMSAA támogatás, de ez D3D alatt nem érhető el.
    Az opcionális DirectX funkciók közül a GCN támogatja a SAD4 utasításokat, a CDB-t és a hardveres atomic countert, míg a Kepler ezek közül egyiket sem.
    Lényegében, ha egy DX11.1-es program olyan shadert használ, ami nem csak compute és pixel shader lépcsőn igényel UAV-t, akkor az képtelen lesz lefutni Kepleren. Ez a képminőségre hatással lesz. Az opcionális CDB és atomic counter esetében nem követelmény ezeket támogatni, de sebességelőnyt lehet belőle kovácsolni. Ez a helyzet tömören összefoglalva.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz TTomax #13119 üzenetére

    Nem mind. Windows 7-re is van DX11.1 runtime, és abban benne van a CDB és a hardveres atomic counter támogatása. Sőt, ezek a DX11 runtime-ben is benne voltak, csak máig opcionálisak, mert csak az AMD oldja meg a támogatásukat. Bizonyos játékok egy-két effekttel építenek ezekre, mint a Dragon Age 2, a DiRT Showdown, a Sniper Elite V2, a Sleeping Dogs, a MoH: Warfighter és a Tomb Raider. Ezek alapvetően teljesítményelőnyt biztosítanak. A CDB emulálható, de ekkor semmit sem gyorsít, míg az atomic countert lehet szoftveresen is kezelni, sőt bizonyos szám felett ez az egyetlen lehetőség, de ha nincs szükség sok counterre, akkor mehet a hardveres.
    A többi fícsőr a Win 8-hoz van kötve, de erre úgyis váltani fognak a gémerek, mert a Frostbite 2.0-s motor DX11.1-es továbbfejlesztése jó 10-20%-kal gyorsabban fut az alábbi DX11.1 funkció miatt Win 8-on. Ezt a sebességelőnyt minden legalább DX11-es kártya megkapja, feltéve, hogy Win 8 az OS.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz TTomax #13124 üzenetére

    A debug speciel pont nem érhető el. A shader trace interfész a WDDM 1.2-höz van kötve. A Windows 7 a DX11.1 runtime összes olyan funkcióját megkapta, ami nem igényel WDDM 1.2 felületet.
    A keménymag szerintem már az év közepén átvált. A gamerek többletsebességet nem hagynak majd a játékokban. Én arra számítok, hogy nem csak a DICE dolgozik a frissített ID3D11DeviceContext::Map kihasználásán. Nagyon egyszerűen beépíthető, és minden legalább DX11-es hardveren azonnali előnyt biztosító megoldás.

    Speciel a ID3D11DeviceContext::Map fícsőr nem igényel GCN-es hardvert. Egy csomó DX11.1-es funkciónak erre nincs szüksége. Szóval ez ingyen sebesség, amit bármikor ki lehet használni. Csak az a kérdés merül fel, hogy miért ne?
    Azt elhiszem, hogy féltek egy irregurális mélységpuffertől, mert az DX11.1-ben a geometry shader lépcsőn implementálható UAV-kkel, így ezt tényleg csak a GCN tudná megcsinálni, de annak az esélye, hogy ezt játékba rakják minimális. Illetve ha van is terv az irregurális mélységpuffer implementálására, akkor biztos kap a motor egy alternatív megoldást, mert megoldható ez a CPU segítségével is más úton, szóval semmiképp sem lesz ebből képminőségre vonatkozó hátrány, maximum sokkal lassabban fog futni nem DX11.1-es hardveren.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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