Keresés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz Fiery #3 üzenetére

    Ez nem nagy kunszt manapság. A modern motorokat úgy tervezik, hogy a lehető legjobban elkülönüljenek az API-któl, így azokat bátran lehet cserélni a motor alatt. Akármennyi low-level API megfelelő dokumentációval és némi tapasztalattal gyorsan beépíthető. A tesztelési célra pedig mindegyik ilyen rendszerhez szükséges egy Mantle-szerű validációs réteg, mert ezzel már a tényleges tesztelés előtt kiderül a hibák jó része. Automatizált tesztelés mellett lényegében igen alacsony költség minden extra API, miközben maximalizálod az adott hardver teljesítményét. Persze aki csak az Xbox One kódot másolja PC-re kvázi módosítás nélkül, annak a DX12 a jobb, de ennek meg az a hátránya, hogy GCN specifikus lesz a kód teljesítménye.

    [ 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 leviske #22 üzenetére

    Nem prioritás jelenleg. Igazából főleg az EA-nek van ilyen igénye, mert nem akarnak OpenGL-re portolni, de ők is még csak vizsgálják a Linux jelentőségét. Egyelőre a piac nagy része eredményt akar, és aztán döntik el, hogy a Linux lehet-e igazán jó játékplatform.

    (#25) .tnm: Csak azt írják elő, hogy egy szabvány API-n is meg kell írni a játékot. Az lehet OpenGL is.
    Emögött az van, hogy árulnak olyan hardvereket is még, amelyekhez nem lesz Mantle.

    [ 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 Jack@l #28 üzenetére

    A Mantle-nek semmi köze a DX-hez. Az egy teljesen külön API.

    A DX már rég nem felel a hangokért és az Inputokért. A DirectSound a Vistában került ki a rendszerből és a helyét az XAudio API vette át, míg a DirectInput helyére az XInput érkezett.

    (#30) Jack@l: PS4-en nincs OpenGL. Csak libGNM API. A PS3-on volt OpenGL ES, de amint lett libGCM nem fejlesztették tovább. A multiplatform fejlesztéseknek lesz még opcióban libGNMX.

    Azt felejtsd el, hogy ezek az új API-k egy régebbi kiegészítései. A next-gen low-level API-k (D3D11.X, libGNM, Mantle, Direct3D12) nulláról újraírt rendszerek. A modern OpenGL, amiről manapság lehet hallani, például azért tud működni, mert magán az API-n belül is elvágták a kompatibilitást.

    [ 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 leviske #26 üzenetére

    Attól függ, hogy milyen PC-s játékpiacot akarsz. A Valve nappalisat, míg a Microsoft olyat, amilyen a mostani, mert a nappaliba nekik ott az Xbox.

    Az igazán jó játékplatform az elterjedt játékplatform. És igen a kiadók elvárják, hogy legyen váráslóbázis. Ha nincs, akkor értéktelen a koncepció. Itt nincs bizalom. Előbb kellenek az eredmények, aztán lesznek játékok. Így gondolkodik a legtöbb nagy kiadó. Semmi személyes, csupán üzlet.

    Pár hónap. Nem az idő a lényeg, hanem, hogy megéri-e.

    Ami közös lehet a Linux és a Windows grafikus driverekben az egy ideje ténylegesen közö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 Peat;) #39 üzenetére

    Az AMD nem content provider. Ezek a stúdiók (főleg a partnerek), és az AMD csak arra van, hogy az igényeiket lefedje. Eddig hardveresen csinálták, de igazából ha szoftverre van szükség, akkor szoftvert fejlesztenek nekik.
    Azért vannak stúdiók, amelyeknek egyedi igényeik vannak, mint a kiadók PC-s fejlesztéseit végző Frostbite Team, Nixxes, illetve ott az Oxide, amely a stratégiai játékokra koncentrál. Utóbbi szempontból a Firaxis is érintett, így annak ellenére, hogy még az év végéig NVIDIA partnerek a szerződés szerint belerakják a Mantle-t, mert szükségük van erre az API-ra. A Civilization 5 esetében kiderült, hogy a deferred context nem megoldása a problémáknak.
    A low-level API gyakorlati vetülete, hogy konzolon frame-enként van lehetőséged 40k-50k batchre, míg PC-n leginkább 10k a határ, amit nagyon kevés stúdió ér el. Eleve a Microsoft nem garantálja, hogy a DX stabil 2k/frame fölött, mégis kockáztatnak a stúdiók, mert nem akarnak a PC-s grafikán butítani. A PC jövője akkor stabil, ha az API-k képesek lesznek minimum 40-50k batchre frame-enként.

    Teljesen világos, hogy hatalmas előrelépés küszöbén vagyunk. Sok fejlesztő évek óta nem költ PC-re, mert ugyan jönnek az új funkciók az API-ban, de ezeknek olyan nagy a késleltetésük, hogy hozzá sem tudnak nyúlni. Teljesen felesleges egy elméletben szuper funkcióra játékot fejleszteni, ha már a prototípus kód is lassú. Nézd meg az EA-t. Már a korábbi büdzsé sokszorosát költik PC-re. Egyszerűen csak azért, mert a Mantle és persze az érkező low-level API-k lehetőséget adnak a fejlesztésre. Első körben nyilván az overhead volt a fő gond, és az asszinkron DMA másolások megoldása, de van még egy rakás olyan terület, ahol az új API-k újítanak, és sokkal jobbá vállnak. Ilyen például az asszinkron compute (egymással párhuzamosan futtathatsz feladatokat a GPU-n), a multi-GPU teljes QoS mellett (ebben mindenki mást lát, de igazából el lehet dobni az AFR-t, és sokkal jobb alternatívákat lehet használni helyette), előzetes culling az IGP-ken a CPU beavatkozása nélkül, illetve post-process feladatok kiszórása az IGP-kre (kvázi minden újonnan vásárolt PC-ben lesz/van a VGA mellett egy IGP - ma még letiltva, tök jó erőforrás ez az egyszerűbb, de fontos feladatok számára). És persze megemlíthetők az olyan speciális dolgok, mint a flow control lehetősége a parancspufferben, amivel nem csak rajzolásokat adhatsz át a GPU-nak, hanem olyan puffereket is, amelyek a kiadandó parancsot feltételekkel (if/then/else, vagy éppen ciklusok) állapítja meg. Ez olyan algoritmusok futtatását teszi lehetővé a GPU-n, amelyeket korábban nem lehetett megcsiná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 Jack@l #41 üzenetére

    A draw call az elsődleges probléma. Nem véletlen, hogy low-level API-k egységesen ezekre kínálnak gyors megoldást, és a fejlesztők is elsőként ezt használják ki. Az a baj, hogy már az előző generációs konzoloktól is messze van a DX, hát még az újtól. Persze semmibe lehet venni az MS ajánlásait a DX-re vonatkozóan, de van egy határ, amit nem éri meg átlépni. Túlzott batch/frame, vagy a mutex-alapú zárolások extrém erőltetése, olyanokat csinál, hogy random ledobja a hardvert az appról. Lásd BF4. Ez még ma is előfordul sajnos, mert a Frostbite 3 túlterheli a DX-et, de nem tudnak vele mit tenni a fejlesztők, mert ha kiveszik a mutex-alapú zárolásokat, akkor az -50-80%-ot jelent teljesítményben. Nyilván az új játékot a Mantle birtokában finomabbra tervezhetik, mert ha kell a sebesség, akkor ott a másik API, de ez egy komoly probléma egy PC-s játéknál, mert nem azért veszed, hogy játék közben ledobja a DX az erőforrást. Ez nem engedhető meg, és ez tisztán az API problémája, driverből is mindenki próbál javítani, de esélytelen a tökéletes stabilitás

    [ 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 Jack@l #44 üzenetére

    A háromszög ma már nem probléma. A gond igazából a raszterizálás. A mai API-kban található futószalag négyes pixelblokkokon működik, tehát ahhoz, hogy a hatékonyság 90% fölött legyen legalább 16 pixelesnek kell lennie a háromszögeknek. Tehát a háromszögek rajzilása nem gond, de azok "színezése" már az. Például a Firaxis ezért dobta el a fixfunkciós tesszellátort használatára épített rendszerét, mert túl kicsi háromszögeket kreált. Helyette írtak egy emulált tesszellátort compute shaderben. Lás csodát még jobb részletesség mellett is 20-30%-kal gyorsabb. Pedig több háromszöget rajzol ki, csak figyel arra, hogy a hardver egyszerre négy pixeles blokkokon raszterizáljon.

    [ 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 Jack@l #49 üzenetére

    A jobb részletesség igazából nem egyenlő a több háromszöggel. Pont ez a baj a fixfunkciós tesszellátorral. Van egy bedrótozott algoritmus, amit nem lehet vezérelni. Helyenként sok, míg más helyeken kevés háromszöget eredményez. Az a jó minőség, ha a háromszögek minden egyes területen elegendő mennyiséget ütnek meg. Könnyen kitalálható, hogy a több háromszögnek az a gondja, hogy rossz lesz a raszterizálás hatékonysága, míg ellenkező esetben a felület lesz a kelleténél rosszabb minőségű.
    Azért csináltak speciális tesszellálást a Firaxisnál, mert a végeredményt tekintve egyik sem jó. A köztes állapotot kell belőni, amikor a háromszögek elég kicsik ahhoz, hogy a felület részletessége maximális legyen, de közben elég nagyok ahhoz is, hogy a raszterizálás hatékonysága 90% fölött maradjon.

    Nagyon fontos még az is, hogy a tesszellálás még akkor sincs ingyen, ha az adott rendszer nem tesszellál. A hull shader ugyanis mindenképp lefut, csak ugye tesszellálás nélkül a számításoknak nem lesz eredménye. Például a Crystal Dynamics a Tomb Raider PC-s verziójában ezért nem használ hagyományos tesszellálást, míg a két új konzolon már ezt használják, mivel ott az API-ban ki tudják vágni a hull shadereket, ha nem lesz tesszellálás.

    [ 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