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

• #59758 HSM félisten fLeSs #59731

  Új Válasz 2023-01-21 21:32:07 #59758

  Ú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

  

  HSM

  félisten

  válasz fLeSs #59731 üzenetére

  "Instabil alatt nemtom mire gondolsz"
  Pl. 280X-ből volt jópár AIB típus, aminél a GPU alatti ramcsipre nem került hűtés, és rendszerint el is melegedett, ami miatt sok szemetelt ezek közül. 290-ekből is volt ramhűtés nélküli AIB, ott is a felhasználónak volt érdemes kicsit besegíteni a kártyának nem túlmelegedni... 5700-nál is volt pár 'érdekes' modell. Ezek nem segítenek építeni a bizalmat.

  "Inkább a driverekkel volt/(van?) probléma."
  Voltak bizonyos alaplapok, amiknél a zerocore módjuk után fekete képernyő jött, nem tért magához a GPU (volt aki írt is rá kis appot, ami meg tudta akadályozni ezt a módot). Na, aztán már mindenféle hibát ennek a számlájára írtak a fórumban, azt is, amiről ordított, hogy kártyahiba, de ugye a "fekete képernyős hiba" villant be...

  "2. átlag vásárló ha ilyet lát ... akkor kétségbeesettséget sejt emögött"
  Nem tudom, én valószínűleg nem ilyen vagyok. Számomra a pl. zárt middleware-ek vagy zárt megoldások erőltetése a szabványok helyett, amire mint a versenyt potenciálisan csökkentő, a vásárlónak hátrányos dologként tekintek.

  #59732 morgyi :

• #59734 Abu85 HÁZIGAZDA fLeSs #59731

  Új Válasz 2023-01-20 22:16:17 #59734

  Ú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 fLeSs #59731 üzenetére

  Az open source egy stratégia. Az NVIDIA is megy az open source felé, lásd Linux meghajtó megnyitása, mert rájöttek, hogy bizonyos piacokon fel sem kerültek a potenciálisan megvásárolható hardverekhez, mert nem volt open source stratégiája. És ezek a piacon már dollármilliárdos szintre nőttek. Ez géming szempontból is hasznos, mert a Steam Deck az open source miatt létezik.
  Emellett nagyon sok open source Vulkan/D3D12 projektje van az AMD-nek, amik nélkül egy csomó játék nem is létezne úgy, ahogy létezik. Például ma már tipikus, hogy a top stúdiók sem írnak saját memóriamenedzsmentet, hanem letöltik ezeket: [link] , [link] - utólag lehet módosítani a forráskódot. Az előző évben az összes Ubisoft és Activision cím ezekkel jött, és idén már egy csomó EA cím is átáll erre a fejlesztési modellre. Például a Star Wars Jedi Survivor. Szimplán sokkal olcsóbb az AMD által megírt kész kódot felhasználni és finomhangolni, mint írni a nulláról egy sajátot. Ráadásul új dolog, hogy az újabb VMA és D3D12MA verziókba már az Intel is optimalizál, vannak kódrészek, amiket a saját Arc hardvereik miatt adtak hozzá. Rájöttek, hogy nem tudják lebeszélni róla a fejlesztőket, így beálltak ők is fejleszteni a kódot. Ez egy stratégia.

  És nem csak a memóriamenedzsmentet egyszerűsítik, hanem az egész Vulkan és DirectX 12 használhatóságát, ugyanis van egy új RPS SDK-juk. [link] Ennek tipikusan az a célja, hogy ha egy indie nem akart explicit API-ra váltani, mert túl bonyolultnak tartotta, akkor használjon RPS SDK-t, és úgy használhat explicit API-t, miközben az alkalmazásának bonyolultsága nem lesz nagyobb a DirectX 11-nél.
  
  A képen látható is, hogy a fejlesztőnek nem kell azokat a sárga bonyolult dolgokat megírni, egyszerűen az RPS SDK megcsinálja helyette automatikusan. Ráadásul nem is szarul, mert az AMD mérései szerint 58 explicit API-t használó játékból 54-nél gyorsabb volt az alap kódnál az RPS rendszer. Tehát még a top fejlesztők számára is elgondolkodtató a használata, mert nem kell másfél évet szenvedni az optimalizálással, megoldható két hét alatt az SDK implementálásával, és mindent automatikusan csinál az RPS. Azt persze hozzá kell tenni, hogy az RPS licenc az nem MIT, tehát ott azért vannak kérdőjelek, de majd kiderül, hogy a végleges verzió milyen licencet kap.

  A stratégia az egész mögött annyi, hogy ha valaki fejleszt egy D3D12/Vulkan játékot, akkor ne is írjon saját memória-menedzsmentet, erőforrás-kezelést, ütemezést a GPU munkafolyamatokra és az erőforrás-korlátozásra, hanem töltse le a VMA/D3D12MA és RPS kombót, oszt kész. Az AMD előre megírt, minden hardveren működő (NV-n és Intelen is), több tízezer sornyi, bármilyen motorba beilleszthető kódot ad, amit később lehet módosítgatni a nyílt forráskód miatt. Persze, ha valaki akar ezzel foglalkozni. És tekintve, hogy a VMA/D3D12MA mennyire bevált, az RPS is kb. arra számíthat, hogy menni fognak érte. És ugye az NV és az Intel is fejlesztheti, hiszen ott a forráskód a GitHub-on. Az Intel már fejleszti is a VMA/D3D12MA-t.

  És ez a fajta stratégia nagyon bevált eddig, mert tök egyértelmű a fejlesztők felé az üzenet. Miért akarnál 30-40 ezer sornyi kódot megírni, amikor le is töltheted, és helyből gyorsabb lesz minden elérhető hardveren, mint amit írni tudnál másfél év alatt?

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