Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
TTomax
#27092
üzenetére
Igen. Az első jelenetnél a víz egyértelműen szebb. Az ami van az eredeti verzióban egy nagyon régi shader, még 2007-es. Nem átlátszó, egyáltalán nem hasonlít a vízre. Az új shader sokkal jobb, szépen át lehet látni a vízfelszínen. Aztán rögtön az elején látható, hogy a fát mennyivel jobb modellre sikerült lecserélni. Nem töredezett, hanem sokkal simább. A lens flare is visszább van véve.
A második jelenetnél nagyon erősek a volumetrikus fények a napból, de csak azért, mert máshogy áll a shadow casting fényforrás, mint az új verzióban. A korábbi verzióban egész felhőkarcoló amin mentél olyan, mintha be lenne árnyékolva teljesen. Az új verzióban végre ezt sikerült korrigálni, viszont látható, hogy így az árnyékok is másképp állnak. Ez egy jó döntés a dizájner csapat részéről.
A harmadik jelenetben szintén a shadow casting fényforrás lett megváltoztatva. Valószínűleg azért, mert a faszi, akit lelőttek az eredeti verzióban világított, mint a karácsonyfaégő, csak nem lehetett tudni, hogy miért. Talán az aurája volt erős.
De az új fénypozícióval ez sokkal jobban van kezelve.
A negyedik jelenetben láthatóan jobb az új verzió. Több a füst, jobb a robbanás. A több pontfényforrás is megtette a hatását.
Az ötödik jelenetben látható, hogy megint eltérő a shadow casting fényforrás pozíciója. Itt látható igazán, hogy mennyire más az új leképező, illetve látható az is, hogy új textúrákat kapott a játék.Nem kommentálom végig az egész videót jelenetenként. De úgy nagy átlagban az előnyére változott, főleg a durva grafikai dizájnhibák tekintetében.
[ 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
TTomax
#27094
üzenetére
Az eredetihez hasonló vizet nem láttam még soha. Olyanhoz hasonlót viszont már láttam, ami a remasterben van. Lásd a trópusokon.
Ha a két jelenetet megmutatnák, és az lenne a kérdés, hogy milyen folyadék van rajta, akkor a másodikra azt mondanám víz. Az eredeti verzióra nem tudnék válaszolni, valami periódusos rendszerben nem létező elemekből összeálló izére tippelnék.Kérdés mennyire durván tőrnek elő a sugarak. Szerintem még a remaster is eltúlzott ebből a szempontból.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27114
Abu85
HÁZIGAZDA
huskydog17
#27108
Abu85
HÁZIGAZDA
válasz
huskydog17
#27108
üzenetére
Azért fényesebb az új verzió, mert háromszor több pontfényforrás van benne, mint az eredetiben. Az UE3-ban korlátozott volt a motornak a tudása, emiatt hiába akartak valamit dizájnolni a fejlesztők, el kellett fogadni, hogy technológiailag az UE3-nak megvannak a korlátjai, és emiatt van egy maximum fényforrásszám, aminél többet nem tudnak használni. Az új verzió már az UE4-gyel készült, aminek sokkal hatékonyabb a leképezője, így el tudnak helyezni benne lényegesen több pontfényforrást, vagyis megkapták a lehetőséget a dizájnnál, hogy olyanra tervezzék a játékot, amilyenre megálmodták eredetileg, csak 2011-ben technikailag kivitelezhetetlen volt.
Miért csináljanak különdizájnolt PC-s verziót. Alig lesz olyan ember PC-n, aki megveszi, mert ezen a piacon már kijátszotta, aki akarta. Örüljünk annak, hogy egyáltalán leportolták a remastert PC-re, mert azt is mondhatták volna, hogy elég az PS4-re és X1-re is.
Egyébként egyáltalán nem történt butítás. A motorváltással történtek változások a leképezőben. Több pontfényforrást lehet használni, tehát a dizájncsapatot most már a motor képességei nem korlátozzák annyira. Emellett persze újra kellett tervezni a textúrák egy részét, mert 4K-hoz igazították a PC-s verziót, aminél nem elég az a felbontás, amit eredetileg alkalmaztak. Annak a duplája kellett bizonyos textúrákra. De a lényeg az, hogy szám szerint mindenben növekedés történt. Semmiféle butításnak a jele nem látszódik. A korábbi hsz-ben le is írtam az első pár jelenetre. Az, hogy neked jobban tetszik az előző, egy szubjektív dolog. A fejlesztők ezzel nem tudnak mit kezdeni, ők egyszerűen beleraktak mindenből többet.
A legtöbb stúdió nem házon belül csinálja a textúrákat. A People Can Fly sem. Egyszerűen vannak erre szakosodott cégek, akiknél leadod, hogy mire van szükséges, és csinálnak jó pénzért neked textúrákat.Adrian Chmielarzzal sem lenne ez más. Azt látni kell, hogy az UE3-ról olyan UE4 verzióra váltottak, hogy a textúraformátum, amit használtak eddig, kompatibilis legyen. Ez gondolom egy nagyon fontos kritérium volt, mert nem akartak minden textúrát újracsináltatni, csak azokat, amelyeknél a nagyobb felbontásra a 4K felbontás miatt feltétlenül szükség volt. Így viszont persze én sem értem, hogy mi kerül ebben 50 dollárba, de a Gearbox egy kapzsi kiadó.
[ 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
füles_
#27132
üzenetére
Lehet, hogy pár 480-as tulaj is lecseréli, mert pont olyan dolgok változtak, amelyekre sokan vártak. Az igazság az, hogy a TPU hazudott az eredeti címben. Azóta ezt át ís írták, mert nem átnevezés, csak ők ezt nem tudják, mivel nem hívják már meg őket a briefingekre. Gondolom valaki elmondta nekik, hogy ne bénázzanak ennyire. Ezért is más már a cikk címe.
[ 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
Locutus
#27135
üzenetére
Sehogy. Rá kell majd nézni a fogyasztásmérőre és ennyi. Ezekről nem lehet beszélni, de tényleg olyan dolgokban hoznak javítást az új lapkák, amelyekért egy csomó Radeon tulaj sír. Gyakorlatilag kisírták ezeket. Csak ugye ezek olyan dolgok, amelyekhez új lapkákat kell tervezni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27173
Abu85
HÁZIGAZDA
huskydog17
#27170
Abu85
HÁZIGAZDA
válasz
huskydog17
#27170
üzenetére
Új a memóriavezérlő, ettől lett egy új órajelállapot a memóriára, és új az UVD, olyan az egység, amiben vannak post-processhez dedikált fix-funkciós blokkok, így ezt a munkát már nem a shaderek csinálják. Ettől esik a fogyasztás. Az egész hardveres változás, mert az említett két blokkot kicserélték. Ezért nevezték el a lapkát Polaris 20-nak. Kapott még egy új AVFS módot is, amivel a gyári tuningos megoldások elmehetnek 1400 MHz körüli tempóra. Emiatt maga a TDP keret is megnőtt, hogy legyen mozgástér a gyári tuninghoz. Emellett ráoptimalizálták a lapkákat a Chillre. Röviden ennyi. Hosszabban majd a cikk első két oldalán.
[ 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
tailor74
#27196
üzenetére
A mikrokódba kell belepiszkálni, de az annyira bonyolult, hogy nem lesz sose megoldva. Ugyanis, ha a mikrokódot sikerül is visszafejteni és visszaírni a változásokat, akkor tulajdonképpen egy 480-a marad a felhasználónak. Egyszerűbb a kártya nevét átírni editorral 580-ra, mert a hatása ebben kimerülne az új frissítésnek.
Sajnos a BIOS nem cseréli le a Polaris 10 GPU-t Polaris 20-ra a kártyán. Az egyébként megoldható lenne, ha valaki szerezne egy Polaris 20-at, leszedné a NYÁK-ról a Polaris 10-et, és így meglenne a hardvercsere, majd az új BIOS-t befrissítené. Ez viszont nagyon macerá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
Yutani
#27227
üzenetére
Nagyon messze van a HBM2 fogyasztásától a GDDR6 is. Egy 1 TB/s-os 8 GB-os HBM2 stack csupán 4 watt. Egy szintén 1 TB/s-os 8 GB-os GDDR6 stack nagyjából 30 watt, beleszámolva a fogyasztáscsökkentést a GDDR5-höz képest. Ez azt jelenti, hogy GDDR6 mellett a TDP keretből 25 wattal kevesebb jut a GPU-nak. És azzal is számolni kell, hogy kell-e a 16 GB VRAM, aminél a HBM2 stack fogyasztása 6 wattra nő csak, de a GDDR6 stack esetében már 60 watt lesz az energiaigény, vagyis rögtön megint 30 wattal kevesebből gazdálkodhat a GPU. Akkora űr van a kettő között, hogy a GDDR6 a középkategória fölött használhatatlan. Persze az olyan trükkök segíthetnek, mint a HW page menedzsment, így mondjuk nem raknak a kártyára csak 4 GB-ot a 16 GB helyett, de még így is nyer a HBM2.
A GDDR6 elsődlegesen azért kell, mert a GDDR5X ára rendkívül magas. Rosszabb rá építeni, mint a HBM2-re, mert drágább lesz a VGA. Viszont a GDDR6 igazi, gyártók által széles körben támogatott szabvány lesz, tehát nem csak a Micron fogja gyártani, így ez végeredményben árversenyhez fog vezetni, és emiatt a GDDR6 végül olcsóbb lesz, mint a HBM2. Lehet, hogy nem az első pillanatban, de úgy fél éves távlatban simán bezuhan majd az ára, ahogy a tömeggyártás felfut.
[ 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
Locutus
#27230
üzenetére
A Fury X a HBM nélkül jó 20%-kal lassabb lett volna. A Vega 10 is lassabb lenne HBM2 nélkül. Azt még nem lehet tudni, hogy mennyivel, de nézd azt a tényezőt, hogy ha nem HBM2 lenne rajta, akkor a TBP-ből nem 4 wattot venne el a memória, hanem úgy 40-et, és emiatt a GPU működési órajele is -200-300 MHz lenne.
Nagyon tipikus probléma a VRAM-ra vonatkozó memória, hogy a hagyományosan épített konstrukciók iszonyatosan fogyasztanak már. Főleg a 256 bit feletti kiépítésben, mert ott már sok memórialapka kell, minimum 12 ugye, de lehet, hogy 24, és utóbbi már megint dupla fogyasztás, vagyis repülnek a mínuszok a GPU órajelére. És ugye ott az a szoftveres probléma, hogy kapacitásban minimum az igény négyszeresére érdemes építeni, mert a program által kontrollált rendszerben elveszhet 75%-nyi memória is. Erre mondjuk pont megoldás a HW page menedzsment, de ezt még csak a Vega tudja.
[ 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
schawo
#27231
üzenetére
Semmi köze a HBM2 fejlesztésének a Vega 10-hez. Régóta kész van a HBM2, régóta rendelhető, nagy mennyiségben. A Vega 10 egy később indított fejlesztés volt, mert azt már a következő generációs problémák megoldására tervezték. Emiatt tud egy rakás olyan dolgot, amilyet más hardver még nem.
De mondjuk az AMD-nek a memóriaválasztása eleve sokkal szabadabb lehet az NV-nél, mert sokkal olcsóbban gyárt nekik a GloFo, mint az NV-nek a TSMC. Nyilván az NV-nél számításba kell venni, hogy nagyon drágán veszik a wafert, ez korlátozza a választási lehetőségeiket. Amúgy mennének ők is a HBM2-re, mert nincs ellenérv rá. Viszont drágán gyártható GPU-k mellett már megfontolandó a GDDR6.
[ 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
schawo
#27236
üzenetére
Elég régóta lehet tudni, hogy milyen újításokat vezet be. Ezek egy részét már az elmúlt évben tartott GDC-n beharangozta Matthaus, ezért maradt egy évig titok a publikum előtt a saját előadása, mert olyan dolgokat mondott el, amelyeket az AMD csak idén tárt fel, de a fejlesztőknek tudnia kellett róla korábban.
A legfontosabb nyilván a HW page menedzsment. Ez a GPU-k következő generációja, kb. akkora áttörés, mint anno a unified shader bevezetése volt. Az egyetlen probléma vele, hogy nehéz megcsinálni, de ha egyszer működik, akkor hatásfokban agyonveri a mostani VRAM menedzsmenteket. Muszáj erre rátérni, mert nem minden fejlesztő fog relatíve használható memóriamenedzsmentet írni a programba a DX12 és a Vulkan API-hoz, másrészt ha mondjuk a fejlesztők tényleg 8 GB-ot fognak igényelni a VRAM-ból, akkor optimálisan 32 GB kell a VGA-kra. Ez fél TB/s-os sávszél mellett már jó 80 wattos fogyasztás GDDR6-ból, és ezt a 32 GB-ot muszáj vinned a normális esetben 120 wattos TBP-jű VGA-kra is, ahol ugye 40 watt marad a memórián kívül minden másra. Ebből látható, hogy mekkora a probléma.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27242
Abu85
HÁZIGAZDA
Petykemano
#27241
Abu85
HÁZIGAZDA
válasz
Petykemano
#27241
üzenetére
A GDDR6 simán jó a középkategóriába, ott nagy sikere lesz. Szerintem belépőszinten marad a GDDR5, míg a felsőházba a HBM2 kell. De középre a GDDR5 kevés, míg a HBM2 nem feltétlenül előnyös, ha nagyon drágán gyártja az adott GPU-t a bérgyártó. Ott a GDDR6 lesz az arany középút.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27244
Abu85
HÁZIGAZDA
->Raizen<-
#27243
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#27243
üzenetére
128 bites GDDR6-tal igazából kiváltasz egy 256 bites GDDR5-ös kiépítést. Nyilván sokkal jobb ezt 128 biten csinálni. A GDDR6-nak árhátránya csak az első fél évben lesz. Utána felfut a gyártás, normalizálódik a verseny, és onnantól már ez éri meg a GDDR5 helyett.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27254
Abu85
HÁZIGAZDA
huskydog17
#27252
Abu85
HÁZIGAZDA
válasz
huskydog17
#27252
üzenetére
Az a baj, hogy egy külön UE4 branchbe került. Ugyanígy van Hairworks, VXAO, Flame, Turbulence, és egy rakás eltérő branch az UE4-re. Az Epic nem engedi meg, hogy bármilyen külső gyártótól származó DRM bekerüljön a main branchbe, és ezáltal a DRM-hez kötött effekteket sem tudják ott szállítani. Ugyanez lesz ennek is a sorsa, mint a fenti sok másik, UE4-be DRM-mel integrált effektnek. A fejlesztők többsége nem kockáztatja meg, hogy nem hivatalosan supportált branchre menjenek, inkább nem érdekli őket az effekt.
Ennek akkor lenne igazán áttörő hatása, ha szimplán egy MIT-szerű licenc mellett felkerülne az effekt a GitHUB-ra, tehát nem úgy, hogy ott a forrás, de bele nem nyúlhatsz, mert a DRM a módosítást nem engedi lefutni, hanem úgy, hogy vidd a forrást, nincs DRM sem és integrált a main branchbe, hogy minél többen használhassák. Ilyen formában sajnos halottnak a csók.
Egyébként az jó hír, hogy a DRM-tól megszabadulhat egy GameWorks effekt. A HBAO-t már megkapta az Epic DRM nélkül, és láss csodát be is építették a main branchbe, de persze közben jelentősen átírták, így sokkal gyorsabban is fut.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A "looks nice" igazából egy szabványszöveg. A helyzet az, hogy soha senki sem írhat mást hivatalosan. Így van ez az NV-nél, az AMD-nél, az Intelnél. Ezek a szövegek arra jók, hogy ha valaki kérdez egy érkező termékről, akkor egy ilyen szabványszöveggel lehet válaszolni, még akkor is ha agyonveri vagy kikap nagyon. Ezek központi utasítások az ilyen cégeknél. Aki ebből hírt ír nem nagyon érti, hogy hogyan működik a cégek közösségi médiájában az irányított kommunikáció. A "looks nice" azért jó szöveg, mert úgy érzi a kérdező, hogy válaszoltak neki, és eközben igazából nem történt konkrét utalás semmire.
[ 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
Raggie
#27264
üzenetére
Nem a Ryzen miatt adják ki, hanem azért, mert az új minimum a négy mag lesz, és egy négymagoson már kurtítani kell majd a látótávolságot, hogy fussanak a következő éra játékai, ezzel csökkentve a kiadott rajzolási parancsok számát.
Az ID tech 7 már duruzsol a Bethesdánál, és kiszedték belőle a régi API-k támogatását. Csak Vulkan API-ra építik, aminek az az előnye, hogy minden legacy eljárástól megfosztották, de cserébe nem a két mag a minimum, hanem a négy, és az ajánlott a hat-nyolc mag. A következő kör motorfejlesztései lényegében abban merülnek ki, hogy kiszedik belőlük a legacy API-k támogatását, így ezekhez már nem kell a motor szintjén igazodni, vagyis sokkal jobban lehet skálázni több magra. Ez nagyobb megengedhető látótávolságot, és több számítási lehetőséget jelent. A hat mag csupán ezért kell az Intelnek is, hogy tudjon az inteles felhasználó is hat magot venni ezekhez az igényekhez. Ha nem lenne Ryzen, akkor is kiadták volna, mert itt sokkal inkább a programokhoz kell hardvert kínálni.[ 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
Raggie
#27268
üzenetére
Amelyik motort sok magra tervezték ott mindig volt haszna, ha négynél több magod volt.
Senkit sem zárnak ki a játékból. A legjobb az új API-kban a skálázhatóság. Alapvetően a szimulációt most sem tervezik többre, mint két mag, annyival pedig mindenki rendelkezik. Ergo azt nem kell skálázni igazán. A rajzolási parancsokkal viszont végre el lehet szállni. A látótávolság lehet igen extrém is, és egy rakás objektumot ki lehet rajzoltatni, és nem kell a LOD-dal levágni. Akinek négy magja vagy négy szála van, annak elég a world detailt low/medium-ra rakni, és rögtön tökélesen fut. Akinek pedig van hat magja mehet highra. Esetleg a 10-12 magos szörnyeknek lehet csinálni egy ultra beállítást.
A lényeg, hogy az új API-k lehetőségeivel a processzoroldali terhelés nagymértékben skálázhatóvá vált, újra, mint régen. Meghatározható, hogy mennyire messze jelenjenek meg az árnyékok az objektumokon, mi az a távolság, ameddig egyáltalán rajzoljon animált objektumot a rendszer. Erre ma is lehetőség van, de a legacy API-k fogják a rendszert, tehát nem tudják nagymértékben skálázni ezt a beállítást egy ideje. Pedig régen nagy különbségek voltak ebből a szempontból. Ez most végre visszatér.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#27281
üzenetére
Az se lett volna erősebb igazából, hiszen a nagy látótávolságú jeleneteknél 20 fps különbség is volt. Itt azért erős a Radeon, mert a CI Games frissítette a CryEngine-t, és az újabb verziók PC-re kétféle módon oldanak meg bizonyos problémákat. A szabványos kóddal szimplán sok atomi műveletet használ a motor a préseléshez, míg a másik mbcnt és ballot függvényt. Utóbbi sokkal gyorsabb már a kód szintjén, de csak GCN-en fut le, tehát a GeForce rá van kényszerítve a lassú kódra. Ennyi a titok. Majd ha az egész szabvány lesz a shader modell 6-ban, akkor ezek a függvények általános szinten is használhatók, és valamennyit gyorsítanak a GeForce-on is.
[ 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
Raggie
#27291
üzenetére
Az nem bug. A motor támogatja a dinamikus napszakváltozást. Tehát, ha tovább állsz egy helyen, akkor a napból származó shadow casting fény már nem olyan szögben világít be. Ez okozza az eltéréseket. Ha pontosan ugyanabban az időben történne a felvétel, akkor ugyanolyan szögből érkezne a fény. A számításigény egyébként ettől nem változik meg, mert a shader úgyis lefut, csak más lesz az output az eltérő input miatt.
(#27285) FLATRONW: Tükröződik, csak valószínűleg egy pár percet állt az egyik gép a felvétel előtt, és ez elmozdította a shadow casting fényforrás helyét.
(#27286) Yutani: Mindkettőn jó, csak mozog a fényforrás. Persze az ennyire erős visszaverődés nyilván egy dizájnhiba, de ezt nem a kártyák rontják el, hanem ilyen a játék. Őszintén szólva az eddigi CI címekhez 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
-
Abu85
HÁZIGAZDA
válasz
tom_tol
#27350
üzenetére
Semmi köze hozzá. A legtöbb esetben az ilyen nagy változásokat, főleg egy negyedéves beszámoló után a következő negyedévre vonatkozó előrejelzés határozza meg. Az AMD 17%-os növekedést jelzett előre szekvenciálisan, és ezt a befektetők kevésnek tartják. Emiatt esett a részvényár.
A Vega egyébként az AMD idei eredménye szempontjából pont annyira nem lényeges, mint a Ryzen. Ami számít az az Xbox Scorpio és a Naples. Ezek az idei húzótermékek. A többi az töltelék, vagy nagyon az év végén jön. A Scorpio azért lényeges, mert az termeli a bevételt a sok eladás miatt (és ha ez az év végén jön, akkor már nyáron el kell kezdeni szállítani), míg a Naples az egy szervertermék, tehát brutális szokás szerint a nyereség rajta. Illetve nem mellesleg bevezet olyan biztonsági újításokat, amelyekkel x86-os adatközpontokban még nem lehetett találkozni.
[ 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
tom_tol
#27364
üzenetére
A következő negyedév az már a Q3. A Q2-re vonatkozik a 17%-os növekedés előrejelzése. Ebben a negyedévben startol egyébként a Naples és a Vega 10. Ezekre a fejlesztésekre számos termék épül majd. Egyszerűen arról van szó, hogy a befektetők 17%-os növekedésnél többre számítottak. Persze ez még simán több lehet, mert ez csak előrejelzés.
(#27361) Zsébernardo: Ez hülyeség. A befektetőknek a teljes évre vonatkozóan két AMD termék számít. Az Xbox Scorpio lapkája és a Naples. A többi az töltelék. Az Xbox Scorpio azért kell, mert megint lesz egy zsíros OEM szerződés, amivel 150 dollár körül rendel a Microsoft többmilliós tételben, ami felnyomja a bevételt. A Naples pedig azért lényeges, mert 300 dollár körül gyártható processzorról van szó, és eladják majd 3000-5000 dollárért. Ez a nyereséget szolgáltatja. A Ryzen, a Vega, a rakás tölteléket kb. leszarják a befektetők. Kb. arra jók, mint most az 500-as sorozat, hogy megdobja a notebookra vonatkozó eladásokat. Ugye ezek a termékek papíron még nem léteznek, de már szállítás alatt vannak az OEM-ek felé.
[ 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
#27366
üzenetére
A konzolos uralom onnantól számít problémásnak a konkurenseknek, ha a szabványalkotók nem a piac érdekeit nézik, hanem a konzolét. Eddig szerencsére ez nem állt elő, de a wave intrinsics a shader modell 6.0-ban eléggé gázos lesz az Intelnek és az NV-nek.
Eddig csak az történt, hogy az AMD-re lehetett hozni opcionálisan konzolos optimalizálást. De ez nem volt szabványos. A Vulkan sokkal általánosabban fejlődik. Például a SPIR-V ballott nem csak GCN-re mappelhető hatékonyan, ellentétben a DXIL verzióval, ami 64 bites maszkkal tér vissza, és milyen véletlen, hogy a GCN 64 bites skalár regisztert használ. Ebből egy éven belül simán lesznek gondok. A Vulkan egyébként nagyon jó PC centrikus megoldásokkal próbál operálni, csak a Khronos lassan halad.
(#27367) Zsébernardo: Mindkettő fontos, de a termékek között is van kritikus fontosságú. Idén ez a Naples, illetve a Scorpio SoC. A többi nem kritikus.
(#27368) TTomax: A konzol az AMD-nek jelenleg évi ~1,5 milliard dollár közötti bevételt jelent. Ezért fontosak ezek a fix megrendelések. Eves szinten ezek tíz milliós fix eladások.
(#27371) imi123: A PS5 messze van. Lehet amúgy egy még gyorsabb PS4 verziót terveztetni az AMD-vel PS4 Pro Plus neven mondjuk. De ezek folyamatosan csúsztatják az új generáció érkezését, mert a fejlesztőknek ki kell termelni a generációra vonatkozó befektetést. A köztes hardver egyébként nem tűnik már rossz elgondolásnak, mert pont annyi időt dob ra az aktuális generációra, amivel elhúzható a valódi frissítés 2023-ig. Ezzel jó pár extra évet nyernek a partnerek, így nagyobb befektetésekkel operálhatnak.
[ 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
#27378
üzenetére
Wave intrinsics kell nem shader modell 6.0. Remélhetőleg csak a Microsoft fogja használni, mert a SPIR-V sokkal általánosabb a hardverkezelés szempontjából. Ma viszont van AGS4.0, ami ugyan nem szabvány, de részben ugyanazokat kínálja, mint a szabványos wave intrinsics. Az AGS4.0 egyes függvényeit már kezeli a Battlefield 1, a Deus Ex: Mankind Divided, a Civilization 6, a Sniper Elite 4, a Resident Evil 7: Biohazard, a Doom, a Warhammer 40000: Dawn of War 3 és a Sniper Ghost Warrior 3. Remélem nem hagytam ki semmit.
(#27380) mcwolf79: A Microsoft wave intrinsics nem AMD-s csodák. Jelenlegi állapotát látva az Xbox One mono hozzáférésének intrinsics függvényéi PC-re másolva. Arra szolgálnak, hogy PC-re direkten átmásolhatók legyenek az Xbox optimalizálások. Az, hogy ez az AMD-nek addig jó, amig GCN-t használnak csak mázli. Viszont PC-re ilyen újításokat nem így kellene hozni, hanem úgy, ahogy a Khronos hozza. Semmi baja az AMD-nek például az 56 bites maszkkal visszatérő bollatt függvénnyel, de a Microsoft mégis 64 bites maszkkal dolgozót hoz, amivel az Intel és az NV hardverek sem igazán tudnak mit kezdeni, így hatásfokot veszítenek. Ez így hülyeség.
[ 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
Valdez
#27383
üzenetére
Éppenséggel van miről beszélni. Itt nem arról van szó, hogy a hardverek lekövetik majd a wave intrinsics követelményeit, hanem arról, hogy a PC-nek nem ilyen szabványokra van szüksége. Persze nem kérdés, hogy két-három év múlva felkészül mindegyik architektúra, de erre nem lenne szükség, ha nem az Xbox megoldását másolnánk. Eleve minek egy szabványos, de gyártóhoz kötődő konstrukció, akinek ez kell majd használ AGS4.0-t. Szabványban olyan megoldás kell, amely figyel arra, hogy a meglévő hardverek között milyen különbségek vannak, és ezekre általános megoldást kínál. Érdekes a Khronosnak ez sikerül.
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
#27385
üzenetére
Azóta a SPIR-V előállt a saját megoldásával, és ez sokkal jobb a PC-nek. A wave intrinsics igazából csak az AMD GPU-ra tudja elhozni az egyszerű portolást. A GCN-nek biztos jó, hogy több függvény is rámeppelhető egy kibaszott utasításra, de ez egyáltalán nem előny általánosan a PC-nek.
Itt alapvető félreértés van a lehetőség és az igény között. Tök jó, hogy egységesítve lesz ez az egész a PC és a konzol között, és nyilván a gyártók kötelezve lesznek az emulációra is, de a fenébe is nem az a szabvány célja, hogy egy konzolt és egy hasonlító alaparchitektúrát kiszolgáljon a szabványalkotó, míg a többin majd le lesz emulálva. Nem erre van szükség![ 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
#27392
üzenetére
Lehet viccesnek is felfogni, hogy ez mennyire az AMD-nek kedvez, de valójában a PC-nek ez eléggé nagy baj is. Nem a kedvezés, mert az API működésében vannak olyan részek, amelyek valamelyik architektúrának mindig kedveznek. Ez kivédhetetlen, amikor valami általános megoldással szeretnének előállni a szabványalkotók. Ugyanakkor ezek mind megbeszéléssel születtek meg, tehát az AMD, az Intel és az NV is elfogadott bizonyos kompromisszumokat. És összességében így "a gép kidobott egy DX12-t és egy Vulkánt", amivel nagyjából minden érintett elégedett most. És ez általános elégedettség, például a DX12-ben vannak pontok (root signature modell, fast pathok kizárása), amelyek az NV-t igen hátrányosan érintik, de a legrosszabb esetben is korrigálható pontokról van szó, csak nem sokan korrigálják azt, tehát végeredményben ugyanott vannak, de legalább nem dönti be a sebességet.
A wave intrinsics ennél sokkal durvább. Nem is igazán érthető, hogy miképp lesz ez elfogadva. Valószínűleg a Microsoft azt mondta az Intelnek és az NV-nek, hogy ez ilyen lesz és vagy támogatjátok vagy viszlát. Ez már önmagában egy hatalmas probléma, meg kellett volna beszélni, hogy az egyes hardverek mire képesek, és azok alapján kialakítani egy közös pontot a függvényeknek. Mert most hiába hozol global ordered append csoportot két függvénnyel, ha csak a GCN-ben van megfelelő belső memória a wave-ek sorrendfüggő feldolgozására. A többi hardver rá van kényszerítve, hogy a VRAM-ot használják, vagyis chipen kívülre kell viszi a munkát, és ez sosem egy sebességbajnok megoldás. Ezzel igazából a fejlesztők végül nem nyernek sokat, mert tök jó, hogy kaptak egy szabványos megoldást a konzoloknál elérhető fícsőrökre, de ugyanúgy kellenek majd alternatív shaderek az NV és az Intel GPU-kra, mint eddig. Csak annyit nyert a piac, hogy az alternatív shaderek az AMD GPU-kra már nem kellenek, de most tényleg erről szólna egy szabvány?[ 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
#27431
üzenetére
Nem, a NAVI az inkább 2019-es fejlesztés. Az már új memóriarendszert használ, leszivárog az SSD a sima Radeonokra, így nem csak a Pro és az Instinct sorozat része lesz, mint a Vega esetében.
A következő nagy probléma a GPU-piacon az adatmennyiség kezelése. Egyszerűen a rendszermemória kapacitása kevés ahhoz, hogy fél terabájtnyi kódolatlan textúrát belezsúfoljanak a fejlesztők, a háttértár pedig túl messze van, és az összeköttetésre használt buszok lassúak. Ezek ellensúlyozására a megfelelő optimalizálást PC-n nem lehet elvégezni, mert túl sok mindent kezel az OS vagy a driver. Tehát még ha a VRAM menedzselése szempontjából a hardveres megoldás sok szemetelési problémát meg is old, akkor is kell a VRAM mellé egy gyors, legalább negyed terabájtos tároló, amibe bemásolható a kódolatlan textúra jelentős részlete. És ez még kódolt textúrával is eljátszható, mert vannak erre formátumok, így gyakorlatilag olyan játékterek építhetők, amelyek kódolatlan formában számolva terabájtos mértékű adatmennyiséggel dolgoznak. Tulajdonképpen megvalósul Carmack nagy álma a megatextúrázásról. A legtöbb mai motor ezt a formát amúgy is támogatja, sőt használja, csak az adatmennyiségnél nagyon finomra veszik a beállítást.
[ 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
TTomax
#27439
üzenetére
Alapvetően az NV-nek is van egy hasonló megoldása a GP100-ban, ami hardveresen próbálja menedzselni az allokációt, de az csak a CUDA-ra működik. A HBCC nem olyan dolog, hogy eldöntöm és csinálok egy ilyet, és hozom is. Az AMD-nél ennek az ötletét még az R600 megjelenésénél vettették fel. Szóval kb. egy évtizedes folyamat, amíg ez az első megbeszéléstől eljut egy lapkába. De abból, hogy a GP100-ban már van egy hasonló, csak még kezdetleges formában tulajdonképpen tudni lehet, hogy az NV is készül vele. Egyes pletykák szerint már a Volta tudja, de nem biztos, hogy mindegyik lapka.
Ez hasonló dolog a feszültség skálázáshoz. Nem azért használ szoftveresen vezérelt DVFS megoldást az NV, mert az olyan jó, hanem azért, mert a teljesen hardveres megoldások nagyon nehezen kivitelezhetők. Az NV mérnöki csapatába nem eset be az előző évtizedben egy rakás processzorokon megedződött mérnök, akik baromira sok know-howt tudtak vinni erről a problémáról. Az AMD-nek pedig beesett, de ha az ATI lenne az AMD még mindig, akkor marhára nem lenne nekik sem AVFS-ük.[ 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
TTomax
#27442
üzenetére
Ez távolról sem annyira úttörő dolog. A memory paging rendszerek évtizedek óta léteznek. A HBCC tulajdonképpen egy ilyen rendszer, se több, se kevesebb. Az AMD-nek azért lesz hamarabb, mert az ATI-hoz beesett egy csomó CPU-s mérnök, akik már tizensokéve erre terveznek processzort. Az NV-nek ezek a mérnökök hiányoznak, tehát nekik fel kell szívniuk a saját tapasztalataikat, mert nem volt olyan szerencséjük, hogy hirtelen a GPU-t tervező részleg mellé került egy csúcsprocesszorokat tervező részleg egy rakás tapasztalt mérnökkel. Az AMD részéről ez az egész színtiszta mázli. Ha az ATI még mindig független lenne, akkor most nem beszélnénk a HBCC bevezetéséről, mert azt az utat kellene járniuk, amit az NV jár, és nem egy gigantikus felvásárlás utáni jól megrakott tálcán kínálják a know-howt a GPU-s mérnököknek.
[ 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
TTomax
#27447
üzenetére
A semminél jóval többre mentek. Tulajdonképpen a kétszereplős piacon másodikként meghatározták, hogy milyenek legyenek az új API-k és az új programozási technikák. Olyanra még soha nem volt példa, hogy egy szabványalkotó a piacvezetőnek kedvezőtlen feltételeket teremtett volna. De most megtörtént. Látszik is, hogy mennyire más a Radeonok és a GeForce-ok DX11-es és DX12-es teljesítménye.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az AMD alámehet az NV-nek árban, mert jóval kevesebbet fizetnek a waferért, de igazából nem valószínű, hogy nagyon alámennek. A Vega inkább be lesz árazva az RX 500-as sorozathoz viszonyítva. Az úgyis a legjobb ár/teljesítményben a jelenlegi palettából.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mikroakadások elsődlegesen az API-tól és az alkalmazástól vannak, nem pedig a drivertől. Ha erre akarsz utalni, akkor jelen pillanatban az a helyzet, hogy az AMD driverei jelentik most a csúcsot. Most az ő fejlesztési konstrukciójuk a legjobb, és emiatt jó szinten tudják tartani a kódminőséget, nem jön gyorsan különböző kritikus hibákra hotfix, stb.
Mi az a BS? Black Screen vagy Blue Screen? Csak azért érdemes ezt értelmezni, mert ha bármilyen hiba van a gépben, akár VGA, akármi, akár szoftver, akkor mindenképpen fekete vagy kék képernyőt kapsz.
A pumpa és a hűtő igazából nem tipikusan olyan hiba, ami az AMD tervezéséből fakad, de nyilván ezek tényleges problémák, ki kell értékelni őket.
A 4 GB HBM memóriával tudtommal nem volt semmilyen stabilitási probléma, vagy bármi bug.
(#27458) Egon: Éppenséggel annyira nincs nagy különbség, hogy AMD vagy Intel proci mellé raksz AMD vagy NV VGA-t.
[link] - Itt meg lett nézve. A GTX 1060 és az RX 480 nagyon hasonlóan teljesít Intel és AMD CPU-val is. Egyedül a Rocket League esetében van az, hogy AMD CPU mellett lényegesen jobban fut Radeonon, de a Rocket League-ről köztudott, hogy egy AMD-re írt játék, az RX 480 is tartja a lépést a sokkal drágább GTX 1080-nal benne (99th percentile mérésben még jobb is az RX 480, nem is kevéssel). Valószínűleg vannak a programban különböző optimalizálási problémák, amelyek az NV driverét rosszul érintik, és emiatt általánosan esik a kártyáik elméleti teljesítménye, AMD CPU-val jobban. A fejlesztők pedig szarnak rá, nem éri meg nekik javítani.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27575
Abu85
HÁZIGAZDA
Petykemano
#27560
Abu85
HÁZIGAZDA
válasz
Petykemano
#27560
üzenetére
Egyáltalán nincsenek túlfeszelve a kártyák. Csak nem értik a felhasználók, hogy a földön uralkodó hőmérséklet és páratartalom nem egységes. Egy kiadott terméknek nem csak mediterrán éghajlatban kell működnie, hanem trópusi és szubtrópusi környezetben is. Az AVFS pedig arra szolgál, hogy a működési órajel ne 800-900 MHz legyen, hanem 1200-1300 MHz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Oké látom ez a skálázás nagyon nem világos. Megpróbálom leírni részletesen.
Szóval kezdjük azzal, hogy van egy termék skálázás nélkül. Ilyenkor az a helyzet, hogy a terméknek vannak megcélzott piacai, és ezeken a piacokon igen eltérő lehet a hőmérséklet és a páratartalom. Elég csak azt figyelembe venni, hogy Indiában azért vannak olyan hetek amikor 45°C van és a páratartalom is az egekbe szökik. De más egyenlítőhöz közel lévő területen is lehetnek hasonlók a körülmények. Ezzel szemben Európa mondjuk egész kellemes egy kontinensnek számít az itt uralkodó éghajlattal. Amikor tehát egy hardvert paramétereznek, akkor olyan órajelet és feszültséget kell beállítani, amivel Indiában is működni fog. Régen ez pusztán a hardvertervezés direktívái miatt nem volt probléma, mert igen kevés lépcsőre bontotta a futószalagokat egy GPU, tehát eleve alacsonyabb órajelre kényszerültek a gyártók, mint amennyit elméletben be lehetett volna állítani. Egyszerűen el kellett kerülni az órajel-csúszásokat. A pite onnan vált meleggé, amikor az órajel elkezdett felfelé kúszni. A gyártók elkezdték úgy tervezni az architektúrákat, hogy a futószalagokat több részre bontották, és ez a lépcsőzés lehetővé tette, hogy egy órajel alatt kevesebb munkát lehessen végrehajtani, tehát maga az órajelciklus is rövidebb lehetett, ami magasabb órajelet eredményezhetett. Ebből a szempontból az első igazán extrém megoldás a G80 volt, ami abból a szempontból nagyon érdekes volt, hogy nem csak többfokozatú lépcsőzést használt, hanem még a multiprocesszorokon belül is több fokozatra bontotta a feladatot. Ezért volt külön mag és külön shader órajel. Itt már volt egy alapvető skálázás a rendszerben, de turbó még nem, mert eléggé kezdetleges volt az egész. Viszont a G80 más feszültségen üzemelt például Európában és más feszültségen a trópusokon.
Az egész futószalagokat felbontó koncepció lehetővé tette az órajellel való játékot, mert már képesek voltak a gyártók elérni azt, hogy ostromolják az adott node határait. Ez hozta el a GPU-knál a komolyabb órajel- és feszültségskálázás szükségességét. Az első igazán életképes rendszereknek a Fermi (GeForce 400) és a Terascale 2 (Radeon HD 5000) volt tekinthető. Kezdetlegesek voltak ugyan, teljesen szoftver vezérelte őket, de működtek, és esetenként belenyúltak az órajelbe és a feszültségbe. Ehhez a meghajtóba volt építve egy táblázat, ami alapján a rendszer kiértékelte, hogy kell-e az órajelet csökkenteni vagy nem. Általában nem kellett, főleg az európai éghajlattal, de a lehetőség ott volt a rendszerben. Biztos emlékeztek még a Furmarkra, ami pont a Fermi és a Terascale 2 után vált használhatatlanná a VGA-k megsütése szempontjából, mert ezekben jött először egy életképes skálázó rendszer. Főleg a Terascale 2 volt védve, mert a szoftveres vezérlés mellett a túlterhelés ellen teljesen hardveres megoldása volt, tehát ha a szoftver nem tudott reagálni a körülményekre, akkor a hardver végső pajzsként megtette.
A DVFS valójában ezután csatlakozott be. Persze bizonyos értelemben a Fermi és a Terascale 2 lapkákat is nevezhetjük DVFS-nek, de a szó legszorosabb értelmében nem szokás, mert szoftverből volt szállítva a táblázat a működéshez, ugye ennek az volt a hátránya, hogy ha elrontottad a szoftvert meg is sültek a termékek, például a Fermi a Starcraft 2 alatt - [link].
A következő körben már igazi DVFS megoldások jöttek. Ezeknél az volt a lényeg, hogy az egyes külső körülményekhez már a lapkába került egy táblázat, ami alapján a rendszer maga is képes volt beállítani a megfelelő feszültséget és órajelet. Ezzel bejöttek a turbók is, mert reszponzívvá vált az egész, nem kellett a meghajtó jóváhagyására várni. Az AMD a HD 6900 sorozattal tért át erre a modellre, ami az első generációs PowerTune volt. Majd ezt követte a második generációs verzió a HD 7790-nel. Az AMD ezt azért fejlesztette két lépcsőben, mert teljesen át akartak térni hardveres vezérlésre. Ezt valójában a CPU-s mérnökök know-howja alapján rakták össze, de ez lényegtelen. Az NV az első igazi DVFS-t a Keplerben hozta. Ők még félig szoftveres szinten maradtak. Úgymond az órajel vezérlése hardveressé vált, de a védelmi rendszerek még szoftveres választi igényelnek, ahogy az órajelállapotok váltása is igényli a driver engedélyét. De ezektől a különbségektől eltekintve, nagyon lecsupaszítva az a lényeg, hogy a hardvert mindig a legrosszabb körülményre kell tervezni, tehát kvázi a trópusi igénybevételre, ugyanakkor Európában másképp is működhetne. Tehát az elérhető órajel más a trópusokon és más a mediterrán területeken. A DVFS táblázata ezt a különbséget hidalja át. Ezzel az elvi maximum órajelhez relatíve közel lehetett vinni a valós órajelet. Tehát ha mondjuk az elvi maximum ~1500 MHz lenne, akkor egy DVFS-sel valóban beállítható a gyakorlatban is egy ~1200 MHz-es maximum szint a táblázatba. Ha nem lenne DVFS, akkor az órajel pedig úgy ~900 MHz lenne, ami ugye eléggé messze van az elvi maximumtól.
Az AVFS pedig a következő lépcső ebben az órajelekért folytatott versenyben. Annyiban különbözik ez a rendszer a DVFS-től, hogy nincs egy előre beállított táblázat a lapkában, hanem az indítás során mért hőmérsékleti értékek alapján kalkulál egy saját táblázatott a chip. Ez azért jobb megoldás, mert ilyenkor a skálázást már nem egy legrosszabb körülményekre állított táblázatból valósul meg, hanem a hardver az adott körülményekhez számol egy sajátot. Ilyen formában mondjuk maradva az elvi ~1500 MHz-es maximumnál, a gyakorlatban beállítható maximum órajellel elérhető az ~1350 MHz is. Ennek az AVFS megoldásnak az a nehézsége, hogy jó táblázatott számoljon a hardver, és ez tényleg olyan nehézség, amely látszatra egyszerűnek tűnik, de a valóságban éves szintű tesztelések szükségesek, hogy egy implementációra rá lehessen mondani, hogy ez jó. Persze ismét vannak olyan GPU-s csoportok akiknek tálcán viszik a rendszert a CPU-s mérnökök, amiért az AMD RTG részlegének a dolga valljuk be baromira egyszerűvé válik. Tehát igazából az AMD és az NV megoldása között csak pár CPU-s mérnök áll, semmi más, mert amíg a CPU-s részleg nem vitt semmit a GPU-s részlegnek, addig az AMD és az NV nagyjából hasonló megoldásokat talált ki. Emiatt az NV mérnökei se dolgoznak rosszabbul, mint az AMD mérnökei, csak nekik senki sem vitt oda egy bő évtizedes know-howt a skálázási probléma kezeléséről. Emiatt lehet, hogy az NV egy másik irányt is válaszott az órajel meghatározása szempontjából, és jóval több futószalag fokozatot használnak az architektúrára. Ezzel a futószalagot több részre bontják, mint az AMD, ami magasabb órajel beállítását teszi lehetővé, de egy órajel alatt kevesebb munkát is tudnak elvégezni. A Vega esetében az AMD is növeli egyébként a futószalag fokozatok számát, hogy növelhessék az órajelet, de ezzel ugye nekik is kevesebb munka lesz elvégezhető egy órajel alatt. Az optimális futószalag fokozatok száma egyébként a GPU-knál is olyan kérdéses, mint a CPU-knál. Se a kevés nem jó, se a sok. Tipikusan van egy optimális szám, ami részben architketúrától is függ. Tehát annak kicsi a jelentősége, hogy az AMD kevesebb fokozattal dolgozik, mint az NV, mert ez egy architektúrára vonatkozó döntés is lehet.(#27576) s.bala31: Nem. Pont, hogy rosszabb. Például ezért nincsenek kiadva az ultragyáriagyontuningolt VGA-k az egyenlítő közelében, többek között Szingapúrban. De mondjuk Indiában is az van, hogy ezek simán nem működnek. A ~45°C-os nyári melegben le fognak fagyni, és azért pár nap van az évben, ami ilyen ezeken a területeken.
[ 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
schawo
#27578
üzenetére
Ilyen a Polaris és ilyen lesz a Vega is. PID szabályozó, fuzzy vezérlővel, és táblázatos rásegítéssel, meghajtó oldali opcionális profilkonfigurálással. A táblázatra igazából azért van szükség, mert gyorsabb előre kiszámolt paramétereket kiolvasni és beállítani, mint real-time számolni, majd mire beállítanád a lehetőség a magasabb órajelre megszűnik. Mikromásodpercen belüli órajelváltás lehetőségével a reakcióidő kritikus.
[ 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
schawo
#27580
üzenetére
Nem fér hozzá a GPU erőforrásához. Egy kis ALU-tömb van mellette, csak erre a feladatra. Az nem egy nagy számítási teljesítményű. Mondhatni eléggé nüansznyi a tempója a GPU-hoz képest.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27585
Abu85
HÁZIGAZDA
Petykemano
#27583
Abu85
HÁZIGAZDA
válasz
Petykemano
#27583
üzenetére
Mert a felhasználó a tuningolást a játékokban teszteli. De a VGA esetében nem csak olyan körülményben kell stabilnak lenni, amely a beépített részegységek zömét azonos időben nem is használja. Az xyz játékokban stabil nem jelenti azt, hogy egy w programban is az lesz. És ez egy fontos tényező az órajel beállításánál.
Nyilván, hogy ha saját magad tuningolsz, akkor te megteheted, hogy egy programra ráoptimalizálod az órajeleket. Mert úgy gondolod, hogy úgy stabil, de bőven lehet, sőt igen valószínű, hogy a világban van még egy olyan program, amellyel a tuningod már nem stabil. Ez saját órajelállításnál a te hibád, de ha az AMD csinálná, akkor az bizony gyártói hiba lenne, amiért leszednék a cég fejét.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27589
Abu85
HÁZIGAZDA
Petykemano
#27587
Abu85
HÁZIGAZDA
válasz
Petykemano
#27587
üzenetére
Használjál. Azért van ott funkció. De gyárilag csak 100%-osan stabil beállításokat fogsz kapni.
Nem szükséges a táblázatot módosítani. Egyik célpiac sem sivatag, hogy 50°C lesz a hőmérsékletkülönbség 24 órán belül. Ha instabilitást érzékel az órajelet viszi vissza. Az bőven elég a stabilitás megőrzéséhez.
A táblázat alapvetően egy működési módot ír le a hardvernek. Ettől az órajelet és a feszültséget is tudja változtatni, mindig annyira, amennyi stabilan hozható. A DVFS is kvázi ugyanez, csak ott a működési paraméterezés Európában is Indiára szabott, tehát nem tud beállítani olyan magas órajeleket és olyan alacsony feszültségeket, amilyeneket ugyanaz a lapka AVFS-sel tudna.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27609
Abu85
HÁZIGAZDA
Petykemano
#27590
Abu85
HÁZIGAZDA
válasz
Petykemano
#27590
üzenetére
Éppen ilyet kapsz.
De az AVFS számol a gyártási varianciával. A DVFS nem tud ezzel mit kezdeni. Ez az oka annak, hogy a Radeonok teljesítményvarianciája 3% alatti a Polaris óta. Például egy Pascal esetében ez a szám 6-7% is lehet. Bár ebben szerepet játszik a binelés.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27615
Abu85
HÁZIGAZDA
Petykemano
#27610
Abu85
HÁZIGAZDA
válasz
Petykemano
#27610
üzenetére
A user azért tudja alulfeszelni, mert xyz programra lehet, hogy jó lesz, de w-re már nem. A gyártónak viszont xyzw programokra is stabil állapot kell.
Minden rendszerben lehet találni egy rakás wattot is, ha csak pár program futtatására alulfeszeljük. Ez okozza a dolog nehézségét. Az AVFS csak abban segít, hogy a DVFS-nél alacsonyabb feszültséget és magasabb órajelet tud beállítani. De még így is messze lehet az elmélettől, viszont nem annyira, mint a DVFS. Emiatt pici a teljesítményvarianciája is. Ami mondjuk a DVFS megoldásokra nem jellemző, azoknál viszonylag nagy a variancia. Gondold el ezt úgy, hogy van két tök ugyanolyan RX 480-ad, és előfordulhat, hogy az egyik 3%-kal gyorsabb a másiknál. Ugyanez igaz a GTX 1060-ra is, ha két ugyanolyan VGA-d van, de itt már a különbség elérheti a 7%-ot is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27617
Abu85
HÁZIGAZDA
Petykemano
#27614
Abu85
HÁZIGAZDA
válasz
Petykemano
#27614
üzenetére
1.) Nem az AMD és az NV megoldását hasonlítom össze, hanem az AVFS-t és a DVFS-t. Itt tényszerű előnye van az AVFS-nek.
2.) Mert az AMD hardvere fel van készítve olyan dolgokra, amihez az NV hardvere még csak hozzá sem tud szagolni, és mondjuk az a buszrendszer, ami szükséges az egyes shader modell 6.0-s függvényekhez igen sokat szokott fogyasztani. Viszont a konzolba kérték a megrendelők a tudást, mert az emuláció túl lassú lenne. Az AMD is tudna egyébként csinálni ultramobil specifikációknak megfelelő hardvert, és akkor most emulációt építenének a shader modell 6.0-ra, nem lenne az, hogy bizonyos függvényekre külön utasítást tudnak rendelni. Ez olyan dolog, mint a procinál az Atom és a Core mag különbsége. Ha több Atomot raksz egy lapkára mint Core magot, akkor az összesítésben gyorsabb lesz és kevesebbet fog fogyasztani. Viszont számos dologban nem lesz olyan jó, mint a kevés magos Core. Pró-kontra elv.
3.) Az AMD megoldása is tud frekvenciát növelni és turbózni. A kettő között az a különbség, hogy az NV-nél a turbó máshogy valósul meg, és ezért eléggé lassú a reakcióidő, amíg azt beállítja. Ezt a rendszer binneli, tehát vannak előre konfigurált lépcsők az alapórajel fölött, amelyekre ugrándozik. Az AMD fordítva csinálja, mert például a mostani AVFS implementáció 1-100 MHz között bármekkorát tud ugrani, tehát nincs lépcsőzés, illetve 2 mikromásodpercenként szabad a váltás. Emiatt a működés miatt az AMD hardverén a turbó nem csak egy extra hatás, hanem egy állandó hatás. Tehát amikor az NV-nek a base órajelre már visszaállt a teljesítménye, az AMD megoldása még lehet, hogy a PowerTune maximumon tud maradni. Itt számít a hőtűrés is, mert például a GeForce a programindítástól számítva 5 percig tudja tartani a maximális teljesítményét. Utána valamennyit vissza fog lassulni (alkalmazástól/hardvertől függően 2-8% lehet), mert eléri a BIOS-ban konfigurált kritikus hőmérsékleti paramétert, ami a visszalassulási küszöb. A PowerTune esetében is volt ilyen tényező, amitől a lapkák a futtatási időben nagyjából 6-7 perc után elkezdet lassulni (ez is programfüggő volt, illetve hardverfüggő is, de általánosságban a mértéke 1-5% körüli). A mostani AVFS-sel viszont ez a tényező a PowerTune esetében már nem létezik. Stabilan tudja tartani az órajeleket a rendszer, nem csak az első nagyjából 10 percben. Ezért alkalmaz az AMD másfajta turbó jelölést, szó szerint a PowerTune órajelet.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27618
Abu85
HÁZIGAZDA
Petykemano
#27616
Abu85
HÁZIGAZDA
válasz
Petykemano
#27616
üzenetére
Az túl bonyolult, olyan sosem lesz. Mérnöki szemmel természetesen cél, hogy az elméletet súrolja a gyakorlat, de a komplex megoldásokra nehéz válaszolni hatékonyan. A fő cél, hogy maximalizálva legyen a gyakorlatban kihozható hatékonyság (tehát nem csak az első pár percben, nem csak a lapkák egy részére nagy varianciával, hanem úgy általánosan), nem pedig az, hogy elérjük az elméleti maximumot. Az AVFS-sel egyre közelebb lehet ehhez kerülni, de minél közelebb vagyunk, a maradék tempó annál költségesebben szedhető ki. Olyan az, mint az F1-ben. X autó az élmenőhöz képest van 4 másodpercre. 3 másodpercet könnyű találni, de a maradék 1 másodpercet már rohadt nehéz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27620
Abu85
HÁZIGAZDA
Petykemano
#27619
Abu85
HÁZIGAZDA
válasz
Petykemano
#27619
üzenetére
A technológiát simán beváltják csíkokra. Nem véletlenül terjedt el a Redditen az AMD FineWine dolog, hogy úgy öregszik, mint egy jó bor. De a dollárhoz más kell.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27667
Abu85
HÁZIGAZDA
Petykemano
#27663
Abu85
HÁZIGAZDA
válasz
Petykemano
#27663
üzenetére
Értem már, hogy miről beszélsz. Félreértettelek. Na de erre is van megoldás, ráadásul gyári. A PowerTune skálázható a felhasználó által. -50/+50 százalékos beállítás van az Overdrive menüben. Az AMD által megszabott 0% egy általuk ideálisnak tartott középút, amivel nem kötelező egyetérteni. Ha szerinted nem elég agresszív, akkor -50%-ig bármit beállíthatsz. Ha szerinted túl agresszív, akkor +50%-ig is elmehetsz. Ezt te döntheted el. Lehet, hogy nem tudsz még róla. Ezt az AMD azért adja a felhasználóknak, mert számos igény van a hatékonyságra vonatkozóan, és nem igazán lehet mindenkinek kedvezően dönteni, ezért inkább adnak egy széles skálát, amivel a felhasználó olyanra állítja a rendszer működését, amilyenre akarja. Az AMD default beállítása nem több egy színtiszta ajánlásnál, és a limit változtatása nem tuning, hanem gyárilag garantált beállítás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27670
Abu85
HÁZIGAZDA
Petykemano
#27668
Abu85
HÁZIGAZDA
válasz
Petykemano
#27668
üzenetére
Nagyon leegyszerűsítve a működését. A 0% az, amit az AMD úgy állít be, hogy ne fogyasszon túl sokat, de a feszültség is finoman ugráljon, hogy az órajel is csak picikét változzon. Ha lefelé viszed, akkor egyre agresszívebben fog a feszültség ugrani, és ez nagyobb órajelre vonatkozó váltásokat is eredményezhet. Ha feljebb viszed, akkor még finomabban ugrál a feszültség, és ez akár teljesen meg is szüntetheti az órajelre vonatkozó váltásokat, kvázi állandósul a PowerTune órajel.
Persze a nagyon gyári tuningos kártyák esetében picit másképp működik, mert ott a gyártók is nagyon kitolják az alaplimitet. Tehát ott már a 0% is szinte olyan, hogy tartja az órajelet, de ott is lehet menni mínuszba.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#27677
Abu85
HÁZIGAZDA
->Raizen<-
#27672
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#27672
üzenetére
Nem. A textúrák kezelése sosem lesz hardverfüggő. A Vega csak annyit hoz be, hogy nem a szoftver fogja vezérelni a streaminget, hanem maga a hardver. Így VGA számára emészthető formátumba kódolt, rendszermemóriába helyezett textúrákat nem egy szoftver rakosgatja majd a VRAM-ba, hanem a hardver. Amiatt nem kell egy rakás problémán átmennie a hardvernek, amikor az allokációkat kezeli.
Végeredményben ez annyit tesz, hogy hardveres menedzsmenttel a hardvernek nem kell a szoftverben lévő hibák miatt bűnhődnie. Maga a hardveres menedzsment hatékonysága simán hozható a mai megoldásokkal is, ha a fejlesztők hajlandók lennének minden egyes GPU-ra külön binárist fordítani. Konzolon simán elvannak 5 GB memóriával emiatt a lehetőség miatt. De PC-n nincs teljesen közvetlen hozzáférhetőség a memóriához se a CPU, se a GPU oldaláról. Ezért kell PC-n ugyanazt a problémát máshogy kezelni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
De az új fénypozícióval ez sokkal jobban van kezelve.
Ú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.
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Promenade Publishing House Kft.
Város: Budapest