2. Fórumok
  3. Videokártyák
  4. Nem jól működik az anizotropikus szűrés az újabb Radeon meghajtókban
Keresés

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

  • #61 Abu85 HÁZIGAZDA huskydog17 #58
    Új Válasz #61
    Ú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 huskydog17 #58 üzenetére

    A Doom demót felejts el. Az nekem se működik, össze van toszva a kód, csak kipróbálás céljából. Lényegesen különbözik a teljes verzió. Az alatt a Vulkan is jó.
    Ugyanígy jártunk mi is a PH-s tesztben. A demó nem működött, de amint megvettük a teljest azonnal futott. Állítólag a demóban csak a szabványos SPIR-V shaderek vannak szállítva, miközben az AMD drivere a speciális kódot várja. Mivel ezt nem kapja meg, így az inicializálásnál megpusztul a demó indítása.
    Igazából maga a program különleges. Nem csak egy Vulkan renderer van benne, hanem gyakorlatilag kettő. Van egy szabványos mindenkinek, és van egy gyors kód az AMD-nek.

  • #59 #25237004 törölt tag huskydog17 #58
    Új Válasz #59
    Ú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

    #25237004

    törölt tag

    válasz huskydog17 #58 üzenetére

    "Megnéztem volna Vulkan alatt is, ha működne a Vulkan leképző, de nem működik, mert összeomlik a program ha át akarok rá váltani." A 6.66 patch nekem sem működött korábbi AMD driverrel, most a 17.7.1 Relive van fent, ezzel fut Vulkan alatt is. (újabbat az Overwatch miatt nem tudok feltenni)

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

    A Dota 2 OpenGL és Vulkan módja is megy, ahogy az új Doom is, meg a Quake Live. Más nem DirectX-es játékot nem szoktam használni.

    Arra kell figyelni, hogy a desktop recording legyen aktív, ez az alapja.

  • #54 Abu85 HÁZIGAZDA huskydog17 #53
    Új Válasz #54
    Ú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 huskydog17 #53 üzenetére

    Kapcsold be a desktop recordinget, és akármilyen API-t használó játékot is kepés lesz rögzíteni. Nekem így egyetlen OGL-es játékkal sem volt gondom.

  • #52 Abu85 HÁZIGAZDA huskydog17 #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 huskydog17 #51 üzenetére

    Ha úgy gondolod, hogy mulasztás történt, akkor nyugodtan írj Roy Taylornak. Ő szokott erre figyelni. De amúgy nem jellemző ez. Arra kell figyelni, hogy ha találsz egy hibát, akkor azt meg kell nézni a legújabb driverrel. Ha azzal is rossz, akkor a Settings vezérlőpultba van egy gomb amivel lehet reportolni. És nagyon fontos az új meghajtó, mert a verziószámot is nézik. Minél régebbi meghajtóból származik a report, annál hátrébb csúszik a listán.

    Persze használom a VCE-t. ReLive-val, illetve PowerDirector 15-tel, meg néha A's Video Converterrel. Nem tapasztaltam problémát. De amúgy jobban szeretem a CPU-s konvertálást a minőség miatt.

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

    Ez messze nem ilyen egyszerű. Annyit lehet látni, hogy a régebbi API-khoz a meghajtóimplementációk a lehető leggyorsabbak és kiforrottak. Talán lehetne még nyerni sebességet, de 1-2%-os extra is aránytalanul sok befektetést igényelne. Ezt már az NV, az AMD és az Intel sem tartja realitásnak, főleg úgy, hogy van két explicit API, ami azért erősen leköti a kapacitást.
    Olyan sincs, hogy általánosan ideális architektúra, mert a DirectX 11 abból a szempontból nagyon speciális volt, hogy igen sokat megengedett az API és az OS a drivernek. Ezáltal voltak olyan eljárások, amelyeknek az AMD implementációja kedvez, de olyanok is, amelyeknek az NV. Például a GPU-driven motorok tipikusan az AMD implementációjával futnak jobban. Az NV megoldásának a DC kedvez, míg az IC+manual threading nem általánosítható, megvalósítástól függ, hogy melyik rendszer érzi jobban magát. Ezek azért alakultak ki, mert a hardverekbe a gyártók egy rakás fast pathot építettek, hogy ezeket használhassák DirectX 11 alatt, csak ezeket a fast pathokat a Microsoft a DirectX 12-vel elvágta, tehát a hardveres képességek jó része az új API-val elérhetetlen. Hasonló reform van a Vulkan API-ban is, az is az egységesítés felé menetel.
    Az újabb hardvereken is látszik, hogy az új API-k mások. A Vegában teljesen áttervezték a parancsmotorokat. Kivágták az összes fast pathot, és kigyúrták a front-endet. Ennek az előnye, hogy sokkal nehezen front-end limitbe ütközni, de a hátránya, hogy egy ilyen hardveres konstrukció jóval több tranzisztort igényel, mintha trükköznének. Viszont sok választás nem volt, mert az új API-val a Microsoft operációs rendszere tölti be a parancsokat és nem a driver. Vagy aláadják a hardvert a gyártók, vagy szopcsiznak.

    Én jelentettem két specifikusan játékra vonatkozó hibát idén, és egyik esetben sem kaptam ilyen választ. Mindkét hibára lett megoldás, igaz nem a meghajtóval volt a gond, de kaptam rá megoldást. Az egyik esetben a Clean Uninstall Utility segített. A drága ismerős perecelte el egy driverpucolással, de végül kiderült és korrigáltuk. ;]

    A fixfunkciós blokknál a driver sok dolgot nem csinál. Ad egy bemenetet, a hardver pedig ad egy kimenetet.

    Pedig egyértelműen így látom. Ma már egyértelműen az AMD van előrébb a meghajtó tekintetében. Nyilván két éve még nem gondoltam volna ezt, de a Radeon Software óta sok víz lefolyt a Dunán. Az NV egyébként szerintem jobban járna, ha hasonló fejlesztési modellre váltanak, mert akkor legalább a hotfixekre nem lenne szükség, és az is előny lenne, hogy össze lehetne vonni a csapatot. Az AMD-nek sem működött az a modell a havi Catalystoknál, amit most az NV használ.

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

    Nem. A bekezdés többi része arra vonatkozik, hogy ezt a problémát a legjobban a 3DCenter Filter Tester alkalmazással lehet látni. Azt egy szóval nem írtam le, hogy a játékokban nem lehet érzékelni, csak nem lehet visszaadni játékból származó képekben. Ezért ott van két kép, ami mutatja a jelenséget. Teljesen felesleges odaképzelni olyan dolgokat, amik nincsenek leírva.

    Fontos más API is, de azokra már több éve kész implementációk vannak. A lehető leggyorsabbak, amelyeket egy adott architektúrára lehet tervezni. Nem is igazán fejlesztik már őket, mert már nincs hova. +1-2% teljesítmény a régi API-ban már aránytalanul nagy anyagi befektetést igényelne. Ellenben a D3D12/Vulkan implementációkban még viszonylag sok teljesítmény van. Lásd a Warhammer 2-ben a DX11->DX12 váltást. [link] - Nem normális, ami történik a Pascal és Maxwell GPU-kkal, holott a Vega és a Polaris GPU-k tudják ugyanazt, vagy gyorsulnak. Egyszerűen meglátszik a meghajtón, hogy az AMD-nek három és fél év munkája van benne, míg az NV implementációja csak három hónapos.
    A multimédia nagyrészt hardveres dolog. A meghajtó tudhat dolgokat, de alapvetően fixfunkciós blokk van a modulok mögött.

    (#41) b. : A kezelhetőség szubjektív. Általában megszokod, tehát arra én nem térnék ki, hogy mi hol van a meghajtóban és milyen az UI dizájnja. Egyedül annyit rónák fel, hogy a GeForce vezérlőpultja nagyon lassú. Kb. olyan, mint a CCC volt. Lomha, sokáig karikázik az egérkurzor. Ezt kellene igazából kezelni, mert a Radeon Settings félelmetesen gyors hozzá képest. A GeForce Experience-be való átköltözés ebből a szempontból lenne nagy előny. Ez a program jóval gyorsabban működik.

    A szolgáltatások szempontjából igazából mindenkinek az számít, hogy kell-e az adott funkció. Ezeket én nem tekintem a meghajtó szerves részének. A Radeon Software is kínál egy csomó olyat, amit a GeForce driver nem és fordítva. Ez inkább az igények kérdése.

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

    "A fenti képből látható, hogy a hiba meglehetősen nehezen észrevehető, legalábbis mozgás nélkül."

    (#34) b. és (#35) huskydog17: Amiben most nagy különbség van az AMD és az NV driver között az az explicit API-k platformabsztrakciós implementációja, illetve a kliens oldali különbségek lekezelése. Mint írtam korábban az NV most kezdte újra az egészet a D3D12 implementációra, mert nem voltak elégedettek korábban írt jó két évig optimalizált rendszerrel. Most van egy friss rendszerük, ami így ránézésre jónak tűnik, de még messze van a jótól, ha specifikus rutinnal 15-25%-ot nyersz egy hét alatt egy kiadott játékon. Azt elhiszem, hogy kb. egy év múlva majd az lesz, de még három hónapos a rendszer, így maximum az mondható el róla, hogy stabil. Az AMD megoldása három és fél éves. Azért működik mindig sokkal flottabbul az AMD-n a DX12 és a Vulkan API, mert három és fél év munka van a platformabsztrakció implementációjában, és nem kell utókezelgetni egy héttel/egy hónappal/egy évvel a játék megjelenése után az implementációt, hogy jöjjön a sebesség. Ebből a szempontból az AMD most nagyon elhúzott. Persze oké mondhatjuk, hogy nekik mennyivel egyszerűbb dolguk volt. A DX12 és a Vulkan API-t is úgy támogatják, hogy húztak egy ICD-t a Mantle PAL rétegére. De akkor is ezt a problémát meg kell oldani, és persze a megoldás fontos eleme, hogy kidobták a korábbi implementációt. Ez bátor dolog volt, respect érte, és szerintem is ez a jó út, csak ezzel két évnyi munkát is kidobtak.

    A többi probléma igazából csak erre vezethető vissza. Most mindenki arra van beállítva, hogy legyen egy jó platformabsztrakciós implementációja a meghajtónak, tehát hiába kellene már egy gyorsabb és jobb vezérlőpult, egyszerűen nincs rá idő.

    b. neked mondom, hogy a GeForce Experience-szel nincs probléma. Ez lehet a menekülőút, mert egész gyors maga a program és ide simán át lehetne költöztetni a driver vezérlőpultját. Ez nem egy nagy dolog. Leginkább a tesztelés szempontjából problémás.

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

Hirdetés