- Bemutatkozott a Transcend SSD-inek zászlóshajója
- Sugárhajtómű ihlette a Zalman CPU-hűtőjét, de nem az üzemzaj tekintetében
- Félreértések az FSR 4 és a PlayStation 5 Pro körül
- Nem tetszik a Procon-SP-nek, hogy a Nintendo távolról kivégezheti a Switch 2-t
- Megcélozta az NVIDIA-t a 2 nm-es node-jával a Samsung
Új hozzászólás Aktív témák
-
#14871
Malibutomi
nagyúr
gbors
#14870
Malibutomi
nagyúr
Visszatekintve, hogyan jonnek ki az utobbi idoben a jatekok siman el tudom kepzelni hogy ez megtortenik. Csak tavaly jopar jatek jott ki, amihez rogton jottek a patchek mar az elso napokban, hogy jatszhatova tegyek, meg javitsak a hibakat.
Komolyan hihetetlen, hogy a jatekiparban fontosabb az hogy kinyomjak minel elobb a termeket, mint hogy par nap csuszassal, de keszen adjak ki.
-
Abu85
HÁZIGAZDA
Meg a HBAO+ nem is middleware-ből van betöltve, ugyanis azt még nem támogatja DX12-ben. Szimplán oda van adva a forrás a Microsoftnak, ami gondolom valami speciális licenc. Ugyanígy van a Rise of the Tomb Raiderben is. Ezért sem GameWorks játékként utal ezekre az NVIDIA.
A PhysX meg teljesen bullshit. Teljesen mindegy, hogy a motor erre vonatkozó beállítása False vagy True, ha csak a szoftveres feldolgozást támogató runtime van szállítva, márpedig most csak az van a programban.
UI.: tiltani kellene ezt a WCCFtechet.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Abu85
HÁZIGAZDA
Na most azért van pár olyan játék, ami a "DX11-ben is egészségesebben használja a CPU-t", mert a konzolon átállnak a fejlesztők a GPU-driven pipeline-ra. A PS4 és az XO is támogatja, és egyrészt ugyan kihasználható DX12/Vulkan API-ban is, másrészt elérhető DX11-ben egy-egy AMD/NV kiterjesztéssel. Az Intel mindegy, azok az IGP-k ezt a modellt amúgy is csak emulálni tudják, de ettől még kompatibilisek lesznek vele a programok, csak nem nyer vele a hardver semmit.
A GPU-driven pipeline nem csak azért terjedt el az elmúlt hónapokban, mert kedvezőbb az aktuális API-k limitációinak, illetve végeredményben a két konzolnak is, hanem azért, mert olyan optimalizálásokat is be lehet rajta vezetni, amellyel növelhető a raszterizáló hatékonysága. Sőt, a DX12/Vulkan (és konzolok) alatt ezt a compute-alapú szűrést aszinkron ütemezéssel is el lehet végezni, vagyis gyakorlatilag a számítások kvázi ingyenesé vállnak, így csak profitálsz belőle. Ilyen opcióval jön egyébként a Hitman, de tartalmazza egy ilyen koncepciót az új Frostbite is, így a Star Wars Battlefront, Plants vs. Zombies: Garden Warfare 2, és ami még jön erre motorra. Ez az optimalizálás a DX12 executeindirect funkciójával a legjobb, de csak azért, hogy ne kelljen a DX11-hez AGSL-t és NVAPI-t használni. A szabvány például azért fontos, mert a Star Wars Battlefrontba például csak az AGSL van beépítve a Radeonra, vagyis az NV-nél egy emuláció fut. A Plants vs. Zombies: Garden Warfare 2 már tartalmazza az NVAPI-s verziót is, és ezt a Hitman is tartalmazni fogja DX11 alatt.
Az Ashes of the Singularity fejlesztői nem különösebben szeretik a gyártóspecifikus hackeket. Gondolj bele ebbe te is, és tulajdonképpen arra jutsz, hogy meg lehet érteni őket ezért. Azzal persze lehetne rugózni, hogy a DX11-es kódjuk lehetne gyorsabb is, ha bevetnék az AGSL-t és az NVAPI-t, de szerintem ez számukra olyan mindegy, amikor a felhasználónak a megjelenéskor felkínálnak majd két szabványos explicit API-t. Nincs az az ember, aki a DX11-et fogja választani, ezért olyan hihetetlenül mindegy, hogy milyen gyors az a kód. És nem csak nekik, hanem a gyártóknak is. Az NV persze lehet elég perverz ahhoz, hogy ragaszkodjon hozzá, hogy szénné optimalizáljanak rá egy DX11-es profilt, de ha megnézed a tesztoldalakat, mindenki arról ír, hogy a DX12-ben mi van. A DX11 senkit sem érdekel már. És megjegyzem függetlenül attól, hogy mi van most, azt is megértem, hogy az NV-nek bassza a csőrét, hogy beleinvesztáltak egy rakás pénzt a fast path parancsprocesszorba, az NVAPI-ba, az OpenGL kvázi átírásába a command list kiterjesztéssel, és persze ezek támogatásába, de mindeközben az AMD "dobjunk ki mindent és kezdjük elölről" lobbija győzött. És most nyilván az NV mérnökei sem hülyék, látva azt a szart, amit 20 év alatt az ipar felhalmozott simán a tiszta lap a legjobb megoldás, csak hát nem ebben fektették az erőforrásaikat, aminek már nem örülnek. -
Habugi
addikt
Félreérthetően fogalmaztam, ugyan neked címeztem a postot mert Abu egy kérdésedre adott válaszára olyan fricskával reagáltál hogy "kevés a jelenidő", ezt hoztam párhuzamra azzal a jelenséggel ami itt gyakran eluralkodik.., plusz aláírásokban is gyakran de ez neked mint itteni topicgazdának nyilván nem sarad..
-
Habugi
addikt
Tengermély tiszteletem kinyilvánítása mellett hagyjuk már ezt a jelen/jelenidő dolgot..!
33éves leszek, anno 16-18éves korom táján kezdett még gimnáziumi osztály szinten is marha ciki lenni ez az élj a mának, azt nézd/azzal foglalkozz mi van ma mentalitás.
Baromira unom olvasni, szerintem viszonylag kevés közöttünk a napközis..
Oké értem én, az AMD ígérget és a jövőről beszélnek legtöbbször de csak GCN-nél leragadva elég ránézni az AoS tesztekre, ugye máris nem nettó saláta volt amit Abu az elmúlt ~2évben szajkózott/"ígérgetett"/előre vetített. Arról nem beszélve, tegnap be lett ide szúrva egy amúgy nevetséges M$ DX12-es promó anyag.., ha mást nem annyit simán ki lehet jelenteni hogy prioritást kapott náluk (is) a DX12, innentől pedig várhatóan elég rendesen be fog indulni a szekér, minden téren.
Értem vagy legalábbis igyekszem megérteni mindkét álláspontot de ezt a "ma ereje" és hasonló agymenéseket ne erőltessük már ennyit pls, megvan a maga diszkrét bája egy bizonyos korig bezárólag de kezd sok lenni.
-
Abu85
HÁZIGAZDA
Mit mikor? DX12-ben alapvető a megoldás. DX11-ben pedig a Frostbite, az új Glacier, az új Dunia, de még a Division által használt Snowdrop is GPU-driven pipeline. Szóval a játékok szempontjából tegnap, ma, holnap.
Ha azt várod, hogy az Ashesre optimalizálnak DX11 profilt, akkor ne várd. A játék négy API-t fog támogatni a megjelenéskor. Csak tud már választani a felhasználó egyet, ami nem DX11. -
Abu85
HÁZIGAZDA
A DX12 csak az ultimate megoldás. A DX11-ben is vannak megoldások, mint a multidraw indirect, amit ma már egyre több játék használ. Az újak közül szinten mind. De azzal a terheléssel, ahol ez probléma ott már átmennek a fejlesztők DX12-re, mert a DX11 nem alkalmas a feladatra. Az API-t 2000 batch-re tervezték, és nagyon nem alkalmas arra, hogy 10000-15000 batch átmenjen képkockánként. Természetesen lehet rá tervezni meghajtóprofilt, mert vannak specifikus megoldások, de ha van a programnak egy DX12-es módja, akkor mi a fenének? Úgysem a DX11-es módot fogja használni a felhasználó. Vulkan opció is lesz, ha valaki nem akar Windows 10-re váltani. Az AMD-nek még Mantle mód is van, innentől kezdve mi értelme van nekik a DX11-es módba erőforrást ölni? Ki fogja azt használni a tesztelőkön kívül?
-
Abu85
HÁZIGAZDA
Ugyanazt a sormintát mutatja a GTX 980 Ti csak más teljesítménnyel. A teljesítményeltérés pedig abból jön, hogy az NVIDIA a parancsmotorjába épített bizonyos fast path-okat, hogy gyorsabban dolgozza fel az egyes parancsokat DX11-ben. A DX12-ben ezek mennek a kukába, mert az OS-hez került a vezérlés, és az nem tölti már be a parancsokat a speciális parancsutakhoz, hanem használja az alapértelmezettet.
Ott van például a multidraw indirect is, mint gyártói kiegészítés, aminél szintén nem használhatók a speciális parancsutak, és DX11 alatt is erősebb a Radeon. Ilyen motor a Far Cry Primalhoz készült Dunia, az új Hitman Glacier frissítése, az új Frostbite. Persze ezekben a motorokban eleve nincs is ezekre szükség.
Az ultimate megoldás az egész nagy problémára a DX12-be épített executeindirect. Nagyrészt emiatt vette el az MS a fő parancsmotor vezérlését a gyártóktól. Persze ezzel megöltek pár innovációs lehetőséget, de az eleve csak tördelte volna a piacot.
-
Abu85
HÁZIGAZDA
Az aszinkron compute implementálása egyáltalán nem nehéz. Mivel a DX12 eleve multiengine API, így csak az a lényeg, hogy jó helyre töltsd a futószalagokat és jókor indítsd el. Nagyjából két napos meló egy single-engine korlátozás mellett. Persze el lehet rontani, de ettől nagyon gyorsan meg lehet csinálni. A aszinkron compute ott válik nehézzé, amikor olyat kell írnod, hogy minden architektúrán működjön valamennyire, és ne rontsa a teljesítményt túlságosan. De ezt nagyon kevesen vállalják majd be, legalábbis innen az látszik.
(#14752) Laja333: Ilyen azért lehet, mert amikor meghoztak bizonyos döntéseket a motorban, akkor a DX12-t helyezték előtérbe, így jó eséllyel a DX11-ben a szinkronizáció el van túlozva, vagy eleve nincs is jól optimalizálva. Sajnos nem lehet olyan döntéseket hozni, ami mindkét API-hoz tökéletesen igazodik.
-
Abu85
HÁZIGAZDA
Igazából miben villantsanak? Ez majdnem egy évtizedes motor strukturálisan abszolút nem a DX12-höz tervezve. Az még rendben van, hogy láttunk már UE3-ban jó explicit API implementációt a Thiefben, de abban a kódban kb. 5%-nyi eredeti UE3 kód maradt meg. És nem azért, mert annyira szerették átírogatni, hanem mert át kell írni, hogy működjön. A GoW egyedül a VRAM allokációból profitál, de másra nem is koncentráltak. Nincs mit igazán kirakni az ablakba ebből a szempontból, mert csak azt fogja kérdezni a user, hogy mi a fenének kell bika hardver pár picit élesebb textúráért. Itt inkább azt lehetne mutogatni, hogy hogyan ne csináld.
Ettől függetlenül persze megoldják a problémát, mert már tesztelik a javítást, de a játék alapja ettől még túl régi marad. Így senki sem fogja mutogatni.
-
Abu85
HÁZIGAZDA
A legfőbb oka inkább a multiadapter. Mindenképpen olyan leképező kell, ami jó mindegyik gyártó architektúrájára. Meg kellett keresni a közös "nyelvet". Ha nem lenne keverhető multiadapter simán elég lenne az eredeti ötlet az AMD-re és a még ma is engedélyezhető single engine kód az NV-re.
-
sayinpety
tag
Nem lehet. Am hardwaret ra lehet tervezni. Velemenyem szerint Microsoft egysegesiteni akarja a hardwaredizajnokat. Talan hibasak vagyunk ebben. Sokat panaszkodtunk eltero front endekre. A DXKG kenyszeriti az IHVt az xBox One integrated GPU front end modelhez. Egysegesitesnek orulok. A modszernek nem.
-
sayinpety
tag
CUDAban nem kovetelmeny a barriers tamogatas. GMUk csak barrier free parancsokat kaphatnak.
D3D12ben DXKG manageli az utemezest. A main command processor OS vezerelt a CPU synchronization miatt. Sok hardwaredizajn nem erre keszult. Am a D3D12 ezert multi engine API. Betoltheto a parancs dedikalt egysegeken. Synchronization kovetelmeny lehet, am ha nem az OS vezerli nem kell ujra-utemezes, cache flush, etc.
-
gamingben és a profi szegmensben nem tudom elképzelni, hogy árbevételben határoznák meg az eredménycéljukat. 75-80% a piaci részesedésük ezekben a szegmensekben. az autóról fenntartás nélkül elhiszem, hogy oda árbevételben határozták meg a célokat. a maradék kettőről nem tudom.
van egy csomó lehetséges magyarázata, hogy a rekord árbevételhez miért társult ennyi költség (kivételesen sok pénz ment a k+fbe, kifizették osztalékként, rolloutolták a minden-középvezetőnek-új-maybachot c. programot), de odáig már nem olvastam a jelentést.
-
#85552128
törölt tag
Pár hét és kiderül, februárra tervezik a második bétát [link]
Kíváncsi lennék, hogy az augusztusban hypeolt async compute mikor kerül bele az AMD kártyákhoz, meg mennyi haszna lesz, mert eddig még csak akkor hozták szóba amikor az nV-ről károghattak arra még mindig nincs magyarázat AMD-n miért nem megy fél évvel később sem
-
Abu85
HÁZIGAZDA
Amikor bejelentették az early access programot, akkor a Stardock felvázolta, hogy lesz egy alpha, ami az alap lesz. A beta 1 lesz az, amikor bekerül pár új játékelem. Új faj, matchmaking, stb. Itt lesz kialakítva a játék alapja. Nagyjából itt tartunk most, ezen belül is az új fajnál. Ezután a beta 2 az, amikor frissítik a leképezőt. Ez már megkapja majdnem az összes effektet, illetve az optimalizálást, ami ma teljesen inaktív. Valamint lesz multi-GPU támogatás ... asszimetrikus és cross-vendor. Ilyenkor lesz stabil maga a játék is. A beta 3 amikor már a technikai oldallal nem törődnek, így ott már a kiegyensúlyozáson lesz a fő hangsúly, és kipróbálásra kerül a térképszerkesztő. Végül jön a release build.
-
rop ide meg oda, én azért még várok teljesítménynövekedést a fijitől.
összeesküvésekről:
For a smooth experience with those max-quality, 4K x 4K textures, a 6GB GPU is instead recommended. And to crank things up to 4K (3840x2160), with Very High textures and max settings, we'd recommended GeForce GTX TITAN X GPUs with 12GB of VRAM, as usage can near 10GB over prolonged sessions. nvidia performance guide. -
Ghoula
senior tag
Ok,természetesen elfogadom.
(Régen olvasottabb voltam ilyen témákban )Igen, sokat nem hoz,de az jól látszik szerintem,ebből és fs-ből is, hogy 290 vonalon jobban megéri a 390 bios-al szórakozni, mint órajeleket hajkurászni.
Valóban,Habuginál az oprendszer is más,de szerintem ott már kezd kifulladni nálam az MC, lásd FS alatt 0 növekmény, remélem hamar érkezik a gpuz feature.
Örülök,hogy sikerült hozzájárulnom a megvilágosodásodhoz.
Arra azért még kíváncsi lennék, Sayinpeti mit mond, memória alrendszert mennyire veszik (mennyire kell) figyelembe kód optimalizálásnál? -
Ghoula
senior tag
Azért crossbar-nál is kell lennie valamilyen paraméternek, pl MC órajel,ami független a gpu órajeltől,vagy az crossbarnál tuti annyi megy mint a mem?
De a blokkméret is beleszólhat, cache szervezés is,amikről nem tudunk semmit.
(rég volt már,lehet rosszul emlékszem dolgokra,nem veszem sértésnek ha kijavítasz
Ebbe így bele se gondoltam,de most hogy mondod, a HUB..., simán lehet, hogy ugyanaz van mint 775nél.
Kár hogy nincs gpu-ra memória alrendszer benchmark.Megcsináltam, de nem olyan látványos. FHD, full, smaa, blur off. Az első missziónál,ahol bedob a játékba,ott néztem osd-n az fps-t, egér nem piszka, hogy hasonlítható legyen.
290
1250: 60-61 fps
1500: 63-64 fps390
1250: 64-65 fps
1500: 68-69 fpsKözben Habugi linkelt a 390x-ével egy FS-t, ugyan 1750-en én nem tudom tekerni a memót, de 1250/1500-on így viszonyul az enyémhez, odaver neki még ~8%-ot.
-
Ghoula
senior tag
Én is így tudtam,de talán a firestrike mérésekből erre lehet következtetni, vagyis inkább arra, hogy ott a latency nagyobb szerepet játszik,mint a sávszél.
290X bios:
1200/1250
1200/1500
compare
2-4% gyorsulás390X bios:
1200/1250
1200/1500
compare
0 differencia290 vs 390:
1250
11% gyorsulás, combined-ban 17%1500
8% gyorsulás 12% combinedGondolom itt már valamennyit behozott a lemaradásból a 290 bios az emelt órajel miatti latency csökkenéssel.
Persze,hogy van neki, nevezhetjük paraméterezésnek is, de pl 775 időkből még emlékezhetsz a performance level/Trd időzítésre, ami nem a memóriához kapcsolódott, hanem a northbridge időzítése volt, hogy a memóriából fetch-elt dolgokat hány órajel késleltetéssel tegye át a GTL buszra. Persze az MC integrálásával ezeken sokat tudtak faragni,de szerintem teljesen nem veszett azért ez el. GPU-nál sem hiszem, hogy másként lenne ez.
Viszont ez alapján azt mondanám, és a tapasztalat is azt mutatja, hogy hiába alacsonyabb pl a maxwell sávszélje, de ha a memória alrendszer késleltetése, nagyobb l2 cache miatti kevesebb memória kinyúlás miatt simán lehet gyorsabb valós felhasználásnál. Persze magasabb felbontásban,ahol több adat mozog, ott a sávszél tud kompenzálni, ahogy látjuk is.szerk,az kimaradt, hogy mindegyik esetben ugyanaz a Stilt féle 1250-es Elpida BBBG timing van a biosokban
-
Ghoula
senior tag
IMC timing,nem a memóriáé. Legalábbis a 390 vs 290 biosnál ez a különbség. Meg ha növeled a mem órajelet,akkor is csökken a latency,vagy rosszul tudom? A sávszél limit is inkább 2 tényezős nem biztos hogy maga a sávszél fog vissza hanem az alacsonyabb órajel miatti magasabb latency. Legalábbis a firestrike tesztem alapján erre tippelnék,mert ott a sávszél (és a tudott,szerkeszthető időzítések) nem változik mégis van 7% difi.
-
Ghoula
senior tag
Amíg nem látjuk,hogy mikor kezd el a memória hibázni,addig vakon tapogatózunk.
(Stilt egyik post-ja szerint lesz majd gpuz-ben monitorozási lehetőség,de konkrétumot nem írt)
Simán el tudom képzelni,hogy ahogy emelte oliba a gpu órajelet,úgy egyre jobban drop-olt load alatt a kártya,és elkezdett ECC-zni.
Amint 1625-ös strap-re váltott, ott javult a helyzet. (Gondolom ha memónál van strap, MC-ben is van.)Sajnos csak gpu órajelet néztem modbiossal,de az látszik, hogy a modbios kb olyan sebesség,mintha gpu ~80mhz-el többet menne.
Emlékeim szerint memória órajel 1500 mindegyik esetben,kivéve talán az 1050mhz-es.Én azt tippelném inkább a latency csökkenésére gyorsul,nem a sávszél miatt.
-
Ghoula
senior tag
Persze, 50% plusz van biosban. Órajelet nem droppol,kopp nyélen megy végig. Hőmérséklet sem lehet probléma, ~55 fokon megy. ECC-t ugye még nem tud monitorozni gpuz,de alap biossal is gyorsult 1375 -> 1500ra. Nekem is soknak tűnik ezért gondolom hogy driver oldalon is lehet valami turpisság.
-
Milka 78
nagyúr
Valóban gyorsabb lett,de nem csak a memória órajel növelésétől.A biosukban fargtak a power tune-on és az időzítésen.A másik,hogy a tesztek ref 290x-el készültek ami igen vicces.
Nekem volt ref 290x-em amit kapott egy rendes oc-t (1580-as memória órajel),majd kapottegy rendes hűtést,majd megkapta a 390x mod biost,így végigkísértem a törzsfejlődését.
A memória oc alig hozott a konyhára (a maxwell jobban reagál),ellenben a normális hűtés és a bios az igen jót tett. -
-
Abu85
HÁZIGAZDA
Most nem azért, de mi másban lehet hinni most? Azért Joe Marci már 8 éve felvázolta, hogy a hagyományos elvek szerint épített memóriarendszerek nem skálázhatók addig, ameddig erre szükség lenne. Ergo a fogyasztásuk egy idő után olyan szintre emelkedik, amivel az erre épített termékkategóriában az új generáció nem gyorsulni, hanem lassulni fog. Elég megnézni a GDDR fejlődését, ahol a dupla teljesítmény azonos buszon mindig kétszeresnél nagyobb fogyasztástöbblettel járt. Az persze világos, hogy a JEDEC feje 8 éve még nem tudta, hogy mi lesz a megmentő, de ettől függetlenül az előrejelzése pontról-pontra bejött. Persze őt ezért fizetik.
Ma HBM-en kívül semmilyen más működő alternatíva nem létezik a Marci által 8 éve felvázolt problémára, így baromira nehéz kétségbe vonni a HBM jövőjét. -
#13600
Malibutomi
nagyúr
gbors
#13599
Malibutomi
nagyúr
Happy
Korbeertunk, abbol indult az egesz hogy itt irtak olyat hogy a GDDR5X mellett nincs is szukseg HBM-re, de ahogy irod a piaci szereplok hisznek benne. Ezt peldaztam fentebb en is az NV valasztasaval, csak belegabalyodtunk a megnevezesekbeEgyebkent kivancsi leszek a HBM2 kartyakra. Leboges lenne ha azok is csikoznanak.
-
#13597
Malibutomi
nagyúr
gbors
#13593
Malibutomi
nagyúr
Megint elbeszelunk egymas mellett.
Azert mindegy mert nem azt irtam hogy HBM1-el adnak ki kartyat, hanem hogy HBM-el. A HBM2 memoria is HBM, a technologia alapja ugyanaz.
A hangsuly azon volt, hogy az nvidia is a HBM technologiat valasztotta a GDDR technologia helyett a csucskartyaira (most nem irtam a GDDR utan sem szamot). Ennyi.
A sikeressegrol en nem beszeltem, arrol vagy a bukasrol majd beszelunk egy jo ido mulva ahogy te is irod.
(#13594) Pepeeeee
Nem no duplajara a grafikai terheles pont az osztottkepernyo miatt. -
Abu85
HÁZIGAZDA
Valójában HBM2 nincs. A HBM az egyetlen specifikált szabvány, csak a magasabb órajel miatt HBM2-nek hívják, de szabvány szinten csak egy HBM update. A két rendszer, amit mi külsőleg számmal megkülönböztetünk, valójában ugyanabba a JESD235 specifikációba van besorolva. Tehát pontosan ugyanaz a technológia.
Akkor beszélünk külön technológiáról, ha más besorolást kap. Például GDDR5 (JESD212), illetve GDDR5X (JESD232). -
#45185024
törölt tag
Ez a mondatod annyira zseniális hogy rá kellene nyomtati az Oculusra
"Jobb a ronda, mint a hányás"
De ha ennyire fontos az FPSt akkor azt hogy oldják meg hogy 90 alá ne essen le?
Mert akkor az kellene hogy azt fixre beállítod és ismerve a kártya adatait pl 970 és akkor magától beállítja a kártyához a grafikát, szóval hogy érted ne engedje be 90 alá semmiképpen. -
Abu85
HÁZIGAZDA
Maga a timewarp eléggé általános megoldás, tehát többféle felhasználási módja van. Most, ha csak arról beszélünk, hogy mi az ideális, akkor nyilván egyértelműen az, ha minden kész nyers képkockát timewarpolunk. De ezt elsődlegesen azért tesszük, mert az aktuális szabványos grafikus API-k csak a jelenet kamerapozícióját fogadják el. Alternatíva a LiquidVR LDL funkciója, amely képes a jelenet kamerapozícióját megváltoztatni a képszámítás előtt. Ilyen módon úgy is kaphatsz felezett késleltetést, hogy nem timewarpolsz.
-
Abu85
HÁZIGAZDA
Nyilván, ha nem számít a pénz, akkor megveszed a Falcon Northwest Tiki-t és le van tudva. Vagy DIY alapon veszel egy Dual Fiji kártyát. Ezzel biztosan nem lesz gond, mert erre lett tervezve. Csak ennyiért autót is vehetsz majd.
Nem akkora gond a timewarp. Bőven megéri használni, mert biztonságos, hogy ha megkétszerezed a valós frame-számítás szinkronablakát.
Az AMD ma még nem alkalmaz semmilyen képminőséget csökkentő módszert a saját SDK-jában. Az NV alkalmaz egy multi-res shading eljárást, ami a kép szélét csökkentett minőségben számolja. Ezt a fejlesztő aktiválhatja, vagy letilthatja attól függően, hogy mennyire van a programja a "hányáshatáron".
A multi-res shading célja egyébként pont a timewarp szabadabb alkalmazása. Kevesebb számítással csökken a késés esélye. -
Abu85
HÁZIGAZDA
A ritka drop nem számít. Nem kellemes, de viszonylag könnyen túléli az agy. A problémát az jelenti, ha folyamatosan lecsúszik a timewarp a szinkronablakról. Itt van egy olyan jelenség, hogy az aktuális grafikus API-kon belül nincs frame megszakítás. A megkezdett munkát be kell fejezni, még akkor is, ha már tudjuk, hogy a szinkronablakról lecsúszott. Ez akár még 3-5 ms-nyi extra számítást is jelenthet, de ugye már mindegy. Viszont a hardver innentől folyamatos hátrányba kerül, mert a még futó, de már felesleges számítás miatt késik az új, de fontos számítás.
Erre lesz egy megoldás idén, de csak a Mantle-be. Ez az instant killnek gúnyolt képesség, ami tulajdonképpen a szinkronablak lekésése után azonnal megöl minden késői timewarp-hez tartozó számítást. -
-
Abu85
HÁZIGAZDA
Finomszemcsés preempcióval gyakorlatilag garantált az aszinkron timewarp elkészülte. Az NV-féle rajzolási szintű preempció is jó, addig amíg 2 ms alatt van az üzemmódváltás. Ha valami beragad 2-nél több ms-ra, akkor a timewarp garantáltan lekési a szinkronablakot. Ezek eléggé nyíltan beszélt problémák a fejlesztők és az Oculus/Valve, illetve a gyártók által.
-
#45185024
törölt tag
És azt sem tudjuk hogy az öreg rókák hogy fognak rókázni a minimum 75 FSP-n.
Mert elő van írva a 90 de lejjebb lehet venni.
Meg kérdés mitől lett hirtelen 600 dollárosan Exclusive mert a FOV ban elmarad más kijelzőktől és nincs benne szemkövés sem, mindenesetre felbontásra nem exclusive csak az árában, köszönjük kedves fészbúk men.
A Scrap mechanic is VR es lesz láttam az inijében a VR=0 beállítást. -
füles_
őstag
Én nem gondoltam hogy ebből ekkora karaté lesz,nem is volt szándékomban karatét indítani
Csak gondoltam hogy beszólok egyet a túloldalnak,amit már megszokhattunk ebben és más topikokban is.
Váltsunk témát
Kicsit off topik,de láttátok már a Division gépigényét?
Kíváncsi vagyok hogy hogyan néz majd ki PC-n -
A költségek így állnak össze (pár fontos dolog úgyis kimarad, de nagyjából jó lesz):
volumentől független:
hardverfejlesztési költségek (k..va sok)
szoftverfejlesztési költségek (k..va sok)
marketing (sok)volumentől részben függő:
értékesítési hálózat (nem túl sok)volumentől függő:
gyártási költségek (egy kevés)
licencköltségek (aprópénz)Ebből látszik, hogy a mostani rendszerben tényleg buknak minden egyes eladáson. Ha normálisan áraznának, akkor a volumen képes lenne pluszba fordítani a mérleget. Persze azt is tudom, hogy az AMD-nél nem ennyire hülyék ülnek, hogy ezt ne tudnák 1 perc alatt kiszámolni.
Nyilván ez az egész arról szól, hogy nem akarják a jelen sikereivel dugába dönteni a jövő lehetőségeit. Ha most alááraznak a piacnak, akkor ezt várja tőlük majd mindenki, és folyamatos szopórolleren lennének a következő években, függetlenül az éppen atkuális sikerektől. Ezt már eljátszották egyszer a HD3000 és HD4000 sorozat alatt, amikor a hasonló bénázás (X1000, HD2000) után a mai szemmel nézve fillérekért odaadták a termékeiket. A volumen kihozta őket nullára, vagy termeltek némi aprót, de nem voltak elégedettek. Húzták egyre feljebb az árcímkét, és játszottak a kategóriákkal (középkategória: HD5000 sorozatban még 700-as volt, HD6000-nél már 800, aztán R9 300-nál már 90-es), de csak nagyon nehezen tudták elfogadtatni a piaccal, hogy az nvidiához hasonlóan ők is prémiummal szeretnék eladni a termékeiket (szerintem még most sem sikerült).
Most nem hajlandók lemondani erről a szép jövőről (szikrázó napsütés, puha, zöld gyep, szivárványos póni
), inkább benyelik a veszteséget. A létező legrosszabb pillanatban jött ez a gyengélkedés, de akkor sem engednek a 21-ből. Hátránya ennek a tervnek, hogy vagy bejön, és lesz jövőjük, vagy befekszenek a saját maguk által ásott sírba. Én nem lennék most AMD részvényes. 
Ha szerencsejátékra vágynék, akkor inkbb Vegasban szórnám el a pénzem, az szórakoztató, AMD részvényesnek lenni csak idegesítő. -
-
daveoff
veterán
A memória botrány ellenére még mindig a legjobb ár/érték/teljesítmény arányú kártyáról van szó, nem csoda, hogy népszerű. Stratégia, és marketing szempontjából ég, és föld a két gyártó. Ez a széria hatalmas lendületet adott az NV-nek, AMD-nek meg hatalmas bukta volt, nagyon kíváncsi vagyok idén mi sül ki ebből az egészből.
(#13428) Valdez: szvsz az architektúrával sincs semmi baj, arra jó, amire használjuk, többi nem számít..
-
#13411
hugo chávez
aktív tag
gbors
#13394
hugo chávez
aktív tag
"A fejlesztők pedig eddig állítólag lángoló hajjal, égnek emelt kézzel imádkoztak a low-level API-kért, aztán meg lehet nézni, hány játék jött ki eddig egyáltalán bármilyen támogatással (ugye legalább kill CPU-overhead), nem beszélve egy új elvek szerint felépített motorról, aszinkron kutyfülével meg minden. Vagy a fejlesztők vágyai lettek aránytalanul felnagyítva, vagy tényleg ez volt a kis szívük minden vágya addig, legalábbis addig, amíg csak szövegelni kellett..."
Na igen... Tök jó dolog az explicit API, meg sokat ki lehet vele hozni a hardverből, de ennek ára van. Ami a sok-sok munka, amíg a megfelelő struktúrájú engine-eket megírják rájuk. És, ha valakinek nincsenek extrém igényei (olyanok, amiket DX11-ben már nem lehet megcsinálni, vagy csak komoly trükközéssel), akkor egyszerűbb maradnia a magasabb szintű API-n, mert azzal jóval könnyebb dolgozni ebben az esetben... Én legalábbis a kezdetektől fogva ezt szűrtem le az "explicit API történetből".
-
#13408
Malibutomi
nagyúr
gbors
#13407
-
Abu85
HÁZIGAZDA
Igen, csak nem tudod, hogy milyen beállításokat rejt az a high ... Simán lehet, hogy minimumon van a post-processt, vagy inaktív a lágy árnyék, meg egy rakás dolog ezen kívül, miközben pár olyan dolog meg maxra van rakva, amelynek látható hatása nem igen van a játékban, de a procit zabálja, hogy még a hat pixelnek látszó útra is autókat rak.
-
-
#13375
#Morcosmedve
veterán
gbors
#13374
#Morcosmedve
veterán
-
#13373
Petykemano
veterán
gbors
#13369
-
Abu85
HÁZIGAZDA
Többször leírtam az okot. A Kepler esetében a magok 33%-a elvész, ha nem optimalizálod jól. Érdekes, hogy sokan jól csinálják, és még a Maxwell is jó.
Nekem mindegy, hogy mit csinálnak, mert ez is csak üzlet. De nem értek egyet vele, mert honnan vagyok kibiztosítva, hogy nem csinálják majd ugyanezt a Maxwellel? Az persze, hogy a Kepler esetében nem tapsikolnak a userek a helyzetre reménykeltő.
A GameWorks esetében a probléma mindig is az volt, hogy rossz minőségű és optimalizálatlan, illetve átgondolatlan. Ez érint minden hardvert. Néha a Keplert jobban. Az igazi probléma a Keplernél a TWIMTBP.
-
Abu85
HÁZIGAZDA
Nem. Te azt mondtad, hogy a hiba nem tuninghoz kötődik. Valójában ahhoz kötődik.
Ha szerinted normális, hogy a 780 a 960 szintjén van pár TWIMTBP játékban, miközben számos játékban a 970-nel küzd, akkor az a te dolgod. Szerintem viszont nem normális, és számos Kepler tulaj szerint sem az, aminek hangot is adnak még az NV fórumán is. Szerintem jól teszik. Próbálják elérni, hogy nagyobb teljesítményt kapjanak, hogy egy 384 bites egykori csúcsmodellt ne verjen el egy 128 bites új talicska, mert amikor megvették a 780-at, akkor bizonyosan nem erre számítottak.
-
Abu85
HÁZIGAZDA
De a tuninghoz kapcsolódott, mert az Overdrive modul onnantól működött rosszul, hogy megváltoztattad a venti szabályozást. Ha azt nem bántottad, akkor nem jött elő a hiba. Ezt onnan tudom, hogy az overdrive modult én használtam még a kiadás előtt, és három játékhoz beállítottam külön órajelet, hogy működik-e a játékokra lebontott tuning, persze a ventihez nem nyúltam, mert az elvégzi a feladatát tuninggal is, hiszen a BIOS-ban leírt profilnál úgy sem tudok neki jobban csinálni. Ilyen formában a venti nem ragadt be.
Természetesen addig eljutnak, hogy aktiválják a modul egyes elemeit, de pont az volt a baj, hogy a tuningra vonatkozott a hiba. Tuningot pedig már nem tesztel senki. Ameddig bekapcsoltad a funkcióit, addig nem jelzett problémát, márpedig az alap teszprotokoll kimerül abban, hogy aktiválják és működik-e. Ilyen formában átment a meghajtó, mert működött. Azoknál nem működött, akik megváltoztatták a tuningbeállításokat.
Arra kérsz bizonyítékot, hogy tuningot senki sem tesztel? Ez a legegyértelműbb dolog. Mit teszteljenek rajta? Nem fogják 1 MHz-enként és 1%-onként az összes nagyjából 1-2 millió kombinációt kártyánként ellenőrizni. Erre nincs kapacitás sehol. Azt csinálják meg, hogy aktiválják a funkciókat és az aktiválás működik-e. Ez működött. Ez az, amit reálisan lehet tesztelni kártyánként. Ez így is elvihet két napot.
Mondtam példát, csak nem tartottad elég jónak. Még linkeltem is az NV felhasználók fórumát, akik elégedetlenek azzal, amit az NV csinál a Keplerrel.
(#13037) ffodi: Nem arról van szó, hogy nem probléma, csak nem olyan probléma, amivel kapcsolatban bárki felelősségre vonható, mert egy olyan modulon belül volt a hiba, amelynek az aktiválásához el kell fogadnod, hogy a gyártó mentesül minden felelősség alól. Ez pont azért van így csinálva, mert képtelenség VGA-nként egymillió konfigurációt végigtesztelni. Tegyük fel, hogy egymillió lehetséges kombinációt kell tesztelni 100 VGA-ra. Az 100 millió teszt, és egy stabilitásteszt 8 órás. Tehát egy meghajtó tesztje 800 millió óra lenne. Ez képtelenség. Ezért jobb a tuningra nem vállalni garanciát.
A tönkretétel egy kamu volt. Egyetlen ember sem jelentkezett a twitteren azok közül, akik beírták, hogy tönkrement a Radeonjuk. Pedig felajánlották mindnek a cserét.
Az overdrive modul eleve a drivertől független settings modul része. Ha utóbbit nem telepíted attól a meghajtó működni fog.(#13038) FLATRONW: Én is arra gondoltam. Volt olyanom. Ma már nincs, mert a GPU PhysX leállt. A Witcher 3-ban is csak lassulást okoz.
(#13041) schawo: Nem hiszem, hogy akármelyik bíróság érvénytelenítene egy olyan EULA-t, amely azt fogadtatja el a felhasználóval, hogy a termék nem rendeltetésszerű használata okozta hiba a user felelőssége.
(#13042) Macka: Azokban a tuningprogramokban is van hiba, amelyeket a gyártók az GeForce-okhoz adnak. Csak az NVIDIA nem teszi lehetővé a tuningot egy gyári modulból, de registry módosítással lehet.
(#13048) Egon: Ez tévedés. A tuningra akkor sincs garancia, ha 1 MHz-et emelsz rajta, és hibátlanul működik. Megteheted, hogy tuningolod, de garanciát senki sem vállal rá. Akármilyen hiba jön elő a te felelősséged, mert egy olyan szerződés elfogadása után egyetlen programban sem lehet tuningolni, ahol te nem fogadtad el azt a feltételt, hogy az esetleges hibák téged és kizárólag téged terhelnek.
Ha aktiváltad az overdrive-ot attól még működött. Onnantól nem működött, hogy kézi ventivezérlésre kapcsoltad, vagyis bekapcsoltál egy tuningfunkciót.(#13050) daveoff: Azért nem csinálják azt, mert az AMD-nek PowerTune technológiája van a hardver vezérlésére és ez nem szoftveres, hanem teljesen hardveres rendszer. Ezt a technológiát annyira védik, hogy még a gyártóknak sem árulják el a működését, így a gyártói tuningprogramok is abból élnek meg, hogy az egyes PowerTune verziókat visszafejtik. Ezért késik mindig az új Radeon VGA-k tuningjának támogatása a 3rd party programokból. Az NV által használt rendszer félig szoftveres csomag, vagyis tulajdonképpen egy szoftvert kérdez meg a hardver, hogy az egyes állapotokra mit lépjen. Ezt jóval egyszerűbb lekövetni, mint az AMD PowerTune rendszerének szoftveres hátterét feltörni. Emiatt csak az AMD képes arra, hogy a PowerTune profilhoz szabott tuningfunkciót biztosítson.
-
Rivyan
csendes tag
Igen, tudom, ott is jártam, ide inkább nem is olyan véleményt várnék, hogy exactly milyen kártyát vegyek, hanem inkább magára a gondolatmenetre választ, hogy megéri-e most kártyát venni, várható-e ekkora teljesítménybeli változás a kövi évben DX12 miatt, és hogy AMD vagy nVidia kártyák között található-e olyan, ami legalább icipicit futureproof. Azért itt kérdeztem ezt, már lehet, hogy az adott topikban inkább a kártya jelenlegi teljesítményén/értékén van a hangsúly, itt ha jól láttam inkább a technológián és azon, hogy mit hoz a jövő a két gyártó közötti "harcban".
De ha nagyon rossz helyen kopogtatok, akkor elnézést
-
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
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
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ha szerencsejátékra vágynék, akkor inkbb Vegasban szórnám el a pénzem, az szórakoztató, AMD részvényesnek lenni csak idegesítő.
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest