Keresés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz Loha #16 üzenetére

    Azt hiába tolják. Az API-nak rengeteg funkciója nincs kész. Az MS 2014 végére ígéri az alpha környezetet. A teszteket is ekkor lehet elkezdeni. Ugyanazt elvégzik, amit az AMD elvégzett a Mantle-lel, csak nem 2012 végén.

    Mindenképp ismerni kell az architektúrát. Top játékban az API ismerete nem elég, mert bizonyos eljárások implementációja lehet lassú. Ha nincs dokumentáció, akkor a szabvány kódnál nem tudja majd a fejlesztő, hogy miért lassú egy effekt. Következésképpen az effektet nem fogja szállítani a végső kódban. Ezért mondta az Ubisoft programozója is, hogy az NV elzárt dokumentációi nekik is károsak.

    [ Szerkesztve ]

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

  • pakriksz

    őstag

    válasz Loha #21 üzenetére

    Uhh nagyon nem értesz hozzá, de még egy játék fájljait sem igazán vizsgáltad meg, akkor nem írnál ekkora marhaságokat.

    Bár igaz, nem kell ismerni a hardvert, úgy is lehet programozni, feltéve ha nem zavar a szaggatás meg a hibák :)

    [ Szerkesztve ]

    Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"

  • Abu85

    HÁZIGAZDA

    válasz Loha #21 üzenetére

    Teljesen fals eredményeket kapsz egy pre-alpha API-val. Nem azért kéri az Intel a Mantle-t, mert támogatnák, hanem azért, mert tesztelni akarják a low-level limiteket, egy olyan API-n, ami már ténylegesen működik. Az AMD meg ezt nem akarja.

    A Tomb Radiert is annyira megoldották megjelenésre, hogy egy csomó patch kellett még a játék kiadása után. Nagyon gáz a fejlesztőknek, hogy írnak egy kódot, ami nem működik, elküldik elemzésre, és eltelik egy hónap ... eltelik két hónap. Hopp ki kell adni a játékot, és még zéró reakció a driver részlegtől. És persze a fejlesztők voltak a hibásak, mert ugyanakkor küldték mindenkinek a kódot.
    A fejlesztőknek meg kell oldaniuk a gondjaikat segítség nélkül. Ehhez dokumentáció kell.

    Igen az. A programozó véleménye nem feltétlen tükrözi a kiadóét.

    [ Szerkesztve ]

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

  • pakriksz

    őstag

    válasz Loha #42 üzenetére

    valószínűbb hogy az intel inkább le akarta másolni a mantle-t és kiadni saját név alatt(ahogy már tette), de úgy hogy azért inkompatibilis legyen a mantle-val. Hülyék lennének odaadni nekik :)
    Egyébként verheted magad, de a microsoft ígérte 2016 környékére a dx12-t, nem az amd ;)

    [ Szerkesztve ]

    Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"

  • Abu85

    HÁZIGAZDA

    válasz Loha #42 üzenetére

    A működik és a jól működik között óriási a szakadék.

    Az Intel tesztelni akar. Már ma is sokat tesztelnek, csak gépi kódokkal, de az nem ugyanaz, mint API-val tesztelni komplex szituációkat. A Mantle itt jól jött volna nekik. Az AMD odaadja, de csak akkor, ha már a DX12 is tesztelhető jól működő állapotban lesz.

    Ezért rossz a "majd a gyártó megoldja" modell. Hiába adják ugyanakkor oda mindenkinek a kódot, ha nem ugyanúgy reagálnak rá a driveres dev csapatok. Ez a fejlesztőknek rossz, mert van egy kódjuk, ami az egyik architektúrán lassú. És arra várnak, hogy vagy meg tudják oldani, vagy nem. A kiadási időpontja pedig csak közeleg.

    Már a Crysis 1-ben is volt, de az UC4 szintje más dimenzió, a fő szempont a vízzel való és az egységes interakció.

    [ 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 Loha #48 üzenetére

    Ki van adva a DX12 a kiválasztott partnereknek. A PC-s fejlesztők közül az Oxide Games kapta meg. Még kezdetleges, de idővel jó lesz.

    Ez egyértelmű. Addig nem adják óda konkurensnek, amíg a DX12 nem lesz tesztelhető állapotban.

    Bullshit. Kérdez meg egy fejlesztőt, hogy mennyire nem halad, amikor arra vár, hogy a problémát a driveres csapat megoldja. A sebességgondok ugyanis legtöbbször nem merülnek ki egy hibában. Ha valamit megoldanak, akkor általában rögtön előkerül egy újabb hiba, ami limitálja a teljesítményt.
    A Mantle kód nem azért készül el két-három hónap alatt, mert sokkal egyszerűbb, hanem azért, mert helyben azonnal javíthatók a hibák. A DX kódnál az optimalizálás azért vesz igénybe jellemzően fél évet, mert a teljesítménygondok javítása legalább három cégen keresztül történik.

    [ 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 Loha #67 üzenetére

    Azért készül el gyorsabban, mert low-level a hozzáférés. Ilyenkor a fejlesztő ír a motorba olyan dolgokat, ami a DX11-nél a driverben van. Egyrészt sokkal több adat alapján dolgozik a motor, mint a driver, így jól paraméterezhető a működés, másrészt a motor profilozható, míg a driver egy rejtett réteg. Utóbbi a gond, és ezért kell a gyártók segítsége, mert ők látják, hogy mi történik a driverben. Azonban egy hibát sokkal egyszerűbb leprofilozni és javítani, mint köldözgetni a buildet a gyártókhoz és várni arra, hogy egyszer valami csoda folytán lesz javítás vagy javaslat a javításrá.

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

  • Abu85

    HÁZIGAZDA

    válasz Loha #81 üzenetére

    Nincs külön optimalizálás a GCN SI-re és CI-re. Nem szükséges, mert mindkét architektúra verzió ugyanazt támogatja, és a függvények ugyanúgy működnek rajtuk. Amíg ez nem változik, addig nem kell külön célozni rendszereket.

    A DX11-nél nincs igazán architektúrákra való optimalizálás, csak aktiválnak esetleg különböző pathokat vagy nem. Például a Frostbite 3 motornál a BF4-ben eredetileg csak a GCN-re kapcsolták be az összes optimalizálást, míg a GeForce-ra és az Intel IGP-kre nem. Az Intel azóta sem változott, de az NV fejlesztette a drivereket, és adtak egy javaslatot, hogy mit kellene csinálni, hogy menjen a tiled compute optimalizálás. Ezt egy patch tavasszal be is építette és megy GeForce-on is. Ez jól mutatja annak a modellnek a hátrányát. Ki kell adni játékot, majd fél év után jön hozzá patch. Ugyanígy a Codemasters is helyrehozta a GeForce teljesítményét a Dirt Showdown alatt, csak egy évvel a kiadás után. Ez meggyőződésem, hogy nem jól működő fejlesztési modell. A fejlesztőknek sem valami nagyszerű dolog fél-egy éve kiadott játékokat patch-elni, mert a driver elrejt előlük a hardver működését.

    Az NV-nek a GameWorks bevezetésével az is az egyik koncepciója volt, hogy eleve olyan shadereket adnak oda, amelyek már optimalizáltak. Nekik ma a legnagyobb gondjuk, hogy ma majdnem minden játékban le kell cserélniük a shadereket, hogy optimális legyen a teljesítmény a GeForce-on. Ez idő, pénz és egy rakás programozót igényel. Ez sem egy jól működő modell, bár ez speciális probléma, hiszen az architektúra regiszterszegénysége miatt kényszerülnek erre, de akkor sem jó visszafejteni a kódokat és cserélgetni a shadereket runtime szinten. Az NV amúgy is agyonoptimalizálta a shader fordítót, ami annyira lassú már, hogy be kellett vezetni a shader cache-t. Ennek az a hátránya, hogy ha real-time shader fordítás kell, akkor garantált az akadás. Az Intel és az AMD ezért nem tervez nagyon agresszíven optimalizáló shader fordítót, mert túl lassú lenne. A pálya betöltési idejének növekedését még túléled, de a valós idejű shader fordítás necces.

    [ 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 Loha #83 üzenetére

    Ez nem a játék problémája, hanem a driver memóriavezérléséé. A 14.4-es driverben már kapott külön vezérlést a GCN SI. A GCN CI flat memory módra van beállítva, vagyis arra, hogy ha a program igényli, akkor képes legyen elérni a Mantle a rendszermemóriát és akár írhat is oda teljesen koherens módon. A GCN SI ezt nem támogatja, így ennek kellett egy másik vezérlési forma. Amíg ez nem volt, addig a VRAM és a rendszermemória között voltak felesleges másolgatások. Nem sok, de arra elég volt, hogy kisebb sebességet adjon. Azóta már ezeket eliminálták. De láthatod te is a linken, hogy a 14.3-nál volt ez known issue.

    [ 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