Tomi Yllgrim-et kérdezd meg erről ő írt már erről:
"0.6.0.1-es SDK-val teszteltem, szemuveg nelkul nekem a gyors korbenezes fejfajasos, kiprobalom az uj 0.7-essel, ebben mar van LiquidVR csomag meg specko driver is ha az megszunteti nalam szemuveggel vagy/es anelkul akkor.." #9814
Ugyanez lesz Nvidián is ...

[ Szerkesztve ]

Nem biztos.
LiquidVR tud 10ms latency-t. Fejfájás nélküli élményhez 20ms alatti érték kell. NV legjobb esetben tud 25 ms-ot.

[link]

Szerintem a VR-nél ne keverjük a szoftveres problémát a hardveressel. Az AMD implementációjának azért olyan alacsony a késleltetése, mert a VR egy VR-re tervezett API-n keresztül működik. Az NV-nek csak a szabvány API-k maradnak, amelyeket nem terveztek olyan igénybevételre, amilyet a VR követel. Függetlenül attól, hogy a hardver mire képes, a szabvány API-k nem alkalmasak a megfelelő késleltetésre. Akkor lesz ez a VR alkalmas a legtöbb hardverre, ha a szabványos VR API-k elkészülnek.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

A Guru3D kapott Nano-t.

Ha már VR. A finomszemcsés preempció kihasználásához szoftveres oldalon mi kell? Csak a LiquidVR?

www.smart-bus.hu

Nem ertem, gyorsabb most a DX11-ben mint a DX12-ben ?

~~~~~~ Privatban NINCS szakmai tanacs! ~~~~~~

Lényegében igen. Valójában persze a Mantle kell, de az a LiquidVR alapja.

Igazából nem ez az AMD igazi VR csodafegyvere. Fontos dolog, de a Latest Data Latch miatt olyan alacsony az AMD VR csomagjának késleltetése. Ez ugyanis lehetővé teszi, hogy a fejpozició közvetlenül a GPU-s számítás előtt legyen meg. Minden más VR rendszer a jelenetszámítás előttről szerzi ezt az adatot, és ez ad hozzá az egészhez úgy 5-10 ms-os extrát.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

A fejpozíció követés már a TrackIr esetén is tökéletesen működik ha megvan a fix 60 FPS. Vagy csak azt hisszük, és nem venni észre az akadást, mert nem a teljes látóteret tölti ki a kép?

Régebbi játékok esetében mennyire lesz bonyolult megoldani a támogatást, hogy normálisan is működjön a VR?

www.smart-bus.hu

Maxwell2 full async

Lehet felesleges volt aggódni :p

The Rematch

GTX 780 Ti vs R9 290X August 24, 2015

Ennyit a kepler nem támogatásáról...

[ Szerkesztve ]

★★★★★ I got too much soul, rhythm and blues R&B ya see, all that's cool, but hip-hop and rap yeah that's where my heart's at Even back when I used to break on a box ★★★★★ "Chief Rocka"

Hoek nem akarlak elkeseríteni de ez nem mond ellen az itt eddig elhangzottaknak.
Eddig is azt mondták hogy tudja (szoftveresen) csak a kontextus váltás miatt nem gyorsul tőle a rendszer.
Erre most ez azt írja:
Maxwell 2: Queues in Software, work distributor in software (]context switching), Asynchronous Warps in hardware, DMA Engines in hardware, CUDA cores in hardware.
Szóval én kivánom hogy tudja és minden Nvidiás is legyen boldog direct x 12 alatt de azért várjunk meg konkrét számokat inkább.

[ Szerkesztve ]

A 980 megjelenését követő prohardveres tesztben a 780ti-t a 980 is bőven előzte. (A 980 előzte, de még a 970 is béfogta a 290x-et is ugyebár)

Ebben a tesztben, amit linkeltél, meg az látszik, hogy! 780ti újra fogja a 290x-et, de nemhogy a 970-980, de még a 980 ti is csak picivel erősebb.

Most ezzel lehet, hogy kivágta magát az nvidia az alól. Vád alól, hogy a korábbi generációk támogatását abbahagyná az új generáció érkeztével. De még súlyosabban vetül rá a piac szándékos szoftveres befolyásolásának árnyéka, saját vásárlóinak manipulálása, az új széria driveren keresztül történő kedvezőbb színben való manipulatív feltüntetése.

