-
Fototrend
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Egyáltalán nem számottevő játék a Prey. Az egyetlen dolog, amiért kiemelt figyelmet kap az AMD-nél az a Bethesdával kötött többéves szerződés. Ez mindkét cégre ró kötelezettségeket. Persze nem azonnal, mert az összefonódás miatt mindkét cégnél szükségesek strukturális átalakítások, de azokat a pontokat, amelyeket azonnal teljesíteni kell, teljesítik is. Például az AMD-nek az egyik kötelezettsége, hogy minden Bethesda által kiadott játékra olyan drivert biztosítsanak az összes elérhető VGA-hoz, amely hibátlanul és a lehető leggyorsabban működik. Nem mellesleg a szerződésnek az is a része, hogy az AMD demózza a Bethesda termékeit, cserébe a Bethesda is nyomatja majd az AMD-t. Itt nem számít a játék maga. A kölcsönösen előnyös szerződés a lényeg.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
arabus
#29151
üzenetére
Egyelőre mindenhonnan azt hallani, hogy nem a hardver a gond. Azt szállítják az előrendelőknek, nem piti mennyiségben, mert ugye több városban kell komplett szerverfarmokban cserélni az összes GPU-t Vegára. A Frontierrel is gondban lennének, ha csak 16-20k lenne a maximum készlet, ezért nincs ugye limitálva a termék. A professzionális szintre a HBCC annyira kell, hogy ekkora mennyiség egy nap alatt elfogyna.
A driver nincs kész. Működik, csak van még benne egy rakás tartalék, amit valószínűleg ki akarnak szedni. Erről nem csak hallani, hanem Raja is utalgat rá a twitteren.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez lehet, hogy elvárás, csak a valóság ettől nagyon messze van.
Egy-két hétből kell kihozni a maximumot. A Bethesda azt szeretné igazán, hogy több időt töltsenek a játékaival az AMD rendszerprogramozói. Ehhez kell a megállapodás, mert arányaiban egy bizonyos erőforrásnál nem éri meg többet beleölni egy játékba. Nem azért, mert nem maradt még tartalék a driverben az adott játékra, hanem azért, mert aránytalanul költségessé válik azok kinyerése.Ilyen megállapodást nem nagyon láttunk még, ahol egy kiadónak konkrétan átadja egy GPU fejlesztőnek az R&D munka egy jelentős részét. Ez az első. Lehet, hogy nem lesz sikeres, de lehet, hogy lavinát indít el. Senki se tudja még ezt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem az a cél a megállapodással, hogy gyors legyen a játék, ez szimplán jön, ha foglalkoznak vele. A Bethesda csak extra törődést vár. Túl sok játék érkezik párhuzamosan egymás mellett, és az AMD, illetve az NV oldalán is túl kevés erőforrással rendelkezik, hogy mindenre figyeljenek. Emiatt minden program korlátozott figyelmet kap. A Bethesda elsődlegesen azért kötött erre külön megállapodást, hogy legalább az egyik gyártón biztosítsa, hogy a megjelenés napján jó lesz az élmény. Ez nagyon fontos, mert jó, hogy voltak "game ready" driverek a Prey-re, de az NV még két frissítést kiadott utána és az 5-én megjelent játékhoz 23-án jött egy olyan profil, amit minden GeForce-on hibátlannak mondtak. Ez a Bethesdának gondot jelent. Nekik erre 5-én volt szükségük, nem 23-án. Ezért van külön megállapodásuk az AMD-vel, hogy ők ezt biztosítsák.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mert a GDDR5 lassú és sokat fogyaszt, a GDDR5X pedig drágább, mint a HBM2, és sokkal többet is fogyaszt. Ennyi.
(#29167) .LnB: Ez a gondja a Bethesdának, hogy csak akkorra oldotta meg. Annak nagyon örülnek, hogy megoldották, de túl későn a Bethesda szemszögéből. Ergo az az idealista nézet, hogy a kiadóknak nem kellenek különálló alkuk a gyártókkal kezd manapság megdőlni. A Bethesda ráadásul nem tapasztalatlan itt. Az AMD előtt az NV-vel volt szerződésük, csak nem voltak megelégedve azzal, amit kaptak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#29170
üzenetére
Ezt tudják ők is. Ezért mennek a következő körben GDDR6-ra. Mert a GDDR5X hiába tudja lényegében ugyanazt, a legdrágább opciónak számít, amit még egyszer nem fognak bevállalni. Simán kellene a GDDR5X az 1070-re és az 1060-ra is, csak nem tudják rájuk rakni az ára miatt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
-Solt-
#29178
üzenetére
Ez nyilván gond, csak nehéz úgy információt mondani, hogy a driver közel sincs kész. Minden bizonnyal van egy szimuláció, amiben látják, hogy mekkora a hardver teljesítménye és vannak a gyakorlati mérések. Melyiket mondják. Ha a gyakorlatit írják ki, akkor lehet, hogy sokan csalódnak, és meg sem várják a megjelenést. Ha a szimulációt, akkor leesik az emberek álla, és mindenki vár, de ott meg attól függ az eredmény, hogy mennyire fejlődik a gyakorlatban a driver. Adjanak a kettő között valamit? Akkor meg csak tippelnek, és azzal pedig az a baj.
(#29180) BReal: Azok. A GDDR5 lassú és sokat fogyaszt. Ezzel senki sem tud mit tenni. A 30 watt pedig sok. A HBM2 4 watt alatt van és gyorsabb. A GDDR5X sebességben jó lenne, csak a HBM2 még ennél is jóval kevesebbe fogyaszt, miközben olcsóbb is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29190
Abu85
HÁZIGAZDA
FollowTheORI
#29185
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#29185
üzenetére
Szerintem inkább az NCU a baj és a raszterizálók. Ezek tartalmaznak olyan újdonságokat, amelyeket PC-n még soha senki nem próbált. Sőt, a teljes iparban nincs pár újdonságról tapasztalat.
(#29188) nubreed: Természetesen az. Azt a 26 wattot hozzádobhatod a GPU-hoz és úgy nagyobb lehet az órajel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#29230
üzenetére
Nem számolod bele, hogy a TDP keret az nagymértékben egy meghatározástól függ. A referencia 580-nak például még mindig 150 watt a TDP kerete. És azt is elmondom, hogy az MXM 3.0b-s RX 580-nak, ami a Computexen van 65-95 wattos keretű (konfigurálható) az asztali specifikációkkal (és alig lassabb, mint az asztali 570 az Asus nyolcmagos notiján 65 wattos limittel). Az egész inkább egy döntés, mint egy valós probléma. Ez a dolog ki lesz fejtve a hírbe, ami készül a mobil 500-akról.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#29238
üzenetére
Pont olyan érv, mint a tied, hogy veszel egy szétfeszelt agyuntinongolt 580-at, de figyelmen kívül hagyod a referenciákat, amelyek messze nincsenek akkora TDP keretre állítva. Pontosan ismert, hogy minden GPU-nak van egy optimális működési tartomány, és ha annak a közeléből kiszedik, akkor szimplán +5%-os teljesítményért is 30-40 wattokat kell fizetni. Ezért képez rossz összehasonlítási alapot a gyári tuning.
Vagy figyelmen kívül hagyod az MXM 3.0b-s RX 580-at. Ez 1340 MHz-en 65 watt. Miért nem ebből számolunk? Ez is hivatalos specifikáció. Vagy itt már érzékeled, hogy jóval bonyolultabb az egész probléma, mint ahogylefestettedleegyszerűsítetted?(#29239) Jack@l: A HBCC-t többször is bemutatták a gyakorlatban. Ha az nem működne, akkor nem mutatnák meg, hogy mennyire sok előnyt tud hozni. [link] , [link]
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#29244
üzenetére
Az egész gondolatmenetednek nem volt semmi értelme. Most csak próbálod magad kötni ehhez a 150 watthoz, mert tudod, hogy senki sem tesztelt referencia RX 580-at. De ettől még a specifikáció világos, és azt is érted, hogy agyontuningolt kártyáról hoztál eredményt, hogy jól eltorzítsd az egészet. Hogy ez neked miért jó, azt nem tudom. Csak a szavahihetőséged veszik kárba.
A throttling pedig ma a hardverek része. A gyári tuningos megoldások elsődleges célja, hogy ezt elkerüljék, és jól felemelik a referenciának szabott TDP keretet, akár 50-70 wattal is. Elég régóta így megy. Viszont referenciaszinten nem éri meg a throttling kivédéséért +50-70 wattot bevállalni. Gyári tuningos termékként simán. Sokakat egyáltalán nem érdekel a fogyasztás.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
SaGaIn
#29394
üzenetére
Az USA-ban a minimum gari eleve három hónap, szóval a gari, amit a gyártók adnak az extra.
Semmi gond. Elkérik az elpukkant kártyát, megjavítják és visszaadják. A legtöbb bányászásra használt VGA-n a VRM szokott gond lenni, amit relatíve könnyű javítani.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért az nem olyan egyszerű. Az NV-nek az OpenCL meghajtója leginkább így alakult dolog, míg az AMD azért ebbe sokkal több pénzt ölt anno. Most ezt korlátozni pár alkalmazásra eléggé nehézkes. Az NV sem direkt korlátozza, egyszerűen csak ilyen a driver. De ez is jó, látod a GTX 1070-eket kezdték el venni a Polaris 10/20 helyett.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
stratova
#29523
üzenetére
Az a baja az Apple-nek, hogy az Intel IGP marhára nem Metal-barát. Egy csomó új képességet csak emulálni tudnak. És mivel Krzanich volt olyan okos CEO, hogy leépítse a grafikus részleget, nagyon messzire kerültek az új fejlesztések.
Ha az Intel nem fog rákapcsolni a fejlesztéseivel, hogy behozzák a szétvert részlegekkel összeszedett hátrányt, akkor csak idő kérdése, hogy bukják az Apple-t. Az lesz majd Krzanich vége is, mert teljesen az ő felelőssége az összes szükségtelen leépítés.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az IPC a GPU-knál eléggé nehezen értelmezhető. Például most a Polaris rendelkezik a legjobb IPC-vel. Aztán az Intel Gen9 alig rosszabbal, majd az NV Pascal picit nagyobb lemaradással. Egy szálú teljesítményben is a Polaris a legjobb, de nem csak picikét, hanem messze előzi a Gen9-et és a Pascalt, ezt az utasítás-előbetöltésnek köszönheti, amihez hasonló képességet a többi gyártó még nem kínál. Az Intel Gen10 fog tartalmazni ilyet, míg az NV-nél majd valószínűleg az ami a Volta után jön.
A GPU-knál azonban van egy rakás más tényező még, elvégre heterogén dizájnokról van szó. Például sokat számít a háromszög/órajel érték, amiből a Vega 10 például pont agyonver mindent a 11-es paraméterével, míg az eddigi legjobb a GP102 volt 6-tal. Szóval a teljesítmény messze nem függ annyira az IPC-től. Ordered atomics mellett valószínűleg a Polaris picikét gyorsabb marad, mint a Vega, de ez csak egy kis tényezője a feldolgozásnak. Ennyi negatívum bevállalható, főleg úgy, hogy az ordered atomics még a Vegával is mérföldekkel gyorsabb lesz, mint Gen9/Pascal architektúrákkal, elvégre ezeknek külső memóriát kell használni a szinkronizáláshoz, míg a GCN-ben van erre kialakított belső memória.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#29650
üzenetére
Ez a verzió egy GPU-s lesz. Konkrétan egy Vega 10 van rajta 16 GB-nyi memóriával. A két GPU-s változat csak az ősz végén jön. Annak a Duo benne lesz a nevében és 32 GB összesített memória lesz rajta.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Dtomka
#29674
üzenetére
Biztos sokkal gyorsabb lesz.
Kint van az előrendelői ára. 1200 a normál és 1800 dollár a vizes verzió.
A sima gaming Vega 8 GB-nyi memóriát kap. Ennyi memória bőven elég rá a HBCC miatt.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
Yutani
#29727
üzenetére
Beáldozni beáldozhatja, csak most pont nem lenne logika benne, amikor ezekre épül a shader model 6.0 és 6.1. Nyilván nem mindegy, hogy az új wave intrinsics függvényeket emulálják, vagy hardveresen van rá utasítás, illetve támogatás.
Az SM6.0 aktuális állapota alapján a WaveBallot, a WavePrefixSum, a GlobalOrderedCountIncrement eléggé GCN-re van szabva. Ezeket mindenképpen emulálni kell a többi architektúrán. A WaveBallot esetében az a baj, hogy 64 bites unsigned integer bitmaskkal tér vissza, és 64 bites skalárregisztere csak a GCN-nek van, tehát a többi architektúrán ezt le kell emulálni, hogy a hardver által kezelt regiszterhez igazodjon a működése. A WavePrefixSum-ra van egy konkrét utasítás a GCN3-tól, míg a többi architektúrán ezt is emulálni kell. A GlobalOrderedCountIncrement függvényre pedig konkrét hardverdizájn van kialakítva a GCN-ben a multiprocesszorok közötti szinkronizálásra, míg a többi architektúránál a VRAM-ot vagy jobb esetben az utolsó szintű gyorsítótárat kell használni ehhez.
Az SM6.1-nél a barycentric bevezetése abból a szempontból problémás lesz, hogy a GCN eleve úgy van tervezve, hogy az LDS a barycentric koordinátákat tárolja. A többi hardveren ez megoldható, de nem így tervezték őket, az NV-nél eleve nagyon kicsi az LDS a multiprocesszorokhoz mérve, míg az Intel erre a célra a nagyon lassú L3-at használja.
Most ezt nincs értelme leváltani, mert pont az a lényege a Microsoft új shader nyelvének, hogy amit megírnak konzolra azt csak copy-paste formában hozzák PC-re.A SPIR-V egyébként sokkal jobban kialakított IR, mint a DXIL. Nem igazán kedvez egyik architektúrának sem, de persze a Microsoft is érthető. Nekik bőven jó, ha a konzol specifikációk élnek PC-n is. Majd az IHV igazodik hozzá.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
stratova
#29733
üzenetére
A WaveBallot nem annyira kellemetlen. Azt csak azért szokás felhozni, mert például a SPIR-V-ben meg van oldva normálisan, míg a DXIL-ben rá van szabva az AMD-re, miközben a Microsoft elvileg független ebből a szempontból.
A WavePrefixSum kellemetlenebb. Az egy órajel vs. sok órajel az emuláció miatt. Az így sokszor gyorsabb, kérdés, hogy sikerül az emulációt megoldani gyártóknak. Ezt az AMD-nek is meg kell csinálni, mert GCN1/2-ben nincs külön utasítás.
A GlobalOrderedCountIncrement az rémálom lesz. Arra annyira rá kell gyúrni a hardvert, hogy az emuláció egyenlő a használhatatlansággal. Ennek az a titka, hogy a multiprocesszorokon belül legyen utasítás-előbetöltés, illetve egy belső szupergyors tároló a szinkronizálásra. Az utasítás-előbetöltés azért kell, mert a multiprocesszor egy wave-re lesz kényszerítve, tehát nagyon gyors szálszintű teljesítmény kell, míg a tárolóra azért van szükség, hogy ne kelljen egy csomó késleltetéssel számolni a szinkronizációnál. Ez egy eléggé GCN4-re szabott dolog így.
A barycentric nem akkora para a technikai oldalról. Ott az lesz a baj, hogy például az NV eleve nagyon sokat spórol az LDS-sel, és egy eleve minimum működésre szabott tárolóból még le kell szippantani a kapacitásának harmadát vagy negyedét, mert valahol tárolni kell a koordinátákat. Az Intelnél van bőven kapacitás, de annyira magas az L3 késleltetése, hogy az fájni fog ennél a műveletnél.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29737
Abu85
HÁZIGAZDA
Petykemano
#29735
Abu85
HÁZIGAZDA
válasz
Petykemano
#29735
üzenetére
A játékokban már az elmúlt évben megjelentek ezek a funkciók, legalábbis egy részük. Most azon van a Microsoft, hogy szabványosítva legyenek, így ne csak az AMD-n működjenek. Csak ugye a szabványosítást lehet úgy csinálni, hogy lemásolják az Xbox One-hoz használt shader nyelvet és ahhoz illesztenek egy IR-t, vagy csinálhatnák normálisan is, ahogy a Khronos, bár ez lassabb módszer.
A fejlesztők sok dolgot akarnak. Érdemes egyébként nézni most Sebastian Aaltonen twitterjét. A szemünk előtt hozza PC-re a Claybookot. Ígért PC-re vonatkozó bejegyzéseket és folyamatosan szállítja azokat: [link] , [link] , [link] , [link] , [link]
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#29738
üzenetére
Tehát szerinted az teljesen rendben van, hogy a konzolon rendkívül sűrűn használt Ballot függvényt úgy hozza a Microsoft PC-re, hogy pont 64 bites a visszatérési maszkja, ami véletlenül pont annyi, amennyi a GCN működéséhez ideális, és pont több annál, amivel az Intel és az NV architektúrája hatékonyan működni tud? Mert szerintem egyáltalán nincs rendben. Ha valaki így akarja használni, akkor ott vannak az AMD saját kiterjesztései, mindenkinek joga van hozzányúlni, de egy szabványalkotó legyen már független.
Semmiféle funkciót nem hozott a GCN4. Nem a hardver teszi a GCN-t azzá amilyen, hanem az, hogy a Microsoft eldöntötte, hogy márpedig a shader model 6.x az lesz PC-n, ami konzolon. Az igazság az, hogy a sokat használt funkciókat tekintve semmivel sem jobb a GCN4, mint a Pascal, csak az AMD mázlista a Microsofttal. Ha most Pascal lenne a konzolokban simán el tudom képzelni, hogy a Pascalra szabott shader model jönne, nyilván a Microsoft nem azért kedvez az AMD-nek, mert szereti őket, hanem azért, mert azzal a saját konzoljának segít.
Ezek a függvények egyébként gyorsítják az egyes algoritmusokat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29746
Abu85
HÁZIGAZDA
Petykemano
#29743
Abu85
HÁZIGAZDA
válasz
Petykemano
#29743
üzenetére
Itt az új shader nyelvvel nem elsődlegesen az a cél, hogy a gyártókra optimalizáljanak. A probléma ott van, hogy a konzol által kínált lehetőségek messze kerültek attól, ahol a PC tart. Ezért egy csomó dolgot a konzolon sokkal gyorsabban meg lehet oldani. Ehhez képest a hardver gyakorlatilag megvan a PC-n, csak a shader nyelv lassan egy évtizede nem változott jelentősen miközben a hardverek már teljesen másképp működnek, mint tíz évvel ezelőtt. A shader model 6.x erre a különbségre reagál.
Például nagyon kirívó példa (ezzel szokott az MS előjönni), hogy amíg a konzolon a préselésre speciális op-kód van, addig PC-n itt mindig az atomi műveletekre építenek a fejlesztők, és ez tulajdonképpen wave-enként annyi atomi műveletet igényel, amennyi lane van az adott wave-ben. Ez marhára rossz hatásfokú, tehát még emulációval is sokkal előrébb lesznek a hardverek, mert lassan egy évtizedes különbség van a shader nyelv és a hardver képességei között.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
És ehhez még hozzászólva az egész szituáció azért baj a Microsoftnak, mert egy multiplatform fejlesztésnél jó esély van arra, hogy a konzolon is a rossz hatásfokú kódot szállítja a fejlesztő, holott ott van a lehetőség a jóval gyorsabb kód biztosításra. Tehát ahhoz, hogy a multiplatform címekkel ez megváltozzon biztosítani kell a PC-hez is nagyjából ugyanazt a shader nyelvet, és nagyjából ugyanazokat a lehetőségeket. Innen már persze elő lehet venni, hogy bár a Microsoftot alapvetően jó szándék vezérli, azért pusztán a saját érdekei dominálnak, és az érdekük az, hogy ne ők igazodjanak az egyes gyártókhoz, hanem majd ezek az egyes gyártók igazodnak hozzájuk. Alapvetően megtehetik. A legtöbb függvény még emulálva is jóval gyorsabb, mint a ma használt, tíz éves nyelvre (és ez megjelenéskor sem volt valami acélos) kialakított eljárás az adott problémára.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29749
Abu85
HÁZIGAZDA
->Raizen<-
#29748
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#29748
üzenetére
A Forza 7 nagyjából ugyanaz lesz, mint a Forza Horizon 3 a legutolsó patch-csel. A fejlesztések jó részét visszaportolták. Egyébként ez már jóval több magot használ a leképezéshez, mint egy. A gépigény egy picit kisebb lesz, mint az utolsó frissítéssel futó FH3-nál, mert bizonyos változásokat nem lehetett egyszerűen visszaportolni, így ezeket inkább hagyták a Forza 7-re.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#29750
üzenetére
Ma shader model 6.0-t nem használnak sehol, most tart a publikus tesztelése a rendszernek, és az őszi Creators frissítésben lesz élesítve, addig nem lehet használni. AGS4.0-t és SPIR-V kiterjesztéseket használnak, ami az sm 6-tal érkező függvények egy részét tartalmazza. Ezek gyorsítását pedig nem lehet lemérni, mert ahogy korábban mondtam nem kérhető az az érintet játékoktól (Doom, DE: MD, BF1, Civ6, SE4, RE7: Bio, WH40K: DoW3, SGW 3), hogy a szabványos shadert futtassák.
(#29751) Szaby59: Véletlen nem az alsó sorra írta az MS, nem nagy ügy.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29756
Abu85
HÁZIGAZDA
Petykemano
#29755
Abu85
HÁZIGAZDA
válasz
Petykemano
#29755
üzenetére
Inkább azt kérhették, hogy a nyelvet vigyék már közelebb a hardverek működéséhez. Azért a mai specifikációkkal a HLSL eléggé egy lane-re vagy egy szálra (de nem olyan szálra, mint a CPU-nál) van szabva, holott a hardvereknek már az lenne a jó, ha a wavefrontokra lenne kialakítva. [link] - itt elég jól leírják: For earlier shader models, HLSL programming exposes only a single thread of execution. New wave-level operations are provided, starting with model 6.0, to explicitly take advantage of the parallelism of current GPUs - many threads can be executing in lockstep on the same core simultaneously. Egyszerűen jóval közelebb kerül a nyelv ahhoz, ahogy a hardver működik. És ez nem az erőforrás problémája, hanem csupán azé, hogy a shader model 5.0 majdnem tíz éves. Akkor nem kellett több, de ma már kell.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#29758
üzenetére
Nem tudod ezeket kiváltani. Ezek mind azért jönnek mert az aktuális megoldások nagyon lassúak, és ezeknél sokszor még az emulació is jobb. A Ballot préselésnél megspórolja az atomi műveleteket, esetlegesen marha sokat. Persze megoldható naiv megközelítéssel is, de ha ez elég lenne nem dolgoznának a szabványalkotók a Ballot szabványosításán. A prefix sum esetében a vektorutasítások hozzáférhetnek a szomszédos lane-el adataihoz anélkül, hogy az LDS-be kellene írni bármit is. Ha arra van szükséged, hogy a wave-ek a létrehozásuk sorrendjében fussanak le, akkor muszáj a ordered countot használni. Erre egyébként nem a Microsoft nevével keress rá, mert az az SM6-os függvénynév. Ajánlott a GCN ordered atomics, a ds_ordered_count, ezek variációi. A Microsoft specifikációja az XBox One másolata, ami meg az AMD ds_ordered_counthoz van igazítva. Az meg világos, hogy találsz róla kérdést, hogy miképp működik nem GCN-en, mert más hardver nem erre lett szánva, viszont fícsőr szempontjából tök hasznos, hogy csupán egy függvény a háttérben mindent sorrendben "varázsol meg".
A barycentric eseteben sincs más lehetőség. Opció persze az alternatív eljárás a geometry shaderrel, de olyan lassú lesz, hogy inkább érdemes pixel shader kódot írni a barycentric koordinátákra építve. Egyszerűen meg a legrosszabb hardveres emuláció is gyorsabb lesz a geometry shadernél.
Nagyon sok esetben mindegy, hogy xy gyártó emulálja. A régi megoldásnál az emulált is lényegesen jobb. Valószínűleg ezért nem érdekli a Microsoftot annyira, hogy minden gyártót figyelembe vegyen. Annyira túlkoros az SM5 feldolgozási modellje, hogy még a legrosszabb emulációk is előnyt jelentenek ehhez képest. De a gyártókat mondjuk érdekelni fogja, hogy az architektúráikon hogyan viselkednek az egyes függvények a konkurensekhez képest.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#29787
üzenetére
A High Bandwith Cache nem egyenlő a High Bandwith Cache Controllerrel. Mindegyiken HBC található, mert oda lehet rakni a GPU számára szükséges adatokat. Csak amíg a Vega 10 esetében ezt egy lapkába épített vezérlő megoldja (HBCC), addig a másik két modellnél a szoftverben kell gondoskodni erről.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#29790
üzenetére
Mert az van rajta. Az a 16 GB-nyi HBM2 egy High Bancwith Cache, ahogy mondjuk a másik modelleknél az x GB-nyi GDDR5 vagy HBM is. Csak a Vega 10 esetében van a vezérlőben egy HBCC is, plusz multiprocesszoronként van egy ATS egység, a másik két modellnél ezek hiányoznak. Tehát ezeken mindin a szoftver fog gondoskodni arról, hogy a High Bancwith Cache-ükben ott legyen a szükséges adat.
A VRAM-ot azért nem használja az AMD, mert annak az elfogadott definíciója a szegmentált fizikai címzésű hardverekre vonatkozik, de a GCN az MMU miatt nem ilyen architektúra. Különösebb jelentősége egyébként ennek nincs.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29805
Abu85
HÁZIGAZDA
Petykemano
#29803
Abu85
HÁZIGAZDA
válasz
Petykemano
#29803
üzenetére
Semmi köze a kettőnek egymáshoz. A HBCC GDDR5 memóriával is működik. Azért kell nekik a HBM2, mert ez a legolcsóbb opció a nagy teljesítményű memóriák piacán. A GDDR5 túl sokat fogyaszt, a GDDR6 pedig túl későn jön, és az sem fogyaszt majd olyan keveset, mint a HBM2.
Az 1 TB/s mindenképpen kell. Nem véletlen lesz a Vega 10 után egy Vega 20 verzió, ami lényegében annyiban különbözik, hogy 4096 bites lesz a buszszélesség 2048 bit helyett. Plusz mindegyik multiprocesszor FP64-re lesz kialakítva, szemben a Vega 10-zel, ahol egy tömbben csak egy multiprocesszor ilyen.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#29817
Abu85
HÁZIGAZDA
Malibutomi
#29807
Abu85
HÁZIGAZDA
válasz
Malibutomi
#29807
üzenetére
Azért van az odaírva, mert mindenből a valódinál alacsonyabb paramétert írtak. Ennek az oka, hogy most még nem akarják elárulni a paramétereket. Majd 27-én, de ott is csak a Frontiernél. Ha megnézed a Frontier oldalát, akkor még mindig ott van a "~" a paraméterek előtt. [link]
A primitive shader bonyolult dolog. Azt API kiterjesztésekkel lehet majd használni. Elég bonyolultan lesz megoldva a háttérben, mert a Mantle ICD-n keresztül fog futni a motorháztető alatt, mivel az aktuális API-k nem engedik a bedrótozott pipeline megváltoztatását. De a lényeg az, hogy a fejlesztők számára ebből csak annyi lesz látható, hogy primitive shadereket kell írni HLSL extben, a többit elintézi a fordító és a driver.
Amiről ír a kiemelt írásod az az, hogy bizonyos vertex shader kódok könnyen átültethetők primitive shaderre. Ez tényleg lehetővé teszi, hogy a nem látható geometria kivágása a pipeline elején történjen meg. Ezek egy vertex shader kóddal továbbmennének, holott a primitive shader meg tudja mondani, hogy tuti nem fognak látszani, tehát tök felesleges továbbengedni őket, és itt marha sok háromszögről beszélünk, ami átmegy a szitán, de hasznuk az nincs, csak ez később derül ki róluk. Nagyjából erről van szó. Ezt egyébként viszonylag sűrűn használhatják a fejlesztők, mert marhára kevés munkát igényel, és nagy boostot hoz. Sokkal kevesebb idő ezt beépíteni, mint másféle optimalizálsokkal megkeresni azt a sebességtöbbletet, amit ez biztosít. Ezt még az AMD is meg tudja amúgy csinálni a driverben, mert csak lecserélik a shadert, csak nem vertexre, hanem primitive-re, viszont ez azért komoly munka a rendszerprogramozóknak, tehát jobb, ha a fejlesztők teszik meg. Ugyanakkor a primitive shader ennél sokkal többről szól, mert kínál olyan képességeket, amelyek az aktuális shader lépcsőkkel nem vagy csak brutálisan lassan valósíthatók meg. Ehhez kell a szabványosítás, hogy az elavult shader lépcsőkkel kezdjünk valamit.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
stratova
#29843
üzenetére
A Frontier egy rést töm be. A prosumer vonalat eredetileg senki sem tartotta sokra, mert nem gondolták, hogy igény lesz a félprofi megoldásokra. A valóság viszont az, hogy igény van rá, és ide az AMD is akart egy terméket. A Quadro P6000 ellen ősszel jön a Radeon Pro WX Vega, de az nem 1200, hanem 6000-8000 dollár lesz.
Az igény egyébként abból adódik, hogy a félprofi megoldásoknál az extrém terméktámogatást nem kell megfizetni. Tehát nem kell sokezer dollárt adni csakis azért, hogy hibátlanul működjenek a fontosabb fejlesztői szoftverek, hanem ezt csak hozza a Pro driver. A gyorsaság itt másodlagos, mert csak azt igényli a piac, hogy működjön. Viszont gaming driverrel nem mindig működik, míg pro termékkel marha nagy ára van a működésnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#29907
üzenetére
Mert a Radeon Pro Vega is sokkal gyorsabb, ha certifikált meghajtót használ. De a Frontier Edition azért 1000 dollár, mert hiányzik a certifikáció. Majd lesz ilyen is szeptemberben, de azt a Vegát nem veheted meg 5000 dollár alatt.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#29916
üzenetére
A WX 7100 egy certifikált termék. A certifikált eredményeket nem szabad összehasonlítani a nem certifikáltakkal. Utóbbi akkor is sokkal lassabb lesz, ha maga a hardver sokkal gyorsabb. Ezért fizetik a sokezer dollárt a certifikációval rendelkező VGA-ra.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#29919
üzenetére
Dehogy van kevés köze. Pont az a lényege, hogy nem fogják vissza a cetrifikált termékekre a meghajtót. Ha engednék a tizedannyiba kerülő termékeken is ezt a teljesítményt, akkor sokkal kevesebben vennék a professzionális VGA-kat.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#29921
üzenetére
Radeon Pro Duo. Az is olyan, mint a Frontier. Nincs rá certifikáció, de a Pro driver felmegy rá. Viszont így a teljesítménye nagyon messze van a nála lassabb, de certifikált modellektől. Ez van. Ez a piac abból él, hogy a nagy teljesítményt a gyártók certifikációhoz kötik. Ha tetszik, ha nem ez a döntésük.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#29924
üzenetére
Kétféle meghajtó van. Radeon Software és Radeon Pro Software. A Pro Duóra mindkettő felmegy. Olyan nincs, hogy CAD-es Pro driver. Az van, hogy a meghajtó kap egy jelet a hardvertől, hogy mikor működhet gyorsan, és mikor települt olyan VGA-ra, amelynél ez a lehetőség tilos. Az AMD lézeres átvágással dolgozik, szóval ha tilos a gyors feldolgozás, akkor azt nehéz megkerülni. Venni kell egy jóval drágább terméket hozzá.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
stratova
#29943
üzenetére
A Vega abból a szempontból más, hogy nagyon sok fals pozitív háromszögről még a pipeline elején megmondja, hogy nem fog látszódni. Ez a mai komplex geometria mellett lényeges, mert egy-egy nagyon komplex jelenetben annyi vagy több a fals pozitív háromszög, mint amennyi a valóban látható. Ezzel tulajdonképpen a hardver nagyon sok felesleges számítást végez el. Ezt próbálta ellensúlyozni a Primitive Discard Accelerator a GCN4-ben, de ez inkább a tesszellációnál volt hatásos, mert ez a lépcső hoz létre egy rakás degeneratív háromszöget, amelyeknek mindhárom csúcsuk egy egyenesen van. A Vega ehhez adta hozzá a primitive shadert, amivel azokról a fals pozitív háromszögekről is megmondható, hogy nem látszanak, amelyek amúgy normálisak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#29955
üzenetére
Igazából a szoftveresen február óta dolgoznak rajta. A hardver elkészülte nem jelenti azt, hogy egy nagyobb csapat lesz mögötte azonnal. Azt még le kell tesztelni, addig pedig a szimulátoron megy a munka. A munka pedig nyilvánvalóan nagy, olyan dolgokat vezet be a Vega, amiket a GPU-k korábban még hírből sem ismertek. Főleg a HBCC a nehéz, mert az egy teljesen más vezérlő, amivel a GPU-k eddig működtek, és mondjuk leprofilozni minden eddig megjelent programot HBCC-re, ha nem is nehéz, de marhára időigényes feladat.
Aztán kérdés, hogy még mit csinálnak meg. Egy rakás vertex shadert kicserélhetnek a mai programokban a driveren keresztül primitive shaderre. Ha megteszik kapnak egy adag boostot. Ez sem különösebben nehéz, csak időigényes a rengeteg elérhető program miatt.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
stratova
#29959
üzenetére
Semmi köze a konzervatív raszterizálásnak a sima raszterizáláshoz.
A korábbi GPU-k raszterizálói mind tartalmaztak valamilyen mozaikos optimalizálást. A mértéke viszont eltérő volt. A Vega esetében az igazán újdonságnak az asztali fronton a draw stream számít. A draw space nem tudom, hogy honnan jön, de ilyen nincs. A draw stream tulajdonképpen listázza a mozaikokhoz tartozó primitíveket és rajzolási parancsokat. Ezekkel a módszerekkel a Vega sávszélességet spórol. A drivernek egyébként van legacy módja is, így itt is profilozni kell az alkalmazásokat, hogy mi megy majd az új módszerrel és mi fut legacy módban.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#29963
üzenetére
Cserélni mindenki cserél shadert. Lényegében a profil azt jelenti, hogy más kódokra cserél bizonyos kódokat a meghajtó.
Attól, hogy a kezelés hardveres még kell egy szoftveres réteg a működéshez. Itt ugyanarról van szó, mint a prociknál a virtuális memória. Ott is van egy címfordító hardver a magokban, de a legfelső szintű működést a firmware és az OS biztosítja. A Vega esetében is van egy ATS egység a multiprocesszorokban, és a legfelső szintű működést a firmware és a meghajtó adja (később utóbbit kiválthatja az OS). Ezek a dolgok annyiban előnyösebbek a korábbi modelleknél, mind a procinál, mind pedig a GPU-nál, hogy a legfelső szintű működés is eléggé alacsony szintnek tekinthető, tehát nem egy magas szintű programnyelven vagy viszonylag magas szintű API-n, illetve meghajtórétegen keresztül fogod megmondani a hardvernek, hogy mit tegyen, ahol a sok hibalehetőség miatt a hatásfok jelentés része odaveszhet. Ennél alacsonyabb szintű hardverelérés csak a fix hardverplatformokon lehetséges, tehát a PC-n kizárt.
Bizonyos értelemben semmi forradalmit nem csinál a Vega. Csak azt teszi, ami egyszer már lezajlott a CPU-knál, amikor bevezetésre került a virtuális memória. Most erre a GPU-kon kerül sor.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#29969
üzenetére
Nem. A program oldalán ezzel semmit sem kell csinálni. Plug&play szintű fícsőrről van szó. De nyilván az AMD-nek össze kell raknia alá a drivert, ahogy a CPU-k virtuális memóriáját is kellett támogatnia az OS-nek. De egyébként akkor is jól futottak a legacy programok, tehát ott is csak a legalsó réteget kellett megírni, és a hardver a többit elintézte.
A HBCC első körben azzal az előnnyel jár, hogy kiszakad a Vega a WDDM modellből, így például nem fog gondot okozni a memóriatörlés. Megcsinálja a hardver úgy, hogy az operációs rendszer nem is tud majd róla, ezáltal a többletterheléssel járó feladatokat sem kell majd a WDDM-en belül futtatni, az OS azt hiszi mindig, hogy van elég memória, a többit pedig a rendszer a háttérben lekezeli.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#30042
üzenetére
Valójában nem lesznek lassabbak. Az elején igen, de hosszabb távon nem. Gyakorlatilag a gaming mód annyi, hogy kétféle módot telepít a csomag. Egy prót és egy gaminget. Amikor váltasz, akkor az olyan, mint egy TDR. Lekapcsolja az egyiket és rákapcsolja a másikat. Bizonyos értelemben valós időben kicseréli a meghajtót, bár nyilván nem az egészet, hanem csak az egyes komponenseket. Az RX Vegának az elején annyi lesz az előnye, hogy a nyers gaming driver egy kicsi ideig frissebb lesz, mint a pro driver, ami picit korábbi gaming drivert tartalmaz. Ez persze mondjuk az első pár tesztnél elég nagy különbséget is eredményezhet, hiszen a binning mód ma még alapértelmezetten legacy, ami mondjuk a Vega 10 esetében nem szerencsés, mert egy Fiji-re írt binning komponens fut egy teljesen másképp tervezett hardveren, de a számítást ez is megoldja, csak az új képességek (draw-stream vagy on-chip bin cache) használata nélkül. Később a szoftveres oldali különbség a gaming módra vonatkozóan el fog tűnni, amint a driverek egységesek lesznek, kb. az RX Vega startja után pár héttel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#30056
üzenetére
A 11 az az effektív peak érték, amikor az összes képesség használatban van.
[link] - itt van részletesebben leírva.
(#30054) =WiNTeR= : A teljesítményre vonatkozóan csak annyit lehet közölni, hogy 4K@60Hz-re tervezett hardver lesz, és ennek megfelelő teljesítményt lehet várni. A többit majd később.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Egy-két hétből kell kihozni a maximumot. A Bethesda azt szeretné igazán, hogy több időt töltsenek a játékaival az AMD rendszerprogramozói. Ehhez kell a megállapodás, mert arányaiban egy bizonyos erőforrásnál nem éri meg többet beleölni egy játékba. Nem azért, mert nem maradt még tartalék a driverben az adott játékra, hanem azért, mert aránytalanul költségessé válik azok kinyerése.
Ú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!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen