- Akciófigyelő: Humble Games Bundle - Nightdive FPS Remasters
- Call of Duty: Modern Warfare III - Új szezon, újabb ingyenes hétvége jön
- Hunt: Showdown - Jön az engine csere, befutnak az újgenerációs verziók
- Steamre tart a Crime Boss: Rockay City
- The Witcher - Befutott a TV sorozat folytatásának első rövid kedvcsinálója
Új hozzászólás Aktív témák
-
#24861
Abu85
HÁZIGAZDA
FollowTheORI
#24858
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#24858
üzenetére
Csak gondolj bele. A GPU IP még nem fizikai dizájn, tehát előbb implementálni kell egy adott node-ra. Az AMD pedig nem tipikusan egy licenceléssel foglalkozó cég, tehát konfigurálható sematikus dizájnt nem fognak árulni. Lesznek azok a sematikus dizájnok, amiket maguknak terveztek és kész. Ha valaki akar egy GPU IP-t az AMD-től, akkor ahhoz licenceli az igényekhez legjobban hasonlító AMD dizájnt, illetve annak komponenseit. Abból megtervezi a saját GPU-ját, amiből készít egy fizikai dizájnt arra a gyártástechnológiára, amit választ. Ehhez a procedúrához nagyjából két-két és fél év kell. Tehát bármit is rendel egy cég ahhoz mindig csak egy generációval később tud fizikai dizájnt szállítani, mint az AMD.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#24864
Abu85
HÁZIGAZDA
FollowTheORI
#24863
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#24863
üzenetére
Ezt rosszul tudod. Nagyon sok időt vesz igénybe egy sematikus dizájn fizikai implementációja. Minimum egy évet. És ezt úgy, hogy a tervek teljesen készek. Emiatt vezette be az ARM és az Imagination a fizikai IP licencelését. Elkészítenek mindenből egy fizikai dizájnt egy-két elterjedt node-ra, hogy azt átemelhesse a megrendelő. Ez nagyon sikeres az ultramobil piacon, mert a jellemző egy-másfél év közötti időigény fél évre csökken.
Az AMD ilyen üzleti modellt nem tervez. Szerintük ez nem kifizetődő. Inkább megrendelhetik a lapkát, ha igény van rá, és az AMD majd elintézi a gyártást is. A megrendelő egy kész terméket kap tokozva, tesztelve. Ha ez nem jó, akkor az ARM és az Imagination szívesen kiszolgál alternatív igényeket.
[ 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
#85552128
#24867
üzenetére
[link] - itt ki van fejtve, hogy ez már egy multi-engine mérőprogram. Ha visszaolvasol nem a külső méréssel volt a gond, hanem azzal, hogy single-engine-ek voltak a mérők.
Ez se tökéletes egyébként, mert külön profilja van például a Deus Ex és a Doom felismerésére. Tehát nem általános megoldás, de nyilván annyira eltérőek a játékok, hogy általános programot senki sem tud majd írni. Viszont játékspecifikusan legalább ez kiegészíthető, tehát mindenre lehet benne reagálni.(#24869) TTomax: Csak elmagyarázom, hogy tök felesleges bizonyos dolgokat várni. Az Intel nem fog azért fizetni, hogy egy generációnyi versenyhátrányba kerüljenek.
(#24872) Szaby59: Az OCAT eltérően működik, mint a PresentMon. Elsődlegesen azért, mert a PresentMon egy single-engine mérőprogram, míg az OCAT multi-engine. Ez különbözteti meg a két rendszert, de nagyon. A PresentMonnál is a multi-engine hiányzott a pontos méréshez, mert single-engine erejéig az is jól mért, de hát a DX12 és a Vulkan multi-engine API.
Azt állítottam, hogy single-engine mérőprogrammal multi-engine API-ban nem lehet pontosan mérni. De ezért lett az OCAT multi-engine mérőprogram, mert ez hiányzott a piacnak.Az AMD mondta el, hogy bizonyos játékok annyira speciálisan működnek, hogy specifikus mérési rutinokat igényelnek. Ilyen például a Deus Ex és a Doom. De erre is lehetőség van az OCAT-ban, és folyamatosan frissülni fog. Tehát mindig a legfrissebb verziót kell használni, és pontosan lehet mérni DX12/Vulkan alatt.
[ 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
#85552128
#24873
üzenetére
Nem igaz, hogy pontosan ugyanaz. A PresentMon egy single-engine mérőprogram, míg az OCAT multi-engine. Ez óriási különbség. Az engine-eken ettől mérhet ugyanúgy, még akár a present detektálás módja is lehet ugyanaz, vagy akár felhasználhat a PresentMon kódjából, de a lényege az OCAT-nak az, hogy nem csak egy, hanem az összes queue-t figyeli. A PresentMon addig volt jó, amíg a program single-engine módban futott, de amint multi-engine volt az alkalmazás rögtön rossz adatokat mért. Ha ez nem lenne probléma, akkor az AMD nem törődött volna egy ilyen program kidolgozásával, hiszen a PresentMon ellátta volna a feladatát. De sajnos közel sem volt teljes a működése. Erre jött az OCAT, mint az első multi-engine mérőprogram DX12/Vulkan API-ra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A flipqueue/pre-rendered frame tök egyszerűen kategorizálható.
Az NVIDIA GeForce driverben alapértelmezetten 3, de opcionálisan 1-4 között állítható.
A régi AMD Catalyst driverekben fixen 3.
Az AMD Radeon Software driverekben fixen 1. Kivéve a ReLive csomagok új Chill módját. Ha a Chill aktív, akkor ez az érték 0 a scene pacing miatt.
Ezek a beállítások addig élnek, amíg egy DirectX 11-es alkalmazás másképp nem rendelkezik. Ugyanis az alkalmazás oldalán lehet kérni azt, hogy a meghajtóba épített beállítást ne vegye figyelembe. Például a BF4 ilyen. Az új Frostbite motor már jobb, így a BF1-ben a meghajtó beállítása érvényesül. Tehát még csak motorhoz sem nagyon lehet ezt kötni. Maximum motorverzióhoz.
DirectX 12-ben a flip queue méret kiválasztása csak és kizárólag az alkalmazás feladata. Egy meghajtó nem képes felülírni. Az alkalmazás fejlesztője dönti el, hogy mi legyen a beállítás, és akár architektúránként eltérőt alkalmazhat.
Konzolokon a flip queue méret univerzálisra van szabva. A fix hardver miatt mindig 1. Ehhez kell írni a programokat.
Általánosan érdemes mindig azt az értéket használni, amit a driver alapértelmezetten felkínál, mert ehhez építették be a rendszerprogramozók az alkalmazásspecifikus optimalizálást.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De úgy volt, hogy explicit API-ban a GCN jóval jobb lesz. És nézzük csak:
Gears of War 4 (DX12) - 390X: 98 fps, GTX970: 72 fps
Doom (Vulkan) - 390X: 128 fps, GTX970: 106 fps[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Oké, 390. Elírtam. A 390X amiről eredetileg szó volt ezekben a vitákban még jobban elhúzna.
Itt mindig azokkal a játékokkal nem játszanak, ahol a GCN sokkal jobban megy, lásd Doom és GoW4.
[ 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
FLATRONW
#24964
üzenetére
Tök egyszerű a helyzet. Kétféle DX12 alkalmazás van. Ahol az MS ajánlásait vették figyelembe és ahol az NV-ét. A RotTR-nél az NV-ét, és emiatt ott lassul az egész DX12 is a DX11-hez képest. Minden más játékban az MS ajánlásai domináltak, amitől az NV bekap egy 7-9%-os deficitet.
Ez az egész egy többszintű probléma. Egyrészt az NV-nek a DX12 meghajtója a bekötési modell miatt nagyobb többletterhelést generál, míg az AMD-nek a bekötés ingyenes. Másrészt ha nem kötvetlenül a root signature-be van kötve egy buffer view, akkor az NV-nél csökken a pixel shader teljesítmény. Harmadrészt pedig az NV-nek a hardverébe vannak különböző fast path-ok építve, hogy bizonyos sűrűn használt funkciókkal gyors legyen. Ezek azonban DX12/Vulkan alatt nem használhatók, tehát az általános path-on keresztül működik az egész, ami lassú. Ezek kombinált hatása okozza azt, hogy a GCN DX12/Vulkan alatt elhúz a DX12/Vulkan játékok 99%-ában. Az NV hardvere túl specifikusan van tervezve, hogy általános környezetben is gyors legyen. Ezzel szemben az AMD hardvere arra van tervezve, hogy általános környezetben működjön, és nincsenek is benne specifikus fast path-ok. Lényegében az NV tervezett a hardvereibe egy rakás speciális funkciót a DX11-hez, amelyektől a DX12 és a Vulkan elvágja őket.
Ez egyébként nem pont az API hibája, hanem sokkal inkább a Microsoft és a Khronos szabta olyanra a specifikációkat, hogy a hardvergyártók trükközését kivágják. Nem az NV-nek akartak persze ezzel rosszat, hanem csak közelebb akarták vinni egymáshoz az eltérő cégek által fejlesztett hardverek működését. Ilyen formában az NV kénytelen az AMD-nek az általánosan kigyúrt hardveres modelljét követni, mert hiába építenek fast path-ot a hardverekbe, azokat nem tudják majd használni.[ 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
TTomax
#24976
üzenetére
Sokszor több GPU-val sincs annyi fps-ed OpenGL-ben, mint egy GPU-val Vulkan alatt. És akkor ne feledjük az OpenGL-ben az AFR kötelezően tripla pufferes késleltetését, ami szembe van állítva a Doom Vulkan leképező speciális front bufferes aszinkron compute modelljével. Nincs különösebb indok a Vulkan leképező használata ellen. Főleg akkor, ha alacsony késleltetés kell, ebben meg nem közelíti az OpenGL. Még egy GPU-s back buffer modell mellett sem.
[ 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
TTomax
#24979
üzenetére
Igazából nem az OpenGL-lel van a gond, hanem maga a motor nem barátja az AFR-nek. Virtuális textúrázás mellett nem is csodálom.
[link] - nézd meg a gyorsulást.
A Radeon Pro Duo egy VR kártya. Az elején is az volt. Ez a professzionális piacra megy a tartalomkészítőknek.
Az OpenGL-t az ID nagyon jól használja. Azért ez az API került bele a Doomba, mert a DX11-es portjuk lassabb volt. Mert van DX11-es portja az ID tech 6-nak. De a Vulkan volt a fő irány, mert az mindkettőnél gyorsabb.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#24985
üzenetére
Jó oka van arra, hogy korlátozza a grafikát. A virtuális textúrázáshoz ugyanis ki kell kódolni a mozaikokat, amely időt vesz igénybe a grafikus vezérlőn. Ezért biztosítani kell hogy kellő mozaik legyen használat alatt, amíg a kikódolás megtörténik. Ha ezt nem teszik meg, akkor olyan lesz az egész, mint a Rage, sok pop-up hülyeséggel.
A grafikai beállítások korlátozása egyébként nem csak pont a VRAM függvénye, hanem részben a számítási teljesítményé is, illetve a kikódolás számításának hatékonyságáé. [link] - itt erről beszélnek, hogy mennyivel másképp tölt be a beállított részletességre a virtuális textúra az egyes kártyákon.[ 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
TTomax
#24990
üzenetére
Mint írtam nem a VRAM mennyisége az egyetlen paraméter. A textúra mozaikok kikódolása GPU compute, és ebben a GCN-ek háromszor is hatékonyabbak. Effektíve tehát egy textúra mozaikot egységnyi FLOPS-ból háromszor gyorsabban számol a GCN. Emiatt van az, hogy a Radeonon szinte nincs is pop-up, míg a GeForce-on meg van. Egyszerűen mindig kész van időre a számítás. Persze ez Vulkan alatt van így, OpenGL-ben más problémák miatt jóval limitáltabb az egész működés, például nincs aszinkron compute, ami ennél a motornál nagyon számít. Elvégre aszinkron compute mellett a mozaikok kikódolása párhuzamosan történhet, míg aszinkron compute nélkül ez csak sorosan lehetséges.
Device ID alapján paraméterez a játék. A Vendor ID ide nem elég.
[ 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
TTomax
#24993
üzenetére
Ez sokkal bonyolultabb. A Vulkannak vannak ebben a játékban igen specifikus követelményei is.
Például AMD-n a Doom olyan memóriaallokációt használ, hogy elég legyen 2 GB VRAM is. Tehát AMD-n a VRAM igény Vulkan API-ra minimum 2 GB.
Ezzel szemben az NV-re már nem elég 2 GB VRAM, mert eltérő az allokációs stratégia. 2 GB-tal egy GeForce-on visszautasítja a Doom, hogy elinduljon. Függetlenül attól, hogy AMD-nél elég a 2 GB is. NV-nél már 3 GB kell minimum.
Az ajánlott az AMD-nél 4 GB, míg az NV-nél 6 GB. De ha mindent be akarsz kapcsolni, tehát nem akarsz automatikus mesterséges korlátozást, akkor Vulkan alatt az AMD-nél 8 GB kell, míg az NV-nél 12 GB.
Ezen lehetne egyébként még optimalizálni, mert aki csinálta a Vulkan kódot gyakorlatilag elismerte, hogy az NV-re nem nagyon tudott optimalizálni, tehát le tudná szorítani az NV-nek a VRAM igényét az AMD szintjére, csak erre a játékra már nem költenek, ergo marad így. De az ID tech 6 új verziójára épülő játékokban nyilván az NV-nek a memóriaproblémája is meg lesz oldva, lévén ez teljes egészében egy ID tech 6-on belül keletkező gond. Az NVIDIA egyébként erre a problémára hozott egy NV_dedicated_allocation Vulkan kiterjesztést, amivel jobban lehet bánni a VRAM allokációval, így a GeForce-okhoz is jobban lehet igazodni. Ezt majd a Vulkanra fejlesztő rétegnek érdemes lesz használni, mert a GeForce a full szabványos allokációval nincs mindig kibékülve, túl sokat szemetel valamiért.
[ 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
keIdor
#25005
üzenetére
Esetleg értelmezzétek is, hogy mi van oda írva. A grafikát a Doom alatt nem ti állítjátok be. A motor bármikor felülbírálhatja a textúrarészletességet. Ha mindig maximális részletességű textúrabetöltést akartok Vulkan alatt, akkor AMD-n 8 GB, míg NV-n 12 GB VRAM kell. Ha ez nincs meg, akkor a mozaikok egy része nem lesz maximális minőségűre kikódolva, illetve lassan töltődhetnek be.
A jövőben ez teljesen általános lesz. Egyszerűen a textúrarészletesség annyit jelent, hogy ha van elég memória és elég számítási kapacitás a virtuális textúrarészletességet kikódolni, akkor betöltheti a maximum részletességet. Ha nincs, hát akkor nem tölti be. Nem fogja megkérdezni futtatás közben, hogy neked jó lesz-e a fal textúrája egy szinttel alacsonyabb minőséggel. Észre sem fogod venni a különbséget.
Az NV-n sincs igazából semmi gond. Nem hardveres hibáról van szó, hanem egy szoftveres problémáról. Ahhoz, hogy az NV-n is jobb legyen az allokáció hatásfoka szükség van az NV_dedicated_allocation kiterjesztés használatára. Ezt már használja az ID tech 6, csak a Doom Vulkan leképezőjébe nem portolták vissza, és valószínűleg nem is fogják már. Elsődlegesen nem az extra memóriahasználat az aktuális verzióval a gond, hanem az, hogy NV-n 3 GB a minimum VRAM igény, míg AMD-n elég 2 GB is. Valójában nem használ több hasznos adatot a Doom NV-n, csak valamiért sokkal töredezettebb lesz a memória a futtatás során (és ez nem csak kevés VRAM-nál számít, hanem soknál is, tehát a töredezettségből eredő hátrány megmarad 8-10-12 GB-on is). Ezt a töredezettséget lehet kezelni az NV_dedicated_allocation kiterjesztéssel. Elképzelhető, sőt, kifejezetten valószínű, hogy ezen lehetne mit reszelni a Vulkan driver oldalán is, de ahhoz nagyon mélyre kellene menni, így az NV jobbnak látta ezt a kiterjesztést, mivel ha dolgoznak is rajta, az hónapokat fog igénybe venni, addig pedig 10 Vulkan játék is jöhet ugyanazzal a problémával, ami a Doomban felütötte a fejét. Szóval a kiterjesztés inkább egy gyorsfix.
Persze az egészben nagy szerepet játszik az is, hogy az ID-nek ez az első Vulkan projektje, tehát nem veti még szét őket a tapasztalat sem. De mondjuk az NV-t sem az explicit UMD-k tekintetében, tehát az egész még nagyon tanulási szakaszban van. Az AMD-nél sem dolgoznak okosabb programozók, csak az ottani emberek két évvel korábban tesztelhették ezt az irányt, mint az NV programozói. Ez azért számít. Pusztán az időelőny miatt sokkal jobban átlátják ma, hogy milyen rutinok működnek, és melyek tűnnek jó iránynak, de valójában zsákutcák. Utóbbit is csak azért tudják eldönteni, mert két év alatt kipróbálhattak pár zsákutcát, míg mondjuk az NV élesben fut bele ezekbe, amiből nem lehet gyorsan kijönni és jöhetnek a gyorsfixek kiterjesztésekkel. Ha mondjuk az AMD-nek nem lett volna Mantle, akkor most ők is belefutnának ezekbe a problémákba, mert hiányozna a tapasztalat. Talán ugyanolyan gyorsfixekkel dolgoznának ők is a problémás UMD réteg javításáig.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Félig. Abban a videóban az látszik, hogy a kikódolás lassú GeForce-on. De ez például attól is lehet, hogy a teljes részletességre történik a kikódolás, ami nyilván lassabban van meg, mint az alacsonyabb részletességnél. Természetesen amellett, hogy a motor igyekszik jól dönteni nem mindig dönt jól. Nagyon komplex a virtuális textúrázás az ID tech 6-ban, és ez okozhat kellemetlenségeket.
[ 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
TTomax
#25012
üzenetére
Azzal nincs gond, ha a textúra részletessége nem egyezik meg a tesztek között. Ez csak a VRAM-ra vonatkozóan terhelés, valójában az elvégzendő számítás ultra low és ultra high textúrák mellett is pontosan ugyanannyi.
Ma már nagyon sok játékban a motor "intelligens" streaming konstrukció. GoW 4, Dishonored 2, Shadow Warrior 2, Titanfall 2, Just Cause 3. Ezeknél hiába állítod be a textúrarészletességet a motor azt bármikor felülbírálhatja, ha nincs elég VRAM. És nem fog megkérdezni róla.[ 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
FLATRONW
#25014
üzenetére
Mint írtam a számítás mennyisége megegyezik. Ugyanaz lenne az eredmény, ha megegyezne a textúrák részletessége. Ezekkel a modern stream rendszerekkel nem lehet mit kezdeni. Így működnek és kész. Még mindig jobb ez, mintha azt mondaná a játék, hogy közepes fölé nem helyezheted a textúrarészletességet.
Nem tudom a VRAM mennyiségét. Tőle kell megkérdezni.
(#25015) V!ck: Persze. A 2 GB ahhoz kell, hogy elinduljon a játék, és fusson valamennyire. De hogy élvezni is fogod, az nem biztos. 4 GB-tól már jó. Egyébként nem tipikus VRAM-para ez, hanem folyamatosan kikódolást kér a rendszer, és ez elveszi az erőforrást a többi grafikai számítástó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
Zeratul
#25086
üzenetére
Az a kisebb probléma. Van még kettő nagyobb:
Egyrészt az adatokat nem felhasználószinten, hanem gépszinten összegzi, vagyis ha cseréltél gépet vagy valamit a gépben, akkor egy évig megőrzi az előző adatokat is, és csak akkor törli, ha nem jelentkeztél be egy évig a régi konfiggal. Ez azért lényeges, mert ha mondjuk eladtad a VGA-d a használt piacon egy másik Steam felhasználónak, aki bejelentkezik és elküldi az adatokat, akkor az adott VGA kétszer van benne a kimutatásban legalább egy évig.
Másrészt csak az első grafikus vezérlőig érzékeli a kimutatást, tehát ha van egy aktív IGP-d, akkor azzal kerülsz be.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
Puma K
#25103
üzenetére
A Valve alapvetően anonim módon bánik az adataiddal, amelyeket felhasználnak markegingre, illetve megosztanak bizonyos partnereikkel. A Steam HWSurvey az egyetlen olyan pont, ahol az adataid mellé valós felhasználót rendelnek, és emiatt is kérdez rá, hogy részt akarsz-e venni a felmérésben, mert onnantól kezdve már nem leszel anonim. Én pedig nem nagyon szeretném, hogy az immáron felhasználóhoz kötött adataimmal harmadik fél dolgozzon. Ez egyszerűen túlmegy azon a ponton, amit elfogadok. Tanultam, hogy mennyire vissza lehet élni ezekkel. Önmagában az nem zavar, hogy a Valve tudja, de hogy egy harmadik fél, az nem fér bele.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#25155
Abu85
HÁZIGAZDA
FollowTheORI
#25152
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#25152
üzenetére
Azért FreeSync a neve, mert bele kell tervezni a FreeSync-et is a monitorba, hogy egyáltalán hitelesítsék FreeSync 2-re. Emiatt minden FreeSync 2-es HDR kijelző egyben sima FreeSync megoldás is. Ez részben üzleti döntés, mert a FreeSync annyira ismert lett a Samsung és az LG reklámok miatt, hogy tulajdonképpen szinte elkerülhetetlen már, hogy a konkurensek amikor rá/áttérnek a szabvány támogatására, ne fizessenek licencet az AMD-nek a névhasználatért. Másrészt nagyon kedvező, ha az összes FreeSync 2-es HDR kijelzőből kizárják a többi VRR eljárást. A monitorgyártók gyakorlata itt kedvező az AMD-nek. Ők minden buzzwordre ugranak, hogy a HDR kijelzőjük ne HDR-ként legyen reklámozva, hanem FreeSync 2-ként. Ez nekik egy extra technológia(tm) a dobozra és a marketinganyagba a simán HDR-rel reklámozó konkurensekhez képest.
[ 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
cyberkind
#25189
üzenetére
A Voltát nem tolták el. Eleve a Vega a Volta ellen készül, és nem a Pascal ellen. Nem véletlen a Poor Volta felirat a reklámban. A Pascal közel sem rendelkezik olyan képességekkel, hogy támogatni tudja azt, amit a Vega támogat. Az a Volta lesz, ami hasonló tudásszintet biztosít az új DirectX és Vulkan verzió mellé.
A fő cél most mindenkinek az, hogy hardveresen tudják támogatni az összes shader model 6.0-s függvényt. Ezt ma csak a GCN3/4 tudja megcsinálni, de a Vega és a Volta is tudni fogja, sőt lesz ugye programozható blending, ami ugye a következő áttörés. Kicsit visszatér majd a régi shader modeles szívás, hogy ha nincs meg a legnagyobb shader model szinted, akkor nem lesz minden effekt aktív. De ezen túl kell esni sajnos.
[ 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
cyberkind
#25193
üzenetére
A Volta az mindig 2017-re volt tervezve GPGPU szinten és 2017-2018-ra VGA szinten.
Eddig is konvertálással készültek a portok. A gond eleve az, hogy a konvertálás által a konzolos funkciók nem érhetők el, emiatt jóval lassabb eljárással kell helyettesíteni azokat. A shader model 6.0 azért jön, hogy ami a konzolon egy utasítás az a PC-n is egy utasítás legyen, és erre legyen a nyelvben egy függvény. Az egyetlen dolga innentől az iparnak, hogy a függvényekhez direkt utasításokat rendeljen a hardver oldalán. Persze a függvény emulálható is, és nagyon sok aktuális hardver így futtatja majd a shader model 6.0 újításait. Ma egyedül a GCN3/4 architektúráknak van minden függvényhez direkt utasításuk, de a Vega, Volta, stb. már felkészül ezekre.
[ 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
imi123
#25197
üzenetére
A Star Wars Battlefront Rogue One: Scarif DLC miatt. Az EA-nek most van egy szerződése, hogy az AMD az új hardvereit egy Star Wars játékkal reklámozza. Ez azért lényeges, mert az EA az összes érkező Star Wars játékot AMD-re optimalizálja, és AMD-s funkciókat építenek beléjük. A BF1-nek a Polarishez van reklámszerződése.
[ 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
#85552128
#25203
üzenetére
Nem számít, hogy mit futtatnak rajta, hiszen az egész egy publikus demó volt. Oda lehetett menni és azt futtattál rajta, amit akartál, de a játékon belül kellett maradni. A lényeg a Star Wars reklám.
[ 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
Ren Hoek
#25201
üzenetére
Most is kihasználják a fejlesztők az AGS4-et, sőt van már AGS5 is. Tehát a Volta érkezése itt lényegtelen. A funkció elérhetősége a lényeges. A szabvány csupán annyit segít, hogy ha arra van leportolva a funkció, akkor amint megérkezik a Volta az is tudja futtatni a gyorsabb kódutat. Nyilván ez egy lényeges szempont a fejlesztő oldalán. Az AGS itt csak egy menekülőút addig, amíg nincs szabványos megoldás.
(#25207) Szaby59: Mert konzolba pötyögni tilos. Játszani lehet, ott van a gép mellett egy ember, aki figyel, hogy ne csinálj olyat, amit nem szabad.
[ 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
Ren Hoek
#25213
üzenetére
A Deus Ex: MD-benben +10-15%-ot jelent. A méréseket pedig láthatod: [link] - egyébként, ha levonod a 10-15%-ot, akkor nagyjából a normál DX12-es helyükre kerülnek a Radeonok.
A BF1-ben kevésbé van használva az AGS4, így ott inkább 6-7% körül nyernek. A többi játékban (Doom, Hitman) is finomabb a felhasználási forma.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Hányszor írtam a GeForce GTX 1080 Ti-ről manapság? Bármit? Egy böffentést? Ha jön valami, mindig hintelek valamit, csak egy apró mosolygást. A 1080 TI-nek még nem adtam életjelét.
![;]](//cdn.rios.hu/dl/s/v1.gif)
[ 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
keIdor
#25372
üzenetére
Sokat pletykálnak manapság.
De érdemes nézni, hogy az 1080 Ti-ről én nem beszéltem hetek óta. Ha lett volna reaális esélye, hogy megérkezik a CES-en valahol elejtek valami hintet.Pascal 2.0-ról sem halottam sosem.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#25463
Abu85
HÁZIGAZDA
->Raizen<-
#25459
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#25459
üzenetére
Mindig ezt mondtam. A shader model 6.0 minimum igénye a feature_level_12_0. Ez nem változott. Tehát AMD GCN2/3/4, NVIDIA Maxwellv2/Pascal, Intel Gen9/en9.5.
Az intrinsics függvények esetében igazából mindegyik függvény megoldható ezeket a hardvereken, csak az egyes függvények az egyes hardverekre nem mapelhetők rá hatékonyan. Ez azért van, mert a Microsoft az egész rendszert a GCN-re alakította ki. Annyit tudni jelenleg, hogy a mostani felhozatalból a GCN3/4 támogat minden függvényt hardveresen.
Igazából a shader model 6.0 intrinsics függvényei az AMD-t eleve kevésbé érintik, mert ők már kínálnak AGS4/5-öt, amelyekben a függvények többsége megtalálható. Ezt már ki is használja pár játék (Doom, új Deus Ex, új Hitman, Battlefield 1). A Microsoft azért hozza a szabványos rendszert, hogy a fejlesztők ne a csak az AMD-nek segítő AGS-en keresztül műtsék be ezeket a játékaikba, hanem szabványból, így ha majd az Intel és az NV is előáll a függvények hardveres támogatásával, akkor ők is nyerhetnek belőle.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#25466
Abu85
HÁZIGAZDA
->Raizen<-
#25465
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#25465
üzenetére
A shader model 6.0, ezen belül is az intrinsics függvények eleve nem a lassulásról szól. Attól, hogy most nincsenek szabványban ilyen lehetőségek PC-n átmentik a konzolos kódokat, csak a nyilván PC-n nem egy utasítás lesz mondjuk egy préselés, hanem írni kell rá egy algoritmust. Az intrinsics függvények azt akarják, hogy legyen PC-n is egy-két utasítás. Nyilván amelyik hardverben nincs rá hardveres támogatás, az továbbra is megoldja csak emulációval, ami nagyjából megfelel a mostani formának.
[link] - ebben a tesztben látható már, hogy mit ér az intrinsics, ha jól használják. A Radeonokon rajta van, míg a GeForce-okon nincs, kvázi emulálnak. Ergo semmi nem fog belassulni, egyszerűen csak azok a hardverek húznak el, amelyeknek nem kell "emulálni".[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#25486
Abu85
HÁZIGAZDA
#Morcosmedve
#25484
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#25484
üzenetére
Nem olyan véletlen az. Az AMD megmutatta a nem partner alaplapgyártóknak is, hogy mit tud a Ryzen. Azóta mindenki érdeklődik. Az EVGA is köztük van. De hogy ebből a médiában miképp lett Radeon+EVGA házasság...
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#02119936
#25487
üzenetére
A gyártók árengedményt adnak az exkluzivitásért. Az AMD és az NV is így csinálja. Ezért nem éri meg a már kialakított exkluzív kapcsolatokat feladni. Például emiatt váltott az XFX az NV-ről AMD-re, és nem csinálták úgy, hogy mindkettő céget kiszolgálják párhuzamosan.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Puma K
#25638
üzenetére
A pályaméretnek nincs különösebb jelentősége az erőforrás-igényre nézve. Manapság a legtöbb esetben nem is a motor korlátozza azt, hanem a tartalomtervezésbe rakott erőforrás.
A Hitman erőforrás-igénye leginkább azért nagyobb a GTA5-nél, mert egy jelenet nagyjából tízszer komplexebb. Jóval több háromszögből áll az egységnyi területre levetített térkép, jóval több a szimuláció rajta, jóval komplexebb már maga a leképező. Az így megugró számításigény pedig nyilván növeli a gépigényt. Speciálisan kiemelve az új Hitman az élmezőnyben van a poligonszám tekintetében, egyedül a Deus Ex Mankind Divided dolgozik több poligonnal a jelenetekre levetítve. Tehát a Hitman esetében igazából a háromszög-feldolgozás gyilkolja a GPU-kat, ideértve minden háromszögekkel kapcsolatos munkát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Aszinkron compute a játékokban: [link]
Az aszinkron compute előnye változó. +7-10%-ot hoz átlagosan a GCN2/3/4-en. Valahol többet is, de a feldolgozás formájától függ. GCN1-en +2-5%-ot hoz, ha aktív. Maxwellv2-n szinte semmit. Pascalon +2-5%-ot.
Az Unreal Engine 4.14-től aktiválható az UE4 játékokra is az aszinkron compute, de csak GCN-re aktiválja a motor.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#25673
Abu85
HÁZIGAZDA
SpongyaBob
#25671
Abu85
HÁZIGAZDA
válasz
SpongyaBob
#25671
üzenetére
Ebbe ne menjünk bele. Elég ha a moderátorok kezelik az újrareges kérdést, amellett persze, hogy nyilván ami feltűnő az feltűnő, és más sem hülye itt. Viszont mindenki kaphat még esélyt. Ha pedig nem él vele, akkor ugyanaz lesz a vége, mint először, vagy esetenként az azelőtti regisztrációval.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez megközelítőleg sem ilyen egyszerű. A szintetikus programok azért nagyon megtévesztők, mert egy heterogén processzor (ugyanis a GPU ilyen) egy apró elemét terheli a limitig. Egy játék azonban teljesen más, számos elemet terhel egymás mellett, és egyrészt ez máshova helyezi a belső limiteket, másrészt annyira eltérő egy mai játék működése egy szintetikus programtól, hogy teljesen mindegy mit mutatnak ezek.
Annak is oka van, hogy a Hitman és főleg a Deus Ex Mankind Divided miért dolgozik sok háromszöggel, jelenetszinten akár 220 millióval. A Square Enix használja az új Glacier 2-ben és az ebből kifejlesztett Dawn motorban egy úgynevezett CTF modult. Ez a compute-based triangle filtering, vagyis egy olyan kivágási rendszer, amely miatt igen szabadon lehet bánni a háromszögek adagolásával, mivel a hardveren futni fog végül egy olyan program, amely a nem látható háromszögek nagy részét úgyis kivágja, és teszi ezt a korábbi opcióknál sokkal-sokkal hatékonyabban. Ezek persze jórészt befutnak a GPU-ba, de a feldolgozás különböző szakaszain jól meg lesz ritkítva a pipeline tőlük. Ezért nagyon fontos megkülönböztetni a szintetikus tesztet a játéktól, mert a szintetikus teszt egy ilyen modult úgy sem fog alkalmazni, hiszen pont a teszt lényegét vágná ki, mivel ettől jól futna a program a hardvereken, és nem ütköznének bele a vizsgálni kívánt limitbe. Egy sok háromszöggel dolgozó játék viszont ilyen CTF modul nélkül nem fog elkészülni, mert nem futna jól a hardvereken. Ergo teljesen mindegy, hogy a GeForce klasszikus kivágás nélküli, vagy szimpla CPU-s feldolgozás mellett jól viseli a terhelést, ha a sok háromszöggel dolgozó játékokban GPU-s kivágásos feldolgozással fog találkozni, és abban már a Radeon a gyorsabb. Arról nem is beszélve, hogy a kivágás lépcsői között az egyes hardverek más kódot kaphatnak. A Hitman és a Deus Ex Mankind Divided a CTF modult más kóddal futtatja Radeonon és más kóddal az összes többi GPU-n. Például a GCN-re a fejlesztők használnak ballot/mbcnt/read lane-t, míg a többi hardveren ezeket igen drága algoritmusok helyettesítik a direkt utasítások hiányában.
Amiről pedig te írsz, hogy "compute vs. poligon"... Ezek ma már nagyon is egybefüggő dolgok egy modern motorban. A CTF modulok ugyanis per háromszög szintű shaderek, vagyis minél több háromszög lesz egy játékban annál nagyobb előnye lesz az AMD-nek benne, hiszen a CTF minden még élő háromszögre lefuttatja a különböző fázisait. Effektíve a háromszögek számának növelése egy modern játékban leginkább a compute teljesítményt szívja le manapság. Így működik egyébként a legújabb Frostbite is, csak ott nem lőtték még el a terhelést 200+ millió háromszög per jelenetig, de idővel ők is megteszik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Csak nem érdemes a játékokra levetíteni őket, mert nagyon másképp működnek a modern motorok.
Az Umbra csak egy occlusion culling megoldás. Ez, illetve a view-frustum culling még mindig a CPU dolga, bár vannak kísérletek arra, hogy áttegyük őket a GPU-ra. Az occlusion cullingra van az Intelnek egy GPU-s megoldása, de az egyelőre TIER_3-as conservative rastert követel, tehát csak a Gen9 hardvereken futna. Mindenesetre az ígéretes. Ugyanakkor közel sem vágnak ki ezek minden háromszöget, emiatt további technikákat kell bevetni. Ezek a technikák a GPU-driven pipeline motorokkal kifejezetten hatékonyak, ezért építi be őket egy csomó stúdió. A technikák gyűjtőneve a CTF. Persze van aki ezt másképp hívja, az AMD például GeometryFX-nek. Az egész arról szól, hogy radikálisan nőjön a raszterizáció hatásfoka sok háromszög mellett.
[ 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
Venyera7
#25796
üzenetére
A shader model 6-os szabványos megoldást kérdezed, vagy az AMD-féle zárt opciót? Előbbi valószínű, hogy lesz, illetve a SPIR-V is ki fog egészülni idén egyre több szabványos beépített függvénnyel. Nyilván hosszabb távon ezeket érdemes használni, tehát amint megérkeznek, áttérnek rá a fejlesztők. Már csak a szabványosság miatt is.
Az AMD-féle megoldás addig általános lesz, hiszen az Xbox One-hoz meg van írva a shader. Ahhoz minimális módosítás kell, hogy PC-n is működjön a GCN-en. Az érkező játékok közül a Resident Evil 7: Biohazard, a Sniper Elite 4, Styx: Shards of Darkness és a Mass Effect Andromeda használja. Utóbbi ugyanazt fogja bevetni belőle, amit a Battlefield 1, míg az előbbi három esetében kérdéses, hogy milyen függvényekhez nyúlnak.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#25800
üzenetére
A Frostbite Team mostanában elég gyorsan frissít, így a legújabb motorverziókat egyre hamarabb megkapják a házon belüli stúdiók. Ezzel a teljes EA részleg megörököl egy rakás shadert, ezen belül a csak GCN-hez írt kódokat is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#25801
üzenetére
Nem értem, hogy a GPU-k miért lennének veszélyeztetve attól, hogy a shader model 6 megadja a gyorsabb kódok futtatásának lehetőséget. Az a veszélyes, ha erre csak a GCN-nek van lehetősége.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nincs gond egyik teszttel sem, csak a Guru3D referenciaórajelekkel teszttel, míg a PCGH agyontuningolt VGA-kkal. Ez óriási különbség.
Az RE7 esetében fontos tényező a shadow cache is, ami egy konzolról áthozott funkció, és ez jobban tetszik a GCN-nek. Emellett a GCN-ek sokkal gyorsabb shadereket futtatnak, mint az összes többi hardver. Az RE Engine a shader intrinsics-re nagyon épít az Xbox One-on, és ha már volt kész kód áthozták PC-re is. Egyelőre csak AMD-re, de később a shader model 6-tal támogatni tudnak más GPU-kat is.[ 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
#85552128
#25858
üzenetére
Nincs. A shadow cache-ből egyértelműen egy GCN2 tud profitálni a legtöbbet. Erre van a leginkább optimalizálva a konzolról áthozott kód.
Azok rendesen meg vannak tuningolva, a hibaarányuk is igen nagy a túl nagy húzás miatt. Elhiszem, hogy e-pénisz, de aligha érik meg a pénzüket.
Az a baj, hogy egy bonyolult dolgot próbálsz elképesztően egyszerűen értelmezni. A GPU-kban annyi teljesítmény van, amennyit kihoznak belőlük az optimalizálással.
[ 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
keIdor
#25823
üzenetére
A GoW 4 motorja már csak a nevében hasonlít az UE4-hez. Valójában kegyetlenül átírta már a Microsoft. A GoW 4-re egy teljesen új leképezőt írtak hozzá, vagyis az UE4-gyel érkező leképezőhöz köze nincs, amit a Microsoft stúdiói kapnak. Eredetileg arról volt szó, hogy a Microsoft visszaírja a saját leképezőjét az UE4-be, de ez eddig nem történt meg, illetve az Epic számára sem kritikus a gyors PC-s leképező. Az ARK egyébként élvezi a Microsoft támogatását, de a Microsoft leképezőjét csak az Xbox One-on használják csak. A PC-re egy 2015-ös verziót alkalmaznak, aminél már az UE4 aktuális leképezője is nagyságrendekkel gyorsabb, de nagyon drága lenne átállni arra a verzióra, miközben a konzolos leképező fejlesztése zajlik, és oda megy az erőforrás. A PC-s leképező majd akkor lesz leváltva az Xbox One-ra használt leképezővel, amikor a konzolon működni fog a rendszer. Utána majd kikerül a játék az Early Accessből, de ez még hónapokra van. A PC-s kód addig ugyanaz a másfél éve ráhagyott szarkupac lesz, és ehhez nem véletlenül nem nyúlnak, egyszerűen ki lesz dobva a fenébe, amint a konzolra portolás kész lesz. Azért várnak ezzel annyit, mert a Microsoft leképezője, amit az ARK tervez használni D3D12 only leképező, tehát amint leváltják a mostani motorverziót nem fog működni tovább a játék Windows 10-nél korábbi OS-eken. Ez persze annyira nem gond, mert a tényleges megjelenés jelenleg inkább 2018-ban valószínű, tehát akkorra már elfogadható lesz a Windows 10, mint minimum igény.
Az UE4-nek az új leképezőjét is használhatnák, de azzal meg az a baj, hogy már egyik opció sem támogatja a multi-GPU-t. Ezt a módot a 4.10-es verzió óta teljesen kivették. Egyedül a D3D12-es verzióban van egy olyan mód, amivel egy IGP és egy GPU összekapcsolható, de ezt is ki fogják venni a jövőben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#25967
Abu85
HÁZIGAZDA
huskydog17
#25962
Abu85
HÁZIGAZDA
válasz
huskydog17
#25962
üzenetére
Egyszerűen csak nincs kész. A LOD menedzsment és a memóriamenedzsment még mindig eléggé bugyuta, de ez az elmúlt években alig változott.
A LOD menedzsmentet egyébként minimum nem ártana rendbe hozni, mert arra nem lesz hardveres gyógyír a jövőben sem.Egyébként az ARK leképezője konzolon és PC-n lényegesen más. A konzolon klaszteres megoldás, amit a Microsofttól kaptak, míg a PC-n egy klasszikus régimódi deferred render van. Ez leginkább a kezdeti UE4-ből megmaradt leképező, de haszna az nem sok, mivel az Epic is kidobta már.
Azt fontosnak tartom, hogy vegyük figyelembe, hogy ez még mindig Early Access, leginkább egy pre-alpha. Leghamarabb 2018-ban lesz kész, de szerintem inkább 2019ben kerül ki az Early Access-ből. Addig nem tisztességes baszogatni őket, mert ki van írva a Steamre, hogy a játék nem végleges, és úgy vegyétek meg.
[ 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
#85552128
#25976
üzenetére
A QB-ben a DX12 módban van kihasználva. De a DX11-es mód nem tartalmaz aszinkron compute-ot. Emellett a DX11 mód sokkal kevesebbet számol a problémás működése miatt. [link] - Ezért nem túl szerencsés az API-kat keverni, mert nem ugyanaz a minőség, amit előállítanak a hardverek. Sőt, a QB esetében csak a DX12-ben van egységes minőségi szint, a DX11-ben a beállításoktól függetlenül más lesz az egyes hardvereken a minőség. Ez egészen kellemetlen programmá teszi a DX11-es verziót.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Ráadásul az adatgyűjtés nem anonim, mert hozzákötik a profilomhoz. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen