Keresés

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

  • Abu85

    HÁZIGAZDA

    válasz Laja333 #16 üzenetére

    Inkább APU lesz. Eleve egyre erősebb a pletyka arról, hogy lesz egy új grafikus API-juk. Ez tízszeresére növelné a batch teljesítményt, viszont ezt szoftveresen nem lehet megtenni, így létre kell hozni magának a grafikus API-nak az IGP-vel történő gyorsítását.
    Az AMD teljesen elrugaszkodott a normál piaci irányoktól. Arra mennek a fejlesztésekkel, amelyekre a fejlesztők mondják nekik, hogy menjenek, és ezért cserébe exkluzív funkciókat és kiemelt támogatást ígérnek számukra. Most is erről van szó. Az aktuális Kaveri APU-k teljesítményének a 80%-a kihasználhatatlan. A következő lépés, hogy tegyék kihasználhatóvá.

    [ 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 #85552128 #13 üzenetére

    A normál CPU teljesen szembemegy azokkal a nézetekkel, amelyeket az AMD vall. Ezért nincs új CPU-juk, mert nehéz két külön irányt fenntartani. Van az FX-8350, az egy két éves fejlesztés, míg az A10-7850K csak egy éves. Utóbbi IGP-jét számos dologra be lehet fogni az új BIOS-szal, és ha megveri az FX-8350-et, akkor nem gond. Lehet azt mondani, hogy persze, hogy megveri, mert újabb fejlesztés. De ha kiadnak egy FX-9999-et 8 Steamroller maggal, és azt megveri, akkor az gond, mert becsapva érezné magát a vásárló, hogy megvette az újat, a drágábbat, de mégis APU-n fut jobban a program. Az egyik irányt kell választani, és az APU-ban több teljesítmény rejlik, ezért az AMD ezt választotta.

    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 #20 üzenetére

    Elmondom amit hallottam. Van ugye a Mantle, ami véglegesítésre kerül hamarosan, és ennek a fejlesztése lezárul. Ez az API, vagy verzió, nevezzük most 1.0-nak nem fejlődik majd tovább, és megnyitják a specifikációt. Lesz viszont egy új grafikus API. Ez elképzelhető, hogy a Mantle nevet kapja valami számmal, de nem lesz kompatibilis azzal a Mantle-lel, amit most ismersz. Ez nagyjából a DX9->DX10 váltáshoz hasonlít majd.
    Ez valószínű is, mert a fejlesztőpartnerek megkérték az AMD-t, hogy ne törődjön a kompatibilitással, mert az okozta a DX-nél a bajt. Ha előnyösebb a kompatibilitás megszüntetése, akkor legyen úgy, csak mindig reagáljon az API az aktuális problémákra.
    Nem valószínű, hogy az APU-kra lesz korlátozva, de szerepet kap benne a HSA. Valószínűleg az APU+dGPU-ra lesz tervezve.

    [ 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 nubreed #21 üzenetére

    Most azt látjuk, hogy amerre elindultak hosszú évek óta azt kihasználhatóvá teszik a gyakorlatban. Ez a frissítés most pont erről szól. Eddig ezt nem lehetett kihasználni.

    (#24) hb1:
    1. igen
    2. igen
    3. Azokra is lesz gondolom. Szerintem a Carrizo már eleve úgy érkezik, hogy elérhetők a képességek.

    Szerverben is elérhető lesz. Ott már most is az az Aparapival.

    (#41) Televan: Igen ez a pletyi most. Nem biztos, hogy kell új termék. Valószínűleg a base funkciók elérhetők lesznek az aktuális termékekkel is, egy új driverrel.

    (#42) Jack@l: Szerintem működni fog APU nélkül is csak lassabb lesz.
    Ezek nagyrészt szoftverek, tehát a user ebből sokat nem érez majd. Új drivereket kell telepítenie. A fejlesztőknek kell új leképzőket írniuk.

    [ 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 Bici #47 üzenetére

    Most zárják le a HSA 1.0 specifikációját.
    A multimédiás progikban viszonylag nagy lesz a támogatás. Ez a piac mindig rástartolt az új dolgokra.
    A játékokban szerintem inkább a multi-GPU kap majd szerepet. Az IGP+dGPU a legegyszerűbb módja az IGP hasznosításának.
    Gaming szempontból az kétségtelenül egy nagy előny az AMD-nek, hogy az EA eldöntötte, hogy az R&D-t az AMD és a Sony low-level API-jaira végzik. Ha még egy nagy kiadó így dönt, mondjuk a Square Enix, akkor az nagy győzelem az AMD-nek, mert hiába lesz DX12, ha nem arra dolgoznak elsődlegesen. Ezt majd az MS-nek is fontos számításba vennie, bár valószínűleg kalkuláltak azzal, hogy bizalmatlanság miatt páran akkor is az AMD API-ját helyezik előtérbe, ha lesz igazi szabvá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 nubreed #56 üzenetére

    Ott a DX12 lehet az opció, de a jelenlegi specifikációkból eleve hiányzik a multi-GPU támogatás, tehát még a hagyományos CF/SLI sem működik az aktuális DX12 béta API-ban. Először mindenképp ezt kellene megoldani, aztán lehet gondolkodni a gyártók mixelésén, ami egyébként elvben megoldható. Viszont szerintem a gyártók mixelése mint lehetőség fel sem merült, de persze örülnék neki, ha megoldnák, csak kicsi az esélye, ha a CF/SLI-re is mostohán néz az MS.

    (#57) Jack@l: A mostani megoldások azért ramatyok, mert nincs explicit hozzáférés a GPU-khoz, így az egész működés emiatt egy hackelt fos lesz. Az explicit hozzáférés viszont ezt teljesen megváltoztatja. A Frostbite fejlesztői dolgoznak egy job-graph rendszeren. Az optimálisan elosztja a terhelé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 Jack@l #59 üzenetére

    Szerintem inkább úgy fog működni, mint a Lucid mGPU-s megoldása.
    Igazából ennek elsődlegesen az a célja, hogy ne csak két GPU-t lehessen úgy használni, hogy az élmény optimális legyen. Egy ilyen job graph megoldással akár 6-7 GPU-t is ki lehet használni anélkül, hogy el kellene viselni az AFR hátrányait. Ezzel ugye elérhetővé válna egy teljesen új teljesítményszint a játékfejlesztők felé, hiszen egy combos PC már nem csak ~10 TFLOPS-ot tudna, hanem 35-40-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 do3om #61 üzenetére

    Érdemes abba belegondolni, hogy ha az AMD saját API-ja nem felelt volna meg az elvárásoknak, akkor nem dolgozna rá közel 100 fejlesztő, nem jelent volna meg rá eddig 6 játék, nem jelentették volna be, hogy beépült vagy hamarosan beépül 7 motorba. Ennek a támogatásnak még a DX12 sincs a közelében sem. Az az API jelenleg hivatalosan, persze zárt formában elérhető 1 motorban és kész. Jelen pillanatban egyértelműen az AMD saját API-jának van nagyobb támogatása a fejlesztőknél. És valószínűleg ez nem változik meg idén, mert a DX12-höz a Windows 10 terjedése is kell, tehát az első pár hónapban kisebb lesz az a felhasználóbázis, amit az MS API-jával el lehet érni.

    [ 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 nubreed #63 üzenetére

    Én sem tartom annyira tömegpiacot célzó elképzelésnek, de kivitelezhető. Ez a job graph rendszernek egy járulékos előnye lenne, aki megengedheti magának az nyomulhat 6-7 GPU-val, akár ötször 4K-s kijelzőn, mert ilyenen is lehet gémelni, csak ma még nem érdemes.

    (#66) nubreed: Azért nem hiszem. A Windows 10 terjedni fog. Még ha a legrosszabbat is feltételezzük, akkor is nagyjából egy évvel a megjelenése után már több gépen lesz elérhető az MS API-ja, mint az AMD megoldása.

    [ 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 do3om #74 üzenetére

    Úgy értettem ~100 stúdió szinten működő fejlesztő. Ebből 20% professzionális szoftvereket, míg 80% játékokat fejlesztő cég. Ezek hivatalos adatok.
    Az alábbi fejlesztők valamilyen formában elismerték, hogy használják az AMD API-ját: DICE, PopCap Games, Firaxis Games, Rebellion, Cloud Imperium Games, Eidos Montreal, Nixxes Software, BioWare, Visceral Games, Mohawk Games, Oxide Games, Stardock, Crytek, Creative Assembly, Ghost Games, Criterion Games, Crystal Dynamics, Gamebase, Capcom

    [ 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 #06658560 #94 üzenetére

    Ezzel csökkentik a saját munkájukat, mert sokkal egyszerűbb egy ismert működésű platformra optimalizálni, mint egy feketedobozra. Ezért mondogatják sokan, hogy a mostani API-k rosszak, mert se nem egyszerűek, se nem gyorsak.
    Azt majd a fejlesztők eldöntik, hogy kinek éri meg. Mindenki képes a saját szempontjai szerint mérlegelni a helyzetet. Jobban mint mi, mert tudják, hogy mit akarnak pár éven belül. Egyébként valószínűnek tartom, hogy a PC-re valóban koncentráló, igen tehetős fejlesztők fognak specifikus API-kat használni. Nekik megéri mindig a csúcstechnikába invesztálni, mert van elég pénzük rá. Ha kiadót kellene mondani, akkor az EA és a Square Enix ilyen cég.

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

  • Abu85

    HÁZIGAZDA

    válasz kleinguru #96 üzenetére

    Az Adobe már többször mondta, hogy az OpenCL nekik jó alap. Azt ráadásul ki lehet egészíteni a HSA kiterjesztésekkel. Nekik ez ideális irányzat, mert mindenkit elérnek és nyílt szabványokra építenek. Ők már most eléggé használják az OpenCL-t, és jön az OpenCL 2.0-s támogatásuk is, ráadásul a problémájukat is megoldja a SPIR. Szerintem ők most pont megtaláltak azt, amire vágytak, és nincs szükségük egy újabb váltásra, ráadásul az OpenCL-ről nincs is igazán hova.

    Nem látom az Adobe fejlesztéseiben, hogy csakis az APU-kra fókuszálnának. Lesz pár specifikus dolog, ami gyorsabb lesz Fine Grain Buffert támogató APU-n, de a legtöbb funkcióhoz sima dedikált GPU is jó.

    [ 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 Duck663 #139 üzenetére

    Az AMD sok fejlesztőnek megmondta, hogy a DX12 az általános alternatíva. Ha azzal nincs specifikus, API-n belül megoldhatatlan probléma, akkor ne használják a Mantle-t, mert az időpazarlás. A Mantle azoknak szól, akiknek a DX12 által felkínált funkcionalitás kevés, azaz valamit nem lehet megoldani a Microsoft API-ján belül. Nekik van indokuk arra, hogy használják a Mantle-t.
    Ugyanez a Mantle fejlesztése kapcsán. Az API extrém igényeket szolgál ki, és nem fognak törődni azzal, hogy az egyes verziók kompatibilisek legyenek, ha a kompatibilitás megtörése előny. Akinek ez nem tetszik ismét használja a DX12-t. Az AMD-nek nem érdeke pont ugyanazt a réteget kiszolgálni, amelyiket az MS kiszolgál. Ez értelmetlen is. Ők azt a réteget szolgálják ki, akiknek a DirectX 12 nem elég jó.

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

  • Abu85

    HÁZIGAZDA

    válasz #06658560 #145 üzenetére

    Van pár cég, amely nem akar a lassú fejlődés miatt féket felszerelni. Ők kérték ezt, csak azért van, mert használni akarják. Ha azt mondják, hogy nincs több problémájuk, az AMD sem fejleszt nekik több API-t. Ez csak addig működik, amíg van rá igény. És egyébként világos cél ez, amíg az EA azt mondja, hogy elsődlegesen az AMD API-jára fejlesztenek, addig megéri, már csak azért is, mert az EA az egyik legnagyobb kiadó. Ha azt mondják, hogy elég volt, akkor az AMD-nek is elég, nekik mindegy, hogy milyen API-t használnak, mert nem ebből származik az előnyük a low-level irányban, hanem abból, hogy mostantól nem ők, hanem a fejlesztők írják a hardver vezérlését az adott programon belül.

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

  • Abu85

    HÁZIGAZDA

    válasz #06658560 #147 üzenetére

    Aki akarja megteheti. Az EA például akarja. Ha van pénzük rá, és Johan Andersson úgy gondolja, hogy ez tényleg megéri az EA-nek a technológiai előnyük növelésére, mert ugye erről az EA-nél ő dönt, akkor mi a probléma ezzel? Ő úgy gondolja, hogy a teljes cég PC-s jövőjére nézve előnyös, ha a DX12 mellett támogatnak egy modernebb API-t is. Ha más egyébként másképp gondolja, akkor az sem baj. Ezért mondta az AMD is, hogy mindenki gondolja át mit szeretne, és ne végezzenek felesleges munkát, ha nem muszáj. Azért ezek az emberek több éve az iparban vannak, van elég tapasztalatuk arról, hogy mire érdemes fejleszteni.

    [ 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 flashpointer #149 üzenetére

    Erre vonatkozóan nincs kötelezettség. Ahhoz, hogy szerezz SDK-t az AMD API-jához egy mail kell a cégnek. Ez a e-mail cím elérhető az AMD developer oldalán. Oda meg kell írni, hogy ki vagy, mit csinálsz, kell egy direkt kontakt, lehetőleg a vezető fejlesztő és azok a játékok, vagy tervek, amelyek az új API-t érintik. Sokan azt írták be, hogy fel akarják készíteni a motorjukat a DX12-re, és erre is megkapták a hozzáférést, mert ez is egy ésszerű indok.
    Az AMD-nek teljesen mindegy, hogy melyik low-level API-t használod. Akkor ajánlják a saját API-jukat, ha annak valami előnye van az adott fejlesztésre nézve. Ellenkező esetben nem ajánlják ők sem. Ezt mindenkinek egyénileg kell eldönteni.

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

  • Abu85

    HÁZIGAZDA

    válasz Duck663 #151 üzenetére

    Akkor, ha olyan programmal játszol, amely támogatja az alacsony szintű hardverelérést, történjen az akármilyen API-val. Jelenleg hat ilyen játék van, de idén lesz még sokkal több. DX12-es is, de ez még titok. Szerencsre én nem írtam alá semmilyen NDA-t, így elárulom, hogy az a stúdió csinál egy PC-s DX12-t is!!! támogató játékot, amelyik kiadta a StarSwarm tesztprogramot, és ugyanazzal a Nitrous motorral fut a program, amely egyébként stratégia lesz. Ha érdekel mi várható, akkor a Steamről letöltheted a tesztprogramot. Itt még összehasonlíthatod a DX11 móddal. A végleges játékban a DX11 támogatása már nem lesz benne. Túl költséges és úgy is akadna.

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

  • Abu85

    HÁZIGAZDA

    válasz Duck663 #151 üzenetére

    AMD-nek mi változik attól, hogy egy program támogatja a saját API-jukat és az MS API-ját is? Elárulom, hogy az érkező 3DMarkban hibahatáron belüli az eltérés a két low-level API teljesítménye között a Farandole tesztben. Sokszor elég a DX12. Az AMD-nek attól nem lesz jobb, hogy a saját API-jukat is támogatná egy program, csak a partnerük szopna vele feleslegesen.
    A low-level irány nem a saját API miatt kell nekik, hanem azért, mert ha a fejlesztő optimalizálni akar, akkor letöltheti a GCN disassemblert, felütheti a több száz oldalas dokumentációkat, és ezekből pontosan lehet tudni, hogy milyen kódot kell írni a GCN-re. Más architektúránál ezt nem lehet megtenni, mert vagy a disassembler vagy a dokumentáció, vagy mindkettő hiányzik. Ennyire mindegy az API kérdése.

    [ 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 Duck663 #154 üzenetére

    Egyik sem érhető el publikusan, de mindegy.
    Miben jelent bármi kárt az AMD számára egy SDK kiadása a partnereinek? Idővel úgyis publikus lesz, magát a specifikációt is megnyitják.

    A konkurencia amúgy is visszafejtené az architektúrát, ahogy az AMD is visszafejti ezeket. Másképp aligha tudtak volna gyorsítani a TressFX-en a kepleres kártyákon.

    A kötelezettségeket a fejlesztők gyűlölik. Ez a legfőbb oka annak, hogy ma az AMD és nem az NVIDIA partnere az EA, a Square Enix, a SEGA, a Nordic Games, az 505 Games, a 2K Games, a Capcom és a Deep Silver. Az NV-nek olyan partnere maradt a PC-re, aki le se tojja ezt a platformot, aka Ubisoft. Szerinted ennek örülnek? Kényszerűen olyan játékokat adnak a termékeik mellé, amelyek nincsenek PC-re optimalizálva.

    [ 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 Duck663 #156 üzenetére

    De milyen visszaélésről van szó? Azért készült az SDK, hogy segítsék a fejlesztők munkáját. Azért használják a fejlesztők mert segíti a munkájukat. Kész.

    Optimalizálás majd a megjelenés után derül ki, de ...:
    muntlis: Battlefield Hardline, Mass Effect 4, Mirror's Edge 2, Star Citizen, Star Wars: Battlefront
    shitworksös: Batman: Arkham Knight, The Witcher 3: Wild Hunt
    Ezek biztosak. A többi majd eldől.

    Nem értem, hogyan jön ide a köpködé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 Duck663 #161 üzenetére

    Ok értem már. Bocs, de nem volt világos mit akarsz mondani. Amit viszont írsz az kizárt, hogy megtörténik. Mégpedig azért, mert az aki használni akarja az AMD API-ját azért teszi, mert nem akar blackboxot. Mivel a Gameworks maga egy blackbox, így hozzá sem fognak érni a teljes kontrollra vágyó fejlesztők.

    Abban a játékban nem láttam Gameworksöt. Mit 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 martonx #179 üzenetére

    Azért ez nagyban függ attól, hogy melyik játék. A Civ6-on az Athlon 5350 nagyon sokat gyorsul. Sokkal kevesebb időből fejezi be a gép a körét, mint DX11-ben, ha már előrehaladott állapotban van a játéktér meghódítása. Eléggé nem mindegy, hogy csak 1 percet vársz a gép lépésére, vagy 3-5-öt. Sajnos a DX11 alatt a gépi AI nincs többszálúsítva.

    Nem véletlen, hogy az új Starship játéknak lesz iOS verziója, de nem lesz Android opció. Egyszerűen a Metállal is többszálúsítható az AI, így az iPaden is értékelhető időn belül léphet a gép. ;]

    [ 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 martonx #182 üzenetére

    A benchmark az fps-t méri, és nem a late game során a körök közötti lépéshez szükséges időt. Az nem teljesen a játékmenet része, de nyilván nem mindegy, hogy mennyi idő alatt lép a gép. Próbáld ki nyugodtan. Minden gépen lesz némi előny, mert csak a DX11 módban van egy szálra kényszerítve a számítá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 martonx #195 üzenetére

    [link] - ez egy márciusban bejelentésre kerülő játékhoz készült motor tesztjelenete. Egészen egyértelműen látszik, hogy a DX11 nem bírja a CGI filmekből lopott technikákat. Sokkal több van ebben, mint 300%. De fontos egyébként, hogy a Nitrous motor már nem úgy működik, mint egy átlag mai valós idejű játékhoz használt motor, inkább a Pixar animációs rendszerének nem valós időben alkalmazott technológiáit követi, csak éppen valós időbe ültetve. Abszolút lehetséges a mai hardverekkel, az API ami ezt megakadályozta. Persze majd a végleges Nitrous játékokban már nem lesz DX11 port, nem éri meg optimalizálni rá, mert nem menne senkinél sem 10 fps fö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 martonx #212 üzenetére

    Még a kiadás előtti StarSwarmból van hivatalos mérés, vagyis azóta már gyorsult, de itt van:

    [ 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 Bici #215 üzenetére

    Arra egy másik API lesz. Az 1.0-s verziót lezárják és megnyitják, hogy az ipar képes legyen félelem nélkül adaptálni. Az ilyen extrém specifikus fejlesztések valóban zártak lesznek és később kerülnek bemutatásra.

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

  • Abu85

    HÁZIGAZDA

    válasz stratova #217 üzenetére

    Azért a fejlesztéseknek van átfutási ideje. De ezért mondta az Oxide, hogy kidobja a Nitrous testjelenetét, hogy lássa a világ mire képes az új modell. Mert erre fognak menni. Maga a StarSwarm egyébként egy játék, csak még nem jelentették be, de tulajdonképpen azt mutatja, hogy hogyan fog futni amint megjelenik, bár a DX11 módot végül kiveszik belőle, mert úgy sem lehet azzal játszani.
    Az egyébként nem szélsőség, amit a Nitrous motor bevezet. Átvenni a CGI megoldásokat a problémákra egy evolúciós lépcső mindig is, most ez azért tűnik hirtelennek, mert nem a hardver korlátozta ezeknek a technikáknak az alkalmazását, hanem az API. A hardverben már rég megvan hozzájuk az erő.

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

  • Abu85

    HÁZIGAZDA

    válasz martonx #219 üzenetére

    Mivel nincs mellé írva a VGA, így kitalálható, hogy milyen hardveren futott. Egyébként a mód sincs mellé írva, de RTS volt. Ez azt próbálja szemléltetni, hogy erre a low-level dologra miért van szükség. A legtöbb új generációs motor olyan lesz, mint a Nitrous. A CGI technikákat fogja átültetni valós időbe. Azok pedig draw call igényesek. A gyorsulás abból következik, hogy a DX11 alatt ezek a feldolgozási formák még a nagyon hatékony Nitrous motornál is csak a processzoridő 10%-át teszik ki, vagyis a hardverben található teljesítmény alig 15%-a lesz kihasználva. Innen gyorsulni egyszerű. Egyébként a Nitrous low-level kódja sem ment 50%-os kihasználás fölé, de nyilván azért, mert még pre-alpha kód volt és nem azért, mert nem mehet.

    [ 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 cskamacska #221 üzenetére

    Játékra gondolsz? A Stardock mondta, hogy a GDC idején bemutatják az első Nitrous motoros játékukat. A megjelenés az év végére fog esni. A komolyabb Nitrous motoros játékoknak meg kell várniuk a DX12-t, mert DX11 alatt nem fog működni. Akármilyen hardvert teszel alá nem lesz meg sebesség. Csak 5-6 fpst fogsz kapni a nagy csatákkor. Eleve a Nitrous rengeteg direkcionális fényforrást használ, és arra árnyékot is számol. A mai játékok nem mennek 2-3 direkcionális fényforrás fölé. Maga a fényszámítás nem annyira gond, de a kaszkád árnyékok számítása az. A Nitrous érdekessége, hogy simán lekezeli a mai jelenetkomplexitás ötvenszeresét, de ehhez több tízezer batch kell, amit a régi API-k nem bírnak el.

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

  • Abu85

    HÁZIGAZDA

    válasz stratova #222 üzenetére

    A lábjegyzet össze volt kavarva, nem ez az egyetlen hiba abban a doksiban. Ez egy A8-7600 volt. A 290X egy ilyen APU-val 70-80 fps fölé megy. Nyilván procilimites. Persze nagy hangsúllyal írom, hogy pre-alpha kód. :)

    (#223) Szaby59: Nem a DX11 kóddal van a baj. Egyetlen olyan másik motor nincs a világon, ami 30 fps-sel feldolgoz 15 ezer batcht. Olyan hiperoptimalizált a Nitrous DX11 módja, hogy példát vehetne róla a világ. De csodát nem lehet tenni egy olyan API-ban, amit nem terveztek 2 ezer batch fölé. Bár önmagában az is csoda, hogy ez a motor az API képességein nyolcszorosan túltesz.

    [ Szerkesztve ]

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

  • Abu85

    HÁZIGAZDA

    Ha nem tudjátok, hogy mitől gyorsult ennyit a Sniper Elite 3, akkor olvassátok el a vezető programozó leírását erre vonatkozóan. [link]

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

  • Abu85

    HÁZIGAZDA

    A Steamen elérhető StarSwarm tesztet már nem feltétlenül érdemes nézni, mert nem lett belefrissítve a Nitrous új verziója. Persze ez érthető, az Oxide-nak a legkisebb gondja is nagyobb annál, hogy egy tesztprogramot tartsanak frissen. Megmutatták, amit megakartak és kész. Viszont az AMD-nek maga a Nitrous Engine test van meg, tehát ők ugyanezt a demót képesek a legfrissebb motorral is bemutatni. Ami elérhető a Steamen az csak DX11-re tartalmaz optimalizálást, míg a Mantle-re nem. Amit a Computexen bemutattak az már Mantle-re is optimalizált.
    Ennél egyébként sokkal gyorsabb az új Nitrous amiben már aszinkron compute is van. Majd a GDC-n bemutatnak pár új dolgot vele. Egyelőre ebből csak keveset láttam, de azok alapján áll leejtős lesz.
    Azt tudni kell a Nitrousról, hogy nem normál módon felépített motor, hanem olyan technikákat alkalmaz valós időben, amelyekkel a Pixar animációs filmek készülnek. Maga a futószalagja is módosított REYES leképző.
    A Nitrous egyébként 2016-ban jelentősen fejlődik, mivel kevés lesz hozzá a frame-enkénti 100000 batch. Az Oxide-nak most az a legnagyobb baja, hogy máris beleütköztek a Mantle korlátjaiba is. Az idei év végére egy olyan API-t kérnek, ami képes 300000 batch/frame-re, vagyis háromszor jobb a Mantle-nél. Egyébként az, hogy az aktuális low-level API-k határait feszegetik már most jelzi, hogy mennyire durva lehetőségek nyíltak meg, amelyekre persze újabb szoftveres megoldásokat kell fejleszteni. Ez van, most nagyon megindul az ipar.

    [ 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 stratova #281 üzenetére

    Négy játék készül ezzel a motorral. Kettőt a GDC-n jelentenek be, míg kettő már be van jelentve.
    Igazából a Nitroust a Stardocknak fejlesztették, bár a jogtulajdonos kétségtelenül az Oxide. De egyébként nem zárkóznak el a licenceléstől, aki akarja viheti, viszont a fő modell a Stardock jövőjének biztosítása.
    A Nitrous gondja a draw call. Kevés lesz hamarosan a 100000 batch. Sokkal inkább vizsgálják azt a lehetőséget, hogy az IGP-k gyorsítsák magát a grafikus API-t. Ne a processzormagok adják ki a GPU parancsokat, hanem az IGP-k a procimagok mellett. Ez az AI-nak is jót fog tenni, mert felszabadul a processzoridő.

    [ 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 huskydog17 #285 üzenetére

    Az egyik az Offworld Trading Company, míg a másik a Star Control. A mikor-holra nem emlékszem.

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

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #287 üzenetére

    Az Offworld Trading Company Early Access! Írják is csillagozva, hogy a végső gépigény eltérhet.

    [ 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