2. Fórumok
  3. Videokártyák
  4. Megkapta a DirectX 12-t a World of Warcraft
Legfrissebb anyagok
PROHARDVER! témák
Mobilarena témák
IT café témák
GAMEPOD.hu témák
Keresés

Hirdetés

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

  • #5 Abu85 HÁZIGAZDA Arnold2 #3
    Új Válasz #5
    Ú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 Arnold2 #3 üzenetére

    Ezért írták előre a Blizzardék, hogy NV-n maradt a DX11 default. A DX12-t alapértelmezetten Intel és AMD GPU-n engedélyezték csak. NV-n opcionálisan lehet átváltani, de nem ajánlják. Látható, hogy miért.

    Állítólag eléggé komplex probléma van az NV-nél a háttérben, így egyhamar nem tudják javítani. Ahhoz, hogy NV-n is gyorsuljon szinte teljesen át kell írni a leképezőnek a parancskezelését, ami ugye azért gáz, mert most írták teljesen újra. Valószínűleg, amikor elkezdik a többszálú optimalizálást ezekre az alapokra építve, akkor a gond megoldja saját magát, így az NV is gyorsabb lesz a DX11-nél. Viszont az is eléggé esélyes, hogy a parancskezelésre vonatkozó problémát innentől hordozni fogja még évekig, túl körülményes lenne ennek javításába komolyabb humánerőforrást rakni. Egyszerűbb lenne, ha az NV implementációja igazodna jobban a Microsoft ajánlásaihoz.

    [ Szerkesztve ]

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

  • #10 Abu85 HÁZIGAZDA Arnold2 #9
    Új Válasz #10
    Ú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 Arnold2 #9 üzenetére

    Ne várj sokat tőle. Annyira komplex a probléma, ami ezt okozza, hogy nem lehet belátható időn belül javítani. Az se biztos, hogy megéri átdolgozni a motort, mert a többszálú optimalizálással úgyis gyorsabb lesz a DX12 mód a DX11-nél.

    A Microsoftnak egyébként lehet, hogy el kellene gondolkodnia azon, hogy más ajánlásokat tegyen a fejlesztőknek, mert az NV implementációja borzalmasan kényes bizonyos dolgokra, amiket ők ajánlanak, míg az Intel és az AMD implementációjának igazából jó az is, amit az NV ajánl. Kevésbé kényesek a meghajtóik, szóval néhol talán érdemes az NV leírásait követni. A parancslistáknál mindenképpen.
    A root signatures és a pufferek helyzeténél nem egyértelmű a helyzet. Azért annak vannak komoly hátrányai is, hogy a buffer view-ek direkten a root signatures-be mennek. Mindenki érti, hogy a GeForce pixel shader teljesítménye romlik, ha a Microsoft "maradt távol a buffer view-ekkel a root signatures-től" ajánlását követi, de sokszor muszáj eleve távol maradni.

    [ Szerkesztve ]

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

  • #35 Abu85 HÁZIGAZDA cskamacska #34
    Új Válasz #35
    Ú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 cskamacska #34 üzenetére

    Azért nehéz a PhysX helyére mit rakni. Azt ugyanis le kell fejleszteni. Tehát, amikor az NV elmondta nekik, hogy levágják a supportról a felhasznált PhysX verziót, akkor kb. az egyetlen megoldás az volt, hogy kiveszik. Ez minden zárt rendszernél probléma. Nem a fejlesztő birtokolja a kódot, így amint a tulajdonos levágja a lélegeztetőről, azonnal veszik is ki a játékokból, mert support nélkül nem tudnak vele mit kezdeni. Ha mondjuk valami bugot okoz, akkor csak nézhetnek egymásra, mert az NV nem fogja javítani, ők pedig nem tudják javítani. Még ha vissza is fejtik a forrást, akkor is a licenc megakadályozza, hogy beleírjanak.
    A Warframe helyzete azért volt sokkal könnyebb, mert ők a konzolhoz eleve írtak egy másik alternatívát, tehát amikor az NV belengette, hogy lekapcsolják a PhysX-üket, akkor rögtön tudtak egy másik rendszerhez nyúlni.
    De láthatod, hogy a fejlesztő keze meg van kötve. Nem tudnak mit tenni azzal a helyzettel, hogy az NV kiveszi a support mögül a pénzt.

    [ Szerkesztve ]

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

  • #37 Abu85 HÁZIGAZDA Raysen623 #36
    Új Válasz #37
    Ú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 Raysen623 #36 üzenetére

    Amivel ugyanott vannak, mint a PhysX-szel. Ha visszamondja a Microsoft a supportot, akkor mehetnek keresni egy újabb megoldást. Nem véletlenül írtak sajátot a Warframe-hez.

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

  • #41 Abu85 HÁZIGAZDA Busterftw #39
    Új Válasz #41
    Ú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 Busterftw #39 üzenetére

    Az újabb verziók mögül még nem szedték ki a supportot, de gondolom ezekbe sem éri meg hosszabb távon önteni a pénzt.

    (#40) kikikirly: De mit vársz a fejlesztőktől? Ők hozott kódból dolgoznak. Ha az NV azt többet nem támogatja, akkor azt ki kell szedniük, mert nem tudják garantálni a működését. Nyilván nekik is egyszerűbb lenne az, ha az NV adna supportot ezer év múlva is, mert akkor nem kell még a kiszedésre se költeni, de nem ez a helyzet. Egy fejlesztő ezzel nem nagyon tud mit kezdeni. Még ha meg is tartanák a támogatást, akkor sincs meg a licencük arra, hogy saját kézbe vegyék a supportot, amint módosítanak a kódon (mert visszafejthetnék és foltozgathatnák), szétpereli az agyukat az NVIDIA. Itt vagy cserélik más megoldásra, vagy kiszedik. Harmadik opció nincs. Biztos nem a fejlesztő ment oda az NV-hez, hogy lőjétek már le a támogatást, hogy legyen egy jó adag extra munkánk ezzel.

    [ Szerkesztve ]

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

  • #44 Abu85 HÁZIGAZDA kikikirly #42
    Új Válasz #44
    Ú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 kikikirly #42 üzenetére

    A fejlesztők ma leginkább saját fizikai motort csinálnak, vagy megveszik a Havok licencet teljesen, és azt módosítják saját igények szerint.. Ha nem így lenne, akkor az Intel nem adta volna el a Havokot, az NV nem húzná ki a pénzt a PhysX mögül, stb.
    A GPU-s fizikai motorral az a probléma, hogy ma a CPU inkább szabadabb erőforrás, mivel az explicit API kihasználhatóvá tette az eddigi zárt CPU-időt. A GPU-nál viszont az aszinkron compute pont bezárja az idle réseket, ahol futhatna egy szimuláció. Ahol pedig nagy segítség lenne a GPU oda a round trip miatt lehetetlen befogni.
    Ha a GPU-s fizika tényleg működne a részecskeszimuláción vagy a cloth fizikán túl, akkor ma mindenki GPU-n számoltatná azt, de nem működik. A Microsoft későbbi fejlesztéseivel működhet amúgy, ezért vették meg a Havokot. Ők már sokkal integráltabb formában tekintenek a GPU-ra, nem egy CPU-tól 10 centire lévő különálló egységre. Az egy érdekes irány, és ott várhatók majd előrelépések.

    [ Szerkesztve ]

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

  • #49 Abu85 HÁZIGAZDA kikikirly #48
    Új Válasz #49
    Ú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 kikikirly #48 üzenetére

    Csak jobb leképezők kellenének, de ez sok pénzbe kerül. Viszont messze vagyunk az ideális szinttől. A legtöbb motor még texel shadingre se tért át, anélkül pedig aligha lehet nagyot lépni előre.

    Az a baj, hogy maga a GPU nem igazán alkalmas egy rakás fizikai szimulációval kapcsolatos munkára. Önmagában legalábbis semmiképpen, mert ezek a pipeline-ok csak egyes lépcsőkben párhuzamosíthatók, más lépcsőben pedig a késleltetés a kritikus tényező. A probléma tehát túl komplex ahhoz, hogy csak a GPU-n vagy csak a CPU-n fusson. Emiatt vette meg a Microsoft a Havokot, ami vissza fog majd térni egy új API formájában, és ott már CPU+GPU feldolgozási modell lesz. Az már ideális a fizikára.

    Sose írtam, hogy a Ray-Tracing abban a formában, ahogy alkalmazni akarják értékelhető. A Remedy adatai szerint hasztalan, hiszen pixelenként egy sugarat, virtuálisan maximum 4 méteres távolságig kilőve a számítások nagyjából 5 ms-ig tartanak Full HD-n egy Titan V-n. Ez azt jelenti, hogy még a raszterizációból is vissza kell venni, hogy működjön. Persze mondjuk két év múlva már sokkal gyorsabbak lesznek a hardverek, és aligha gondolkodik a Microsoft közelebbi dátumban.

    [ Szerkesztve ]

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

  • #52 Abu85 HÁZIGAZDA kikikirly #51
    Új Válasz #52
    Ú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 kikikirly #51 üzenetére

    A Microsoft Havok átalakítása az leginkább az Intel ötlete. Ők is dolgoztak rajta, csak ugye eladták a Havokot. De nagyrészt részei a projektnek. Nem nyilvános, de erre hozzák a saját GPU-jukat. Szóval az elérhetőség is nagyjából akkor lesz, amikor megérkezik a pGPU-s platformjuk.

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

  • #68 Abu85 HÁZIGAZDA kikikirly #57
    Új Válasz #68
    Ú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 kikikirly #57 üzenetére

    Hülyeség magszinten felosztani a feladatokat. Sokkal jobb egy job rendszer, több motor is így dolgozik ma. A skálázódás ott szokott nehézségbe ütközni, hogy a CPU-időt elveszi a GPU kernel driver, de explicit API mellett ez sincs, tehát itt már tényleg felhasználható a szabad CPU-idő. Ehhez viszont megfelelően kell tervezni a motort.

    Nem a háromszög a Wolf 2-nél a probléma, hanem a rajzolási parancsok száma. Ez a Doom esetében 1000/frame volt. A Wolf 2-nél 30000/frame. Működött igazából az OpenGL port, de annyira lassú volt, hogy értelmetlenné vált a szállítása, a GPGPU cullingot sem portolták rá, de mondjuk ez kikapcsolható volt.
    Háromszögek szintjén a Wolf 2 hatmillió háromszög/frame-mel dolgozik, ami nem kirívóan magas érték, bár persze nem is alacsony. :)

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

  • #69 Abu85 HÁZIGAZDA Z_A_P #60
    Új Válasz #69
    Ú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 Z_A_P #60 üzenetére

    Nem. Az NVIDIA hardverei egy probléma miatt lassulnak nagyot. A DX12 implementációjuk nem igazán szeret bizonyos dolgokat. Erre speciel fel is hívják a figyelmet:
    "Be aware of the fact that there is a cost associated with setup and reset of a command list
    - You still need a reasonable number of command lists for efficient parallel work submission
    - Fences force the splitting of command lists for various reasons (multiple command queues, picking up the results of queries)"

    A probléma az, hogy a Microsoft például egyáltalán nem dokumentál semmit arra vonatkozóan, hogy a fences kényszeríti a parancslisták felbontását. Ergo az API nézőpontjából ez a tényező nem létezik, és a GPU-nak belül kell az érintett problémákkal megbirkóznia, a DX12 gyártói implementációja mögött. Egy ideje viszont gyanítható, hogy az NV architektúrái bizonyos feladatokat nem tudnak elvégezni a host processzor segítsége nélkül, vagyis ha a fejlesztők nem gondoskodnak speciális kódról annak érdekében, hogy megfelelő legyen a hardver számára a párhuzamosan futtatható feladatok biztosítása, akkor a GeForce-ok egy rakás stallba futnak, ami bedönti a DX12 alatti teljesítményüket. Ez ellen az egyik megoldás, ha az NV ajánlásait figyelembe veszi a fejlesztő, mert az AMD és az Intel DX12 implementációjának nem különösebben számít, hogy kevés vagy sok parancslista van. Az NV-nek viszont létkérdés, hogy sok legyen.

    [ Szerkesztve ]

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

  • #73 Abu85 HÁZIGAZDA Z_A_P #71
    Új Válasz #73
    Ú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 Z_A_P #71 üzenetére

    Az is. Mindegyik GeForce. De nem akkora para ez, mint amilyennek tűnik. Akkor lenne gond, ha az Intel és az AMD implementációja például pont azt nem szeretné, amit az NV implementációja szeret, de az Intel és az AMD DX12 meghajtója egyáltalán nem kényes, jó az is nekik, ha az NV parancslistákra vonatkozó ajánlásait követi a fejlesztő. Igazából a nagy kérdés, hogy a Blizzard miért nem azt követte. Elképzelhető, hogy volt valami ellenérv a háttérben, csak nem tudunk erről.

    (#72) Puma K: [link]

    [ Szerkesztve ]

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

  • #77 Abu85 HÁZIGAZDA Z_A_P #76
    Új Válasz #77
    Ú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 Z_A_P #76 üzenetére

    Leginkább annyi, hogy nem gondolták előre, hogy a DX12 parancslistákra vonatkozó működése bármelyik gyártó implementációjának/hardverének problémákat okozhat.
    Azt nem hiszem, hogy ha az NV ajánlásait követi egy fejlesztő, akkor attól leolvad az API. ;]

    [ Szerkesztve ]

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

  • #80 Abu85 HÁZIGAZDA Ragnar_ #79
    Új Válasz #80
    Ú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 Ragnar_ #79 üzenetére

    A DX12 is ilyen. A Vulkan esetében két tényező van, ami fontos még. Az egyik, hogy jellemzően OpenGL-ről váltanak erre az API-ra, amibe nagyságrendekkel kevesebb erőforrást rak minden érintett a DX11-hez viszonyítva. A másik, hogy a Khronos sokkal inkább egy közös nevezőre tervezte az API kritikus részeit, ami jó például az NV-nek, illetve alapvetően mindenkinek. A Microsoft nem igazán foglalkozott ezzel, ami jó volt az Intelnek azt specifikálták és kész. Az részletkérdés volt, hogy helyenként ezzel az NV-nek kárt csinálnak, például a parancslistáknál vagy a root signature esetében. Az AMD-vel sem igazán foglalkoztak, nekik csak szerencséjük, hogy a GCN semmire sem kényes igazán, tehát az is jó, amit a Microsoft specifikál, és az is jó, amit más ajánl, teljesítményben nagyjából ugyanott lesznek.

    A DX12-vel egyébként két tipikus késbe lehet futni. Az egyik a parancslisták helyzete. Ebből sok kicsi kell, hogy az NV-nek jó legyen a program, és az Intel, illetve az AMD meghajtója nem különösebben érzékeny erre, tehát nyugodtan lehet az NV ajánlásai szerint fejleszteni, az más kérdés, hogy ez a program oldalán nem kevés extra meló, tehát mondhatja a fejlesztő, hogy "baszki erre nincs időnk, hozzatok jobb hardvert". A másik tipikus gond a root signatures. Az NV azt szereti, ha buffer viewek közvetlenül ebben vannak, míg az Intelnek ez pont nem jó, és azt kedvelik, ha a Microsoft ajánlásai szerint ebben lehetőség szerint csak közvetetten vannak buffer viewek a leírótáblákon keresztül bekötve. Az AMD-nek pedig igazából mindegy, hasonló a teljesítmény így is, úgy is.

    Egyébként annak oka van, hogy a Microsoft miért így alakította ki a specifikációt. A buffer viewek esetében azért nem ideális, ha közvetlenül a root signatures részei, mert a leírótábla vagy -halmaz mögött ezek állapotát manuálisan követni kell, így ha mondjuk új információ kerül beírásra, akkor tudni kell, hogy az olyan helyre kerüljön, amit a GPU már nem használ. A root signatures részeként ez a szabály nem érvényes, vagyis minden új információt a rendszer új memóriaterületre írja, meghagyva a régi adatot is, ugyanis nem kötelező érvényű, hogy egy leképező kiderítse, hogy az használatban van-e, és jellemzően nem is teszik meg, mert a root signatures részeként nem olcsó az eljárás. Ez viszont azt jelenti, hogy a memória folyamatosan telik meg a játék előrehaladtával, amire végeredményben nagyon nehéz alkalmazásoldali menedzsmentet írni, mert csak egy bizonyos időtávon belül lehet nagy biztonsággal meghatározni, hogy mi lesz a memóriában. Hosszabb távon viszont már jönnek a gondok, ami előhozza azokat a teljesítménykritikus jelenségeket, amelyek létezése a vezető indoka volt az explicit API-k megalkotásának. Szóval a buffer viewek helyzete marhára nem egyértelmű. Igen nyomós indokok vannak arra vonatkozóan, hogy miért nem jó az NV ajánlása. És igazából a mai memóriaárak mellett a brute force módszerben sem lehet bízni, hogy majd úgyis lesz 20-30 GB VRAM a VGA-n, amit tele lehetne pakolni szeméttel.

    [ 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