Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
#85552128
#11647
üzenetére
A teljesítménye teljesen stabil. Az meg logikus, hogy egészen másképp látja a megbízhatóságot egy OEM gyártó, ahol heti szinten sokezer kártya átmegy, mint te, ahol éves szinten nem egy át összesen tíz. Egészen mások lesznek a preferenciák. Arányaiban az eddigi tapasztalatok alapján a referencia R9 290 a legmegbízhatóbb termék a Hawaii sorozatból, és nincs ok feltételezni, hogy egy új steppingre épülő lapka ugyanazzal a NYÁK-kal nem lesz ugyanolyan megbízható. Innen a választás logikus, az kell, ami eddig bevált, megbízható, és ma is gépek épülnek rá.
(#11649) rocket: 50k teljesen reális az XFX-nek, amit előirányoztak a telekonfon. Ne feled, hogy az OEM-eket igazából a TUL szolgálja ki, és ők még szállítanak 290 OEM-et. Amint azok elfogynak valószínűleg ők is átállnak a 390-re, ugyanarra, amit az XFX kap.
Az OEM-eket elsődlegesen a megbízhatóság érdekli. Mivel ezek a hardverek már dinamikus órajelvezérléssel reagálnak a túlmelegedésre, így nem probléma az sem, ha a ház hőelvezetése nem jól méretezett, viszont az probléma, ha az adott termék meghibásodási arány 2% feletti.Az XFX ugyanolyan helyzetben volt, mint a BFG, ha nem váltanak, akkor az AMD felveszi a BFG-t és az XFX megy tönkre. Az XFX lépet hamarabb, így a BFG ment tönkre.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#11644
üzenetére
Az a baj, hogy abszolút nem veszitek figyelembe, hogy egy OEM gyártó mit szeretne. Ők megbízhatóságot akarnak, és magasan a referenciamodellek a legmegbízhatóbb termékek a teljes piacon. Ráadásul ezeket jórészt úgy tervezik, hogy blower dizájnok legyenek, vagyis kifelé tereljék a hőt, ami szintén egy alapvető OEM igény. Sokkal hamarabb választ egy ilyen referencia Radeont az OEM, mint egy egyedi verziót, mert szimplán jóval jobban illik azokba a konfigurációikba, amelyeket régen erre terveztek. Ha ezekbe beleraknak egy szimpla verziót, akkor a meleg bent marad és elkezd a rendszer túlmelegedni.
Az XFX felismerte, hogy lenne jó havi 50k-s igény ezekre a 390-ekre a 290-es OEM modellek kivégzése után. Hát beleugrottak. Persze hivatalosan ez nem referencia, de gyakorlatilag a referenciát másolták le teljesen. Egy OEM jóval hamarabb rendel ilyet, mint bármilyen más verziót, mert ilyet használtak eddig is, így legalább nem kell áttervezni a konfigokat. -
Abu85
HÁZIGAZDA
válasz
#85552128
#11640
üzenetére
Ez nem igazán az XFX egyéni döntése, pusztán a piac akarata. Az OEM-ek a blower dizájnt nagyon keresik, mert kitolja a meleget a házból. Mivel az AMD OEM szintre nem csinált referencia R9 390 sorozatot, így az XFX most lefedi ezeket az igényeket. A dizájn megtartása is azt célozza, hogy gyártóknak ne kelljen új házkialakítást tervezni, mert a blower helye is pont ugyanott van. Az XFX-nek ez elég jó üzlet, hiszen havi szinten legalább 50k ilyen kártyát leszállítanak majd, főleg most az ünnepek miatt. A maradékot pedig eladják dobozban.
-
Abu85
HÁZIGAZDA
válasz
rocket
#11623
üzenetére
Ha a HairWorksre gondolsz, akkor az már csak 32x-es tesszellálást használ. Egy patchben visszavették, mert nem jó 10% alá csökkenteni a GPU-k raszterizációs hatékonyságát. Ilyen formában az elvégzett munkának a 90%-a felesleges. A 32x beállítással már "csak" a munka 70%-a felesleges.
De egyébként a HairWorks gondja nem az, hogy sokat tesszellál, hanem az, hogy nagyon ronda. Sajnos a többi GameWorks effekt is hasonló. Egyszerűen jóval jobb minőségben megcsinálták már mások ugyanazt.
A HBAO+ nem számít. Ez gyorsabban fut Radeonon, ettől függetlenül ez is ronda. Bár én az SSAO technikákért nem rajongok. Ma már obscurance fieldset kellene használni, mert az figyelembe veszi a képen nem látszódó részeket is, és azokból is keletkezhet árnyék.
-
-
Abu85
HÁZIGAZDA
válasz
#45185024
#11618
üzenetére
Ha a GameWorks és a moddolásról beszélsz, akkor a GameWorks csak azokat a tartalmakat helyezi DRM mögé, amelyek kapcsolódnak az adott effekthez. Tehát ha az a bizonyos tartalom módosulna, akkor az negatívan érintené az effektet. Ilyen lehet például a textúra, tehát potenciálisan érdemes azt átgondolni, hogy például a textúrák módosítását megtiltsák a modközösségnek.
Ez egyébként jellemzően minden motorban így van. A DX10-től kezdve a Microsoft megadta a lehetőséget arra, hogy a fejlesztők megnehezítsék a moddolást, ha azt akarják, hogy a játékhoz ne készüljenek egyéni tartalmak. Például a Frostbite motor esetében is probléma, hogy nehéz moddolni, mert annyira védve van a tárolt tartalom, hogy nehéz hozzá olyan eszközöket készíteni, amelyekkel ez kicserélhető. -
Abu85
HÁZIGAZDA
válasz
wjbhbdux
#11610
üzenetére
Az API kész van, csak az implementációk nem teljesek, de a fontosabb dolgokkal mindenki kész van.
Egy explicit API alapja, hogy a programozó manuálisan eldönthesse, hogy mit akar. Egy olyan API-nál, mint a DX12, vagy akármelyik hasonló rendszer mindig a programozó fogja a parancsot létrehozni, felvenni és tetszőleges időben egy kötegelt csomagban továbbadni a GPU felé. Ez a cél, hogy így történjen.
A DX11-ben ez úgy működött, hogy a parancsot létrehozhatta a programozó, de felvételt és a kötegelést már a driver csinálta. Ezzel az volt a gond, hogy ha rosszul jött ki a kötegelés, akkor a fejlesztő nem tudott vele semmit sem tenni. Ez teljesen megakadályozta a hatékony optimalizálást. -
#11604
Abu85
HÁZIGAZDA
#Morcosmedve
#11601
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#11601
üzenetére
Viccelsz? ... Ma már a trailernek is trailere van. A drivernek a leak lesz a marketingje.
-
#11600
Abu85
HÁZIGAZDA
#Morcosmedve
#11599
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#11599
üzenetére
Szerintem meg a WccfTech-et hanyagolni kellene teljesen.
-
Abu85
HÁZIGAZDA
A hardver tudását idővel mindig behozza a PC. A Carrizo SoC APU például már nagyobb tudású, mint ami a két konzolban van. De a konzol előnye marad a szoftver, mivel PC-re sosem fognak olyan alacsony szinten kódolni.
Az új generáció csak úgy éri meg a piacnak, és a konzolgyartóknak is, ha az AMD és az Imagination versenyezhet a bekerülésért. Ha elvárás lesz, hogy az új hardver futtassa a mostani programokat, akkor az Imagination kiesik, és az AMD olyan árát szab meg, amilyet akar, tehát az egész koncepciót már a tervezésnél lefújná a megrendelő. -
Abu85
HÁZIGAZDA
válasz
rocket
#11586
üzenetére
2018-ig nem fogják kitermelni a kiadók az aktuális generációba való befektetést. Két eset lehetséges. Azt mondja az MS és a Sony, hogy kérnek egy-egy olyan új APU-t az AMD-től (rohadt drága lesz, mert az AMD úgy áraz, ahogy akar), amelyek figyelnek a visszafelé kompatibilitásra, vagy hoznak olyan új konzolokat, amelyek erre nem adnak lehetőséget, és onnantól kezdve az pedig a kiadókat nem fogja érdekelni, mert úgy nem fognak befektetni rájuk, hogy még dollármilliós mínuszban áll az előző generációs befektetés. Még akkor sem fognak átállni, ha már pozitív lesz a mérleg. Fel fognak menni dollármilliós pluszig. Ez az egész konzolpiac alapja, ha elvágják, akkor az a piac értelmét kérdőjelezi meg.
-
Abu85
HÁZIGAZDA
válasz
rocket
#11532
üzenetére
A karácsony az NV-nek a Star Wars Battlefront promócióinak az elfedésére megy majd el. Az AMD-nek olyan szerződése van egyébként az összes érkező Star Wars címre, hogy azt a játékot mindenhol csak Radeonon lehet futtatni, illetve Radeonhoz lehet adni, illetve Radeonhoz lehet csak kirakni a reklámot. Ez kétségtelenül nagyon sokba került, de a Star Wars-ot és az NVIDIA GeForce-ot a szerződés miatt egy mondatban nem lehet kiejtenie a hivatalos csatornákon. Még az Intelt sem, és ezért futott mindenhol full AMD-s gépen a Star Wars Battlefront. Az NV-nek a szerződése az EA-vel addig terjed, hogy ki lehet rakni a játékokat a saját oldalukra, de az exkluzívra kötött játékokkal már nem reklámozhatnak.
(#11534) gbors: Nézz utána a neten. Lehet, hogy egy NV-fan megpróbálja megvédeni, de nem NV-fan NV tulajok jó része számára is negatív az élmény vele. Baromira nehéz bármilyen pozitívumot felhozni mellette. Ha most így nekifutok, akkor akármennyire erőltetem, semmivel sem tudom megvédeni a koncepciót. Még azzal sem, hogy az effektek szépek, mert nagyrészt csúnyák és átgondolatlanok.
Te is mit mondasz? Kapcsold ki és boldogság lesz. Oké, ez egy lehetőség, csak nem érv mellette. Vagy ha érv, akkor azt nagyon nehezen raknám a pozitív érvek mellé. -
Abu85
HÁZIGAZDA
Az a baj, hogy ez az általános megítélés. Ami jogos egy átlagfelhasználó szemével, mert ők egyszerűen csak nem tudnak felhozni pozitív példákat a GameWorks-re. Egyszerűen van bennük egy rakás negatív tapasztalat, amire jut egy rakás olyan pozitív tapasztalat olyan játékok formájában, amelyek nem NV logóval indulnak. Ez volt, amire az NV-től eljött rendszerprogramozók figyelmeztettek, hogy ezt lehetetlen jól eladni a játékosoknak, mert a fejlesztők keze az optimalizálás szempontjából meg lesz kötve. Az, hogy ez a nézet Magyarországra is becsúszott alapvetően várható volt. Picit késett, mert írtunk pár cikket, amiben próbáltuk a GameWorks problémakörét átfogóbban elemezni, de a végső szempont a felhasználónak úgyis az, amit tapasztal, és ez jelenleg negatív jellegű.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#11523
üzenetére
A Bethesdának egyértelműen. Azért tudják relatíva magasan tartani az egyes játékaik árát még sok év után is, mert a mod közösség még mindig aktív. És nem csak játékmeneti szinten, hanem grafikai feljavításban is. Lásd Morrowind. [link] ... ezeknek az elkészültét egy GameWorks-féle middleware DRM nagyban akadályozná.
Nyilván nem tartom kizártnak, hogy a Bethesda át akarja helyezni a konzolra a modközösséget, mert a PC-n meg van kötve a kezük a moddolásra alkalmas eszközökkel kapcsolatban. Ez természetesen egy opció, de szerintem annyira erős a modközösség, hogy ebből inkább meghátrálás lesz. Volt itt idén fizetős mod lehetőség is a Steamen és napokon belül visszavonulót fújtak a felek.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#11517
üzenetére
Játékmechanikai módosításokat enged, vagy HUD módosításokat például.
A GameWorks csak azokat nem engedi, amelyek a grafikára vonatkoznak, és az adott effektre potenciálisan negatívan hatnának. Bizonyos effektek esetében ebben benne van a textúra és a modell is. Ezeket egyszerűen elrejtik a DRM mögé, és ha ki is nyered a tartalmat, oda visszaépíteni egy módosítást gyakorlatilag lehetetlen, mert nem fog egyezni az ellenőrzőösszeg, így a GameWorks DRM nem fogja engedni a program elindítását.Szerintem a Fallout sorozat részben a moddolásról is szól, és emiatt nagyon nehéz egy moddolást bizonyos szempontok szerint akadályozó middleware DRM-re igent mondani. Maximum azok a részek jöhetnek, amelyeknek a tartalom mindegy. Ha a fejlesztőket ez a moddolási lehetőség nem érdekelné, akkor nem látnák el a közösséget különböző eszközökkel.
-
Abu85
HÁZIGAZDA
A Fallout 4 Havokot használ. Ez hivatalos, benne van a Havok brosúrában. Azt nem tudom, hogy ez publikus-e, de amit nekem küldtek, abban ott van, hogy Havok Physics és Script technológiákat használ.
A GameWorks a Fallout sorozatnak nehéz ügy, mert a middleware licenc megköveteli, hogy a játék moddolhatósága korlátozott legyen. Például a Witcher 3 emiatt moddolható sokkal rosszabbul, mint a Witcher 2. Az effekttől függ, hogy melyik részeit nem lehet bántani a programnak és a tartalomnak. Ez egy elővigyázatosság, ugyanis a zárt kód mellett sokkal kisebb az esélye annak, hogy a moddolt tartalom is jó lesz. A GameWorks DRM-jét pedig nehéz lenne feltörni egy modcsapatnak. Mivel a licenc szerint az effekt élvez elsőbbséget, így a mod lehetőség lesz letiltva. Maga a tartalom/modell is el van rejtve a DRM mögé, még ha ezt fel is törik, ide visszaépíteni egy modot szinte lehetetlen. Tekintve a Bethesda mod közösségét, nekik ez nem lenne túl kifizetődő döntés, de az sem kizárt, hogy pont azért jelentették be a konzolos moddolást, mert a PC-s moddolás korlátozott lesz, így a moddereket át akarják vinni konzolra. Egyelőre erről keveset tudni.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#11481
üzenetére
Arra ezek a programok egyáltalán nem alkalmasak. Az, hogy melyik architektúrának fekszik jobban csak a teszt után derül ki. Amire alkalmasak ezek a programok az az, hogy meghatározható legyen, hogy az adott alkalmazás mennyire terheli le a GPU-t. Konkrétan eldönthető, hogy a PC-s port trehány vagy elfogadható, esetleg minőségi. Mi évek óta kiszedjük a trehány portokat, mert ezek csak a PC megítélését rontják. Jelenleg minimum elvárjuk egy alkalmazástól, hogy a GPU minimum 30%-os mértékben leterhelje. Ez alatt nem kerülhet be semmi, az már túl rossz. Persze a 30%-ot is tekinthetjük annak, és szerintem az, de manapság ennyi az átlagos hardverterhelés.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#11452
üzenetére
Áh nem szükséges. Inkább a gyártókat húzom le. Nekik van bőven.
![;]](//cdn.rios.hu/dl/s/v1.gif)
De köszi. 
(#11454) Ren Hoek: Nekem a munkám miatt fontos a funkcionalitás. Ezért kell nagy tudású cucc. Nem feltétlenül kell szupergyors, de lehetőleg tudjon mindent, amit lehet, hogy ha kapok valamihez hozzáférést, akkor azt meg tudjam nézni.
Most úgy néz ki, hogy LGA1150-es vagy Socket FM2+-os lapot kérhetek. Szóval az fogja eldönteni, hogy mennyi pénzt akarok elnyomni procira.
-
Abu85
HÁZIGAZDA
válasz
gtamate2
#11448
üzenetére
Hát ez van. Én is sajnálom, de gondoltam rá, hogy napi 14 óra mellett nem fog örökké működni. Baj igazából nincs, mert van még mellette több pótalkatrész, szóval össze tudtam rakni egy gépet munkára. Aztán majd várom, hogy mi van elfekvőben. Én ráérek. Mondtam, hogy a szállítási költséget duzzogva, de állom.
(#11447) Ren Hoek: Áh olyat nem fogok kapni.
Igazából csak lapot kértem, mert procit majd veszek bele magam. Úgyis tudom, hogy van egy rakás elfekvő tesztalaplap, ami megjárta a Balkánt és ma csak fel van rakva egy polcra. Tökéletes lesz. -
Abu85
HÁZIGAZDA
válasz
gtamate2
#11419
üzenetére
A Q9550-nek már mindegy, mert az alaplap 8 év után felmondott, ráadásul rendkívülivel.
Szóval mindenképpen váltás lesz. Azt még nem tudom, hogy mire, de biztos nem Sany Bridge-re. Olyan processzort akarok, ami támogatja a WDDM 2.0 IOMMU címzését. Egyelőre még beszélek az alaplapos spanokkal, hogy mit tudnak küldeni olcsón, aztán ahhoz veszek valamit. -
Abu85
HÁZIGAZDA
válasz
daveoff
#11413
üzenetére
Nekem tették bele, mert a Dragon Age-et nem akartam 10 fps-sel játszani, így ment az 40-nel is.
Nehogy azt higgyétek, hogy aki tud venni egy 40-70k-s Radeont az képes venni egy 40-70k-s processzort. A helyzet az, hogy a procira a legtöbb átlagos játékos 100 dollárt költ, hogy több maradjon a GPU-ra. -
#11412
Abu85
HÁZIGAZDA
gainwardgs
#11411
Abu85
HÁZIGAZDA
válasz
gainwardgs
#11411
üzenetére
A TressFX egyszerű, mert nyílt a forráskódja. Bár a TressFX 2.0 és 3.0 bonyolultabb, mert annak két OIT verziója van. Egy PPLL adatstruktúrát felépítő és egy mutex zárolásos. Előbbi eléggé szabványos kód, és ez jól működik a Tomb Raiderben, de lassú. Utóbbi kvázi szabványos kód, de olyan hardvert igényel a problémamentes futtatása, amely virtualizált LDS-t használ, de cserélbe sokkal gyorsabb. Ezt használja a Lichdom és sajnos ezt AMD-only effekté rakták a fejlesztők. A legjobb opció, amit az AMD javasol, hogy építsék be mindkettőt, és akkor a PPLL adatstruktúra mehet a mutex zárolást nem szerető hardvereken.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#11392
üzenetére
Nincs olyan, hogy AMD vagy NV közeli fejlesztő. Fejlesztő van. Sajnos arról nem lesz előadás, hogy az Ubisoft és a Rocksteady kiáll, hogy "na ezen csúszott el a PC-s port". Pedig érdekelne, de mit mondhatnának... Max az NV állhatna ki, hogy "márpedig az összes cuccunk jó, csak hülye fejlesztők használják ezeket", de ilyen sem lesz, mert az rombolná a partneri kapcsolatokat. Szóval ebből nem igazán lehet főzni. Csak arról lehet hír, aki kiáll és bemutat valamit, ami jön.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#11355
üzenetére
Éppenséggel beszélhet. Phil Rogers egy ideje a HSA Alapítvány szóvivője volt, és emellett részt vett a platform tervezésében. Mivel végig open-source projekteken volt rajta, így túl sok titkot nem őriz.
Az NV-nek a szaktudása az integráció miatt kell, mert Phil Rogers ennek a területnek a szakértője. Nyilván gyorsítókártyákkal a jövőben nem mennek majd semmire még az NVLINK-kel sem, így kell egy képzett ember, aki képes normális IBM-Pascal (esetleg ARM-Pascal) párosítású rendszerchipeket összerakni a szerverekbe megfelelő szoftveres csomaggal. -
Abu85
HÁZIGAZDA
válasz
Locutus
#11335
üzenetére
Amikor terveznek egy multiplatform játékot, akkor megvizsgálják a célplatformok képességeit és aszerint hoznak döntéseket. Minden esetben a legrosszabb hardverelem lesz megcélozva. Például a valóban befogható processzoridő szempontjából a PC-k a legrosszabbak, míg a grafikus teljesítmény szempontjából a PC-k jobbak. De a lényeg, hogy mindenből a minimum kell. Akkor válik ez az egész problémává, amikor egy játékot eredetileg csak konzolokra terveztek, és később eldöntötték, hogy lesz PC-s port. Ilyenkor a konzolokon elérhető valós processzoridőre terveznek, ami biztosan nagyobb, mint a PC-n elérhető, de persze csak a régi API-kkal. Az új API-k egyébként pont azt célozzák meg, hogy a PC-n se csak a processzorod teljesítményének a 10-20%-a legyen elérhető.
(#11336) Loha: 10.valamelyik.
-
#11334
Abu85
HÁZIGAZDA
FollowTheORI
#11330
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#11330
üzenetére
Igazából az MS ezt leszarja, csak azért javasolják, hogy ne költsenek el a fejlesztők egy rakás pénzt és fél évet az optimalizálásból, egy nem működő irányra.
A probléma a processzoridő felhasználása. A konzolokon a fejlesztők elérik a processzoridő ~90%-át is. PC-n az agresszív DX11-es meghajtók miatt az elméleti processzoridő 10-20%-a áll rendelkezésre. A maradék 80% erőforrás hiába áll tök üresen, a driver szinkronizációs munkája miatt nem tudsz rádobni feladatot. Az eredetileg konzolra tervezett játékoknál ez gáz, mert így az előző generációs konzolok processzorteljesítménye is nagyobb a legtöbb PC-nél, ami ellehetetleníti a portolást.. Idővel aztán vagy kukázták ezt a lehetőséget, vagy kivárták, amíg nő annyira a teljesítmény, hogy bevállalható legyen a port.
-
Abu85
HÁZIGAZDA
válasz
Gainka
#11327
üzenetére
Már rég multi-thread az AMD driver. De figyelembe kell azt is venni, hogy egy bizonyos szint fölött a driver megakadályozza a fejlesztők munkáját. Az Intel pont ezért nem csinál multi-thread drivert, mert csak csökken tőle a programhoz felhasználható valós processzoridő, amiért a fejlesztők meg ordibálnak.
Most már mindegy is, mert a fejlesztőket megkérte a Microsoft, hogy többet ne adjanak ki deferred context alkalmazást, nem mintha annyira sokan tették volna eddig. A deferred contextbe ölt kutatás gyakorlatilag kuka. -
Abu85
HÁZIGAZDA
válasz
janos666
#11283
üzenetére
A Gaming Evolved applikáció az AMD sajátja. Annyi köze van a Raptr-hoz, hogy annak az adatbázisát használja. Ennek a koncepciója az, hogy minden Raptr közösségi funkcióit el lehet érni az AMD programjával is.
Egyedül az Intel használ 3rd party szinten Raptr-be épített hivatalos funkciókat. Ők is arra a hatalmas felhasználóbázisra pályáznak. Nem kizárt, hogy később csinálnak saját verziót.
-
Abu85
HÁZIGAZDA
válasz
janos666
#11270
üzenetére
Ezt rosszul tudod. Mindegyik gyártó cucca működik, bár az való igaz, hogy az Intel és az NV nem ad olyan paraméterézési lehetőségeket a minőségre, mint az AMD. De hardveresen Full HD 30 fps-t mindegyik tud.
A program oldali támogatás pedig lehet hivatalos és nem hivatalos. Az NV a GeForce Experience, míg az AMD a Gaming Evolved programon keresztül támogatja ezeket. Driverekben telepíthetők is. Az Intel hivalatos támogatása a Raptr programon keresztül érhető el, később ha megegyeznek a licencen, akkor az Intel drivere tartalmazni fogja a Raptr-t, de addig csak külön telepíthető. A nem hivalatosakra pedig nincs igazából garancia sehol, de nem akadályozzák a használatát. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#11172
üzenetére
Régi API-val az, de a low-level érában már nincs kernel driver. Ott 100%-ban a programon múlik a sebesség.
(#11175) FLATRONW: Az AMD nem téma, mert visszafejtik a D3D bájtkódot és kiveszik belőle a mesterséges lassítást. Ez egy-két hónap munka biztos lesz, de megcsinálják. Ott a HairWorks példának. Egyszerűen kicserélték a shadert rá és begyorsultak. De az igaz, hogy a kezdeti 64x-es tesszelláció helyett már csak 32x-est használ valamelyik W3 patchtől kezdve, és az FC4 is már csak 16x tesszellációval fut. Egyedül a Keplert tudják így bátani, ami a nem TWIMTBP játékokban (pl.: Battlefront) mutatja, hogy még mindig elvan, ha nem szopatják szoftverből. És ez nettó bunkóság, a Keplert vásárlók is megérdemlik, hogy teljes erőből mehessen a kártya.
-
Abu85
HÁZIGAZDA
Akkor erre építve a következő kérdés. Képes lenne megkönnyíteni a fejlesztők dolgát úgy is, ha nyílt forráskódú lenne? Szerinted rontana, vagy javítana a helyzeten?
Nyilván tudom előre a választ, így bónuszkérdés, hogy ha javítana, akkor miért nem nyílt forráskódú? Netán nem lenne előnyös, ha a fejlesztő kiműtené belőle a lassításokat és optimalizálná Keplerre? -
Abu85
HÁZIGAZDA
A middleware-ek célja általánosan az, hogy megkönnyítsék a fejlesztők munkáját. 2015-ben kvázi mindenki biztosít forráskódot, ami megkönnyíti a munkát. Az AndroidWorks vagy Radeon SDK pontosan ilyen. Nyílt és jól használható.
A GameWorks pontosan lehetne ugyanez, ha nyílt lenne, de zárt. Pedig utóbbinak semmi értelme, mert még az algoritmus védelme sem merül fel. Mit lehet védeni egy HairWorksön, aminél például a TressFX konstrukciója sebességben és minőségben is jobb. Az egyetlen cél, hogy a fejlesztő képtelen legyen kikapcsolni a gépigényt nagymértékben megnövelő, de a minőségre semmilyen előnyös hatást nem kifejtő algoritmust.
De ha úgy gondolod, hogy tudsz olyan előnyt mondani, amit a GameWorks nem tudna biztosítani nyílt forráskód mellett, akkor itt a lehetőség. -
Abu85
HÁZIGAZDA
válasz
imi123
#11167
üzenetére
Én nem utálom az NV-t. Rengeteg relikviám van személyesen tőlük (egyedi NVIDIA pendrive-ok, pólók, gravírozott egyedi késkészlet), amelyekkel elismerték már a munkámat. Kifejezetten kedvelem a hardvereiket, például a Fermi nagyon tetszett, ahogy a Tegra is nagyszerű. Viszont nem értek egyet azzal, hogy a felhasználóik számára jó dolog az, ha a gépigényt mesterségesen manipulálják. Ez egy rossz döntésük, amivel kárt okoznak a PC-nek.
-
Abu85
HÁZIGAZDA
Más célja nehezen lehet egy zárt rendszernek. Már önmagában az NV-nek nagyon káros, hogy a világ pofájába kell hazudniuk, hogy 2015-ben normális egy middleware-t zártként fejleszteni, amikor ennek pont az ellenkezője igaz és idén a korábban zárt middleware-ek forráskódját folyamatosan publikálják az érintettek.
A GameWorksnek más célja nincs, mint az előző generációs GeForce-ok teljesítményének mesterséges visszafogása vagy a gépigény mesterséges növelése. Minden egyéb célhoz megengedhető a nyílt forráskód, mert a licenc így is megvásárolható. Lásd az AndroidWorks. Az tök ugyanaz, mint a GameWorks és az összes sample forráskódja fent van a GitHUB-on. Még azt is mondta az NV, hogy csak így lehet optimalizálni a programot. És az AndroidWorksöt többen licencelik mint a GameWorksöt. -
Abu85
HÁZIGAZDA
válasz
rocket
#11159
üzenetére
A Vulkan API-val egy gondja lesz a DICE-nak. Nekik a shaderek HLSL-ben, PSSL-ben vagy az AMD-féle HLSL ext.-ben vannak megírva. A Vulkan egyiket sem fogadja el, mert úgy döntöttek, hogy csak SPIR-V kód szállítható. Persze az megoldható, hogy a DICE ír egy saját fordítót, amely a HLSL, vagy az AMD HLSL ext., vagy a PSSL kódot SPIR-V-re fordítja. A gond az, hogy SPIR-V-hez az AMD-féle HLSL ext. az ideális, de az meg GCN-re szabott kód teljesen, tehát eleve sok átírást von maga után. PSSL szintén, hiszen PS4-re van. A HLSL kód pedig nem éppen SPIR-V-hez való, bár a fordítás így is megoldható, viszont így lassabb lehet a Vulkan, mint a DX12-es opció.
Semmi köze nincs a Vulkan API implementálásának ahhoz, hogy ki a Khronos elnöke. Ő amúgy is csak moderációs feladatokat lát el az ARB-ben.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#11131
üzenetére
A Keplerrel akkor nincs és nem is lesz baj, ha a fejlesztő minden shadert rá tud optimalizálni. Mindenki ismeri ennek az architektúrának a gyenge pontját, és emiatt mindenki tudja hogyan kell kezelni. Lényegében arról van szó, hogy a multiprocesszoron belül normál ütemezéssel csak a magok 66,7%-a etethető, így a maradék 33,3%-ra független feladatokat kell találni. A legtöbb shaderben ezt viszonylag egyszerű kivitelezni. Egy DICE-nak ez nem jelenthet problémát, mert az elmúlt években már kitapasztalták. Ez csak akkor gond, amikor a shadert az NV szállítja és nem lehet optimalizálni. Az NV-nek az az érdeke, hogy a Kepler már ne teljesítsen. Alapvetően emiatt vezették be a GameWorksöt, ha jön egy új architektúra, akkor szoftveresen képesek legyenek mesterségesen kivégezni az előzőt.
-
Abu85
HÁZIGAZDA
Az új CryEngine és hasonló eredményeket mutat fel, mint az új Frostbite. Valószínűleg ehhez köze van annak, hogy ezek már teljesen PBR/PBS-es motorok, és itt általánosan erősebbek a Radeonok. A PBR/PBS miatt nagyobb teher jut a memóriabuszra, mert olyan leképező kell, amely pixelenként a megszokottnál több bitnyi információt kezel hatékonyan. Ezek a leképezők az utóbbi időben háttérbe szorultak, mert szűkössé vált a sávszél, de az új technikákhoz újra elő kell szedni őket. Illetve az is látszik, hogy ma már a középkategóriában is alap a 256 bit + GDDR5. Csak egy szem GTX 960 miatt nem döntenek úgy, hogy mégse fejlődjön a motor.
-
Abu85
HÁZIGAZDA
válasz
gtamate2
#11107
üzenetére
Röviden az Apple normális OpenCL támogatást kért, de az NV nem adott. Helyette a CUDA-t erőltette. Erre az Apple lecserélte a Quadrókat a Mac Próban FirePrókra. Amire áttértek a szoftverfejlesztők OpenCL-re. Erre az NV így sem reagált jó OpenCL meghajtókkal, így nem volt más választás, mint kidobni őket. Ennyi. Az Apple célja az, hogy minden partnere a saját zárt rendszerét támogassa a jövőben. Az NV-nek ez nem tetszik, mert az Apple képes kivégezni a CUDA-t a konzumer és profi vonalon. Legalábbis azt a részét is, ami meg maradt belőle.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#11102
üzenetére
De a te géped nem presztizscucc.
Az NV egyébként a Google Pixeljébe eladta a Tegra X1-et szóval a mostani Bookkal kb. jól állnak. De majd vissza kell szerezni az Apple bizalmát. Mondjuk ez nehéz lesz, mert ehhez az AMD-nek úgy kell majd szopatnia az Apple-t, ahogy az NV tette az elmúlt években. -
Abu85
HÁZIGAZDA
válasz
Yllgrim
#11098
üzenetére
A Linuxban az AMD játékos szemmel nem bízik. Annyira töredezett az egész, hogy esélye sincs a Windows 10 ellen. A Vulkan is Windows 10-en lesz a legjobb, mert a Linuxból hiányzik a WDDM2.0 alternatíva. Még a WDDM 1.1 képességeit sem tudják hozni.
Az egyetlen remény a játékosoknak a SteamOS, de ahhoz is meg legalább két év fejlesztés kell, hogy Windows 10 szintre jusson. De az biztató, hogy a Valve látja azt a problémát, hogy a Linux legfőbb baja a kismillió ablakkezelő és kompozitor, amelyek fejlesztése teljesen átgondolatlan, és erre vonatozóan lemásolják azt, akit az MS csinál. Lesz egy kivalasztott alapcsomag és az lesz szarráoptimalizálva. -
Abu85
HÁZIGAZDA
Egy ilyen üzletnek semmi köze a hardverek képességeihez. Az Apple, a Google és az MS úgy választ, hogy melyik cég tudja nagyon olcsón biztosítani a megfelelő termeket. Az NV-nek nulla presztízscuccban van idén VGA-ja, mert az AMD elvitte az Apple megrendeléseket, így a Booksba muszáj volt bekerülni egy VGA-val. Jó eséllyel az AMD-t ez már nem is érdekelte, mert elég az Apple megrendelés. Nem jó túl sok olcsó üzletbe belemenni. Ezért nincs olyan, hogy valaki végignyeri az Apple, Google, Amazon, MS cuccokat.
-
#11087
Abu85
HÁZIGAZDA
gainwardgs
#11086
Abu85
HÁZIGAZDA
válasz
gainwardgs
#11086
üzenetére
Egy low-level API biztos támogatva lesz a három közül. Nem tudom melyik, azt nem mondták.
-
Abu85
HÁZIGAZDA
válasz
janos666
#11073
üzenetére
Biztos nem lesz visszaportolva egyik régebbi Frostbite verzióba sem a DX12 és a Vulkan. Valójában a Mantle is csak akkor lehet használatban mostantól, ha a fejlesztő olyan dolgot szeretne, ami szabványosan nem érhető el. Elég sok dolog hiányzik még a DX12-ből ami konzolokon van, és a Mantle API-ban benne van.
A Mantle bekötési modellje is sokkal jobban hasonlít a PS4-es libGNM-re, illetve az Xbox One DX12 mono API-jához. A normál DX12 és a Vulkan API más bekötési modellt használ, bár a Vulkan modellje csak annyiban különbözik, hogy emuláció céljából fenntart bizonyos specifikus puffereket, hogy az AMD-n kívül más is tudja futtatni a Vulkan alkalmazásokat. -
Abu85
HÁZIGAZDA
válasz
Sir Ny
#11063
üzenetére
GP100 vagy GP200. Összekavartam. Köszi.
(#11064) Szaby59: A GM200 az nem számít, mert az semmi újat nem mutatott. Ergo a tape-outtól a megjelenésig megcsinálták 9 hónap alatt. A következő kör sokkal nehezebb, mert tapasztalat nélkül lesz egy új node-ra való átállás, új memóriavezérlő tervezésével, új memória bevezetésével és interposerrel. Egyenként megvan rá az esély, hogy kivégeznek egy terméket és egyszerre kell átállni mind a négy nagy váltásra. Tehát itt azért több idő fog eltelni, amíg a tape-outtól eljut a termék a boltig. Másfél év alsó hangon, de látva, hogy a Fiji mikor ért el a boltokig 2013Q2-es tape-outtal inkább két évet mondanék.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10968
üzenetére
Azért nincs újra kiadva, mert még nincs kész. Ugyanis tele van hibával az újraírt erőforrás-kezelés. A patch azért került ki, mert már segít a teljesítményen, de még bele telik pár hétbe, amíg a hibákat kijavítják. Amint ezzel végeznek felrakják újra a Steamre, és akkor lesz kész, akkor lehet újra megvenni.
Az early access esetében is alapvető követelmény, hogy legyen stabil, de ezt még az Arkham Knight nem teljesíti. De ez nem gond, nyilván ezért nincs még visszarakva a Steamre. Még tart a tesztelés.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10965
üzenetére
A hiba jellegét tekintve teljesen mindegy lenne, hogy a driver WHQL vagy béta. A WHQL teszt ugyanis nem tartalmaz ellenőrzést egy ilyen problémára.
Tegyük hozzá, hogy az Arkham Knight még ki sincs újra adva. Nem véletlenül vonta vissza a Steam a játék értékesítését. Egyszerűen ma még béta állapotú. Emiatt teljesen természetesen a hibák vele. Akkor lehet reklamálni, ha újra kiadják.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10880
üzenetére
Az OpenGL és a driverek állapota csak tünet. A probléma az, hogy egy rakás kompozitor és ablakkezelő létezik, és ezek fejlesztésében a gyártók nem vesznek részt. Plusz a zárt driverek ezekbe nagyon beletúrnak, tehát gyakorlatilag minden céghez külön implementáció kell. A Valve nem véletlen választotta azt, hogy áttérnek a Waylandre, de az erre való váltás sem problémamentes, mert a Wayland nem támogatja natívan az OpenGL-t. A SteamOS azért jön, mert a Valve rájött arra a problémára, hogy a sok alternatíva egy problémára nem nyerő, így csinálnak egy olyan disztribúciót, amelyben kiválasztanak egy alternatívát minden területre, és azt optimalizálják majd halálra, illetve a fejlesztőknek is aszerint kell dolgozniuk. Nem véletlen, hogy ők már átrakták a Source 2-t Vulkan API-ra, mert amikor bevezetik a Waylandet, akkor jó eséllyel sok probléma lesz az OpenGL-ben írt játékokkal, hiszen a legtöbb OpenGL implementáció telepít GLX-et, ami összeakad a Waylanddel.
-
Abu85
HÁZIGAZDA
válasz
letepem
#10874
üzenetére
Linus azért mutatott be az NV-nek, mert leálltak az open source projektek támogatásával és nem dokumentálják a hardvereiket. Ez jelentősen megnehezíti a Linux fejlesztését az NVIDIA hardvereken. Illetve nehezebb lesz olyan cégekre Linuxot tukmálni, akik NVIDIA-t használnak. A játékokat Linus le se szarja, aki használ Linuxot az elsődlegesen nem játékra használja.
-
Abu85
HÁZIGAZDA
válasz
sayinpety
#10857
üzenetére
Az parancslista túlterhelése vezethet olyan problémához, amiről az Oxide beszélt a Nitrous és az async compute NV-s problémáival kapcsolatban? Szimplán annyira megnövelte a processzorterhelést a driver munkája a hardver hiányosságainak kezelésére, hogy az egész eredménye lassulás lett úgy is, hogy elméletben gyorsulnia kellett volna?
-
Abu85
HÁZIGAZDA
válasz
Laja333
#10822
üzenetére
Valószínűleg ehhez köze van annak, hogy az AMD csak pár órával a megjelenés előtt adta oda az új meghajtót, így nem volt idő mindent azzal letesztelni. Erre egyébként az Anand is felhívta a figyelmet. Szóval vagy a régi, vagy az új meghajtóval futottak a hardverek, vagy keverten.
Ebből szerintem úgyis lesz még egy kör teszt, amikor az MS kiadja a végleges tesztprogramot.Az UE4 MS-es verziója eléggé sávszélzabáló. Ezért rendeződnek ennek megfelelően a hardverek.
-
Abu85
HÁZIGAZDA
válasz
rocket
#10819
üzenetére
Tök mindegy, hogy mi kerül beállításra a driverben DX12-ben a kényszerített szűrők nem számítanak, mert a driver nem tud már kényszeríteni kernel meghajtó hiányában. Másrészt az UE4 új verziója nem támogatja az AF-et. Egy speciális szoftveres szűrést használ a POM miatt.
Egyébként most tök mindegy, hogy ki mér, mert a program csak három előre konfigurált profilt használ. Ezeket egyénileg nem lehet paraméterezni.(#10820) gV: A Kepler csak akkor szerepel rosszul, ha a program nem veszi számításba, hogy független utasítással ki lehet tömni a feldolgozók 33%-át. Mivel a Microsoft nem használ GameWorksöt, így képesek úgy írni a programot, hogy optimálisan fusson Kepleren. Ezek nem nehéz optimalizálások, csak szánni kell pár órát a beépítésükre.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#10757
üzenetére
Ha arra gondolsz, hogy ellopják az adatokat, akkor azt megtehetik, ha azt akarják, hogy a termékük sose jelenjen meg. Ugyanis az AMD a saját csomagjára kapott értékeket tartja számon. Az NVIDIA lapkáival nem is tesztelnek. Amiket pedig a HBM-ről tudni lehet, azt a Hynix és a Samsung úgyis elmondja. Persze leginkább a Hynix, mert a Samsung itt szűz ilyen szempontból.
(#10759) rocket: Amiket meg tudnak osztani, azt megosztják, de az NV nem megy semmire azzal, hogy az AMD-n milyen konfiguráció a működőképes. Megnézhetik, de számukra ez értéktelen információ.
(#10763) Loha: Erről beszélek. Az AMD és az NV is közel két évvel az első termék után jutott túl az 5 GHz-en. Sajnos 5,5 GHz felett drasztikusan romlik a GDDR5 fogyasztása, így csak akkor mentek fölé, ha nagyon szükséges volt.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#10754
üzenetére
Itt nem a mérnökök tudásán múlik. Lehet szuperokos akármennyi mérnök, de alapvetően előnyben van az a csapat, amelyik nem 2015 közepén látott először HBM termékmintát, hanem 2014 első felében. Az a mérnök csapat, amelynek másfél éve van hardvere már túl van minden olyan fontosabb teszten, aminek a többi csapat még csak most kezd neki. És az ezeken a teszteken gyűjtött tapasztalatot semmilyen elméleti tudás nem képes helyettesíteni.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#10751
üzenetére
Ahogy ez most alakul messze nekik lesz a legjobb, mert gyorsabban válthatnak HBM2-re, mint tervezték. Nekik az átállás eleve sokkal könnyebb lesz, mint bárki másnak, mert tömeggyártanak egy komplett HBM-es rendszert. Olyan dolgokat ismernek a teljes rendszer működéséről, amelyet más 2016-ban fedez majd fel, mint probléma.
Minden memóriaváltás nehéz, és a GDDR5-nél látható, hogy miért. Az AMD az elején képes volt építeni 4 GHz-es VGA-kat, majd később 5 GHz-eseket és így tovább. Ezeket a lépcsőket a tapasztalat hozta össze. A Radeonokon már 5,5 GHz-es memóriák voltak, amikor más épphogy elérte a 4 GHz-et.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#10733
üzenetére
A Micron HMC borzalmasan drága és nem is működik. Az Intel is egy speciális változatot használ, ami nem a Micron interfészével dolgozik. Ez elfogadható egy 2000+ dolláros Xeon Phi-n, de még így sem biztos a nyereség. Egy 1000 dollár alatti VGA-ra darabonként 1000 dollár veszteség nem vállalható be.
A HBM1+GDDR5X lehetséges, csak borzalmasan hátrányos és drága, mert fizeted az interposert és fizeted a NYÁK extra költségét is. Akkor már inkább csak GDDR5X-et érdemes használni.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#10741
üzenetére
Az a baj, hogy a konzol egy fix hardver. Tehát a programozó tökéletesen képes olyan kódot írni, amelynek minimalizálja a memóriaelérését. Kvázi a munkát a lapkán belül tartja. Egy PC-n a rakás eltérő hardver miatt ilyet nem lehet csinálni, mert nem érdemes egy hardvert kiválasztani a sok száz közül, és arra rágyúrni a programot. Fix hardvert a változó hardvert kínáló platformokkal nem szabad összehasonlítani, mert fix hardverrel olyan dolgokat tehetsz meg, amelyek drasztikusan gyorsíthatják a feldolgozást.
-
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#10568
üzenetére
Akkor egy kicsit érthetőbben. A VR-nél a lényeg, hogy legyen új képkocka a vertikális szinkron idejére. Mindegy, hogy valós vagy warp, csak ne legyen kirakva az előző. A preempció a timewarphoz kell, és ennek a hatékonysága határozza meg, hogy mekkora eséllyel lesz új warp. Finomszemcsés preempcióval a legnagyobb az esélye és rajzolási szintű preempcióval a legkisebb. A kettő között helyezkedik el a Hawaii leginkább a finomszemcsés eredményeihez közel.
(#10572) cain69: Mivel ez hardverfüggő, így nem lehet ennyire megmondani, de vannak olyan rajzolások is, amelyek 10 ms-nál is tovább tartanak egy gyors hardveren. Ez egyébként nem baj önmagában. Az a baj, ha mögé szorul a timewarp.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#10565
üzenetére
Mert a GCN2-nek sem kell a timewarphoz kontextust váltania, és a preempciós képességei így is nagyon jók, csupán nem tud éppen futó wavefrontot leváltani, ami pár száz nanoszekundumos késést jelenthet. De a PS4 alapvető előnye, hogy a teljes szoftvercsomagot egy fix hardverre optimalizálták igen alacsony szinten.
Az NV problémája onnan ered, hogy nekik a timewarp nem garantált funkció. A kért kontextusváltás akár 7 ms-mal is késhet, ha előtte beragad egy hosszú rajzolás. Ilyen körülmények között gyakorlatilag biztosan nem lesz timewarp szinkronablakon belül. Ezt valószínűleg úgy fogják kezelni az NV-nél, hogy a látótér szélein keveset számolnak. Kvázi ezért került be a multi-res shading a GameWorks VR-be. Ez sokat ront a minőségen, de drasztikusan növeli a sebességet.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#10563
üzenetére
Fogalmam sincs igazából, hogy mi fog változni. Volt az AMD-nek egy régi OEM útiterve, amiben le volt írva, hogy a GCN1 verzióhoz képest miket terveznek még:
fast context switch (GCN2)
unaligned memory access (GCN2)
memory address watch (GCN2)
system & device unified addressing (GCN2)
multiply compute queue (GCN2)
mid-wave preemption (GCN3)
scan & cross-lane ops (GCN3)
mixed precision (GCN3)
quadruple precision (???)
octa precision (???)
system & device transactional memory (???)
quad-fragment merging (???)Bejelöltem zárójelben, hogy mi valósult meg és mi nem. Azt nem tudom, hogy megvalósulnak-e. Annyit tudok, hogy a GCN4 és a GCN5 kódolási sémája más, mert a GCN disassemblerben már lehet kérni ennek megfelelő kódot. Gondolom van GCN4 és GCN5 szimulátoruk.
-
Abu85
HÁZIGAZDA
válasz
imi123
#10558
üzenetére
Az az AMD-nek sem jó, hogy a konzolokra fejlesztenek. Most az egy rövid ideig, de később ez limitáló lesz nekik is, ahogy mindenki másnak. A GCN3 már okosabb annál, amit a konzolok kaptak, és akkor jön még GCN4 és GCN5.
A TrueAudiót a konzolon sem használják még, de egyre többen fogják, és onnan a kód átmenthető. De a PC-n a TrueAudio egy fontos VR komponens. Nélküle nem lehet kis teljesítményigény mellett térhangzást kínálni a VR-hez. Ez az egyik dolog, amit vizsgál például a Realtek is az ALC5677-es DSP-vel. Ez ugyan harmadannyira olyan erős, mint a TrueAudio, de a VR miatt érdemes rárakni bizonyos alaplapokra (VR-re tervezettekre), mert szükség lesz rá, és még portolhatók lesznek a konzolos hangrendszerek hozzá. -
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#10542
üzenetére
GPUPerfStudio.
A GPU-Z csak azt ellenőrzi, hogy egy másodperces időkeretben a GPU hányszor fogadott parancsot a CPU-tól, és arra ad egy százalékos értéket. Azt nem fogja megmondani neked, hogy ezek a parancsok hogyan és mikor futnak le a GPU-n belül.(#10546) imi123: Az AMD pont a gyors hardverfejlesztésekben hisz, mert jellemző, hogy két-három évvel hamarabb vetik be az újításokat, mint a konkurensek. Lásd.: SVM, FP16, ordered atomics, LDS virtualizáció, OOO parancsprocesszor, mid-wave preempció, SRIOV, gyors kontextusváltás, stb. Gyakorlatilag kimondták a Mantle-lel, hogy ha jöttök, ha nem, mi megyünk előre. Ennek az lesz a vége, hogy mindenkinek lesz egy saját API-ja, mert az nem járja, hogy az AMD-nek nem kell megvárnia az adott problémák megoldására szánt szabványt. Lásd most a VR.
-
#10554
Abu85
HÁZIGAZDA
Petykemano
#10537
Abu85
HÁZIGAZDA
válasz
Petykemano
#10537
üzenetére
Igen oda lehet tolni extra számításokat, de maga a multi-engine nem arra készült, hogy alapvetően rosszul megírt motorok működésén javítson. Persze segít, de a megoldás inkább a PC-khez való optimalizálás. A legnagyobb probléma az utóbbi hónapokban kijött játékokkal az adatfeltöltés. Annyira logikátlanul vezérelt az adatfeltöltés, hogy túl sokszor kell leállítani a GPU-t. Konzolon ez nem baj, mert ott van aszinkron mód, de DX11-ben erre nincs lehetőség, DX12-ben és Vulkánban lesz. Viszont rövidtávon ez nem jó így sem. Segít ugyan az összes GCN-en és a Maxwell2-n, de a többi hardveren továbbra is gatya lesz. Inkább jó adatfeltöltési stratégia kellene, mintsem tüneti kezelés a gondokra.
-
#10536
Abu85
HÁZIGAZDA
Petykemano
#10535
Abu85
HÁZIGAZDA
válasz
Petykemano
#10535
üzenetére
A legtöbb játékban nem volt lényeges különbség. A probléma alapja ugyanis, hogy a GPU-k a rossz optimalizálás és rossz feldolgozási stratégiák miatt tele lesznek idle buborékokkal, és ez egyaránt érinti az összes hardvert, mert a logikai felépítés hasonló. Persze az idle buborék mérete változó, de a probléma inkább program oldalon keletkezik, így végeredményben minden hardver kb. hasonló büntit kap.
Ha nagyon vissza akarjuk vezetni a problémát az alapokhoz, akkor az lehet a gond, hogy magát az adott motort nem igazán tervezték rá PC-re, vagy szimplán túl öreg. A Nitrous azért fejt ki olyan brutális terhelést, mert eleve PC-re tervezték, és a működést a modern hardverekhez igazították. -
Abu85
HÁZIGAZDA
válasz
Televan74
#10531
üzenetére
Az a baj, hogy ha kicseréli, akkor az sem feltétlenül ér valamit, mert a problémát az idézi elő, hogy az új program úgy terheli a VGA-t, amire a gyári tuning tervezésekor nem számítottak. Ergo a cserekártyánál is megvan esélye annak, hogy az sem lesz stabil.
Az utóbbi időben azért engedték meg a gyártók maguknak a már-már extrém gyári tuningokat, mert az elmúlt egy évben fokozatosan csökkent a programoknak a GPU-ra kifejtett terhelése. Amíg másfél éve tudtunk olyan programot választani a PH tesztbe, ami leterhelte a GPU-t 50%-ra is, addig ma már kénytelenek voltunk ezt a megkötésünket 30%-ra csökkenteni, mert több új játék 25%-ra sem terheli a VGA-kat. És a gyártók valószínűleg arra számítottak, hogy ez a trend belátható időn belül nem fordul meg, de úgy néz ki, hogy megfordul. -
Abu85
HÁZIGAZDA
Igen, és erre egyébként az AMD direkt figyelmeztette a gyártókat. Attól, hogy az aktuális játékokon stabil egy +200 MHz-es tuning még nem feltétlenül lesz az a jövőben. Aztán később nem is engedték, hogy sokat húzzanak a hardvereken. Az NV is most kezd rádöbbenni, hogy marhára nem jó az, ha a partnerek szénnétuningolják a lapkáikat, mert tele vannak TDR-es panaszokkal a fórumok, és a tuning után kell menni az órajelváltások optimalizálásánál, ami aztán lehet, hogy nem stabil a gyári kártyákon. Most egy kártyára minimum egy tucat rutint kell használni, és ide-oda pakolgatni az egyes termékeket, attól függően, hogy sok-e még a TDR-es panasz vagy nem. Ennek az lesz a vége, hogy a problémás játékoknál profilban levágják fix órajelre a kártyát az alap alá úgy 10-15%-kal.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10517
üzenetére
A Nitrous ilyen. Szerintem meg fogják közelíteni a Furmark terhelést, ha így haladnak az optimalizálással. Szóval a beállított tuningok nem biztos, hogy stabilak. De nem ez a probléma vele, hanem az, hogy a gyárilag tuningolt kártyák is nagy százalékban instabilak, és egyre több gyártó panaszkodik a Stardocknak, hogy túl erős a játék terhelése, már alpha szinten. Ez a gyártóknak gáz, mert ha tovább optimalizálnak az Oxide-nál, akkor esélyes, hogy az összes eladott gyárilag tuningolt kártya felét is cserélni kell, ami a legtöbb cégnek hatalmas katasztrófa lenne, szóval most valami szoftveres megoldáson gondolkodnak, ami egy profilban fixálná alacsonyabb szinten az órajelet a tuning ellenére is.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#10433
üzenetére
Szerintem túlságosan csak a TFLOPS-okra koncentráltok. A DX12 és a Vulkan igazi célja nem éppen a teljesítmény drasztikus növelése. Az a DX10 és a DX11 célja volt, csak helyenként elhibázták a működést. Az ipar most a valóban új generációs konzolos motorokra koncentrál, amelyeket régi API-kra portolni sem lehet. Innen két választása van a PC-nek. Vagy leköveti a konzolos API dizájnokat, és hátrányokkal ugyan, de portolhatók maradnak az új játékok, vagy azt mondják, hogy a PC járja a saját útját a konzolra írt AAA játékok nélkül. Az iparág inkább a reform mellett döntött, mert az nem biztosított, hogy a top AAA játékok nélkül a PC-piacon el lehetne adni egy rakás gamer hardvert. Szerintem jó döntés született. IPhone játékok HD-sítéséből a PC nem élne meg.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#10417
üzenetére
Előfordulhat ilyen is. Nyilván az implementációtól nagyon sok függ. Azért a Frostbite-ban a Mantle implementáció a BF4 óta nagyon sokban változott, tehát lehet, hogy egy még újabb architektúrára már nem reagálna így. Önmagában a BF4 egy pilot projekt volt egy olyan ösvényen, amit a DICE előtt senki sem járt. Az optimális használatot pedig ilyenkor ki kell tapasztalni.
Egyébként ugyanezzel a gonddal a Thief is küszködött, és arra kiadtak egy javítást egy évvel később. Persze elsődlegesen nem a gondok korrigálása miatt adták ki, hanem ki akartak próbálni az async shadert élesben.
Viszont lehet vele mit kezdeni. Az AMD ezért ír GCN4 és GCN5 szimulátorokat, hogy a hardver hiányában is előre legyen optimalizálás. Ezt a lehetőséget a többi cégnek is érdemes észben tartani.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#10409
üzenetére
Ezt már többször elmondtam, hogy a low-level API-k alapvető hátránya lesz, hogy a kernel driver megszűnésével átkerülnek a menedzsmentre vonatkozó alapok a programkódba. Így ha érkezik egy új architektúra, akkor azon nem fut olyan jól a programkód, mint a kiadáskor ismert architektúrákon. A GCN3-ra nem jött ki BF4 javítást, mert túl nagy változást igényelt a motorban, de az összes későbbi Frostbite játék már GCN3 optimalizálással érkezett.
Ugyanez lesz a DX12 és a Vulkan. Sajnos előfordulhat, hogy ha veszel egy új hardvert, akkor azzal már nem tudod már olyan részletességgel játszani a kedvenc játékodat, mint az előzővel, mivel nem tudja a gyártó a driverben a megfelelő menedzsmentet ráerőszakolni a programkódra. Erre kell egy patch-et kiadni az adott játék fejlesztőjének. -
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
Locutus
#10362
üzenetére
Az AMD mindig úgy kommunikálta, hogy nagy hatása van a piacra, és tulajdonképpen az volt. Ha nem jött volna ki, akkor jelentősen csúsztak volna a DX12 fejlesztések is, mert nem tudták volna előre felkészíteni a motorokat a fejlesztők a low-level irányra. Ez azt eredményezte volna, hogy 2016 közepéig nem jött volna DX12-es játék. De mivel rengeteg motort előre átírtak az AMD API-jára, így ezeknél a motoroknál már csak a render back-endet kell lecserélni. Hozzávetőleg 120 fejlesztőről van szó, aki ezt megcsinálta az elmúlt másfél évben. Emiatt gyakorlatilag előkészült egy olyan terep, amelyre az elkövetkező egy évben több tucat DX12 és már Vulkan játék is jöhet, mert a render back-endet hetek alatt ki lehet cserélni.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#10353
üzenetére
Az E3-on is ki lehetett az NV standjánál a VR-t. De független stúdiók standjánál LiquidVR volt, még akkor is, ha NV partner volt a stúdió. Egyszerűen számottevően jobban működik az AMD megoldása. A többiek gondja ott kezdődik, hogy nincs grafikus API-juk VR-hez, az hogy hardvernek vannak hiányosságai már csak ráadás lehet. Ez a legfőbb oka, hogy az Intel és az NV nem akar VR tanácsot, mert a jelenleg előirányzott minősítési rendszerrel esélyük sem lenne arany vagy ezüst minőségre. Maximum a bronz, amit megkaphatnak, vagy az "only for multimedia" matrica.
Eleve az arany minősítés tervezett követelménye 10 ms-nál kisebb motion-to-photon latency, ami nem lehetséges Latest Data Latch nélkül. -
Abu85
HÁZIGAZDA
válasz
daveoff
#10336
üzenetére
Promózni meg beszélni lehet róla. Amiről itt szó van az a technikai megvalósítás. Ebben a LiquidVR a mezőny előtt jár, elsődlegesen azért, mert nem korlátozzák a szabványos grafikus API-k a lehetőségeket. Az E3-on nem véletlenül futott minden játékbemutató LiquidVR-en. Például hiába partnere az NV az EVE: Valkyrie című játéknak, akkor sem olyan jó a GameWorks VR csomag, hogy azon mutassák be a játékot. Persze nem írták ki, hogy amin futott az a LiquidVR, mert gondolom a partnerszerződés megtiltotta, de muszáj volt azt használni.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#10321
üzenetére
Csak nem mindegy, hogy mennyit érnek ezek a megoldások. A Latest Data Latch például nagyon sokat, és az így nagy előny az AMD-nek, de ilyen extrákat mindig az elején lehet szerezni. Ahogy kerülnek közel a határokhoz egyre nehezebb további előnyt szerezni, szóval az olló gyorsan záródik össze.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#10317
üzenetére
De azzal előrébb lennének. De az nyilván problémájuk, hogy egy ilyen megoldás nem rajtuk múlik, mert nem rendelkeznek saját grafikus API-val, mint az AMD, így a saját VR csomagjuk tervezésében sokkal korlátozottabb lehetőségeik vannak.
Az NV a fentiek miatt teljesen más opciókat fejleszt a GameWorks VR-be. Nem véletlenül adják hozzá a multi-res shadinget. Nem tudnak olyan késleltetést elérni, mint a LiquidVR, mert nem tudnak kamerapozíciót módosítani képszámítás előtt, de el tudják érni, hogy a képkockán, ami nincs középen, vagyis a szem várható fókuszpontjában az legyen rossz minőségű, tehát kevés számítást igényeljen. Ezzel szintén csökken a késleltetés, de VR-ben a szemed mozoghat, tehát rá tudsz nézni a rossz minőségű képterületekre is, ami már baj. -
Abu85
HÁZIGAZDA
válasz
#45185024
#10296
üzenetére
Jedec szabvány, akkor gyárt ilyet a többi memóriagyártó, amikor akar. Nem a memória a probléma a HBM-nél, hanem az interposer.
(#10284) pengwin: Az MS-nek egyikhez sem kell részesedést vásárolni. Egyszerűen elég terméket rendelni.
Az AMD most abból a szempontból érdekes, hogy a VR biznisz gyakorlatilag egy jó ~180 milliárd dolláros üzletnek tűnik éves szinten, és egyedül az AMD rendelkezik olyan csomaggal, amely ezeket a VR cuccokat problémamentesen meg tudja hajtani. És most a játékokat mindenki leszarja, a nagy biznisz az orvosi, az oktatási és a professzionális felhasználás lesz. Ezért megy most a matek, hogy jó lenne az AMD-ben részesedést szerezni, mert hozzávetőleg 3 évig nem lesz még szabvány, vagyis gyakorlatilag ingyen ebéddé válik minden VR terület az AMD-nek. A Facebookkal nem akar senki sem versenyezni, mert ők eleve rohadt pénzesek, más VR eszközökre szakosodott céget meg nem akarnak venni, mert az Oculus technikailag jobb, és a Facebook pénze garantálja, hogy más ne érhesse utol őket. Innentől kezdve, ha valaki VR-ből hasznot akar, akkor a komponensgyártókat célozza meg. Egyébként nem valószínű, hogy a Microsoft vagy az Intel bármit is elér. Sokkal inkább a Silver Lake az opció, mert ők mindig nagyon rástartolnak az üzletileg kritikus területekre. Nyilván ők is számolgatják, hogy mekkora lesz a VR üzleti felhasználásból származó bevétele, mert az AMD gyakorlatilag az egyetlen jelölt a VR-es alapként legyen szó orvosi vagy oktatási felhasználásról, vagy bármiről.
A Microsoftnak stratégiailag akkor lenne lényeges az AMD-be bevásárolni magát, ha túl sok alternatív területre felhasználja a cég a Mantle-t. Az a Microsoftnak nagyon káros lenne, mert arra kényszerítené az összes gyártót, hogy fejlesszenek egy saját grafikus API-t. Emiatt talán megérné részesedést szerezni, és kierőszakolni a cégen belül, hogy a Mantle halljon meg, mert potenciálisan káros a Microsoft ökoszisztémájára nézve, hogy az AMD minden problémára képes 2-3 évvel hamarabb reagálni. Ez csökkenti a Microsoft szabadságát is a kutatásban, mert bizonyosan ott ordít mindenki a fejük felett, hogy baromira kell a VR-es DirectX, hogy tudják célozni azokat a területeket, amelyeket az AMD már elér. -
Abu85
HÁZIGAZDA
válasz
rocket
#10248
üzenetére
Nem az AotS kapcsán volt róla szó. Az async DMA és compute egy olyan dolog, amit a konzolra dolgozó fejlesztők jó ideje használnak. Tehát semmi újdonság nincs benne, csak PC-re még nem használták sokan (csak a Thief). Elsődleges célja, hogy ingyenessé tegyen bizonyos számításokat, mert ezeket a hardveren belüli buborékokra rá lehet ütemezni. Például shadow mapoknál a shader feldolgozók 90%-a NOP-ot futtat, vagyis nem csinálnak semmit, csak várják, hogy végezzen a ROP a számítással. Ezekre a feldolgozókra ki lehet osztani feladatokat, amelyek addig végeznek, amíg a shadow mapok számítása zajlik. Ergo a teljes számítás, amit ezekre kiosztottak gyakorlatilag ingyenessé válik. Számolt a rendszer egy csomót, de közben kvázi semmit sem lassult a tempó, mert a shadow map számítása tovább tartott így is.
A multi-engine ezeknek a hardveren belüli idle buborékoknak a betömésére jó.
Aztán ott a gyakorlat, hogy ezt ki hogyan használja, mert egészen sok lehetőség adódik azzal a modellel, amit a DX12 lehetővé tesz. Nem muszáj buborékokat tömködni, akár elindítható több alacsony prioritású compute feladat is a grafikai feladatok mellett. Valószínűleg a Nitrous eleve egy nagyon kiegyensúlyozott motor, így nem sok buborékot lehet betömni, ami miatt inkább párhuzamos megközelítéssel dolgoznak a fejlesztők. De az valóban igaz, hogy a motorok 99%-a a Nitrous teljesítményének a töredékét sem képes hozni, és így logikus, hogy jóval több idle buborékok lesz a hardvereken belül. Így például ezeknél a motoroknál lehet más megközelítéssel is élni. Írtam az ezzel kapcsolatos cikkben, hogy az NV valószínűleg azért nem tiltja le csípőből ezt a képességet, mint az Intel, mert egyrészt szeretnék használni az async DMA-t, másrészt nagyon valószínű, hogy van olyan megközelítés, amitől a Maxwell 2 is gyorsul, mert valószínű, hogy a compute bizonyos grafikai state-ekre épül. Bár a Maxwell 2-ről nincs dokumentáció, de nagyon jellemző, hogy stateful hardvereken a compute és a pixel feladatok ugyanazokat a state-ket használják. Nyilván, ha az NV azt gondolná, hogy a fejlesztők nem képesek olyan kódot írni, ami a hardverükön gyorsul, akkor nem is gondolkodnának a multi-engine hardveres kezelésén.Az meg teljesen normális, hogy egy fejlesztő letilt dolgokat, bizonyos alternatív kódrészletekkel, ha az adott implementáció nem felel meg az adott hardvernek. Pontosan ezért van a Nitrousban egy NV-re kialakított kódrészlet a fő programkód mellett. Ez nem tudom, hogy miért újdonság, hiszen lassan egy évtizede folyamatosan alkalmazott praktika.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#10265
üzenetére
Csak más fog velük játszani. Bár a fejlesztők is gamerek bizonyos szinten, szóval ők is játszanak majd.
Hidd el egyébként nem hülyeségből kérnek olyan dolgokat, amelyekkel hatékonyabban tudnák programozni a GPU-kat. A mostani nyelveket a tíz évvel korábbi modellekre találták ki. A Vulkan az első API, amely lépéseket tesz annak érdekében, hogy C++11 vagy akár C++14 részhalmazának képességeit el lehessen érni. Ez az olyan cégeknek, mint az Ubisoft nagy segítség lenne, mert ők már most azon gondolkodnak, hogy átvisznek bizonyos számításokat a CPU-ról a GPU-ra. GPU-driven pipeline modell.
És itt megint csak a PC-ről van szó, mert konzolon megcsinálják, itt az a kérdés, hogy PC-re hogyan oldják meg. Nyilván első körben az executeindirect elég, de később szükségük lesz a Vulkan újításaira.
-
Abu85
HÁZIGAZDA
Nem feltétlenül függ az API-tól, hogy egy játék Win10 only-e. A Vulkan éppúgy lehet Win10 only, ahogy a DX12, mert a WDDM 2.0-ból profitál. Az valóban igaz, hogy a Vulkan esetében van esély rá, hogy egy játék elinduljon Win7/8.1/akárminamireleszVulkan, de ha egy motor valamilyen szempontból kötődik a WDDM 2.0-hoz, vagy egy hasonló modellhez, amit nem lehet igazán jól visszamappelni a WDDM 1.x-re, akkor Vulkan ide vagy oda a programhoz Win10 kell.
Ettől függetlenül a Vulkan valamivel jobb API. A DX12 nem tartalmaz olyan funkciókat, amelyeket a fejlesztők kifejezetten kértek, és elérhetők konzolon is. Mint például az ordered atomics, GPU dispatch, SIMD lane swizzle, template támogatás a shader nyelvben. Ezeket a Vulkan tudja.
-
#10244
Abu85
HÁZIGAZDA
Dark KillerX
#10238
Abu85
HÁZIGAZDA
válasz
Dark KillerX
#10238
üzenetére
De az MS bármikor mondhatta volna nekik, hogy köszönjük értékeljük a munkátokat, de nem kérjük. Viszont ezzel sem lenne előrébb az ipar, mert akkor is kiadták volna a saját API-jukat, és akkor ott tartanánk, hogy az Intel és az NV is tervezné a sajátját. Az átmenet rossz lesz, de összességében jól jártunk azzal a váltással, amit az MS végigvitt. Lehet, hogy jövőre lesz némi kellemetlenség belőle, de két éves távlaton túl csak pozitívumokat fog hozni.
-
Abu85
HÁZIGAZDA
válasz
Televan74
#10153
üzenetére
Arról van szó, hogy van két nagyon jövedelmező terület, amely befuthat a jövőben. Az egyik az AR, míg a másik a VR. Az AMD bemákolta a helyzetet úgy, hogy senki másnak nincs működő csomagja ezekre, és gyorsan alakítottak egy cégen belüli csoportot, hogy reagálni tudjanak az AR és a VR irányára. Ez lehetővé teszi, hogy hamar megoldjanak hardverekkel és szoftverekkel olyan problémákat, amelyek előreviszik ezeket a piacokat.
Ezt most ki kell használni, mert olyan többet nem lesz, hogy a konkurensek sehogy sem készültek fel egy már látható jövőképre. -
Abu85
HÁZIGAZDA
válasz
proci985
#10142
üzenetére
Az Oculus SDK nem támogatja a multi-GPU-t, de a LiquidVR igen, szóval azokon a játékokon fog működni, amelyek LiquidVR-t is használnak. A Hawaii nem rossz, de a VR-hez egy fokkal előnyösebb a finomszemcsés preempciót használó hardverek, mint a Tonga és a Fiji.
(#10143) NetTom: Az Oculus a Facebooké.
Szerintem az ilyen befektetési csoportokat annyira nem érdekli, hogy business vagy experience vonalról válik be egy dolog. De önmagában a VR egy business is lesz, mert a VRLA-n már elég sok ötlet merült fel az orvosi felhasználásról, oktatásról, stb. Lehet, hogy ez érdekli őket igazán.
Egy biztos, hogy nem a Zen érdekli őket, mert az csak egy szimpla processzor. -
#10141
Abu85
HÁZIGAZDA
FollowTheORI
#10139
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#10139
üzenetére
Nem teljesen. A VR a kulcs, mert az a piac felfutóban van, és az AMD egyedül kínál csomagot hozzá, egészen addig, amíg nem lesz szabvány. Ez érdekli őket, nem a Zen.
A Silver Lake amúgy is nagyon érdeklődik manapság a VR célpontok iránt.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10082
üzenetére
Amit az Ubisoft akar az más. Oda ExecuteIndirect kell, de ezt a Unity még nem jól használta a konzolokon. Nem is igazán lehet használni magas szintű eléréssel. PC-n is csak az AMD-n érhető el ez a fícsőr DX11-ben, ráadásul ott is egy AGSL kiterjesztéssel, ami ugye a multi-draw indirect. Ilyen kiterjesztés az Intelhez és az NV-hez nincs.
A SIGGRAPH alapján az Ubi valszeg átvált teljesen DX12-re azért, hogy PC-n is működjön az ExecuteIndirect, mert annak meg nincs értelme, hogy DX11-ben csak AMD-re írnak játékot. Persze azt nem tudom, hogy más csinál-e multi-draw indirect kiterjesztést. Erre van opció, de igazából felesleges, amikor ott van szabványosan a funkció a DX12-ben. Esetleg OpenGL4-DX11 interoperabilitás lehetséges, de nem hiszem, hogy ez minden vágyuk. -
#10069
Abu85
HÁZIGAZDA
tibcsi0407
#10068
Abu85
HÁZIGAZDA
válasz
tibcsi0407
#10068
üzenetére
A valós különbségről sokat elárul a Nitrous. Ezt a motort úgy építették, hogy minden gyártóval együttműködtek, és egy évvel korábban megosztották velük a teljes forráskódot. Ez a normális fejlesztés. Sajnos lesznek olyan fejlesztések, ahol megírják a kódot az Xbox One-ra, és azt egy az egyben áthozzák PC-re. Na az gáz lesz, mert sokkal rosszabbul teljesíthet benne minden nem GCN architektúra, csupán azért, mert minden döntést csak a GCN-t szem előtt tartva hoztak meg. Ebből lesz szerintem a jövőben a probléma, nem az olyan fejlesztési modellből, amit az Oxide folytat a Nitrous esetében.
Az világosan látszik, hogy az Oxide járja most a nehezebb utat azzal, hogy mindenkire optimalizálnak, viszonylag sokat. És ez előtt le a kalappal, de félő, hogy a többség csak az XO-ra fog optimalizálni. -
#10066
Abu85
HÁZIGAZDA
tibcsi0407
#10060
Abu85
HÁZIGAZDA
válasz
tibcsi0407
#10060
üzenetére
A naiv konzolportok rosszabbak lesznek, mert olyan kódot is át lehet hozni az Xbox One-ról, amely sokkal rosszabb hatékonysággal fut a többi architektúrán, mint például a Nitrous. Ez azért nem egy átgondolt stratégia sajnos, függetlenül attól, hogy az MS arra buzdít, hogy jó az Xbox One kód PC-re. Persze GCN-re jó, de a többire egyáltalán nem az.
-
#10057
Abu85
HÁZIGAZDA
tibcsi0407
#10054
Abu85
HÁZIGAZDA
válasz
tibcsi0407
#10054
üzenetére
Azt nem kell implementálni, mert a feldolgozási modell követeli meg a TIER3 bekötést. Arra kell írni a kódot, és azt a kódot tudja az API úgy kezelni, hogy fusson az alacsonyabb szinteken. Maga a DX12-ben nincs definiálva az, hogy csak TIER2 vagy TIER1 bekötésre írsz programot. Ilyen formában egy kód nem fut az API-n, mert a Shader Modell 5.1 hiányolni fogja a shaderekben a bekötést. Nem fogja lefordítani a kódot D3D bájtkódra, mivel az API nem fogja tudni kezelni a shaderbe írt memóriaelérés nélkül. Erre a validátor fel fogja hívni a figyelmet.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De köszi. 
Ú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.
- VR topik (Oculus Rift, stb.)
- OFF TOPIC 44 - Te mondd, hogy offtopic, a te hangod mélyebb!
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Kuponkunyeráló
- PayPal
- Arc Raiders
- Proxmox VE
- Építő/felújító topik
- Projektor topic
- Kapható a strapamobil, aminek kikapcsolása nélkül lehet kicserélni az aksiját
- További aktív témák...
- GYÖNYÖRŰ iPhone 12 Pro 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3281, 100% akkumulátor
- Gamer PC-Számítógép! Csere-Beszámítás! R5 8400F / RX 6800 16GB / 32GB DDR5 / 1TB SSD
- Xbox Series S 512 GB + kontroller 6 hó garancia, számlával!
- Playstation 4 GoldHEN 12.02 FW - BD-JB Lapse lemezzel és sok játékkal
- JBL Quantum400 gamer fejhallgató
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő