Keresés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz Tyrel #2 üzenetére

    Mindegy, mert az aszinkron compute egy megoldás a nem optimális etetés direkt kezelésére. Tehát ahogy válik limitálóvá az aktuális hardvereken ez a modell, úgy lehet egyre inkább behozni az aszinkron compute-ot, hogy megetethetők legyenek a nem kihasznált egységek. Abban van csak probléma, hogy a PIX-nek a PC-re nincs hardveres nyomkövetést biztosító profilozómodulja, ami leegyszerűsítené a limitek megtalálását és kezelését. Xbox One-ra például van ilyen. Alapvetően lehet beszélni ezekről a limitekről, de a PC-s PIX nem mindig mutatja ki pontosan a limitáció helyét, így pedig nagyon nehéz ezeket eltüntetni.

    [ 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 Tyrel #5 üzenetére

    Igen a Radeon GPU Profiler már hardveres nyomkövetést használ, ahogy a konzolos profilozók. Viszont ezt a Microsoft még nem használta. Később lehet, hogy bevetik, erről nincs álláspont.

    A PIX amúgy egy komplett teljesítménymonitorozó és debug eszköz Windows és Xbox platformokra.

    [ 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 zborai #10 üzenetére

    Implementációtól függ. A Pascal nem minden implementációt szeret. A Vegának igazából mindegy.

    A Vega csak annyiban más, hogy már úgy tervezték a hardverét, hogy jobban igazodjon a Microsoft újabb rendszereihez. Ha mondjuk a Forza 7 komolyan használna async compute-ot, akkor a legtöbb hardvernek nem lenne baja, mert más parancslistákon keresztül a program megpróbálná etetni a GPU-ban található kihasználatlan részegységeket. Ez azonban nem valósul meg komolyabb formában, így a Vegának van egy olyan aprócska előnye, hogy már eleve sokkal jobban igazodik az új parancsfeldolgozási rendszerhez, így async compute nélkül sem igazán fut front-end limitbe egy ilyen speciális körülmény mellett.

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

  • Abu85

    HÁZIGAZDA

    válasz Tyrel #13 üzenetére

    Meg mondjuk az SW BF2 még béta.

    A PlayStation 4 Prónak lesz hatása a fejlődésre. Az a legtöbb multiplatform fejlesztés vezérplatformja. Egy PC-s hardver ezen nem változtat. A legtöbb PC-s hardvert nem is ismerik a fejlesztők.

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

    Mert tök egyértelműen látszik, emellett 4K-ra és 8xMSAA-ra a fejlesztők 8 GB VRAM-ot ajánlanak.

    Nem veszik át a vezetést. Minimumban sosem tudják elérni a Vegát, mert túl sok limitbe futnak bele. Alapvetően ez az, ami jelentősen limitálja a hardvereket, mert a rossz kihasználás gyengébb minimumokat eredményez. Lásd itt: [link] - tökéletesen látszik, hogy hol jelentkeznek a limitek. Ezek nem túl nagyok, de ilyen mértékű visszaesésekkel nem lehet találkozni a Vegánál, tehát ez a hardver sokkal kevesebb nyers limittel találja szembe magát. A limitek többsége egyébként nem tipikusan hardveres, lást a következő bekezdést.

    Az SW BF2 még béta. Nincs aktiválva az aszinkron compute, és a szervizkönyvtárak támogatása is le van még lőve. Ezek jókora boostot okozhatnak, de a működéshez új meghajtók kellenek. Végeredményben azt várják, hogy a GCN-en a DX12 GPU-limites környezeteben 5-7%-kal lesz gyorsabb a DX11-nél, tehát nagyjából azt hozza majd, amit a Battlefield 1.
    A GeForce-szal rövid időn belül nem valószínű, hogy tudnak mit kezdeni, mert nyáron megváltozott a meghajtóimplementáció. [link] - Ez a Frostbite-ot igen kellemetlenül érinti, mert minden olyan munka, amit az év első felében a GeForce-ra való optimalizálásba öltek, gyakorlatilag semmissé vált, olyan mintha nem is dolgoztak volna rajta. És sajnos nyár óta igen kevés idejük volt ezt megváltoztatni, főleg úgy, hogy maga a meghajtó is furán viselkedik bizonyos szituációkban, tehát az optimalizálás újrakezdése előtt mindenképpen érdemes megvárniuk azt, hogy az NV az új implementáció problémáit lekezelje. Körülbelül fél-egy év, mire egy ennyire új meghajtóimplementáció kiforrja magát. Szóval abban most vastagon benne van az UMD is, hogy a GeForce teljesítménye a DX11->DX12 váltástól a korábban megszokottnál jobban esik. Egyébként biztos jó oka volt arra az NV-nek, hogy a korábbi UMD-t megváltoztatták, tehát emiatt nem érdemes bírálni őket, de az időpont, amit erre választottak, nos rendkívül rossz. Már csak azért is, mert egy jó két éves munkát dobtak ki az ablakon a nyáron, és most kvázi kezdik elölről. És ötlet szintjén lehet akármilyen jó az új UMD implementáció, akkor is megvalósításban jó két év mínuszban 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 Petykemano #27 üzenetére

    Nem a program veszi ki ezt a meghajtó kezéből. A Microsoft döntött úgy, hogy innentől kezdve a fő parancsprocesszor etetéséért nem a meghajtó felel, hanem létrehoznak egy univerzális tulajdonképpen drivert, amit ők írnak meg, és ez támogatja az összes DX12-es hardvert. És innentől kezdve ez az univerzális modul eteti a fő parancsprocesszort. Ezt azért lépték meg, mert egységesíteni szeretnék a rendszereket ebből a szempontból, és ha mondjuk az NV és az AMD nem tud trükközni a meghajtóban bizonyos parancsok gyorsabb bevitelével, akkor muszáj az általánosan erősre tervezni a parancsprocesszort. Ennek várható következménye volt, hogy előbb-utóbb lesz egy olyan hardver, amit már a Microsoft új modelljére szabtak, így nem csak működik ezzel a konstrukcióval, hanem nagyon hatékony is vele.
    Ez az egész a Vegának pusztán időelőny. Később fogtak hozzá a tervezéséhez, így amikor a Microsoft a koncepcióját véglegesítette, akkor arra Pascalban/Polarisban már nem, viszont például a Vegában pont tudtak rá reagálni. Számos ilyen apró nüansz van egy hardver tervezésénél, amivel az API bizonyos képességeire reagálnak direkten. Ha belefér az időbe, akkor meg kell lépni, mert előnyös lesz.

    [ 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 NandoXXL #31 üzenetére

    [link] - A frame-time-ra jellemző kilengések implementációfüggők. Nem tipikusan program okozza. A nagyobb kilengések nagyon egyszerűen kezelhetők, de kell idő neki, mert az NV most kezdte újra a D3D12-es implementációját, tehát egy jó fél év lesz, mire ezt olyan megbízható szintre fejlesztik, amilyen a nyár előtt volt. Az előző két évi munkát kidobták az ablakon.

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

  • Abu85

    HÁZIGAZDA

    válasz Viszpi #44 üzenetére

    Igen. Ez igazából normális jelenség a D3D12 programokban. Az AMD aktuális D3D12 implementációja nagyon régi. A PAL réteg gyakorlatilag egyidős a Mantle-lel, és a kezdetek óta nem változott. Egyedül az ICD réteg módosul felette, de az is két éves, tehát amit látsz az AMD-n az úgy összességében három és fél év optimalizálás eredménye. Az NVIDIA aktuális D3D12 implementációja sokkal fiatalabb. Nekik az újraírt PAL-szerű (ők nem PAL-nak hívják, de ugyanaz a célja) rétegük mindössze három hónapja stabil. Optimalizálásra még nem is volt idejük. Most bő három év mínuszban van az NV az optimalizálás tekintetében az AMD-hez képest, és ez okoz ilyen különbségeket. Ez egyébként mindenképpen megjavul egyszer. Egy új implementáció sosem működik optimálisan már az első napon. Az AMD is ugyanúgy megjárta ezt a lépcsőt, csak ők már 2014-ben megtették.

    [ 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 hackeeeee #50 üzenetére

    Mint írtam ez implementációfüggő. Nézd meg a Radeont, hogy mennyivel simább.

    Egyébként most nem érdemes ezért bántani senkit. Egyszerűen a korábbi hardverek belefutnak bizonyos limitációkba. Ezek egy része hardveres, egy része szoftveres. Főleg az NV-nél vannak szoftveres problémák, mert az új PAL-szerű implementációjuk csupán három hónapja stabil. Persze, hogy nem tudja azt hozni, amit az AMD három és fél éve optimalizált PAL megoldása. Kell neki egy-másfél év, mire kiforrja magát. Ha már a váltás mellett döntött az NV, akkor biztosan nem fognak visszatáncolni a régi implementációra, még akkor sem, ha az esetleg ma még jobban működne.
    Nem azt mondom, hogy ez így jó a GeForce tulajoknak, mert nyilván nem, de az NV hozott egy döntést. Valószínűleg, ha tudnának építeni időgépet, akkor megtennék, és visszamennének 2014-be, hogy már eleve ezzel az implementációval kezdjék meg a D3D12-t, de ezt nem tudják megtenni. A hardveres limiteket pedig kezelni fogja a Volta.

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

    Eléggé. Írja is a CB cikk.

    Azért a minimum a lényeg: [link]

    Megfelelő implementációval érdemes használni, főleg multiban. Nem megfelelővel nyilván nem érdemes.

    [ 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 hackeeeee #56 üzenetére

    Nem ismerték el. Csak átalakították, mert a Forza 7-hez terveztek egy új rendszert. Ezt részben visszaportolták.

    Semmit sem rontottak el. Ugyanúgy működik, ahogy az FH3, de a Forza 7-nél a szabad CPU-időt friss bemeneti adat keresésére használják fel. Ezzel nem csak a skálázás lesz olyan, amilyen az FH3-nál, hanem alacsonyabb lesz a késleltetés is. Ez egyértelműen jobb. Ha ez nem lenne, akkor mindegyik szálra 10-20%-ot terhelne.

    Mondtam, az egyik problémára jön a Volta, de a másikra elég egy friss meghajtó is. Három hónapos az NV-nek az új D3D12 implementációja. Három hónap alatt nem lehet csodát tenni. Inkább egy-másfél év mire ebből nem csak stabil, de tényleg abszolút problémamentesen működő implementáció lesz. A Volta megjelenésére valszeg már jó lesz.

    Ha most kell nagyon smooth élmény, akkor erre a játékra ott a Vega, vagy egy Xbox One.

    [ 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 hackeeeee #59 üzenetére

    Akkor várni kell. A problémák egy része relatíve jól kezelhető, csak tényleg nem érdemes elvárni a hatékony működést egy három hónapja kész implementációtól. :) Ez így rosszul hangzik, de minden bizonnyal jó okkal váltott az NV. Aztán ehhez a fejlesztőknek is igazodni lehet, mert eredetileg ezeket a motorokat még a régi implementációhoz optimalizálták. Csak az már eltűnt az UMD-bő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 huskydog17 #64 üzenetére

    Ajánlom a figyelmedbe: [link] - nem kellemes dolog a frame-time ingázása. Lehet azt mondani, hogy marhára rendben van, hogy 140-ről hirtelen leesik 70-re, majd vissza és ciklikusan ezt csinálja, de a valóság az, hogy marhára nincs rendben. Főleg úgy, hogy a Vegákon ez a jelenség nem létezik, és a többi GCN-en is jóval kisebb mértékű.

    (#65) Raymond: Ugyanez vonatkozik a te feltevésedre is. Lehet azt mondani, hogy tökéletes, ha a játék 140-ről 70-re esik, majd vissza és mindezt pillanatokon belül, de ezt olyan felhasználóknak kell elmagyarázni, akik 150-250k-t adtak ki egy olyan hardverért, ami ezt a jelenséget produkálja, és alapvetően elvárnák, hogy olyan frame-time-ot kapjanak, amilyet a Vega biztosít, de legrosszabb eseten is egy Polarishoz hasonlóra vágynak. 150-250k kiadása után én elhiszem, hogy nem érzik jónak a 140->70->140 fps-es ingázást, még akkor sem, ha szerinted ez így jó.

    A 4 GB-os Fury X-re azt írtam, hogy a 4 GB kevés 4K-ra és 8x MSAA-ra.

    [ 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 Raymond #70 üzenetére

    [link] - ha nem látná, akkor nem jelezné, hogy ingadozik az fps. Más dolog, hogy szerinted mi a jó, és más amit mondjuk szeretne a user látni 150-250k kiadása után. A 140->70->140 fps nem fér bele. Főleg úgy, hogy a Vegákon ez a probléma nem létezik. A legtöbb játékos azért fizet ki egy hónapnyi fizetést egy hardverre, hogy ne tapasztaljon ilyen jelenségeket.

    Leírtam, hogy a fejlesztők 8 GB-ot ajánlanak 4K+8xMSAA-ra. A minimum, amivel ez a beállítás értékelhető fps-t ad az 6 GB, de ilyenkor lehetnek akadások. Ebben benne van az is, hogy a 4 GB kevés. Azt hittem ezt össze lehet rakni logikával. Elnézést, hogy sokat feltételeztem.

    [ 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 Raymond #72 üzenetére

    A legnagyobb baj, hogy csak addig értelmezed a bekezdést, ameddig szeretnéd, de a bekezdés végén leírja, hogy a GeForce még mindig nincs elég közel a Vega majdnem tökéletes frame-time-jához. Egyszerűen, ha ennyit kiadsz egy hardverre, akkor elvárod, hogy működjön, és ne legyenek a futtatás közben 140->70->140 fps-es ugrások. Ha ez nem lenne probléma, akkor hackeeeee is azt írta volna, hogy minden szuper, és nem azt, hogy össze-vissza ugrál az fps.

    A tök egyértelműen látszik arra vonatkozott, hogy 4 GB kevés azon a felbontáson, amit láthatsz a CB teszben. A fejlesztők pedig mondták a kérdésemre, hogy 4K+8xMSAA-ra max beállításokkal 8 GB memória az ajánlott. 6 GB a minimum, amin működni fog, de ezzel a mennyiséggel elképzelhetők kisebb akadások. Persze ennek a jelenségnek a vizsgálata nehézkes, mert csak GeForce-ot találni 6 GB VRAM-mal, és az NV D3D12 implementációja még egy 8 GB-os, teljesítményben erősebb VGA-n is rendkívüli mértékben dobálja az fps-t, tehát végül nem látszik majd egy GTX 1060-on, hogy egy adott akadás a memória hiánya vagy a meghajtó implementációja okozta.

    [ 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 hackeeeee #73 üzenetére

    Ezek egymástól függnek. A frame-time az a képkockák elkészültének ideje ezredmásodpercben. Ilyenkor csak az adott képkocka számít, és így lehet visszamenőlegesen felvázolni, hogy mennyire volt egyenletes a megjelenítés. Az fps az inkább arra vonatkozik, hogy több másodpercen át milyen volt a frame-time, noha az való igaz, hogy a valós fps mérésnél a programok egyszerűen úgy dolgoznak, hogy 1000/frame-time=fps. Ennek igazából nincs sok értelme, mert nem feltételezhető csupán egyetlen frame számításának idejéről a teljes másodpercre vonatkozó számolt frame-ek mennyisége, de amikor látsz egy nagy fps esést, akkor az történik, hogy az adott frame-nél a frame-time megnő annyival, amekkorát esett az fps. Tehát ezek arányban vannak. A jobb valós idejű mérők egy korlátozott, ideális esetben egy másodpercnyi időtartamra mért frame-time-ot átlagolnak. Ez már valamivel jobb fps kijelzést eredményez.

    [ 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