Ahogy korábban Abu említett egy példát, hogy vajon hogy érezheti magát az a titan vásárló, aki látja, hogy a 960 bizonyos játékokban jobban teljesít. Vajon hogy érezheti magát az, aki épp 780ti kártyáját cserélte a sokkal jobb maxwellre. Ami most mint kiderült annyival nem is jobb.

De le a kalappal. A stratégia működik. Egyrészt ez generál eladásokat. Másrészt durva, hogy olyan komoly szoftveres tartalék van a kártyákban, amely lehetővé teszi/tette a 780ti elhanyagolását úgy, hogy versenyképes maradt a konkurenciával a Maxwell megjeleneléséig.
Harmadrészt működik. A S/A fórumon olvastam valakitől, hogy egy ismerősével egy időben vásároltak videókártyát, 7970, ill 680. Az nvidiás már cserélt maxwellre. Mikor beszélgettel az aszinkron shaderekről, és hogy jobban járt-e aki amdt vett, az nvidiás azt felelte,hogy nem baj,majd amikor kijön az új nvidia kártya, ami már nem marad abban sem alul, megveszi azt is.

Könnyen észrevehető, hogy az elégedett vásárló, nem Mindig a legjobb üzleti stratégia.

Találgatunk, aztán majd úgyis kiderül..

Ez a tipikus amerikai mentalitás, vedd meg az ájfón hármat a négyet az ötöt, mert neked szükséged van rá.
Miért is mert van benne ujlenyomatolvasó, és az cool, mert nehogy már megjegyezd a 4 jegyű pinkódod inkább vásárolj 200 ezerért.
Az hogy meg tud az ipar győzni embereket hogy nekik szükségük van 250-300 ezres videó kártáykra és minderre másfél évente persze, az teljes agymosás, és mégis létezik és most már az AMD is kezdi ezt átvenni felzárkózva Nvidiához.
Így tűnt el szép lassan a középkategória.

[ Szerkesztve ]

Na a Nano tesztpéldényok limitálásával tényleg elérte az AMD a legalja szintet... ez már gáz... komolyan felmerül bennem a kérdés, miből fog élni a vga részleg, ha csak az átnevezett termékek vannak a piacon, a Fiji alapúakból meg kb 0 értékelhető mennyiséget gyártanak. Nagyon nagy a baj már az AMD-nél.. már azzal sem tudnak a piacon jelen lenni, ami tán eladható lenne.

Az meg hogy TPU-nak nem adnak tesztpéldányt, kb olyan, mintha egy autógyártó a Top Gearnek nem adna.Irtó béna, és gyerekes húzás.

Hát lehet bölcsebb döntés lett volna megvárniuk a 14nm-t.
Gyakorlatilag mire tudnak értékelhető mennyiséget gyártani Fury-ból elfogadható áron addigra jön a 14-16nm.
Kínszenvedés amit csinálnak.Sajnálom az ATI-t hogy nem talált jobb gazdára.

Tévedni emberi dolog, de állati kellemetlen.

Nem, szerintem ez a bekötés... eddig is tudtuk, hogy TIER 2, tehát több CPU overhead-et fog emészteni a GPU etetése paralell... Ezt már hónapok óta tudni, hogy szoftveres context switch van benne, míg GCN-ben ott lapul HW-ben.

Itt már olyan vádak érték a Maxwell2-őt, hogy nincs benne egyáltalán Async motor, és driveresen sem lehet megírni. Nagyon kíváncsian várom mi lesz a végkövetkeztetés, lehet nem fog annyit gyorsulni mint a GCN, vagy nagyobb overhead lesz, de ha megtanulják használni a másfajta rendszert a fejlesztők, akkor nem jutnak az Oxide sorsára, hogy DX11-ben majdhogynem gyorsabb.

Abu azért jó lenne ha ránézne és validálná az infót

Miről beszélsz te? Hisz van Fury a piacon.[link]

Nanot meg levadászták az oem -ek.Ott talán nem kell árversenyt vívni az AMD -nek,és felvásárolják az összes legyártott darabot, kérdés nélkül.
Majdnem olyan mint a 380X, papíron van,de mind a Apple -é.

TPU meg talán valamikor megsértette az NDA -t és azért nem kap. Amúgy meg az olyan olvasók mint én is,akik google -n keresünk rá a tesztekre.Majd most nem a TPU olvasottságát fogjuk növelni hanem más weboldalakét.

(#9967) imi123 Lehet hogy a Fury csak egy tesztfázis a 16/14nm előtt.Nekik addigra már lesz tapasztaltuk a HBM -el.

[ Szerkesztve ]

Amikor nincs remény! Jusson eszedbe nincs isten, csak én!

Végül is valahol el kell kezdeni.
Kemény év lesz 2016.

Tévedni emberi dolog, de állati kellemetlen.

Mit gondolsz nem miért nem veszem most fullhd -re GTX980Ti -t vagy Fury -t? Csak kihúzom a következő generációig valahogy a MSI R9 390 -nel.Még ha néhány játéknál vissza is kell vennem a látványból.

Amikor nincs remény! Jusson eszedbe nincs isten, csak én!

Hát egy 390-el el lehet 1-2 évig lenni.Jó kis kártya.
Én is elvagyok 980-al Fullhd-n.Nekem mondjuk elég a 60.FPS bőven.Minimum FPS legyen minél nagyobb.

Tévedni emberi dolog, de állati kellemetlen.

Ha elfogadjuk így van, akkor sincs gond feltétlen.

Ez csak azt mondja hogy az ACE bizonyos része szoftverben(driver) van megoldva, míg AMD-n hardveresen.
Ettől még nem feltétlen lassabb (pl kell context switch), csak máshogy törénik a vezérlése/előkészítése.
(Pl lehet CPU igényesebb csak, az meg ma már nem igazán gond.)

[ Szerkesztve ]

Steam/Origin/Uplay/PSN/Xbox: FollowTheORI / BF Discord server: https://discord.gg/9ezkK3m

Wikin amugy ez van írva a context switchről általában:

"Hardware vs. software

Context switching can be performed primarily by software or hardware. Some processors, like the Intel 80386 and its successors,[6] have hardware support for context switches, by making use of a special data segment designated the task state segment or TSS. A task switch can be explicitly triggered with a CALL or JMP instruction targeted at a TSS descriptor in the global descriptor table. It can occur implicitly when an interrupt or exception is triggered if there's a task gate in the interrupt descriptor table. When a task switch occurs the CPU can automatically load the new state from the TSS.

As with other tasks performed in hardware, one would expect this to be rather fast; however, mainstream operating systems, including Windows and Linux, do not use this feature. This is mainly due to two reasons:

1. Hardware context switching does not save all the registers (only general purpose registers, not floating point registers — although the TS bit is automatically turned on in the CR0 control register, resulting in a fault when executing floating point instructions and giving the OS the opportunity to save and restore the floating point state as needed).

2. Associated performance issues, e.g., software context switching can be selective and store only those registers that need storing, whereas hardware context switching stores nearly all registers whether they are required or not."

Szóval várjuk meg mi lesz, lehet ettől még gyors. Attól függ az nVidia hogy oldotta meg.

[ Szerkesztve ]

Steam/Origin/Uplay/PSN/Xbox: FollowTheORI / BF Discord server: https://discord.gg/9ezkK3m

Külön pikáns az ügy egyébként ennek fényében , már a Fermi is:

[ Szerkesztve ]

Steam/Origin/Uplay/PSN/Xbox: FollowTheORI / BF Discord server: https://discord.gg/9ezkK3m

"nVIDIA do support Asynchronous Compute on a hardware level but a large part of their scheduler is implemented in software. Therefore what feeds their Asynchronous Warp Schedulers is a series of Software solutions."

Nem biztos, hogy előrébb lesznek.

Ezt eddig is tudtuk. Főleg a Context Switch szoftveres részt.

Nem ez tulajdonképpen a "szoftveres bekötés"? Mert ha igen, akkor semmi új infó nincs.

gcn stateless, cserébe nem "emlékezhet" az előzőleg végrehajtott feladatokra, csak azzal dolgozhat a gpu, amit megkapott.
amíg nvidiánál sávszél spórolás van, addig a stateful működés nekik a megfelelő, és a soros feldolgozás.
de majd a profik megmondják.

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.

Elég részletes leírás itt

Találgatunk, aztán majd úgyis kiderül..

Jó kis cikk (így reggel félig másnaposan )
Ha tényleg Slow Content Switch-nek hívják már, akkor mitől async? Lehet semmit se fog gyorsulni, mert összeadódnak a ms-ek.

Hamarosan roskadásig lesz Hardverapro 100 ezres 980 Ti-kkel

Jó kis írás, érthető, és nem utolsósorban magyarázza az összes eddigi jelenséget / állítást. Ha az "üzemmódváltás" tényleg up tp 1000 ciklust igényel a Maxwellen (ez azért egy elég súlyos állítás), akkor a gyakorlatban frame-enként nem lehet több 1-2 ilyen átkapcsolásnál (sőt, ALU-limitált esetben 1-nél sem nagyon), azaz a schedulernek nagyon komolyan rendezgetnie kell a feladatokat. Ezt meg lehet csinálni egészen addig, amíg a graf és a compute feladatok nem használják össze-vissza egymás eredményeit. Ezzel meg is van a recept, hogy hogyan lehet megcsinálni a földalatti óceán AMD-s megfelelőjét

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Ha jól értem, ez azt jelenti (amit 970 topicba is írtam), hogy limitált módon, de működhet az Async nem?
Tehát 1 graf, 1 compute szál még oké lehet slow context switch-el is, mert az még etethető szoftveresen, beleférne a frame-be.

"Ezt meg lehet csinálni egészen addig, amíg a graf és a compute feladatok nem használják össze-vissza egymás eredményeit."

Erre alapból figyelni kéne a paralell programozás miatt, nem? Vagy nem világos GCN-en ez miért ne okozna fejtörést.

Azért azt tartsuk szem előtt, hogy a város alatti óceán mindkét hardvert megizzasztotta annak idején, csak belerakatták, mert míg NV-n csak 17-21% sebességbe került, addig az AMD-s kártyákon 31-38%-ot vett el a teljesítményből. [link]

Háttérstory, hogy az Nv halál feleslegesen rakta bele a hardverébe az atomdurva tesszelátort, a HD5850-em "elsőgenerációs" tesszelátorával is még évekig remekül el lehetett lenni a legkisebb gond nélkül.

Async shader esetében viszont arról van szó, hogy az egyik termék tud egy igen hasznos funkciót, ami ráadásul a DX12 egyik lényegi újdonsága, amivel jócskán gyorsulhat a feldolgozás, míg a másik hardver úgy néz ki, csak papíron tudja ugyanezt és még lassulhat is.

Tehát az első esetben egy nem központi funkció irreális (mesterséges) túlhasználatáról volt szó, amitől mindkét hardver szenvedett, csak az AMD kicsit jobban praktikusan a semmiért. A második esetben viszont az új API egyik lényegi újdonsága fest úgy, hogy nem hoz pozitív eredményt az Nv hardveren, míg az AMD-n igencsak.

Továbbra is amondó vagyok, hogy korai lenne túl messzemenő következtetést még levonni (mindamellett azért már kezdenek kirajzolódni dolgok), az érvelésem csupán arra irányult, hogy én egészen másmilyennek látom ezt a szituációt, mint anno a Crysis 2 tesszelálós történetét.

(#9982) Ren Hoek: A GCN-nek nem okoz fejtörést, mert ott vannak a hardveres ütemezők (ACE-k) valamint "stateless" architektúra, azaz nem kell állapotot váltania bizonyos funkciók elvégzésére.

[ Szerkesztve ]

"A második esetben viszont az új API egyik lényegi újdonsága fest úgy, hogy nem hoz pozitív eredményt az Nv hardveren, míg az AMD-n igencsak."

AOTS esetében...egy kezdeti benchmarknál. Ez a meccs még nincs lejátszva.

Nem a compute queue-k száma az izgalmas kérdés, hanem (feltéve, hogy tényleg ekkora overhead a CS) a szükséges váltások száma. Ha pl. az összes compute queue scene-előkészítési feladatokat végez, amik mind lefuthatnak a grafikai taskok előtt, akkor nyugodtan lehet több queue, először azokat hajtja végre a GPU - aztán vált, és jöhet a grafika (mellesleg ez nagy előnye a félig szoftveres megoldásnak). Ennek persze előfeltétele, hogy a frame-re vonatkozó összes feladat meglegyen, amikor elkezdi a számítást - ezt nem tudom, hogy így van-e, ill. ha nincs, akkor megoldható-e egyáltalán. Ez egy második, ellenkező irányú nagy HA.

Az önmagában nem gond, ha az adat ide-oda vándorol a compute és a grafikai queue-k között - miután ezek az architetktúrák erősen latency-állók, szerintem a GCN-en ez csak akkor gond, ha eszement mértéket ölt. Ami inkább kérdés, hogy a gyakorlatban mennyi értelme van ennek - nem vagyok grafikus programozó, úgyhogy erről inkább véleményt sem mondok.

(#9983) HSM: kicsit túlpörögted azt az egy mondatot, nem? Nem a két szituációt hasonlítottam össze, csak annyit jegyeztem meg, hogy most már az AMD oldalon is van csodafegyver.

Az, hogy a gyakorlatban mi lesz, attól még nagyon messze vagyunk. Egyrészt ott voltak sayinpety fórumtárs saját tapasztalatai, ahol a Maxwell is gyorsult az a-c hatására, tehát elvileg működésre lehet bírni a dolgot normálisan. Másrészt B megoldásként ott lesz a lehetőség, hogy mindent a gf queue-ba tesz a program, mint az AotS esetében - így az aszinkron sebességnyerés elmarad, de ez úgyis kisebb lett volna, mint a GCN esetében. Harmadrészt pedig, ki tudja, milyen meglepik jönnek még elő...

[ Szerkesztve ]

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Amúgy AOTS bench akkor most milyen állapotban van? Nekem ez sem tiszta.

- Multicore támogatás egyelőre nem aktív? (FX ezért maradt le)
- Van benne jelenleg Async? Milyen mértékben/formában? (Abu említette, lesz majd olyan pálya ami DX12-ben indul csak el, olyan "durva") Vagy NV egyelőre kikapcsoltatta a saját kártyáira?

Csak mert sokan olyan következtetéseket vonnak le architektúrákra nézve, egyetlen programból, hogy az totál értelmetlen.

David Kanter itt eléggé körbejárja a témát. [link]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

csak nem mindegy, milyen mértékben tette.
ez még áprilisi állapot, azóta lehetséges, hogy voltak változások. ha még olvassa a threadet, gondolom elmondja.

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.

Az jó kérdés, hogy hogyan csinálta, hogyha nincs implentálva driverben. Lehet valami trükk? Remélem olvassa és megosztja az infókat ... egyetlen igazán hasznos kommentelő ő volt itt az utóbbi időben

Lásd egy kicsit lejjebb, 5. bekezdés, ugyanezt írtam.

(#9985) gbors: Dehogy pörögtem túl, csak pár gondolat ébredt bennem, amiket leírtam.

Szval efféle fegyverre gondoltál... Hát igen, mostmár úgy tűnik van.

sayinpety fórumtárs éppen olyan eredményekre jutott, hogy a GCN marha sokat gyorsult DX12-vel, míg a Maxwell-ek alig. De azt az eredményt jó rég linkelte. (Erre gondoltam (#9988) cain69, köszönöm! )

A Maxwell-ben a gond ott lehet, hogy pl. másolási műveletek nem futhatnak tetszőleges más feladat mellett, míg GCN-en igen. Ugyanis vagy grafikát számol, vagy mást, amennyire kivettem az adatokból. Ez pl. komoly gond lehet, főleg olyan programoknál, amik sok adatot másolgatnának, ami egyébként indokolt is DX12 alatt, elkerülendő a VRAM megtelését, és a mikroakadásokat.

A jelen téma szempontjából teljesen mindegy, milyen mértékben, az a lényeg, hogy gyorsult, nem pedig stagnált, és főleg nem ment át mocsári csigába, ahogy az AotS-es srácoknál. Az érdekes, hogy hogyan csinálta, de lehet pl., hogy vmi speciális experimental development drivert használtak, vagy ilyesmi.

(#9986) Ren Hoek: mindegy igazából, ez a bench csak egy katalizátor volt ahhoz, hogy egy probléma a felszínre kerüljön. Következtetéseket nem az eredményeiből kell levonni, hanem pl. abból, amint lejjebb linkelt Petykemano.

(#9990) HSM: azon sok meglepődnivaló nincsen, hogy a Radeonok többet gyorsultak - az ilyesmire jobban kihegyezett uarch mellett több is a kihasználatlan erőforrás bennük. Ugye a GCN tervezésekor az AMD már erre az irányra gyúrt, csak lassabban jött el, mint gondolták. Biztosan lesznek is fájdalmak emiatt a Maxwellel - a két fontos kérdés pedig ugyanaz, mint eddig:
- Mikor?
- Mennyi extra munkát fektetnek majd a fejlesztők abba, hogy ezeket enyhítsék?

[ Szerkesztve ]

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

nyilván nem retail drivert használtak. írta korábban, hogy az ő motorjuk karakterisztikája nagyon eltér attól, ami az aotsben van. ergo mindkét állítás igaz lehet, mert nem feltétlenül lehet az egyik engineről tapasztalatakat kivetíteni a másikra. túl kevés az infó.

[ Szerkesztve ]

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.

Most nem azért, de ha egy 290X 19ms alatt végez ugyanazzal, amihez a GTX980-nak 28ms kell, az eléggé mocsáricsiga kategória, pláne ahhoz képest, mennyivel drágább kártya volt a 980.
Ez másfélszeres FPS, ha átszámolod.... 35 vs. 52.

A kérdéseid amúgy jogosak. Ugyanakkor ha azt nézem, a fő platform a konzol, akkor azért nem biztos, hogy prioritás lesz, hogy az Nv hardveres gyengeségeit valahogy szoftverből gyorsítgatni próbálják, amikor a GCN "magától" is gyors lesz.

LOL, mert nyilván egy alfa állapotú teszt az szentírás...
1. Nem tűnik fel, hogy a nevezett fórumtársnál async off-fal is gyorsabb a 290X a 980-nál, ami minimum furcsa? MIből gondolod, hogy ebből a tesztből általánosítani lehet (ráadásul pont az áprilisi változatból)?
2. Attól, hogy a konzol a fő platform, PC-n az nV-nek van jóval nagyobb részesedése. Ezt vagy figyelembe veszik, vagy nem: innentől hitkérdés.
3. gbors kérdéseit inkább így kellene feltenni:
- Mikor?
- Mennyi? (pontosabban mennyi optimalizálás nélkül, és mennyi ha optimalizálnak rá...)
- Milyen arányban fektetnek a fejlesztők plusz munkát az nV-re optimalizálásra, azaz 100 megjelenő játékból hány lesz Maxwellre (is) kigyúrva?
Ezek a legfontosabb kérdések, amik olyan szinten eldönthetetlenek, hogy még tippelni is nehéz rájuk. Innentől kezdve felesleges az okoskodás (talán pár hét múlva többet lehet majd látni).

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Ajánlom akkor neked is: [link]

Attól, hogy korai messzemenő következtetéseket levonni, bizonyos dolgok azért kezdenek világossá válni.

1. A fórumtársnál alapból is azért volt gyorsabb, mivel sok compute futószalaggal dolgozott a motorjuk, az pedig az AMD-nek jobban fekszik.
2. A konzol jóval nagyobb piac, mint a PC, ezt ne felejtsd el.
3. ... Lásd első két sor.

A "Lehet" is egy kérdés azért... mennyire lehet szoftveresen javítani ezen? A mikor lehet egy év is amíg kiderül hogy viselkedik játékok alatt.

1, [link]
a kiindulási helyzet mindenhol dx12, azt írta, hogy a legacy supportot elhagyták, ergo ne dx11es bencheket hozzatok, kkthxbai.

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.

JAh, általános, EGY motor alatt. Ebből ne vonjatok le olyan következtetést, hogy az ÖSSZES motor ilyen lesz, kkthxbai...

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Minek olvassam el a marhaságaidat? Odáig olvastam, hogy "a másik hardver úgy néz ki, csak papíron tudja ugyanezt". Ennek az ellenkezője bebizonyosodott a most tárgyalt, általad szentírásként vett tesztben is, korábban is milliószor cáfolták, de úgy látszik egyeseknek hiába...

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

nem általános, de a sega által fejlesztett játékokra jellemző lesz, emiatt rájuk nézve következtetés levonására alkalmas.
total war, company of heroes, alien és w40k: dow franchiseok.

off: weeee 10k.

[ Szerkesztve ]

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.