Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12893
üzenetére
A WHQL-en sajnos nem biztos, hogy mindent lefuttatnak a gyártók. Csak azt, amit az MS kér. Ezt azért teszik, mert egy aláírás így is benne lesz három hétben.
Valójában a driver az eléggé speciális terület. Egyrészt egy meghajtó sosem lesz kész. Másrészt sosem lesz hibátlan. Viszont, ha azt nézzük, hogy melyik megy át több teszten, akkor a béták a WHQL előtt vannak.
-
-
Abu85
HÁZIGAZDA
A FutureMark régóta szokott reklámot biztosítani a gyártóknak. Úgy tudom, hogy most a Galax vásárolt magának felületet. Kb. annyira lényegtelen, mint az MSI vagy a Sapphire korábbi reklámjai. Ettől a Galax kártyák nem lesznek jobbak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12826
üzenetére
Az egész DX11-es működési modellnek nincs semmi értelme. Ezt már a Microsoft is elmondta az idei GDC-n. Lassan egy évtizede rossz irányba fejlesztettek, mert azt hitték, hogy ezzel jót csinálnak. Nem baj egyébként, mert nyilván nem szándékosan vágták maguk alatt a fát, de ha megnézzük a mi történt a régi DX-ekben, akkor az állapotblokkok, a nagy állapotcsoportok és végül a deferred context is totális bukás. Az első kettő alig ér valamit, míg a harmadik opció implementálása olyan drága, hogy másfél évig kell kódolni a működését. Nagyon sok motor elindult a deferred context felé. Még a Frostbite is, csak fél év után ráhagyták, mert nem éri meg. Most képzeld, ha egy EA azt mondta, hogy nem finanszírozza tovább, akkor egy kisebb kiadó mit mond...
-
Abu85
HÁZIGAZDA
válasz
Petykemano
#12825
üzenetére
Igazából a Microsoft ajánlásait csak az Intel követi. Az NV nagyon nem, míg az AMD a kettő közötti vonalat akarja megtalálni. Mivel nem a gyártóknál van a hiba, hanem az API-ban, így egyik sem jó megoldás. Az Intelé és lényegében a Microsofté azért nem, mert bár sok szabad processzor erőforrást hagy a programnak, a többi driver miatt ezekhez a fejlesztők nem nyúlnak. Az AMD megoldása azért nem jó, mert az ideálisnak vélt balanszra való törekvéssel az Intel és az NV iránya közé esik, és ez igazából a kétmagos HT-s gépeken ideális. Az NV megoldása pedig azért rossz, mert nem veszi figyelembe a kétmagos procikat és a kétmagos gépeken csökkent a minimum fps-en.
A megoldás erre az, amit az MS javasolt. Aki skálázódást akar menjen DX12-re. Ott nincs kernel driver, ami elvegye az erőforrást. -
Abu85
HÁZIGAZDA
válasz
Petykemano
#12823
üzenetére
Nem. Semmi köze az emulációhoz. Ahhoz van köze, hogy mennyi processzoridőtől érdemes megfosztani a programot. Le lehet programozni, hogy a driver elvegye az erőforrások többségét csak nem érdemes. Eleve azért nem, mert az MS arra kérte a fejlesztőket, hogy többet ne használják a deferred contextet. Azért hozták a DX12-t, hogy az elhibázott irányt kiváltsák vele.
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#12820
üzenetére
Akkor az valami bug lesz. Nem így kellene működnie.
Ja igen, akkor már megjelent. Az első EGO sem sikerült jól a DiRT első részében. Ez ilyen tanulópénz szintű dolog. A nagy változások nagy kockázattal járnak. Majd lesz fejlesztett verzió jövőre.
Az EGO 3 stabilabb volt. A DiRT Rallyhoz jobban illett.
-
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#12813
üzenetére
A legfontosabb kimaradt: GPU Particles
Az Advanced Blending az Intel effektje. Lehetővé teszi a korrekt megjelenítést az átlátszó felületekhez.
A program sokat változott, így meg kell várni az új drivereket, mert a mostaniakkal vannak benne hibák.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
Petykemano
#12807
üzenetére
Ha nincs spanja, hogy lezsírozzon neki egy cserét, akkor el kell adnia a 960-at. Azt pedig nem tudja olyan drágán eladni, hogy megérje.
-
Abu85
HÁZIGAZDA
válasz
arcsi84
#12805
üzenetére
Most már semmit. Sokat buksz ha eladod.
A 970-en 4 GB van, csak fél GB-ot nem lehet elérni a teljes sávszélességgel. De ez is Maxwell v2, mint a 960.
A 390-nek tuti elég egy 500 wattos FSP. Az elég jó táp. Igen ez csak a GCN2. Ennek az a hátránya, hogy nem támogatja az FP16-ot. De ettől futni fognak a programok, csak GCN3-on bizonyos puffereket kétszer gyorsabban és feleannyi sávszéllel is ki lehet majd számolni.
A 380/380X egyértelműen jó választás a GCN3 miatt. De a legjobb a 285, mert az már olcsó a neve miatt és ugyanaz.
A 960 4 GB biztosan nem éri meg a felárért.
A PBR az egy új lehetőség a fejlesztőknek. Mennek előre. Normálisan megcsinálni nagyon nem egyszerű, így csak a top cuccok használják tényleg erőteljesen. Frostbite, CryEngine, Dawn Engine.
-
Abu85
HÁZIGAZDA
válasz
arcsi84
#12802
üzenetére
Itt az is nagyon fontos kérdés, hogy kit tekintünk játékfejlesztőnek. Aki szarik bele és áthozza az Xbox One kódot módosítás nélkül, vagy aki tényleg portolni fog.
Egyébként a DX12-nek nem lesz köze a sávszélhiányhoz. Sokkal inkább a PBR terjedésének. PBR-es motor például az új Frostbite. [link]
A DX12 maximum olyan dolgokat hoz csak be, mint az aszinkron compute, ami egy nagyon elterjedt funkció lesz a motorokban, hiszen kvázi ingyen lehet compute-ot futtatni. Ez nem jelenti azt, hogy a Maxwellel nem törődnek, csak az ingyen effekt az ingyen effekt.
Ha a Maxwell nagyon fontos megírják CUDA-ban is a kódot HyperQ-ra. -
Abu85
HÁZIGAZDA
válasz
#85552128
#12766
üzenetére
Az nem nagy üzlet, mert a HBM1 fenntartása nekik nagyon hátrányos. Nekik az volna a jó, ha mindenki HBM2-t rendelne. De ha nem sikerül implementálni, akkor meg rendelés sem lesz. És ez nem csak a Hynix problémája, hanem azé a vállalaté is, aki nem tudja implementálni. Ezért jobb a Hynix ajánlásait követni.
Csak két GPU-gyártó létezik, és az AMD a HBM1 után biztosan HBM2-re lép tovább. Az NV pedig a két új Teslához HBM2-t használ.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#12764
üzenetére
A HBM1-et használják majd mások. A Hynix továbbra is kiáll amellett, hogy nulláról senki se lépjen HBM2-re, így előbb a HBM1-re építsen. Túl nagy a kockázata, hogy a HBM2-es terméket törölni kell, ha nincs tapasztalat a HBM1-ről. Több FPGA dizájn használ majd HBM1-et.
-
Abu85
HÁZIGAZDA
Az 512 GB/s az 384 bitről van. Az 512 bit GDDR5X-szel nem ajánlott, mert vállalhatatlanul bonyolult. A 384 bithez is a maiaknál sokkal komplexebb routing kell és jobb PCB. Bár a Micron szerint 512 bit lehetséges, de nem látnak rá esélyt, hogy bárki bevállalja. Ahhoz aztán nagyon tök kell.

A GDDR5X célja egyébként egyértelműen nem a fogyasztás javítása volt. Ebből a szempontból a GDDR5 is jobb opció.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
A látvány terén is egyértelmű a különbség.
A Ryse nyilván teljesítményigényes program, de még így is jobban van optimalizálva, mint a többség.
Mindegy, hogy van-e PC-n az Order attól a leképező etalon.(#12715) huskydog17: De az említett stúdiók technikailag már teljesen lemaradtak. Nem baj egyébként, mert függetlenek, tehát nincs mögöttük egy EA, aki kinyitja a pénzcsapot bármilyen kérésre, de az biztos, hogy a függetlenként még technikailag magát úgy ahogy tartó Rebellion is kezd lemaradni. Egyszerűen ők is érzik, hogy nem lehet ugyanazt hozni, mint amit tud a Frostbite, ha az R&D tizedannyi vagy még kevesebb.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12709
üzenetére
Elsődlegesen azért olyan szép az Order, mert tényleg új generációs post-process pipeline-t alkalmaz. Abszolút nem erős az elmosása. Láttam sokkal rosszabbat is a TXAA-val, de az nem használ oversharp filtert.
PC-be azért kellenének ezek, mert az Order 1886 megoldott egy csomó aktuális grafikai problémát, mint például a specular aliassing, amire PC-n nincs megoldás még, de nyilván ahogy dolgozzák ki az új post-process pipeline-okat úgy fogjuk kivezetni az előző évtizedből beragadt technikákat. Ez inkább kutatás és idő kérdése, vagyis nem technológiai probléma. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12703
üzenetére
Az nincs elmosva, csak borzalmasan komplex post-process pipeline-ja van, ami nem csak az adott képkockára számol, hanem temporálisan is vannak adatai. Az egész rendszer 12 analitikai élsimítási pipeline-ból áll össze, amelyek specifikusan reagálnak a problémákra. Hasonló rendszereket fogunk látni majd a PC-n is, ha végre eljutunk oda, hogy a mostani, lényegében előző évtizedből származó post-process pipeline-okat kidobjuk.
(#12702) imi123: Szerintem érdemes jobban megnézned. A Witcher 3-nál már az előző Frostbite is jobb volt Dragon Age-ben, az új pedig összehasonlíthatatlanul jobb.
-
Abu85
HÁZIGAZDA
válasz
imi123
#12700
üzenetére
Nekem mindegy, hogy mi számít nektek. Alapvetően már a futottak még kategória is szép. De az kétségtelen, hogy a Star Wars Battlefront, a Ryse vagy az Order 1886 grafikájával nem vetekszik semmi. Azt nem mondom, hogy ezek legyenek a normák, mert a legtöbb fejlesztőnek nincs arra pénze, hogy ilyen minőségű leképezőket fejlesszen. Ettől vannak a futottak még kategóriában.
Az említett három játék az előnyeit nem a rajzolásokkal szerezi, hanem a PBR megvalósításával. Ebben sokkal jobbak mindennél. Az Order még olyan gondokat is kezel, mint a specular aliassing, ami már régóta bassza a csőröm, és folyamatosan mondogatom az AMD/Intel/NV-nek, hogy kezdjenek már vele valamit. -
Abu85
HÁZIGAZDA
Pedig a PBR eléggé sávszélgyilkos. Jóval több bitnyi információ szükséges pixelenként.
Project Cars leképezője abszolút nem modern. A Witcher 3-ba pedig az eredetileg tervezett E3-on bemutatott leképező nem került bele. Ezek a játékok a renderer tekintetében messze elmaradnak attól, amire a Frostbite és a CryEngine képes. Még attól is elmaradnak, amit a leváltott Frostbite 3 tudott, pedig az már öregnek tekinthető.
Az a baj, hogy nagyon sokan vannak már a futottak még kategóriában, tehát nagy átlagban nem tűnik fel, hogy ezek mennyivel rosszabbak, mint amit el lehet érni, csak akkor, ha előveszünk olyan címeket, mint a Star Wars Battlefront, a Ryse vagy az Order 1886. -
Abu85
HÁZIGAZDA
A szávszélre vonatkozó takarékosság ma inkább pénzhiány, vagy mobil fókusz eredménye. Az idei évben nyilvánvalóvá vált, hogy csak pár tradicionálisan PC-s motor fejlődik igazán: a Frostbite, a Nitrous, a LORE és a CryEngine. A többiek vagy nem értékelik az asztali PC-t annyira, hogy pénz rakjanak bele, vagy szűkös költségvetésük van erre.
A piac láthatóan kettészakad. Lesz egy nagyon nagy, elsődlegesen mobil fókuszt előtérbe helyező csoport, és marad pár olyan stúdió, akik szerint az asztali PC még mindig megéri a befektetést. A két opció között viszont nagyon kinyílik az olló. Azt ne tekintsük optimalizálásnak, amikor szimplán pénz hiányában nincs lehetőség olyan szintű PBR-t használni, mint amilyet az új Frostbite használ például. -
Abu85
HÁZIGAZDA
válasz
#85552128
#12646
üzenetére
AAA nem biztos. Nagyon sokan csak úgy építenek low-level támogatást a játékba, hogy lefrissítik az új motorverziót. Az új Unity-ben és UE-ben a DX12 csak egy checkbox. A fejlesztőnek be kell pipálnia és köpi a kódot az SDK. Így készült el a Caffeine is. Bárki aki UE4-re épít, az innentől leszedheti az UE 4.9 DX12-es verzióját. Pipa be a DX12 elé és DX12-es a program. Eddig tart a portolás.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#12640
üzenetére
A userek a következő év első felében fognak ebből tömeges szinten profitálni. Ma csak pár DX12-es program van. De egyébként a shaderekkel mindenki küzdeni fog. Bár talán nem annyit, mint a Frostbite, mert nekik eleve az a problémájuk, hogy minden shaderük olyan nyelvben van, amit csak a Mantle fogad el. A többiek szerintem eleve szabványos nyelvre írják át a shadereiket. OpenCL C++ elég jó opció.
A Frostbite Team már ezzel nem akar foglalkozni. Marad ez a nyelv, és onnan fordítgatnak. -
Abu85
HÁZIGAZDA
válasz
nonsen5e
#12638
üzenetére
Az új Frostbite már van az NFS-ben és az SW Battlefrontban. A low-level patch attól függ, hogy mi lesz a megoldás a shaderekre, mert azokat szerintem hét szentség, hogy nem írják újra. Szerintem nekik a Vulkan a legjobb opció, mert írhatnak egy olyan fordítót, ami a meglévő HLSL ext. shadereket lefordítja SPIR-V-re. Azért gondolom nekik sem mindegy, hogy cirka 30-40 ezer kódsort újra kell írni, vagy csak fordítót használnak. És akkor innen maradhat az a fejlesztés, amit használnak. PSSL kódok, abból HLSL ext. konverzió, és ebből megvan az Xbox One és a PC port. PC-n SPIR-V-vel.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#12636
üzenetére
Olyan nincs, hogy komolyabban kihasználja, vagy kevésbé. Maga a DX12 és a Vulkan annyira különbözik a DX11-től, hogy teljesen új motorstruktúrát követel meg. A DX11-hez optimalizált struktúrával nem működik. És ez látszik az UE4-en, illetve a Unity 5-ön. Hiába van bennük a DX12 még sok helyen nem gyorsabb, mint a DX11, mert nem alakították át a működési struktúrát.
Ahol először működni fog az a Frostbite új verziója, mert ott már kész a motor struktúrája a low-levelhez. Viszont ott az a gond, hogy egy rakás kódjuk van a fejlesztőknek HLSL ext. nyelven. Ezt a nyelvet sem a DX12, sem pedig a Vulkan nem támogatja direkten. Szóval át kell konvertálni HSLS 5.1-be, vagy írni kell egy SPIR-V-re dolgozó fordítót hozzá.
-
Abu85
HÁZIGAZDA
Az AFR DX11-ben nagyon nehéznek tűnik a Just Cause 3-ban. A Waveworksnek van normál és temporális variánsa. A normál drágább, de működik vele az AFR, míg a temporális verzió gyorsabban dolgozik, viszont nem implementálható vele az SLI és a CF. Valószínűleg a temporális verziót választották, ezért nincs AFR. Ha meg a normál verzió fut, akkor lehet AFR.
-
Abu85
HÁZIGAZDA
Abban volt szó dollármilliókról?
Mi a szép? Az biztos, hogy a Thief fény-árnyék hatásokban verhetetlen jelenleg. De más stílus. A hangulaton nem tudom mit értesz, de ha az élményt, akkor technikai dolgokba szerintem ezt ne keverjük bele.
A Witcher 3 lehetett volna szebb is, ha berakták volna a tervezett effekteket. Ez szintén egy middleware probléma sajnos. Dying Light nem kimondottan szép. Elég rossz a LOD-kezelése, így távolra elnézve kifejezetten ronda lesz.Figyelj, erre azt tudom írni, hogy hozzanak bizonyítékot arra, hogy a GameWorks jól működik. Mind sebességben, mind minőségben. Amíg ez nincs, addig természetes, hogy kapni fogja a sarat. És természetes, hogy a PC-s játékosok itt a leghangosabbak, mert ők kerültek a fallosz rosszabbik végéhez.
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#12482
üzenetére
Ezt félreérted. A Speedtree csak akkor middleware, ha úgy építed be. Van erre is licenc, de nagyon sokan nem így építik be. Egyszerűen csak fogják a forrást kiszedik, ami kell és azt beleírják a motorba, mintha őt írták volna az egészet. Ilyen formában ez közelében sincs a middleware implementációkhoz. Így már nem middleware-ként működik a Speedtree, hanem egy teljesen beépített rendszerként. Ennek nyilván az előnye, hogy rendkívül gyors. A hátránya viszont, hogy ha jön egy új Speedtree verzió, akkor a csere nem annyi, hogy betöltöd az új middleware-t, hanem konkrétan megint elölről kell kezdeni mindent. Ezért is adják a cégek drágán az efféle licenceket, mert aki egyszer egy verziót kért, az már nem kér újat soha. Tehát másképp kell fizetniük a technikáért.
Természetesen van olcsó licenc, de ott ne is álmodj róla, hogy be tudod majd integrálni a motorba. Viszont könnyen fejleszthető. -
Abu85
HÁZIGAZDA
válasz
huskydog17
#12480
üzenetére
De a Speedtree esetében a licenc nagyon rugalmas. A legtöbb nagy kiadó azt választja, hogy megveszi magának valamelyik verziót és onnantól kezdve szabadon fejleszthetik házon belül. Ez persze marha drága, viszont ilyen formában a Speedtree esetében tulajdonképpen kutatást veszel és nem konkrét implementációt, mert azt a kutatásra építve írod be a motorba. Vagyis ilyenkor a motorba másképp van implementálva a Speedtree. Kvázi nem middleware-ként, hanem a motor részeként. Ez sokkal inkább hasonlít ahhoz a modellhez, amit például régen követtek a GPU-gyártók az effektfejlesztéshez. Megcsinálták a kutatást, csináltak rá egy példaimplementációt, de a végén úgyis át írták a kódot a fejlesztő.
Ugyanilyen licence egyébként van a Havoknak is. Marha drága, de ezért működik bizonyos játékokban piszok jól. Ki van vágva a forrásból ami kell, és marhára mélyre be van integrálva a motorba.
-
Abu85
HÁZIGAZDA
válasz
imi123
#12475
üzenetére
Ez nem vicc egyébként. Ha a PC-s port minőségi, akkor az AMD sokat fizet. Ott van most a Star Wars Battlefront. Az több millió dolláros üzlet. Persze annak nem csak a kulcsok a részei, hanem az exkluzív reklám.
Sajnos az is előfordulhat, de az is fejlesztői hanyagság kategóriába sorolható. Méghozzá abba, hogy áthozták a DX12-es Xbox One kódot PC-re mindenféle reális optimalizálás nélkül. Ez egyértelműen legalább annyira rossz, mint ha middleware-eket használnának, mert egy Xbox One-hoz tervezett memória menedzsment, csak a GCN2-n fog jól működni. Abból még a GCN1 és a GCN3 is hátrányt szenved. Azt meg kell érteniük a fejlesztőknek, hogy a DX12-ben nincs kernel driver, ami helyettük optimalizálja a memória és az erőforrás menedzsmentet. Itt le kell ülni, és a motorba le kell kódolni egy általánosan jól működő modellt.
-
Abu85
HÁZIGAZDA
Ki mondta, hogy annyit perkálnak le érte? A millió dollárok csak akkor jönnek elő, ha kódokat vásárolnak. Ha megüti a játék azt a mércét, amiért megéri venni pár százezer kódot.
Én nem láttam még idén a Thiefnél jobban optimalizált játékot (60-70%-ra terheli a GPU-kat, egy mai év végi játék a 20-30%-ot sem éri el), vagy olyat, ami olyan skálázást csinál, mint a Dirt Rally. [link] - nem beszélve arról, hogy sosem láttam még olyan játékot, ami ennyire nem küzd a részecskeszimuláció szintjén a többletrajzolás problémájával. Egyszerűen nagyon konstans a sebesség, akármilyen közeli a kamera, és akármennyi a részecske.
Mondj egy olyan GameWorksös címet, amelyben a GameWorksnek nincs valami problémája a sebesség vagy minőség tekintetében. Nem véletlenül alakult ki a világon a Shitworksözés, vagy a Game(Don't)Worksözés. Szerinted van olyan fejlesztő a világon, aki bármit is tud tenni azzal, hogy az által kapott lényegében dll-ben szállított zárt kód nem működik jól? Nem ez a probléma gyökere, hanem az, hogy akármilyen minőséget elfogad az NV és fizet érte, de a GameWorks a probléma része, mivel hogyan várhatnák el azt, hogy a program optimalizált legyen, ha nem biztosítják a forráskódot a fejlesztőnek, hogy optimalizálja.
Nézd meg mi történik a világban. Kétféle általános fejlesztői nézőpont van most. Menjünk a middleware-ek felé (és nem csak a GameWorks, hanem mindenféle middleware felé), mert az olcsó és ennyi. Ilyet alkalmaz az Ubisoft, az Epic, a Rocksteady/Warner, stb. Az eredmény AC Unity, AC Syndicate, UE4 PC-s leképző, Batman AK. A másik opció az oké, hogy a middleware olcsó, de lassú és bugos, illetve esetenként zárt is tehát javítani sem lehet. Az efféle távolodjunk a middleware-ektől irányba megy az EA, a Square Enix EIDOS csoportja, a Crytek, stb. Az eredmény Star Wars Battlefront, Thief, Ryse. Az egészen egyértelmű, hogy melyik működik, mint ahogy az is egészen egyértelmű, hogy melyik irány oldható meg olcsóbban, sokkal olcsóbban. Létjogosultsága mindkettőnek van, ez vitathatatlan, mert bizonyos kiadók nem engednek a minőségből, míg bizonyos kiadók egyszerűen nem rendelkeznek akkora tőkével, hogy a PC-vel szimplán csak minimálisan is törődjenek. Ugyanakkor a PC-s játékosok szemszögéből a middleware-ek csak rossz portokat fognak jelenteni. Pusztán azért, mert meg kell küzdeni a bugjaival, a nehézkes integrálásával, és rosszabb esetben azzal, hogy szimplán a zárt kód miatt implementálni sem lehet megfelelően, mert nem tudod módosítani, hogy a leképezőhöz igazítsd. Egy működő leképezőt pedig szimplán egy middleware effekt beépítéséért nem fognak átírni. Ilyenkor jön a "Nézd a downgrade-et az E3-hoz képest!", lásd Witcher 3. Szemét fejlesztők nem ezt ígérték. Hát persze, de mit csináljanak? XY effektért készítsenek alternatív leképezőt, csak azért, mert az effekt nem igazítható hozzá a stabil és kész leképezőhöz? Inkább búcsút intenek az effektnek.
-
Abu85
HÁZIGAZDA
Éppenséggel de. Sokaknak már a PC egy hatalmas nyűg. Inkább elfogadják az óriási gépigényeket, ha ezért is kapnak támogatást a porthoz. Az NV csak arra kéri őket, hogy ne módosítsák az effektjeiket a jobb sebességért. Vannak persze még kiadók, akik nem akarják, hogy a PC egy szemétdomb legyen, de ők egyre kevesebben vannak. Inkább azok a kiadók vannak többen, akik elfogadták, hogy a konzolpiac az egyetlen értékelhető terület, és a PC pedig mindegy. Csinálnak egy portot, ami épphogy működik, oda pedig tökéletesek a middleware-ek, akár zárt, akár nyílt.
Nyilván ebben a kiadók többségének igaza van. Sokkal nehezebb olyan szuperoptimalizált PC-s portokat csinálni, mint a Star Wars Battlefront, a Sniper Elite 3, a Tomb Raider, Dirt Rally, Thief, stb-stb. Sokkal könnyebb azt mondani, hogy a PC egy másodlagos platform a konzol mögött, és eszerint kell hozzáállni. Az, hogy az NV ilyen felfogásra is fizeti a marketingtámogatást, csak erősíti ezeket a kiadókat abban, hogy jól választottak, amikor úgy döntöttek, hogy elvágják a PC-s portoktól a pénzcsapot. Ezért kaptunk idén Batman AK-féle szörnyűségeket. Egyszerűen már ezért a minőségért is fizet az NV. Régen nem fizettek volna, mert volt egy léc, amit azért át kellett volna lépni. Ma akkor is fizetnek egy rakás kulcsért, ha a PC-s port egy rakás szar. Egyszerűen a minőséget mennyiségre váltották.
Az AMD-nek azért sikerül mindig szuperoptimalizált játékokat kihozni, mert nagyon magasan tartják a lécet. Ha azt a játék nem ugorja meg, akkor még a fejlesztőnek kell fizetni, hogy az AMD egyáltalán foglalkozott velük. Mivel ilyen formában sokkal rosszabbul járna a kiadó, így törekednek arra, hogy a meghatározott minőségi szintet elérjék. Akár extra befektetéssel is, mert ha ez megtörténik, akkor az AMD kinyitja a pénzcsapot, és egy csomó kulcsot vásárolnak, ami végső soron már megéri.
Azt egyébként nem mondanám, hogy az NV felfogása hibás. Tény, hogy a PC-s játékosoknak sokat árt, mert semmi sem kényszeríti a partnereket, hogy legyen jó a port, viszont az NV-t ez már nem érdekli. Akármilyen lesz megveszik a kulcsokat.A kettő között az van, hogy a fejlesztőnek mi a jó. Az AMD-féle dolgoznotok kell azért, hogy fizessünk a kulcsokért, mert nem fogadunk el akármit. Vagy az NV-féle mindegy a minőséget mindenképpen megvesszük. A legtöbb vezetőségben utóbbit választják, mert a gyártói pénz biztos. És azért már megéri portolni. A piacon pedig elég, ha a konzolport jól teljesít, a PC mindegy.
-
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#12447
üzenetére
Jó, de azokat nem vigasztalja a probléma ritkasága, akiket pont érint.
Persze kiállhatnának a gyártók, hogy eladtunk már x-százezer példányt és csak x-száz report van a gondról, de ez azt hiszem, hogy minden esetben csak olaj lenne a tűzre. 
-
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#12445
üzenetére
Itt nem a probléma mértéke a lényeg, hanem, hogy jelen van. Nyilván az efféle specifikus problémák zöme nem érinti az eladott termékek 99,9%-át, de az 0,1% is probléma, főleg, ha abból ered, hogy nincs betartva a szabvány. Ez megkérdőjelezi, hogy miért is dolgozzuk ki ezeket.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#12442
üzenetére
Előfordul. Ez nem gyártófüggő. Az alapprobléma tényleg az, hogy nem követik az alaplapgyártók a szabványt, és persze kitesztelik, hogy mekkora időbüntetéssel lehet PCI Express üzemmódot váltani biztonságosan, de a módváltás biztos nem lesz szabályos, mert a késleltetés alacsonyabb, mint ami a specifikációban szerepel.
Például az NV-nél ilyen hiba a Maxwellek esetében a low GPU usage. Ezt is az okozza, hogy egy nem szabályos parancstól limitált üzemódban ragad a hardver, egy új parancs érkezéséig, és ezért működik valakinek rosszul a GeForce 900-as, míg másnak jól. A kulcstényező az alaplap. -
Abu85
HÁZIGAZDA
válasz
#85552128
#12439
üzenetére
Nem fog mindenhol jelentkezni. Ha jelentkezne, akkor rossz lenne az egyedi séma. Tipikusan akkor jelentkezik, amikor a VGA jóval újabb az alaplapnál, mert azt még laborszinten sem valószínű, hogy ellenőrizték az éppen elérhető BIOS kiadása előtt. Az viszont vitathatatlanul gáz, hogy ha van szabvány és az alaplapok nem követik. Nem véletlen, hogy arányaiban a "szupergamer" alaplapokra van messze a legtöbb panasz, míg az olcsókra a legkevesebb, annak ellenére, hogy sokkal több olcsót adnak el.
A javítás egyébként elméletben egyszerű. Összeírni a problémás alaplapok listáját és kérni rájuk egy új BIOS-t. Ha nem lesz, akkor pedig a driverbe kell egy rutin, hogy xyz alaplapról érkező nem szabályos parancsot ne hajtsa végre, de ettől romlik a PCI Express energiagazdálkodás. -
Abu85
HÁZIGAZDA
válasz
#85552128
#12430
üzenetére
Az ilyen csíkozások/képremegések nagyrészt kompatibilitási hibák. Én is belefutottam egy képremegésbe az októberi gépváltásnál. Eredetileg ASUS A88X-GAMER alaplapot vettem, de azzal a 285 idle-ben remegtette a képet. Ritkán, de akkor kellett egy újraindítás. Kértem egy másik alaplapot, és azzal is rossz volt. Aztán egy foxconnos kontakt javaslatára váltottam egy tök alap MSI-re. Ő azt mondta, hogy a legtöbb gyártó -3-5 wattért ma már úgy dönt, hogy nem követi a szabványos PCI Express energiagazdálkodást, és ez okozza a problémák zömét. Szerinte legjobb módszer nagyon olcsó alaplapokat venni, amelyekből ezeket a "szeretetcsomagokat" kihagyják, így szabvány szerint működnek.
-
Abu85
HÁZIGAZDA
Durván jó port lett az új AC: [link] - Ennyi hibát a Titan X-szel elérni azért kemény.
Ez a legjobb
:
De ez sem rossz
:
Amúgy más észrevette azt, hogy mindegy, hogy mekkora az fps, akkor is olyan, mintha 30 fps-sel futna? 30 jelenetre van fixálva a szinkronizáció és csak kiszámolja ugyanazt a jelenetet többször, mint a Crew?
Ha igen, akkor
-
Abu85
HÁZIGAZDA
válasz
#85552128
#12326
üzenetére
A programok szabálytalan hozzáférése javítható. Ha nem létezik az a regiszter mondjuk, amihez például a HWiNFO hozzá akar férni, akkor át kell írni a programot, hogy ne is próbálkozzon hozzáférni, és akkor nem lesz tőle vöröshalálod. Ez nem egy javíthatatlan gond, csak jellemzően előfordul, hogy a program fejlesztője későn kapott specifikációkat, vagy nem is kapott és ilyen hibák lehetnek tőle. Ennek a megoldása teljes egészében az adott program fejlesztőjére vonatkozik.
-
Abu85
HÁZIGAZDA
Mindkettőtől. Bár az AMD hozza hamarabb.
(#12302) Petykemano: Nagy csoda lenne, ha bárki az új hardvereket tömeggyátrás szintjén hozná ősz előtt, nem lesz elég interposer.
A Dual Fiji a Rifthez érkezik, hiszen VR-re kihegyezett cucc lesz.
A 370 a Pitcairn.akoska07 és Szaby59: A vöröshalál régóta létezik, csak fekete képernyő formájában. Az ok lehet szabálytalan VBIOS kiolvasás például. A vöröst azért vezették be, mert így elkülöníthető a probléma jellege. A vöröshalál jelzi, hogy konkrétan egy futó program csinált valami rosszat (pl: nem létező regisztert címez). Ezt a futó programban kell orvosolni. Azért köthetik sokan a tuninghoz, mert a tuning tesztelésénél sokszor fut a háttérben diagnosztika, vagy GPU-Z-féle program, amelyek sokszor csinálhatnak ilyen szabálytalanságokat.
-
Abu85
HÁZIGAZDA
válasz
rocket
#12283
üzenetére
Ezért nem fog 220 wattot fogyasztani.

(#12289) rocket: A driverek nem jelentettek sokat, mert csak az AMD változtatott a Batman AO profilon, aminek meglátszik az eredménye a Nano esetében, de ennyi. A többi játéknál nem lenne hatása a frissebb drivereknek. Persze jó lenne újramérni, de időre kell dolgozni.
A játékok modernizálásán dolgozunk, de az összes megjelent új játék egy optimalizálatlan bughalmaz PC-n, amelyeknek ezernyi problémájuk van. Például kikapcsolhatatlan V-sync. A váltásokat kidolgozzuk, de ami rossz port az nem fog bekerülni, mert nem akarjuk azt mutatni, hogy a PC egy olyan szar piac, ahol nincs optimalizálás. -
Abu85
HÁZIGAZDA
Az erőltetett AFR-rel az új Frostbite nem fog jól skálázódni sosem, mert nagyon sok az inteframe kommunikáció egyes helyeken. Amikor nagy mennyiségű adatot kell másolni, akkor az a probléma áll elő, hogy a másolás idejére a GPU-nak le kell állítania a munkát, és ezt megérzi a teljesítmény. A low-level API-kkal aszinkron DMA felel a másolásért, vagyis a képkocka számításának kezdetén teljesen párhuzamosan megtörténhet az adatmásolás, így az ingyenessé válik, tehát helyenként sem rontja a skálázást. DX11-re talán az AMD bevetheti az XDMA-ra a specifikus aszinkron profilt, de az sem hoz annyit, hogy megérje vele foglalkozni, másrészt nem mindegyik Radeonban van XDMA. A problémát DX11-ben nem lehet megoldani sajnos.
-
Abu85
HÁZIGAZDA
válasz
velizare
#12226
üzenetére
Mindegyik natív kód továbbfejlesztette a Frostbite 3-ból. Bár a DX11-es kód már nem tartalmazza az összes effektet. Például élsimításra csak sima FXAA variáns van már csak. Az analitikai AA-t a konzolok mellett csak az explicit PC-s API-k kapják meg. De a PC sajnos később.
-
Abu85
HÁZIGAZDA
válasz
velizare
#12214
üzenetére
A WDDM 2.0-t akarja minimumnak. Az API mindegy. Az új Frostbite eleve ugy készült, hogy a PC-s natív kód a Mantle és a DX12, illetve a Vulkan ebből konvertálható, mivel a motor kapott erre egy réteget. Tehát effektíve valós DX12 és Vulkan kód nincs, csak konvertált. Ez teljesen jól megoldható, mert mindhárom API alapja ugyanaz, így a közös metszett igen nagy. Ami gond, hogy mindhárom API más shader nyelvet használ. A Frostbite-nak vannak HLSL 5.0-s és HLSL ext. shadedei a PC-re. A DX12-vel és a Vulkannal egyik sem kompatibilis. A DX12 innen több munka lenne, így a fő projekt a HLSL ext. kódok megőrzése és írni egy fordítót a SPIR-V-re. Ez a legegyszerűbb módja annak, hogy az EA játékok szabványos explicit elérést kapjanak. Ez jövőbiztosabb is, mert SPIR-V-re lehet majd OpenCL C++ kódokat is fordítani, ami mindegyik shader nyelvnél jobb alternatíva.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#12188
üzenetére
Igazából nem elég csak a DX12. Nyilván lehetővé teszi, hogy egy rajzolási parancsot akár egymilliószor gyorsabban is kiadj a DX11-hez képest, de ettől még ezeket ki is kell rajzolni, vagyis önmagában a DX12 nem oldja meg a problémát. Ezért használ a Nitrous OSR-t, amivel lehetővé válik, hogy egy kész egységet objektumként kezeljenek és annyiszor helyezzenek el a kijelzőn, ahányszor csak akarnak. Ilyenkor csupán egy egység költségét fizeted meg, miközben kirakhatod mondjuk 10-20-50-szer is. A DX12 persze sokat segít, de a Nitrous titka az OSR.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#12182
üzenetére
A felszín ebben a játékban nagyon nehéz ügy. Azért vannak csak kicsi mapok az alphában, mert a terepgenerálás lassú. A GPGPU-s generálás csak Mantle-ön működik, de ez is inaktív a publikus verzióban. Az jelenti a gondot, hogy egy tényleg nagyméretű térkép generálása, gyakorlatilag ténylegesen maximális részletességgel egy hatmagos Core i7-en is lazán elvisz 30-40 percet. Na most ez végleges formában nehezen vállalható. Mivel az AVX-re való kutatás teljesen leállt, így most az OpenCL van központban, hogy azzal majd megoldják a terepgenerálás problémáját mire megjelenik.
-
Abu85
HÁZIGAZDA
válasz
nonsen5e
#12178
üzenetére
Ez nem művészi probléma. Ha nem különítik el eléggé azokat az egységeket, akkor annyira beleolvadnak a játéktérbe, hogy képtelenség lesz jól játszani a játékkal. Mivel ez elsődlegesen a játék, így szem előtt kell tartani, hogy játszható legyen.
De a kinézet így is bőven túlteljesít bármin, ami ma létezik RTS szinten. Egyszerűen csak nézd meg, hogy minden lövés egy shadow casting fényforrás is egyben, ez páratlan még CGI szempontból is, nemhogy játékban. Az SC2 például csupán egyetlen egy shadow casting fényforrással dolgozik, ami az ég, míg a lövések sima pixelfények, de csak tömbösítve. -
Abu85
HÁZIGAZDA
Úgy néz ki, hogy jövőre jön a Nitrous új verziója. A fényszámítást teljesen átírták compute-ra. Akár 80%-ot is gyorsul tőle az egész. Így valószínűleg jönnek az AotS-be a nagyobb pályák is, nem csak a legkisebbek lesznek benne. Az a terv, hogy mire ténylegesen megjelenik a játék, akkorra a futószalagok fele compute legyen.
-
Abu85
HÁZIGAZDA
Az AMD LiquidVR és az NV GameWorks VR dolgokat érdemes beépíteni a VR mellé, mert az Oculus SDK-nál jobbak. Amíg nincs szabvány a VR-re, addig ez van. A GameWorks VR egyébként fontosabb a MRS miatt, mert sima Oculus SDK-val bármikor jöhet a róka GeForce-on. Muszáj az MRS-t alkalmazni, hogy le legyen butítva a képminőség a sebesség növelése érdekében, így akár a timewarp is mellőzhető, de minimum biztosítható, hogy nagyobb esély legyen arra, hogy a szinkronablakon belül befut az eredménye.
A LiquidVR nem olyan fontos. Az AMD eredménye Oculus SDK-val is jobb, mint amire a GameWorks VR képes, mivel a hardver kezelni a komplex helyzeteket és nem szorul szoftveres segítségre. Csak akkor kell a LiquidVR, ha 10 ms alatti M2P késleltetést akar elérni az adott fejlesztő. -
Abu85
HÁZIGAZDA
válasz
rocket
#12091
üzenetére
Nehezen képzelem el azt, hogy az a grafika mainstream legyen. A motort alá meg lehet írni, de rendkívüli befektetés olyan tartalmat készíteni hozzá, mint amit a CIG csinál. A legtöbb stúdiónak egyszerűen nem lesz rá pénze. Ma többen abba sem fektetnek be, hogy átdolgozzák az előző generációs motorokat.
-
Abu85
HÁZIGAZDA
válasz
marcusa
#12081
üzenetére
A God Rays effekt túlságosan extrém és túlságosan elsötétíti az előtte lévő tárgyak hátsó részét. Ez a valóságban messze nem ilyen, és jellemzően, amikor ilyen effektet terveznek, akkor figyelnek erre, de ahogy mondták annyira későn látták meg, hogy milyen az effekt, hogy nem volt lehetőség áttervezni a játékot. Hibának én sem mondanám, még ha annak is tűnik, de egyértelműen nem szép. Valószínű, hogy akik ezt a játékot felépítették azok a konzolra írt effektekre tervezték az egész grafikai dizájnt, és ha a PC-n ezek közül valamelyiket lecseréled, akkor az problémás megjelenítéshez vezethet. Érződik, hogy az effekt nem illik a környezetbe.
A lámpának ehhez nincs köze, az csak a narancs fényt adja, ami nyilván a két képen máshol van. -
Abu85
HÁZIGAZDA
Na szóval az van, hogy ez nem bug, hanem hát ilyen. A God Rays helyenként nem ad jó eredményt, de ennek semmi köze az effekthez, csupán a játék "művészi dizájnját" nem erre tervezték, mivel nagyon-nagyon későn látták meg, hogy milyen az effekt. Emiatt már nem tudták a játék problémás területeit újratervezni, így bár az eredmény bugosnak néz ki, de valójában nem az.
Sírva fakadnék ilyenkor, komolyan mondom. Egyszer annyira elbeszélgetnék azokkal a gyakornokokkal (mert tapasztalt fejlesztő ilyet nem talál ki, az nem lehet
), akik szerint ez jó így. -
Abu85
HÁZIGAZDA
A PCGH felrakott egy nagyon jó képet a Fallout 4 God Rays effektről: kikapcsolva és bekapcsolva.
Finoman megkérdeztem a Bethesdát, hogy ki az a vaskalapos balfasz, aki ezt így jóváhagyta.
Majd megírom a fejleményeket. 
-
Abu85
HÁZIGAZDA
válasz
guftabi96
#12050
üzenetére
Annak a motornak az alapja amire a Fallout 4 épül nagyjából 11 éves. Nyilván nem lehet a végtelenségig foltozgatni, tehát technikailag abszolút versenyképtelen lesz a modernebb alapokra építkező motorokkal. Grafikailag és teljesítményben az egy évtizedes lemaradás valamilyen szinten mindenképpen meg fog látszani.
(#12053) huskydog17: Nyilván oka van annak, amiért állandó a V-Sync. Sajnos a szinkronizációt 30 Hz-re tervezték, de láthatóan nem katasztrófa 60 Hz-en sem, csak fölötte lesz nagyon rossz. Ugyanez a hiba egyébként megvolt a Skyrim esetében is. Ez a motor így működik, még ha nehéz is elfogadni. Igazából az a lényeg, hogy 60 Hz-es kijelzőn játssz aktív vertikális szinkronnal és akkor nem lesz nagy probléma belőle. Nyilván nem elegáns megoldás, de túl rossz az alap, amit használnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12043
üzenetére
Annyit hozzátennék, hogy a TressFX memóriaigénye amiatt, hogy belevitték a minőséget jóval több, mint a HairWorks-é. A PPLL gyorsítóstruktúra egy karakterre 170 MB körüli, és ez szükséges ahhoz, hogy sorrendtől független átlátszóságot kapj. Az AMD másik megoldása erre a gondra a mutex zárolás, ami kevesebb memóriát használ, mint a PPLL, de a hibátlan futtatása csak olyan architektúrán garantálható, amely virtualizálja az LDS-t. Erre pedig az aktuális hardverek közül csak a GCN képes. Viszont ilyen formában a TressFX 3.0 például mutex zárolással több karakterre is használható lenne. De a többi architektúrára szükséges egy PPLL path, illetve a legtöbb hardveren így is csak két karakteren lenne aktív, mert az műr hat UAV, és rengeteg GeForce például nem támogat 8 UAV-nél a futószalagon.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12043
üzenetére
Csak nézd meg a két effektet. A hajszimulálásnak a legkritikusabb pontja, hogy a haj nagyon vékony tincsekből áll. Olyan vékonyakból, amelyeket baromira nehéz sorrendben megjeleníteni, illetve nehéz meghatározni, hogy a több tucat hajszálból, ami átmegy az adott pixelen melyik is látszik dominánsan.
Ha megnézed a Witcher 3-ban Geralt haját, akkor látod, hogy a kamera forgása közben a hajtincsek pozíciója folyamatosan változik. Mindig más tincs lesz a domináns és ettől olyannak tűnik az egész, mintha a haj élne és mozogna. Másrészt gondot jelent az is, hogy nincs egyértelmű sorrend a hajszálak között, így az egész spagettiszerű lesz. [link] - ezt némileg a képek is visszaadják, de mozgásban sokkal rosszabb a HairWorks. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12016
üzenetére
A TressFX számításigénye akkor meglapozott volt. Az effekt büdzséje 4-5 ms egy erősebb GPU-n. Ebbe kell beleférni a szimulációnak, a geometria kirajzolásának, az élsimításnak, az átlátszóságnak és az önárnyéknak. Hogy érzékeld azt, hogy ez mennyire durva terhelés elárulom, hogy a konkurensnek tartott HairWorks az utóbbi két eljárást meg sem csinálja, mert már a szimuláció, a geometria kirajzolása és az élsimítás elvitte az 4-5 ms-os büdzsét. És arányaiban az átlátszóság, illetve az önárnyék problémája jelenti a legnagyobb terhelést a GPU-ra nézve és a TressFX 1.0 számításigényének a 80%-át ez vitte el. Valójában a TressFX ezek nélkül is üzemképes lenne gyakorlatilag lényegesen gyorsabban, de olyan félelmetesen ronda lenne, mint a HairWorks.
-
Abu85
HÁZIGAZDA
Ez még hagyján, de nézd meg az elmúlt 3 évet. Nagyjából látom, hogy ki mit fejleszt, és igazából egy kezemen meg tudom számolni, hogy komoly problémákra hány fejlesztés reagált. És most itt nem a hajszimulálásra gondolok, mert az új terület, hanem évek óta létező kritikus problémákra, mint például a részecskerendszereknél az többletrajzolás jelensége. Faszért terheljük agyon a hardverek fill-rate-jét, amikor az effekthez közelítve a számítások 80%-a irrelevánssá válik. Az ehhez hasonló problémákon kellene gondolkodni nem pedig azon, hogy mi lenne, ha egy sík felület nem kettő, hanem 16-256-4096 poligonból állna.

Mondjuk igaz, hogy a részecskerendszereknél már van két potenciális megoldás, de a lényeg érthető belőle. -
Abu85
HÁZIGAZDA
válasz
huskydog17
#12026
üzenetére
A God Rays esetében nagyon sok algoritmus van, amivel ezt meg lehet csinálni, és ezek minősége eltérő, bár az effekt jellege miatt azért hatalmas különbségek nem lesznek. Itt azt szokták mérlegelni, hogy az egyes algoritmusok mennyire eszik a sebességet, és azok az előnyök, amiket behoznak megérik-e az időbudget feláldozását. És most itt ne a GameWorks-féle megoldásra gondoljunk, annak a minősége kb. az összes ismert alternatíva közül legrosszabb ráadásul nevetségesen magas gépigénnyel. Ha ki kellene emelni valamit, akkor az Uncharted 3-nak van nagyon jó volumetrikus fénykezelése.
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#12001
üzenetére
Jó hát ez van. Egy zsír új motor kifejlesztése drága, így marad a régi polírozása. Ronda a játék mint a bűn, de elég jól fut a gépeken és elég stabil a motor ahhoz, hogy jó játékot tudjanak rá építeni.
(#12002) Szaby59: De az az effekt a legnagyobb probléma. A Low beállításról Ultrára váltás gyakorlatilag megfelezi a sebességedet. +30-50 fps-t nyersz vele, ha leveszed lowra, és észrevehető minőségkülönbség nincs! Ez az egész PC-s ipar égbekiáltó problémája, és az NV a szoftveres fejlesztéséinél nem azt nézi, hogy mi hozhatna valódi minőségi előrelépést a PC-nek, hanem azt, hogy mivel lehetne egyszerűen megnövelni a gépigényeket.
-
Abu85
HÁZIGAZDA
A volumetrikus fényeket, vagy más néven God Rayst nem kell kikapcsolni. Elég ha kikapcsoljátok rajta a teljesen felesleges tesszellálást. Ez a low beállítás. Ezzel lehet nyerni +30-50 fps-t is, és a különbséget nem lehet észrevenni:
Low vs. Ultra
Feleslegesen van mesterségesen megnövelve a low fölötti beállítások gépigénye, de jól döntött a Bethesda, hogy skálázható lett. Az NV oszthatja a bullshitjét a birkáinak ész nélkül, mi hozzáértők pedig játszhatunk a low beállítással minőségromlás nélkül. Ez elfogadható kompromisszum szerintem. -
Abu85
HÁZIGAZDA
válasz
#85552128
#11893
üzenetére
Tipikus utilizációs probléma. Ezért nem szabad egy az egybe lemásolni az Xbox One-os leképezőt, dehát ezeknek beszélhet az ember.

(#11896) huskydog17: Igazából nem attól, hanem pont azért.

Én értem, hogy sokkal egyszerűbb a konzolos technikákat átültetni PC-re, de ezekkel az API-kkal ezek jó része nem működik. Ez tipikusan resource leaket és utilizációs hibákat hoz maga után. -
Abu85
HÁZIGAZDA
válasz
huskydog17
#11890
üzenetére
Tehát áthozták egy az egyben az Xbox One kódot és kiderül, hogy a GCN-en igazán jó. Wow, so shocking!

-
Abu85
HÁZIGAZDA
válasz
Petykemano
#11886
üzenetére
Egy olyan pert is kb. annyi esélyük lenne megnyerni, mint ezt.
Legalábbis, ha olyan írja a problémaleírást, aki nem ért hozzá, mint most. -
Abu85
HÁZIGAZDA
Mihez képest? Az nem volt eltitkolva, hogy a front-end mit tud, annak ellenére, hogy a vásárlókat nem érdekli. Olyan pedig minden processzorban előfordul, hogy a végrehajtó adat hiányában éhezik. Ez a velejárója a processzoroknak. Az oka ennek az, hogy nincsen kvázi végtelen mennyiségű tranzisztor arra, hogy a legrosszabbakra felkészüljenek a mérnökök. Tehát arra építenek, hogy ha nem optimalizálod megfelelően az adott processzorra kódot, akkor lassan futhat? És erre most jöttek rá?

Nem látom még az USA-ban sem, hogy ez bármilyen formában megállná a helyét. Egyszerűen nincs meg az alapja. Amit látok, hogy fogalmuk sincsen a processzorokról úgy általában, ezért leegyszerűsítik annyira a működést, hogy megértsék, és így lett egy saját víziójuk arról, hogy mi történhet. -
Abu85
HÁZIGAZDA
Oké tényleg. Nem vettem észre. Viszont ha erre alapoznak, akkor eleve vert helyzetből indulnak neki, mert nem ismerik, hogy miképpen működik a lapka. Előtte talán ki kellene kérni egy szakember véleményét, hogy ne hülyeséggel menjenek bíróságra, ugyanis a Bulldozer sosem működik olyan módban, amikor a modulon belüli két mag nem működhet egymástól függetlenül. Egyáltalán ki mondta azt nekik, hogy így működik a lapka?

-
Abu85
HÁZIGAZDA
válasz
Petykemano
#11880
üzenetére
Arra biztos nem. Az ugyanis a gyakorlatban kimérhető és lényegében majdnem kétszeres növekedéssel jár az extra négy mag befogása, ahhoz képest mintha csak négy szálon futna a program. Ezzel gyakorlatilag azonnal elvesztenék a pert, mert pont azt bizonyítanák, hogy az extra négy mag valóban extra négy magként viselkedik. Ezt inkább a védelemnél tudom elképzelni, mert ez fájhat majd a vádnak. Egy ilyen példaprogramot, ami ezt kiméri viszonylag egyszer csinálni.
-
Abu85
HÁZIGAZDA
Először is tisztázni kellene, hogy mit hit az áldozat. A leírás szerint azt, hogy egy nyolcmagos processzort vett. Az pedig egyértelmű, hogy annak a procinak, amit vett nyolc magja van. Nincs olyan, hogy nem úgy nyolcmagos. Ha a Phenom II a kiindulási pont, akkor valószínűleg arra mehet rá a vád, hogy azokban a magokban egy szálhoz van dedikálva integer és FP erőforrás, de valójában ez pontosan ugyanebben a formában igaz a Bulldozerre is. Hiszen nem normál FP erőforrása van. Ez valójában a marketinggel ellentétben nem kapcsolódik sosem össze. Mindig az adott maghoz tartozik az erőforrás, de ha úgy az ideális, akkor az egyik mag FP-je futtathat olyan folyamatot, ami a másik magot segíti. Egyszerűen nincs olyan tényező, ami a Phenom II és a Bulldozer esetében ne lenne egységesen igaz.
-
Abu85
HÁZIGAZDA
Ez szimplán józan ész. A vád semmilyen formában nem áll meg. Olyan ez, amikor a Al Bundy behúzott az őt beperelő betörőnek és beperelte, mert a szakálla felsértette a kezén a bőrt. Mondjuk igaz, hogy a sorozatban azt megnyerte.

De nyugodtam mond meg azt a formát, amiben a vádjuk megáll. Bármivel, amivel alá lehet támasztani azt. -
Abu85
HÁZIGAZDA
Teljesen mindegy. A definíció jogilag teljesen helytálló. Egyszerűen csak be kell vinni a terembe azt a whitepapert és kész. Azzal nem lehet mit kezdeni, mert abszolút meg van magyarázva technikailag is, ráadásul még így kívülállóként is helytálló az egész dokumentum leírása. A cégek emiatt leszarják ezeket a pereket, ezért mondtam, hogy az embereknek kell változni, mert megnyerni ezt a pert nem lehet.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#11864
üzenetére
Ennek a pernek az a szépséghibája, hogy az AMD egészen pontosan definiálja, hogy egy lapkán belül mi számít egy magnak: "any core capable of running at least one process in its own context and virtual memory space, independently from other cores."
Ez ott van a weboldalon, de bele van írva a kézikönyvbe is: [link]Az embereknek azt kellene megérteni, hogy az órajel, a magok száma, a gyorsítótárak mérete, a multiprocesszorok száma, a ROP-ok száma, az akárminek a száma alapján a teljesítmény nem meghatározható, mert nem ismert a lapka ütemezése.
-
Abu85
HÁZIGAZDA
Mert a PS4-en miért ne futna ugyanaz pár soros vertex shader, ami mozgatja a növényzetet?
Mit kell tesszellálnak 2D-s meshen? Komolyan kérdezem.
A PS4-en nem csak köd van, hanem god rays is. Ez a volumetrikus köd effektet eltompítja, de ettől jelen van. PC-n vagy ez vagy az aktiválható csak.
Nem kell ezt a programot megvédeni, hogy jó lett. Aki írta a motort és a leképező nagy részét az sem védte meg. Elment inkább az IW-hez dolgozni. -
-
Abu85
HÁZIGAZDA
válasz
daveoff
#11809
üzenetére
Azt nem értem, hogy ha konzolon megoldották, hogy legyen god rays és volumetrikus köd az FC4-ben egyszerre, akkor PC-n miért nem. A HRAA-t még megértem, hogy miért nincs PC-n. A legtöbb hardverben nincs SAD4, vagy manuális interpoláció. Na de a másik tisztán egy kompatibilitási probléma. Csak ki kellett volna cserélni az egyik effektet, hogy mehessenek együtt.
(#11817) huskydog17: Semmi extra nem lesz a haj. Rajzolnak egyet és kész. Szimulációnak nyoma sem lesz.
(#11821) Szaby59: Valójában a god rays az gameworks effekt, bár lehet, hogy még egy nagyon régi verzió, és ezért nincs DRM mögé rejtve. Nem vállalták be, hogy moddolhatatlan legyen a játék PC-n. Viszont így az effekt forráskódját láthatta a Bethesda, szóval kivételesen láthatunk majd egy optimalizált implementációt.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#11807
üzenetére
Azért nehogy már PC-n 2014-ben az legyen a probléma, hogy kompatibilitási hiba miatt nem működik egyszerre a god rays és a volumetrikus köd. Ez 201x-ben meg volt oldva több tucat játékban. Akármekkora marketinget raknak az effekt mögé az úgy akkor is bullshit, ha a futtatás érdekében egy másik, legalább ugyanolyan fontos effektet inaktiválni kell. Az pedig a szánalom legmagasabb foka, amikor a két effekt PS4-en működik együtt.

-
Abu85
HÁZIGAZDA
válasz
huskydog17
#11803
üzenetére
Az hagyján, de a PS4-en az FC4 esetében volt egy olyan fasza god rays effekt, amit Michal Drobot kidolgozott, hogy példát vehetett volna róla az ipar. Ráadásul 0,2 ms volt az egész és kompatibilis volt a volumetrikus köddel is. Erre a PC-ben választani kell, hogy god rays vagy volumetrikus köd. Akkora bullshit ez, hogy az valami félelmetes.

De azé megy a MasterRace meg minden.
-
Abu85
HÁZIGAZDA
Könnyen észre lehet venni a különbséget, mert simán nagyon magas shader beállítással viszonylag kis távolságból is elkezdenek kifehéredni az objektumok élei:

Ultra beállítással ez a jelentség nem létezik:
Persze valószínűleg ennek inkább ahhoz van köze, hogy a nagyon magas szint eredetileg még közepes minőségi szint sem lett volna. Valamivel jobb átmenetet kellett volna ide csinálni, mert az ultra szint minősége nem szükséges, viszont a nagyon magas szint minősége túl rossz. A középút lenne az ideális.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#11799
üzenetére
Csak egy god rays lesz? Többre számítottam.
Remélem nem az a fos verzió jön, amit kapott az AC4 vagy az FC4. Az borzalmasan elnagyolt algoritmus. Sokkal jobban néztek ki a konzolról átportolt opciók. FC4-ben még inaktiválja a volumetrikus ködöt is valami kompatibilitási hiba miatt, ami azért elég fontos effekt, hogy szakadnának meg. 
(#11800) huskydog17: Az ultra megmaradt a legjobb, és úgyis ez a lényeg. Ki akar gyenge minőségen játszani PC-n.

30-40 fps közé jó lesz. Ez olyan stratégia, ahol nincs igazán szükség többre. -
Abu85
HÁZIGAZDA
válasz
Malibutomi
#11786
üzenetére
Nem játszhatatlan az Ultra magas shader szint. Radeon 285/380-on 1080p-ben AA nélkül 40-45 fps-sel megy Ultrában. Nagyon magas beállítással 50 fps környékén fut. Egyértelműen megéri bekapcsolni. Ez a különbség a kettő között: Nagyon magas és Ultramagas.
-
Abu85
HÁZIGAZDA
BRÉKING!
Beszéltem az Anno 2205-ösökkel. Állításuk szerint egyik gyártó sincs általánosan előtérbe helyezve, de a bétához képest megváltozott a shader minőségi skála. Eredetileg volt alacsony, közepes, magas és nagyon magas szint. A közepes, a magas és a nagyon magas rosszul futott a nem GCN-es hardvereken, így a nagyon magast átnevezték ultramagasra, míg a közepest és a magast eldobták. A nagyon magas helyére egy olyan shader szint került, amelyet a Maxwellre optimalizáltak és ennek a minősége az eredeti alacsony és közepes közötti. Az eredeti alacsony szint lett az új magas, az új közepes egy extra alacsony szint, és az új alacsony még alacsonyabb.
Állításuk szerint a végleges programban a nagyon magas és az ultramagas között radikális a különbség. Olyan teszt kellene, ami ezt kiméri. -
Abu85
HÁZIGAZDA
válasz
TTomax
#11735
üzenetére
Nem. A Rocksteady dolgozott rajta és két külső stúdióból kaptak segítséget, illetve Tom Petersen az NV-től a legjobbakat adta oda nekik a második körben. Persze a megmaradt legjobbakat, mert a legjobbak, mint Timothy Lottes, Cass Everitt, John McDonald, stb. már kiléptek akkor, amikor kiderült, hogy a GameWorks tényleg megszületik, és nem sikerült megakadályozniuk ezt. Ők karrieristák voltak, nem akartak szégyenfoltokat az önéletrajzukban.

-
Abu85
HÁZIGAZDA
válasz
nonsen5e
#11723
üzenetére
A Nixxestől függ az egész. A Square Enixnek az NV-vel van partneri szerződése, és az AMD-vel reklámszerződése, de a nagyobb játékok bizonyos platformot célzó portjait a Nixxes csinálja. Őket nem birtokolja a Square Enix, csupán megbízza a portolással a stúdiót. Szimpla kapcsolat ez. A Square Enix fizet azért, hogy a Nixxes megcsinálja a portot olyan minőségűre, amilyenre a Square Enix elvárja. Ha nem csinálja meg, akkor kötbért kell fizetniük, és emiatt a Nixxes ragaszkodik hozzá, hogy ők választhassák ki a hardverpartnereiket, mert optimalizálás szempontjából megbízható céggel akarnak dolgozni. A Nixxes állandó hardverpartnere emiatt az AMD.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#11680
üzenetére
Alapvetően 2015-re csak azért jellemző az, hogy az eddig zárt dolgokat megnyitják, hogy optimalizálni lehessen. De a GameWorksnek nem célja az, hogy a kód optimalizált legyen. Akinek ez nem tetszik hagyja el a PC-t, de ezen felesleges vitázni, mert ettől a PC-nek nem lesz jobb. Vannak a játékosok érdekeinél fontosabb érdekek is. Mint látható annál is van fontosabb érdek, hogy az adott effekt szép legyen.
(#11681) Interceptor: Én eleve azt mondtam, hogy a Bethesda olyan middleware-t nem fog használni, ami a játékot moddolhatatlanná teszi. Fizikára pedig csak a Havokot használják.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#11664
üzenetére
Ez nem olyan egyszerű, hogy nem megy át a minőségi szűrőn, akkor nem reklámozzák. Nyilván így lenne az ideális, de nem várhatja el az NV, hogy a fejlesztők optimalizáljanak egy olyan middleware-re, aminek a forráskódját nem írhatják át. Itt kapod, amit kapsz és kész. Valószínű, hogy amikor ezt a modellt kidolgozták, akkor számítottak rá, hogy lesznek olyan fejlesztők, akik nem tudják elérni a minimális minőségi szintet. Talán nem gondolták, hogy ennyien lesznek, de ez a reklámszerződéseken nem módosít. A pénzt elutalták, a játék jött, és mindenki boldog, csak a játékosok nem. Viszont nagyon fontos, hogy a GameWorksnek sosem volt célja, hogy a játékosok boldogok legyenek. Vagy, hogy a PC-s piac minőséget kapjon. Tehát így tekintve a GameWorks hozza azt ami a célja volt, vagyis a mesterségesen kialakított magas gépigény.
(#11666) Interceptor: Nem tudom mi az a flex.
-
Abu85
HÁZIGAZDA
válasz
imi123
#11657
üzenetére
De ez egy OEM-et nem érdekli. Nekik vannak preferenciáik, és onnan rendelnek, ahol ezeket kiszolgálják. Tetszik vagy sem ez pont annyira egyéni választás egy nagy cégnél, mint egy átlagos felhasználónál. Azzal a különbséggel persze, hogy az OEM megrendelés az komoly mennyiség. És ha megnézed, akkor a teljes piac mindegyik igényt kiszolgálja. Neked is lehet egyedi hűtős 390-ed, és az OEM-eknek is lehet blower hűtős.
(#11659) Szaby59: Referencia 390/390X nem is létezik. Az AMD nem csinált, tehát olyan sincs, hogy hivatalos referencia-órajel. Nem hivatalosan van egy minimális órajel, amit az AMD elvár, és ezekre állítottuk vissza a termékeken az órajelet, amikor mi teszteltük ezeket a kártyákat. Referencia hiányában ennél jobb megoldás nincs.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#11656
üzenetére
Attól függ, hogy milyen a játék. Természetesen azokon a mai játékokon, amelyek a GPU-ban lévő részegységek 20-30%-át sem terhelik le nem jelent majd gondot ez a tervezés, de például az OEM-ek nem ezekkel tesztelnek, hanem speciális terhelésszimulátorokkal, amelyet az AMD ír a termékeire méghozzá az adott lapka saját ISA-jára. Ez még a Furmarknál is nagyobb terhelést jelent. Ilyenkor már erősen throttlingol mindegyik hardver, és amikor a stabilitást ellenőrzik, akkor ez a körülmény számít.
Az OEM-eknek nem ezzel van a gondjuk, hanem a varianciával. Két ugyanolyan termék fizikailag nem ugyanolyan. Az AMD az új generációs 300-as (+Nano/+Fury) sorozatra hivatalosan maximum 6%-os varianciát specifikál, ami azt jelenti, hogy például két amúgy tök ugyanolyan R9 390 között akár 6%-os teljesítménykülönbség is lehet. Ezt az OEM-ek soknak tartják. Ugyanez a gond az NV-nél is. Ott a Maxwell2 sorozatú kártyáknál 13% a variancia, amit sokan nagyon soknak tartanak. Az NV csinál is külön OEM szintre bevizsgált modelleket, amelyeknél a variancia specifikációja 10% alatti.
-
Abu85
HÁZIGAZDA
válasz
imi123
#11653
üzenetére
Nem rosszak. Azt teljesítik, amire tervezték őket. Kitolják a forró levegőt a házon kívülre. Attól, hogy nektek ez nem igény még az OEM-eknek lehet az. Ha nem lenne igény, akkor az XFX nem foglalkoznak ezzel a kéréssel. Nekik is egyszerűbb lenne a saját egyedi 390-jüket gyártani és eladni, de akkora tétel forog kockán, hogy az OEM-eknek is van beleszólásuk abba, hogy mit vesznek. Biztosan nem tetszik az XFX-nek, hogy két sorozatot kell ugyanabból a termékből fenntartani, de hát ha elviszik, akkor megcsinálják.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#11652
üzenetére
Minden egyes piacon elérhető kártya és processzor throttlingol, méghozzá azért, mert így vannak tervezve.
Az XFX akciójának nem lesz látható hatása a 390-ek eladására. Nem arról van szó, hogy ezek most extra eladások lesznek, hanem arról, hogy oda ahova eddig 290 OEM-ek mentek most 390 OEM-ek mennek már. A 290 OEM-eket is az XFX adta el a partnereinek, ezért is tudnak úgy számolni, hogy ebből havi szinten 50k-s eladásuk lesz, mert az ünnepekkor eddig is ennyi ment el. Annyi a különbség, hogy a saját dobozos piacra szánt 390-jük helyére az OEM-ek most már rendelhetik a referenciadizájnt, és ezt fogják inkább rendelni, mert az egyedi dizájn nem azokba a gépekbe való, amelyeket a 290 referenciára terveztek. Az XFX számára valójában mindegy, hogy a terméket milyen hűtővel adják el, egyszerűen reagáltak arra, hogy az egyedi verzió nem jó, és a TUL sem tud több 290-et gyártani. Mivel a megrendelés nagy, így nekik belefér, ha refhűtőt kapnak. Persze az OEM megoldásokból valamekkora mennyiség átcsúszik a dobozosba is, de erre való alapvetően a dobozos termékskála.
Ú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.
- Google Pixel topik
- sziku69: Fűzzük össze a szavakat :)
- Genshin Impact (PC, PS4, Android, iOS)
- Konzol Screenshot
- Ekkor startol és ennyit gyártanak a Galaxy TriFoldból
- Milyen monitort vegyek?
- Red Dead Redemption 2 (PC)
- Mesterséges intelligencia topik
- Azonnali informatikai kérdések órája
- Bemutatkozott a Poco X7 és X7 Pro
- További aktív témák...
- Gainward Phoenix 3080 10G golden sample
- 27% - GIGABYTE RTX 3080 Ti OC 12GB GDDR6X GAMING Videokártya! BeszámítOK
- Sapphire RX 7900 XTX NITRO+ Vapor-X 24G - Garancia: 2026.03.16 ALZA
- Hp NVidia RTX 2070 Super 8Gb Videokártya - HP L84981-001
- GIGABYTE GeForce RTX EAGLE 3090 24G OC GDDR6X 384bit (GV-N3090EAGLE OC-24GD)
- LG 27UL550-W - 27" IPS / 3840x2160 4K / 60Hz 5ms / HDR10 / AMD FreeSync
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- Apple iPhone 17 Pro Max 256GB,Uj, Bontatlan,36 hónap garancia
- Honor X7a 128GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 11 Pro Max 64GB Midnight Green -1 ÉV GARANCIA - Kártyafüggetlen, MS3253, 100% Akksi
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő

Persze kiállhatnának a gyártók, hogy eladtunk már x-százezer példányt és csak x-száz report van a gondról, de ez azt hiszem, hogy minden esetben csak olaj lenne a tűzre.
:
:







