Új hozzászólás Aktív témák
-
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.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...
-
-
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). -
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). -
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). -
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). -
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? -
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? -
"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.
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.
-
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.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
-
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ő...
-
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.
-
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ő...
-
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.
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ő...
-
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.
-
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
-
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
-
gbors
nagyúr
Elég részletes leírás itt
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
-
Petykemano
veterán
-
velizare
nagyúr
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.) -
-
"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.
-
FollowTheORI
nagyúr
Külön pikáns az ügy egyébként ennek fényében
![;]](//cdn.rios.hu/dl/s/v1.gif)
, már a Fermi is:
-
FollowTheORI
nagyúr
-
FollowTheORI
nagyúr
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. -
-
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.
-
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.
-
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.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
-
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.
-
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.Ha azalatt az 1 év alatt csak egy ötszázast félretesz az ember naponta a következő generációra, már meg is lehet venni az újat, a régit meg el lehet adni.
Persze, ettől még túlárazottak a kártyák. -
Petykemano
veterán
-
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.
-
MiklosSaS
nagyúr
Itt is eléggé látszik, hogy AMD CPU-n nem túl fényesen teljesít:
Így nem mondanám túl relevánsnak az összehasonlítást, meg nem is sok következtetést lehet levonni a 970 teljesítményét illetően.
-
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.
-
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 ... -
#45185024
törölt tag
NV on VR [link]
All our GPUs for the last several years do context switches at draw call boundaries. So when the GPU wants to switch contexts, it has to wait for the current draw call to finish first.
So, even with timewarp being on a high-priority context, it’s possible for it to get stuck behind a longrunning draw call on a normal context. For instance, if your game submits a single draw call that happens to take 5 ms, then async timewarp might get stuck behind it, potentially causing it to miss vsync and cause a visible hitch.
-
#Morcosmedve
veterán
-
Malibutomi
nagyúr
-
h1mpi
félisten
Ja jó gyenge, veri az 5960X-et
-
Hova erősebb?
"Veri" a Haswell-E-t is.Én még mindig bizonytalan vagyok, hogy 970-et vegyek-e jövő héten, vagy valami AMD-t.
Ebben az évben nem fogsz visszagazolást kapni a döntésed helyességéről bármelyiket is választod.
Ha AMD-t veszel akkror az NV lesz a befutó ha NV-t akkor az AMD. -
bombibmw
veterán
Hova erősebb?
"Veri" a Haswell-E-t is.Én még mindig bizonytalan vagyok, hogy 970-et vegyek-e jövő héten, vagy valami AMD-t.
-
#Morcosmedve
veterán
Itt is eléggé látszik, hogy AMD CPU-n nem túl fényesen teljesít:
Így nem mondanám túl relevánsnak az összehasonlítást, meg nem is sok következtetést lehet levonni a 970 teljesítményét illetően.
Azt hittem erősebb a Skylake.
AMD jó gyenge,
-
tibcsi0407
félisten
Úristen ki használ 9590-et, mondjuk a 290 mellett is az van, csak ugye 5ghz-en nem pedig 4.6-on. (Btw, mintha 4.7 lenne az alapórajele)
Itt is eléggé látszik, hogy AMD CPU-n nem túl fényesen teljesít:
Így nem mondanám túl relevánsnak az összehasonlítást, meg nem is sok következtetést lehet levonni a 970 teljesítményét illetően.
-
#Morcosmedve
veterán
-
Átmásolom a Maxwell topicból. Mégse égett le a DX12 teszten az nV és ez csak jobb lesz, ha elkezdenek drivert is finomítani. Bocs telórol nem tudok linkelni.
http://forums.overclockers.co.uk/showpost.php?p=28522270&postcount=2
Csak nekem jön le ebből az, hogy a 970 nem fog brillírozni?
Vagy csak a 9590 miatt van a gyengus eredmény? -
-
tibcsi0407
félisten
-
Televan74
nagyúr
a $699-es árával alá akar vágni a Fury X-nek?
Ezek mindig túlárazott termékek voltak és lesznek is.
(#9934) wjbhbdux Én csak azt nem értem,hogy az NV miért nem mondta a probléma kezdete óta,hogy nálunk van a hiba,dolgozunk rajta. Úgy néz ki mintha homokba dugnák a fejüket és várnák hogy elüljön a vihar.
-
tibcsi0407
félisten
a $699-es árával alá akar vágni a Fury X-nek?
Ha nem is játékra, de biztos van olyan szegmens, ahol ezért a pénzért tökéletesen ellátná a feladatát. A 16 GB ram nem jöhet rosszul 1-2 renderelésnél, vagy hasonló szituban.
Bár ez az ár egyáltalán nem félelmetes egy 2GPU-s kártyáért.
Játékra gondolom inkább Fury X-et érdemes venni.wjbhbdux
Ez csak jó hír, így elkerülhető a lázadás
Miután 2 hete vettem VGA-t, egy picit szíven talált a dolog. -
wjbhbdux
veterán
Oxide fejleszto bedobta, hogy driver hianyossag van az Nvidia reszerol az async computeal kapcsolatban, meg az o megvalositasuk nem is jo pelda erre a featurere
. -
Petykemano
veterán
-
Petykemano
veterán
-
Ren Hoek
veterán
Szerintem ez az egész jól jellemzi az AMD termékstratégiáját. Konkrétan az, hogy nincs.
Nem az van, hogy kiadnak X típust, az előre beharangozott tulajdonságokkal, hanem az épp aktuális gyártási helyzet (és hogy mennyire tudják belőni a mérnökök) határozza meg a kiadott terméket, kb startkor.- Fury X, az "overlockers dream", mindenki arra számított, menni fog mint állat, minek is tennének rá vizet, ha nem? Ehhez képest semmi. Azóta sincs semmi unlock rá.
- Nano: Először 290X/970 helyére vártuk, kb árra is (+ értéktöbblet HBM stb miatt benne volt)... ehelyett kiadtak egy méregdrága rétegcuccot, ráadásul nem adnak belőle a tesztoldalaknak mert startra nem jött le annyi.
Hogy is van ez? A start előtt pár nappal találják ki kb milyen legyen a VGA
Annak függvényében alakul, hogy mennyit tudnak lehozni belőle, és hová tegyék a chipeket. Nekem ebből a kapkodás jön le, és az, hogy nincsenek nagyon a helyzet magaslatán (pénzügyileg sem) -
Sajnos ezeken a grafikonokon nem fog szerepelni a Nano mert a TechPowerUp sem kap tesztpéldányt, ahogy a Techreport sem...
Az nem biztos, hogy baj, mert akkor nincs NDA sem. Lehet, hogy a TPU-nak előbb lesz tesztje
-
Sajnos ezeken a grafikonokon nem fog szerepelni a Nano mert a TechPowerUp sem kap tesztpéldányt, ahogy a Techreport sem...
-
Sajnos ezeken a grafikonokon nem fog szerepelni a Nano mert a TechPowerUp sem kap tesztpéldányt, ahogy a Techreport sem...
Csunyan mutatna a performance/$ grafikonján a TPU-nak a Nano
Meg ok tesztelnek Project Cars-al is, biztos az is baj.
Nevetseges amit muvel az AMD. -
Sajnos ezeken a grafikonokon nem fog szerepelni a Nano mert a TechPowerUp sem kap tesztpéldányt, ahogy a Techreport sem...
-
Sajnos ezeken a grafikonokon nem fog szerepelni a Nano mert a TechPowerUp sem kap tesztpéldányt, ahogy a Techreport sem...
-
Nem kell átgondolni mert a legalsótól erősebb lesz:
és itt csak Direct X 11 ről beszélünk ugye.Sajnos ezeken a grafikonokon nem fog szerepelni a Nano mert a TechPowerUp sem kap tesztpéldányt, ahogy a Techreport sem...
-
Dark KillerX
addikt
-
h1mpi
félisten
Nvidia esetén driverben bekapcsolt Vsync-el, mért csökken a 3d-s teljesítmény, pl Firestrike alatt?
Mert ezelőtt 5 évig használtam AMD-t ( nem volt különösebb gond
) és ott a sriverben bekapcsolt Sync-el , ugyanannyit kaptam a 3d-s tesztek alatt Viszont ha alapértelmezettre állítom , a GPU nem megy 100%-on, és ez nem jó (kb 90%-on megy ) AMD vs NVidia összehasonlítás szempontjából is érdekes lehet ez
-
Dark KillerX
addikt
Nvidia esetén driverben bekapcsolt Vsync-el, mért csökken a 3d-s teljesítmény, pl Firestrike alatt?
Mert ezelőtt 5 évig használtam AMD-t ( nem volt különösebb gond
) és ott a sriverben bekapcsolt Sync-el , ugyanannyit kaptam a 3d-s tesztek alatt Viszont ha alapértelmezettre állítom , a GPU nem megy 100%-on, és ez nem jó (kb 90%-on megy ) AMD vs NVidia összehasonlítás szempontjából is érdekes lehet ez
-
-
tibcsi0407
félisten
-
h1mpi
félisten
Ez elég beteg, végre egy olyan AMD termék amit megvennék
-
#45185024
törölt tag
Te jó ééég egy 16 Gigás két magos 390 es
Ez a szörny kinek a rémálmából pattant ki ? Fury proval kellett volna ezt csinálni...
Majd lehet mondani direct x 12 alatt ó hát ezt a 980ti-t még egy 390 is megveri -
tibcsi0407
félisten
-
Jó
de a Shelteren kívül mondjál már mégegy androidos játékot fejből amit mindenki ismer...Azért ez nem igaz... nem véletlenül készül el most már minden androidra is
Shelter amúgy poén, bár kimaxoltam mindent 170 dwellerrel... kár hogy nincs több kontent benne. Abban egyetértek, a többi mobiljáték egy fos f2p... de ez kell a népnek, a komplexebb játékok kora sajnos leáldozott kicsit. Gyors, könnyen fogyasztható szórakozás. Emiatt kurvultak el a fogyasztók. Talán emiatt lesz egyre kevesebb rituálé szerűen PC elé leülős, összetett, gondolkozós játékmenetű game.Steam gép pedig PC-ként lesz elterjedve úgy tűnik. Értelmetlen lenne kihozni egy N-ik tiszta konzolt
-
FollowTheORI
nagyúr
![;]](http://cdn.rios.hu/dl/s/v1.gif)
, már a Fermi is:
) és ott a sriverben bekapcsolt Sync-el , ugyanannyit kaptam a 3d-s tesztek alatt Viszont ha alapértelmezettre állítom , a GPU nem megy 100%-on, és ez nem jó (kb 90%-on megy ) 
Ú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.
- Elektromos autók - motorok
- Xbox tulajok OFF topicja
- Gyúrósok ide!
- gban: Ingyen kellene, de tegnapra
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Yettel topik
- BestBuy topik
- Huawei Watch Fit 5 Pro - jó forma
- Okos otthon - Home Assistant, openHAB és más nyílt rendszerek
- Kezdő fotósok digitális fényképei
- További aktív témák...
- Dell Optiplex/Precision MT/SFF 3430, 3050, 3060, 3070, 3080, 5060, 7060/7.-8.-9.gen/SZÁMLA-GARANCIA
- AKCIÓ! 2TB Kingston Fury Renegade NVMe SSD meghajtó garanciával hibátlan működéssel
- BESZÁMÍTÁS! MSI B650 R7 8700F 64GB DDR5 512GB SSD RX 7700 XT 12GB LIAN LI LANCOOL 217 FSP 650W
- 64GB DDR5 RAM Kit!
- HIBÁTLAN iPhone 14 128GB Blue -2 ÉV GARANCIA - Kártyafüggetlen, MS5331
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest