Hirdetés

  2. Fórumok
  3. Videokártyák
  4. AMD vs. INTEL vs. NVIDIA

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

  • #5483 Abu85 HÁZIGAZDA #85552128 #5479
    Új Válasz #5483
    Ú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

    Abu85

    HÁZIGAZDA

    válasz #85552128 #5479 üzenetére

    A DX12 sem lesz csoda. Oké eltűnik az overhead, így a látótávolság, illetve a szimuláció részét nem képző objektumok száma növelhető. Nyilván ez a W3-ra is igaz lesz, hiszen ez a játék is küzd attól, hogy 10x-es a rajzolási parancsok többletterhelése DX11-ben, mint low-level API-val. Nyilvánvaló, hogy főleg ez fogja korlátozni a látótávolságra vonatkozó beállításokat, illetve a növények mennyiségét. Ezzel ma nem tudnak mit csinálni.
    A zárt effekt egy másik lapra tartozik. Az nem egy API-val kapcsolatos probléma. Az egy döntés, ami vagy bejön vagy nem. Ha úgy veszed akkor a végeredményben lehet úgy gondolni rá, hogy nem vesztesz vele semmit. Ha nem működik, akkor nem lesz benne a végleges játékban. A GameWorks esetében főleg az NV pénze áll benne, vagyis nem az adott fejlesztő büdzséje került elégetésre. Nyilván valamennyit az adott stúdió is belerak, de közel sem annyit, mint amennyibe kerülne egy saját rendszer kidolgozása. Mondjuk utóbbinak az előnye, hogy nagy eséllyel működne, de ha valami gondja van, akkor minimum javítható.

    (#5482) Szaby59: A rajzolási teljesítmény a konzolon nem gond. PS4-en egy rajzolási parancs beírása a parancspufferbe mindössze három órajel a GNM API-val. Ugyanez DX11-en nagyjából kétmillió órajel. A DX12-ben ezt csökkentik 10-20 órajel közé. Világosan látszik, hogy miért nem rajzolhatsz akármekkora távolságra. Majd az új API-k ezen javítanak. Ez az egyik dolog, ami tényleg nem a fejlesztők hibája.
    GameWorks nincs konzolra. Fel sem merül, hogy ott olyan kódot használjanak, amelyet nem tudnak optimalizálni. Ergo semmiben nem határozza meg a két konzol azt, hogy melyik GameWorks effekt kerül beépítésre a PC-s portba és melyik nem.

    (#5481) TTomax: Nem az a probléma, hogy nincs erőforrás ténylegesen megírni egy komplett rendszert, ami működő. Ezt konzolra minden fejlesztő megteszi lassan pár éve állandó jelleggel.
    A PC problémája igazából az, hogy sok az olyan komponens, amelyet semmilyen formában nem tudsz befolyásolni. Például az API és a driver modell, amit érdemes egybevenni. Van egy programod, amelyet ezen futtatsz, és tulajdonképpen a driver csinál valami csodát, hogy jó legyen a hardveren. Na de ha nem jó, akkor mit tudsz tenni? Igazából nem sokat. Semmilyen lehetősége nincs a fejlesztőnek megkeresni a hibát, amely a gondokat okozza, mert nem tudja profilozni a meghajtót. Tehát van egy kód, amelyben elvileg nincs gond. A driver valamit elront, és igazából a programozónak fingja nincs róla, hogy mit. Ekkor jönnek a megbeszélések, hogy hol a hiba. A gyártó és a fejlesztő összeül elemezni, és arra jutnak, hogy ez bizony az API hibája. A fejlesztő elmegy az API biztosítójához, ahol kiderül, hogy márpedig a gyártó a bűnös, azok a szemetek még hazudnak is. A gyártó és az API biztosítója esetleg még összeül, és megegyeznek abban, hogy itt csak a fejlesztő lehet a hibás, néznek egymásra, hogy mégis mi a fasz baj van ezekkel az emberekkel... Na ez az iparág legnagyobb hibája. És akkor kezdődik a foltozgatás, hogy legalább egy picit működjön a program, de valójában senki sem tudja igazán, hogy hol a hiba. Ha a gyártó és a fejlesztő nincs szoros kapcsolatban egymással, akkor talán rá sem jönnek, mert a gyártó a program profilozásánál látja, hogy mi történik a driverben, és még annak a forráskódjával is tisztában van, de a program forráskódják már nem látják. A fejlesztő pont a program forráskódjával van tisztában, de a driverét már nem látják. Aztán az ilyen helyzetek jellemzően megoldódnak úgy, hogy a gyártó visszaad a fejlesztőnek egy forráskódot, hogy ezt írják be és elvileg jó lesz. Aztán később azon megint módosítanak, és kezdődik a buli újra. És a gond ott van, hogy egy hibajavítás hónapokig is tarthat, ami miatt előjön a kérdés, hogy megéri-e bizonyos effektek fejlesztésébe invesztálni, ha ekkora az esélye annak, hogy végül úgy sem fog működni.
    MultiGPU dettó. Meg van határozva, hogy mire kell ügyelni, hogy működjön a kényszerített AFR. Megírnak erre egy elvileg jó motort és nem működik. Mindenki csak néz előre, hogy na mi lehet a baj, és megint pitiáner dolgokra mennek el olyan erőforrások, amelyeknek meg lenne a helye. Hogy kevesebb az AFR-t támogató játék manapság? Csodálkoztok? Ki garantálja, hogy működni fog az AFR optimalizálás? Senki. Ilyen szituációban mégis miért lehetne cél az, hogy ebbe invesztáljon egy fejlesztő.
    Ezek azok a dolgok, amik miatt a fejlesztők ennyire akarják a feketedobozok eldobását. Hogy lehetnek-e hibák low-level API-val? Hogyne, de nagy különbség lesz, hogy ezeket leprofilozzák, és kijavítják, anélkül, hogy hetekig megbeszéléseket folytatnának a gyártókkal, a szabványalkotókkal, és még az isten tudja kivel. MultiGPU dettó ugyanez. Lehet gond vele low-level API-val? Naná, de ki lehet javítani.

    Az a poén, hogy ha egy fejlesztőt megkérdezel, hogy mit tart a low-level API-k előnyének, akkor sokan nem a kisebb overheaddel jönnek elő, vagy a hasonló dolgokkal, amelyeket az érintettek esetleg hype-olnak, hanem azzal, hogy kiszámítható lesz a működés. Látják, hogy a program hogyan fut a hardveren, és nincsenek elrejtett szálak, amelyeket nem lehet leprofilozni, vagy olyan forráskód, amelyet nem látnak. Minden hibára célirányos megoldást lehet találni, és nem kell új ösvényeket vágni, amelyek vagy működnek vagy nem. És erre már van erőforrás, mert kiszámíthatóvá vált a rendszer. Tudod a buktatókat, és nem egy előre nem várt tényező fogja megakadályozni, hogy végül az effekt ott legyen a játékban.

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