Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#42694
üzenetére
Ez nem a leképezőn múlik. Attól függ az egész, hogy építenek-e be olyan játékmenetbeli elemet, ami igényel komolyabb szimulációt. Ha nem, akkor felesleges ezekre erőforrást pazarolni.
-
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42692
üzenetére
A memóriaigény 4K-ra van megadva. 1440p-ben csökken memóriaigény, így nem kell már 12 GB. Emellett a Primal update bevezet egy új textúramenedzsmentet. Ha nincs elég VRAM a VGA-n, akkor elkezdi dinamikusan csökkenteni a textúrák méretét, így nyerve extra kapacitást az RT shadow effektre, ami önmagában 3 GB körüli VRAM-igénnyel rendelkezik.
Az árnyékok jelentik a legnagyobb problémát, amit nem lehet RT nélkül megoldani. Minden más problémára van gyorsabb, hasonló minőséget adó alternatíva. Sőt, a Far Cry 6-ban az Ubisoft bevezet majd egy hibrid SSSR-t. Az lényegében az RT visszaverődés effektekhez hasonló minőséget ad, csak negyedannyi erőforrásigény mellett, töredék memóriahasználattal. Egyébként lehetne alkalmazni jó hatékonysággal RT-t az árnyékokon túl is, de egyszerűen nincs még traversal shader, amivel visszafogható lehetne a memóriahasználat. Utóbbi a legnagyobb probléma, mert ha nem tudod a LOD-ot megfelelően kezelni, akkor jobban jársz egy trükkös implementációval mondjuk a visszaverődésre, mert az RT-s megoldás csak a kamerához nagyon közel működhet kevés VRAM terheléssel. Az Ubisoft főleg emiatt a probléma miatt vetette el az RT reflectiont a Far Cry 6-nál. Elképesztően limitált a mostani API.A Flight Simulator is viszonylag jó. A legnagyobb problémája az, hogy elavult API-t használ, mert a motor alatta sok éves.
A The Coalition a Microsoft tulajdona, ezért fértek hozzá az Unreal Engine Microsoft által módosított változatához, ami jelentősen átírt ám, emiatt fut sokkal jobban, mint a gyári. -
Abu85
HÁZIGAZDA
Az AMD csak hozott pár jó döntést a múltban, és most úsznak az árral. Az NVIDIA is meghozhatta volna ugyanezeket a döntéseket, és ugyanúgy fordíthatnák az új pipeline-ra a régi shadereket.
Azért kevés cég optimalizál jobban PC-re, mint a Microsoft. Nem véletlenül fut elképesztően jól a Gears 5.
-
Abu85
HÁZIGAZDA
Ez mindig így volt, amíg egy új, de nagyon drágán hasznosítható technológiából csak a potenciális vásárlóbázis töredéke jut előnyhöz, addig nem is igazán piszkálják a fejlesztők. Vannak nagyobb gyorsulás biztosító, jóval olcsóbban beépíthető újítások. Ezeken lesz a fejlesztői fókusz. A VRS itt a fő irány mostanság. És már olyan formában is létezik, amihez nem kell VRS-t támogató hardver.
Szimplán compute shaderben le van implementálva. Az új Call of Duty ezt használja, és minden DirectX 12-es VGA-n megy.Szorgalmazni lehet, de ha nem fizetnek százezer dollárnyi zsetont a kód karbantartására, akkor senki sem fog veszteséget bevállalni egy gyártóért. Egyszerűen nem jön ki pozitívra a mérleg, és így nincs értelme erre dolgozni. Gondolod véletlenül maradtak ki a mesh shaderek a PC-s portokból? Nem. Egyszerűen kurva drága beépíteni és karbantartani. Gondolkodj egy fejlesztő szemével. Van egy büdzsé gyorsítani a kódon valami új technológiával. A mesh shaderre írt culling a mai geometriai komplexitás mellett nagyjából képes eredményezni úgy 2-3%-nyi gyorsulást. Ezért +50 ezer sor beírása és költséges karbantartása kell. Ezzel szemben mondjuk a VRS képes biztosítani 5-15% közötti gyorsulást. Az implementációs költség a már elérhető kódoknak hála minimális, sokszor csak copy-paste az egész, és a karbantartási költség sem magas. Nyilván azt választják, ami olcsóbb és nagyobb gyorsulást hoz.
-
Abu85
HÁZIGAZDA
Alapvetően az AMD-nek mindegy, hogy van-e mesh shader egy játékban vagy nincs. A legacy kódokat mindenképpen szállítani kell, és azokból tudnak NGG módba fordítani az 5700-asokra is. Az RDNA 2 pedig megeszi a mesh shadert.
A fejlesztők számára nem kell az AMD kímélete. El tudják dönteni, hogy belefér-e +50 ezer sornyi kódot írni, és ezt folyamatosan karbantartani a vásárlóbázis maximum 10%-ára. Nyilván az AMD is átgondolta ezt a kérdést, és arra jutottak, hogy a magas költségeket figyelembe véve nem éri meg. Nem véletlenül tervezték úgy az RDNA2-t, hogy majdnem minden vertex és geometry shadert NGG-be fordítson a fordító. Ugyanígy gondolhatott volna erre az NVIDIA is. Egyébként létezik mesh shadert használó játék már. A Gears 5 Xbox Series S/X frissítése erre épít. Megvan írva a teljes kód, és azt se hozza át a Microsoft PC-re, mert jelentős többletköltsége lenne a support oldalán. Egyszerűen a vásárlókból nem termelik ki. Ehelyett olyan megoldásokat portolnak vissza PC-re, mint az új VRS. Az legalább a support költséget nem növeli jelentősen, és abból is lehet nyerni egy rakás teljesítményt. Talán többet is, mint a mesh shaderből, miközben a költségek szintjén olcsóbb. Persze a Microsoft igazán kinyithatná a pénztárcát a mesh shaderre, hiszen nagyságrendekkel nagyobb anyagi tartalékaik vannak, mint bárki másnak, de osztottak-szoroztak, és egyszerűen nem éri meg, még úgy sem, hogy a portolás copy-paste lenne.
A mesh shader akkor kezd majd igazán terjedni, amikor a vásárlóbázis 60%-a is el tudja majd érni. Addig igazából pénzkidobás fejlesztői szemmel. Nekem sem tetszik, de ez van. Némelyik fícsőr beépítése olcsó (például VRS), némelyiké pedig költséges.
-
Abu85
HÁZIGAZDA
válasz
atok666
#42682
üzenetére
Az UL megkérhette őket, hogy ennek a tesztnek a shadereit ne fordítsák a mesh/primitive pipeline-ba. Ez a 3DMark szempontjából fontos. Az AMD-nek ez nem sok munka, mert ki tudnak jelölni a meghajtóban egy programot, aminek az indítását detektálják, és annak egyes shadereit legacy futószalagra fordítják. Akinek ezzel sok dolga lesz az az UL, hiszen az AMD meghajtójára így muszáj engedni az "alkalmazásspecifikus optimalizálást", és ha köcsög az AMD, akkor elkezdik lecserélni a 3DMark többi shadereit is, ezzel nyerve 2-3 ezer pontocskát per kártya. Ezt majd az UL-nek folyamatosan ellenőriznie kell.
#42684 b. : Az AMD-nek jók mesh shaderrel és anélkül is a portok. Úgy van felépítve a hardverük és a fordítójuk, hogy minden esetben az NGG módban fut a program. Ha most egy fejlesztő a vertex/geometry shaderek mellé akar írni mesh shadereket is, akkor csak nyugodtan. A stúdióknak és kiadóknak fog jelentősen nőni a játékra levetített support költség nem az AMD-nek.Egyébként a legnagyobb gond, nem az, hogy nem tudsz mesh shadert írni, hanem, hogy az átállás nagyon drága. Egyrészt minden geometriára vonatkozó shadert kétszer kell megírni. Egy komplex játéknál az simán +50 ezer sor. Másrészt mindkét kódbázist szállítani kell, mert a legacy kártyákat támogatni kell. Az tesztelés szintjén dupla munka, ami végeredményben megduplázza a support költséget. Szóval ez nem egy olyan döntés, amit egyszerű meghozni. Ha nincs meg az anyagi háttér a mesh shaderhez, akkor nincs értelme beépíteni.
-
Abu85
HÁZIGAZDA
Ezt valószínűleg az UL kérte, mert nem tudják befolyásolni a meghajtó működését, így a megfelelő százalékos gyorsulás kiértékeléséhez mindenképpen szükség van arra, hogy az AMD nem fordítsa a vertex/geomatry shadereket a mesh/primiive pipeline-ba. Ha megteszik, akkor a Radeonra nem tudja megmondani a tesztprogram a gyorsulás mértékét. Most, hogy kikapcsolták, meg tudja majd mondani. Nem kritikus fontosságú, de az UL számára fontos, mert ők képtelenek megkerülni a fordító működését. Csak az AMD tehet azért, hogy ez a teszt megfelelő értékeket adjon vissza a százalékos gyorsulásban. Az AMD ezt rohadtul leszarná, hiszen nekik aztán teljesen mindegy, hogy hány százalékot ír egy szintetikus teszt. Nekik a review policy-jük, hogy szintetikus teszteket senki se használjon. De nyilván meg tudják érteni, hogy az UL-nek ez bassza a csőrét, hiszen dolgoztak a programon, így átdolgozták a meghajtót, csak közben ez azért egy nehéz kérdés, mert az UL tiltja a 3DMark felismerését, tehát az AMD-t az egyik legfőbb szabály alól kellett felmenteni. Ez veszélyes az UL-nek, hiszen így az AMD-nek szabad a 3DMark felismerése, és manipulálhatják az alkalmazás futtatását, amit innentől folyamatosan ellenőriznie kell a finneknek, minden egyes kiadott Radeon driver után. Nekik sem lesz túl jó az élet innentől, havi két driverrel számolva, igencsak sok dolguk lesz.
-
Abu85
HÁZIGAZDA
Na jó hír a mesh shader tesztre vonatkozóan. Az AMD és az UL megegyezett, így a 21.2.2-es meghajtó már letiltja az NGG módba való shader fordítást. Ezzel már valóban lehet mérni az előrelépést, illetve mesh shadert is másképp fordítja a fordító. Sajnos még nincs hivatalos eredmény, de az UL egy szimpla 6800-ra 1600%-ot mért.
Némi torzítás még, hogy az intelligent workload distributor nem letiltható. Enélkül az AMD hardvere már nem működik, vagyis az NGG módból csak a shader fordítás kontrollálható, a feladatkiosztás mindenképpen az új generációs futószalagon megy a hardveren belül, mert a régi futószalag konkrétan ki lett véve a lapkából. Elméletileg ez csak kismértékben torzít.
-
Abu85
HÁZIGAZDA
A Radeon RX 6000 eleve NGG módba fordít. Nem lehet rajta megnézni, hogy mit tudna legacy pipeline-nal. Ezzel a 3DMark sem tud mit kezdeni. Lehet, hogy az AMD a legacy pipeline-t már teljesen leépítette a hardverben, így nem is tud működni hatékonyan az RDNA 2 a régi futószalagon. Erről elég kevés az adat, de valamiért a meghajtó fordítója a vertex és geometry shadereket is mesh/primitive pipeline-ba fordítja. Ezt a múltkor láttam az RGP-ben. Az AC Valhallában egyszerűen egyetlen vertex és geometry shadert nem fordít vertex és geometry futószalagra az RDNA2 fordítója. Mindegyiket átkonvertálja a driver mesh/primitive-be. És azok elég komplex shaderek, nem olyan egyszerűek, mint a 3DMarké ami szintetikus terhelésre van tervezve.
Ahhoz, hogy lássuk a százalékos gyorsulást az AMD-nek ki kell kapcsolnia az NGG módot a driverből. De nem fogják megtenni, a program pedig nem döntheti el, hogy hova fordít a meghajtó. -
Abu85
HÁZIGAZDA
válasz
imi123
#42664
üzenetére
Nem igazán maradt. Az UL már elmondta, hogy a százalékos érték a fontos, mert ez egy szintetikus teszt. A nyers fps semmit sem jelent önmagában, de számol a teszt egy százalékos adatot, hogy mennyit gyorsít a mesh shader. Persze az RDNA2 esetében ez is torz, leírtam a cikkben, hogy miért.
Az fps-t azért felesleges nézni, mert aszerint a GeForce GTX 1660 Ti megveri az RTX 3090-et. Közben a játékokban nem ezt látod. De ez egy szintetikus teszt, úgy lett felépítve, hogy a gyorsulást mutassa meg.
-
Abu85
HÁZIGAZDA
Ezerszer le lett írva, hogy a Steam survey egy nem reprezentatív statisztika. Semmiféle statisztikai módszertan alapján nincs kezelve. Oda van hányva egy csomó adat, amelyek már rég annyira tele vannak szemetelve, hogy használhatatlanok. A Valve-ot igazából nem érdekli, hogy ezt javítsa.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#42543
üzenetére
Azok korábban jelentek meg. A gyártásukat még nyáron kellett fixálni. A 3060 gyártását decemberben fixálták, akkor már teljesen más volt a piac, mint a nyár közepén. Ennek megfelelően alakult a memória is. Az NV rendelhet ehhez is 1 GB-os GDDR6-ot, de egyrészt kevesebb van mennyiségben, vagyis hiányuk lesz, másrészt a 2 GB-os lapka alapvetően nem drágább, és van belőle bőven.
#42542 huskydog17 : Egyrészt a mobil 3080 az közelebb van az asztali 3070-hez a kiépítésben, mert GA104-es lapkát használ, másrészt a fogyasztása a normál mobil verziónak 150 watt.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#42536
üzenetére
Nem pofájuk nem volt, hanem memória nincs hozzá elég. A GDDR6-nál a 2 GB-os stackekre nőtt meg az érdeklődés, és emiatt az 1 GB-os stackek gyártását gyakorlatilag visszafogta mindenki. Ez annyira durván megmutatkozik, hogy a 2 GB-os stack alig drágább, mint az 1 GB-os, ezért rendeli most mindenki azt. Majdnem ugyanolyan áron mennek, és 2 GB-os stackből még van elég is, míg az 1 GB-os stack ellátása limitált. Jelenleg ha akarnak se tudnak 6 GB-os verziót csinálni.
-
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#42511
üzenetére
Nem nézték be, csak nincs natív libGNM implementáció PS5-ön, és ezek a játékok azon futnak. A libGNM-re írt kódot a PS5 egy wrapperen keresztül futtatja az új API-ján. Nyilván ennek nem valami jó a hatásfoka, de annyi nyers erő van a gépben, hogy könnyen elfedi a szoftveres rétegezésből eredő rosszabb hatékonyságot. Ha nyers teljesítmény kell, akkor át kell portolni a játékot a libGNM-ről.
Emiatt nincs egyébként PS5-ön ray tracing a Dirt 5-ben. A port igazából nem a natív API-ra van írva. A legnagyobb gond szerintem az, hogy az új API nem támogat legacy geometry pipeline-t. Tehát abban csak primitive shader van és kész. Ez még nem a világvége, de nem lehet minden vertex és geometry shadert csak úgy primitive shaderbe fordítani. Ez egyébként nagyon sokat ér, meg lehet nézni, hogy mit kihozott a Microsoft a Gears 5 natív Xbox Series S/X portjából. Ott elég rendesen használták a mesh shadert. Emiatt nem hozzák le ezt a portot PC-re, mert itt ugye két külön programkód is kellene. Egy a régi pipeline-ra és egy az újra. Az meg dupla support költség.
-
Abu85
HÁZIGAZDA
Kell a VRAM, csak nincs elég nagy kapacitású GDDR6X, hogy olcsón lehessen sok VRAM-ot rakni a VGA-ra. Ha csak 1 GB-os lapkákat gyárt a Micron, akkor verheti az NV az asztalt 2 GB-os variánsért, akkor sem tud adni a beszállító. Egyszerűen nem létezik még a kívánt termék.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#42435
üzenetére
Az AMD is átírhatja a Quake 2 kódját, ahogy az NV tette. Az eredeti kód openszósz. Erről régebben kérdeztem őket, és RT-vel nagyjából annyi hozható ki, amit a Quake 2 RTX kihoz, de ennek a minősége elmarad a többi Quake 2 grafikai mód mögött. Például a Bersekerhez viszonyítva elég sok a különbség: [link]
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#42427
üzenetére
Többeknek van már itt a fórumon. Ha megfizeted az árat, akkor mindkét gyártó VGA-it be lehet szerezni, de olyan drágák, hogy sokan nem fizetik meg. Megjegyzem nagyon helyesen teszik.
-
Abu85
HÁZIGAZDA
Az Ethereum 2.0 nem fog majd igazán jól futni GPU-n. De mire kivezetik a PoW rendszert, addig még eltelik három év, ameddig az Etheriumon lehet keményen bányászni egy GPU-val is. Emiatt ugranak egyre többen rá, mert most még van benne GPU-val kinyerhető pénz. Majd amikor csak PoS blokkok lesznek, akkor vége lehet a GPU-s bányászatnak Ethereumon, de ez 2023 előtt tuti nem jön el. Akkor majd keresni kell egy új kriptovalutát.
-
Abu85
HÁZIGAZDA
Így pedig Kína mondhatja, hogy ők tisztán játszanak, hiszen a több kínai vezető mást akar. Mennyire kár, hogy Wu hatalma jelenleg túl nagy, és Hszi Csin-ping ezt biztos elképesztően sajnálja is...

Ha Kínának Wu tényleg annyira nagy probléma lenne, már rég eltávolították volna. Gondolod pont egy ilyen illiberális államban nem tudnak piszkos eszközökhöz nyúlni? A valóság az, hogy Kínának nagyon is tetszik az a káosz, amit Wu teremt, mert egy olyan üzletet hátráltatnak vele, ami az országnak rossz. A megegyezés csúszásával viszont fel lehet készülni a későbbiekre. -
Abu85
HÁZIGAZDA
Amit nem fog megkapni, mert az brutálisan sok, vagyis végeredményben teljesíti azt a szerepet, amit rábíztak, hátráltatja az üzlet létrejöttét, amíg a kínai projekteket leszedik az ARM-ról.

Idővel majd el fog fogadni egy ajánlatot, és amikor megy ki az ajtón, akkor visszafordul, hogy sajnálja, hogy Kína otthagyja az ARM-ot. Ez politika már, érdekek és érdekellentétek.
-
Abu85
HÁZIGAZDA
A DLSS-t alapvetően készre kapják, tehát azért aligha hibáztatható az Ubi, de a játék többi elemében vastagon benne vannak. Márpedig vannak nem kis problémák a PC-s porttal. Gondolom a DLSS a legkisebb, azért felmarkolták a pénzt, és szarnak bele.
-
Abu85
HÁZIGAZDA
válasz
nkaresz1976
#42045
üzenetére
Kevert. Némelyik ultra, némelyik afölötti, némelyik high vagy medium.
-
Abu85
HÁZIGAZDA
válasz
GodGamer5
#42034
üzenetére
Nem akarok elkeseríteni senkit, de a next-gen címek ilyen processzorigénnyel rendelkeznek. Leginkább hat maggal érdemes belevágni. Ez van. A konzolban van erős nyolcmagos, és nyilván nem fogják lebutítani a minőséget a PC-s portra, bizonyos elemek nem skálázhatók. Egyszerűbb lenne a helyzet, ha a PC-s port az Xbox One verzióból jött volna, akkor sokkal jobban futna a gyengébb CPU-kon, de úgy meg az lenne a baj, hogy sokkal rondább, mint az új generációs verzió.
A VRAM-ból sem elégszik meg kevéssel. Max részletességhez dobni kell alá 12 GB-ot legalább.Ray tracing is lesz benne, csak az újságírói verzió egy nagyon régi kód.
-
Abu85
HÁZIGAZDA
válasz
gainwardgs
#41973
üzenetére
Kettéhúgyozza (2 fps), agyonveri (1 fps), majd még egyszer kettéhúgyozza (2 fps).
-
Abu85
HÁZIGAZDA
Nem céloz olyan piacokat, mint a konkurensek, ahol nagyon zsíros haszonnal lehet lapkákat eladni, ráadásul tömeges mennyiségben. Alapesetben az AMD sem tudná ezt, ezért vitték el a GPU-k gyártását régen a GlobalFoundries-hez, viszont mivel a TSMC-hez vitték a CPU-k gyártását, így már könnyen túl tudnak licitálni akárkit. De ha csak GPU-kat gyártanának a TSMC-nél, akkor ugyanúgy tennének, mint az NV, keresnék a Samsung kegyeit, mert a GPU-k piaca messze nem akkora, mint a CPU-ké, és olyan orbitális hasznot sem tudnak rácsapni, mint a CPU-kra.
Alapvetően ez a licit nem termékekre vonatkozik, hanem waferekre. Az AMD-nek nem különösebb gond, ha drága a wafer, mert lehet, hogy a GPU-kon nem keresnek, vagy akár buknak is egy picit, de a CPU-kkal együtt bőven pluszban van a waferszinten leadott rendelés. Az NV-nek ez nagy gond, mert nincsenek CPU-ik, amik pozitívba tolják a waferekre leadott rendeléseiket, tehát nekik olyan megoldás kell, ami a GPU-kkal is nyereséget termel. Ez a TSMC üzleti modellje mellett baromira nehéz. Pár rohadtul minőségi piacot célzó cég úgyis rád fog licitálni, amit esélyed sincs tartani, mert gondolni kell arra, hogy nyereséget kell majd termelni. Az AMD-nek sem lenne ugyanúgy semmi esélye, ha nem gyártanának CPU-kat is.
-
Abu85
HÁZIGAZDA
Írni lehet erről, de a TSMC szempontjából miért is adná olcsóbban a wafert, ha eladja normál áron is. Attól, hogy a DigiTimes ír valamit még nem jelent semmit. A DigiTimes azt is állította már, hogy a Zen 3 5 nm-en jön, aztán látjuk, hogy rohadtul nem. De anno le is írtam, hogy miért volt faszság, amit írtak. [link]
A probléma az, hogy média nem tudja elképzelni, hogy a Samsung jót tud gyártani. Pedig igazából a 8 nm egy proven technology. Nem új dolog, évek óta hibátlanul gyártanak rajta vagy a korábbi verzióján a cégek. De ami ennél is durvább, hogy sokan azt hiszik, hogy 7 nm-re könnyű átugrani. Ahogy a DigiTimes azt hitte, hogy 5 nm-re ugrani csak egy döntés, de nagyon nem, bizonyos node-ok nem kompatibilisek egymással, és az áttervezés ideje másfél-két év.
Az NV-nek nem feltétlenül a waferár a gondja a TSMC-nél, hanem az, hogy ha például ma eldöntik, hogy átmennek, akkor abból 2022 első negyedévében lesz termék. Ezt már innen nem viszik sehova. Az ilyen problémákat hagyni kell a fenében, és át kell ugrani azt. El kell vonni az erőforrást a fejlesztéstől, majd koncentrálni a következő generációra.
-
Abu85
HÁZIGAZDA
Minek reflektáljon rá a Samsung? Nagyon régóta működik a 8 nm-es eljárásuk. Az NV előtt sok cég csinált már rá több tucat lapkát, mindet probléma nélkül. A half-node-okkal sosincs igazán baj, mert az mindig egy továbbfejlesztése egy már évek óta tökéletesen működő node-nak, jelen esetben a 10 nm-es eljárásnak.
Akit érdekel a 8 nm, az tud kérni a Samsungtól jelentést, hogy mire képes, és az ezerszer több adatot jelent számukra, mint a pletykacikkek. Az alapján fogják eldönteni, hogy ez az ideális választás-e számukra. Az NV is így csinálta. Kértek jelentést a TSMC-től és a Samsungtől az elérhető gyártástechnológiákra. Ezeket a bérgyártók megadják, természetesen a többi partner adatainak a védelme mellett.A 7 nm-es TSMC node-ra való áttérés lehetséges, de a Samsung és a TSMC gyártástechnológiai nem kompatibilisek, tehát ez nem olyan, hogy akkor eldöntöm, hogy inkább a TSMC, mert előbb át kell tervezni a dizájnt, hogy ott is gyártható legyen. Az NV ezt vállalhatja, de ha ezt eldöntik egyszer, akkor onnan másfél év legalább, hogy tömeggyártható lapkák szülessenek. Tehát, ha még csak most gondolkodnak egy ilyen váltáson, akkor az Ampere refresh az kb. egy 2021Q1-es történet lesz. Jóval hamarabb kellett erről dönteni, ha egy refresht akarnak csinálni 2020-ban.
#41781 b. : De a Samsung nem onnan szerez vevőket, akik a pletykalapokat olvassák. Ha van érdeklődő, akkor ők direkt felkeresik a céget, és kikérik az adatokat az adott node-ra.
A TSMC senkinek sem ad kedvezményt. Lehet licitálni a gyártókapacitásra és kész. Akinek nem tetszik, az várhat a következő licitekre. A TSMC-nek mindegy, a pénzüknél vannak mindenképpen maximum nem az NV-nek gyártanak, hanem a Qualcomm, Apple, AMD, Xilinx, akárkinek. De ha ez a rendszer nem jó, akkor lehet menni máshova, de kedvezmény itt sosincs. Ellenben mindenkinek van esélye waferhez jutni, csak túl kell licitálnia a többieket. Az NV elsődlegesen azért keresi a Samsung kegyeit, mert az említett cégekkel szemben nem túl könnyű waferekhez jutni, ha a Xilinx nem is feltétlenül, de az Apple, AMD, Qualcomm simán túllicitálja őket, és akkor még jön az Intel is a TSMC node-jaira. Ők is olyan piacokat céloznak, amiből okádni tudják a pénzt a TSMC-nek.
Arról nem is beszélve, hogy a TSMC nem különösebben érdekelt abban, hogy specifikus node-okat tervezzen egy olyan megrendelőjének, aki messze nem a legnagyobb. Ellenben a Samsung megcsinálj. Az NV is egy rájuk tervezett 8 nm-es variánst használ. -
Abu85
HÁZIGAZDA
GDDR6X. Ez a gondja a 3080-nak és 3090-nek. A GDDR6-tal a 3070-ből több lesz, de azt meg az OEM-ek is nagy mennyiségben rendelik, mert sok gépbe a 3080 és a 3090 nem jó. Túl nagyok és túl sokat fogyasztanak. A 3070 viszont elég sok konfigurációba beépíthető, így ebből nagyon bevásárolnak éppen. Itt gondolni kellett volna arra az NV-nek, hogy az OEM-eknek nem adják ki a 3070-et, és akkor lenne belőle bőven elég dobozos. De mennyiségileg ebből tényleg nagyon sokat gyártanak, bőven a tízszeresét a 3080-3090-nek, csak az OEM-ek, meg kb. ennek is a sokszorosát rendelik, hiszen kő a hardver a karácsonyi szezonra.
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#41758
üzenetére
Az Ubisoft már előre gondolkodik. Lesz egy rakás platform, ami támogatni fog raytracinget. Arra ki kell alakítani egy olyan környezetet, amiben mindent le tudnak fedni a legkisebb munkával. Egyelőre itt a Radeon Rays 4.0 az a rendszer, ami hosszabb távon megoldja ezt, mert támogatni fogja majd a Stadiát, támogatja a két új konzolt, támogatja a PC-s Radeonokat, és generál majd fallback kódot szabványos DXR-re. Tehát egyszer írsz raytracing támogatást, és lefedsz vele mindent, amit alapvetően le lehet fedni. Ha nem erre mennének, akkor kellene szabványos PC-s/Stadia kód, egy külön kód az új Xbox-ra, és egy harmadik az új PS-re. Az eredmény majdnem ugyanaz, csak a befektetett munka háromszoros.
Na most ezeket ki kell kísérletezni, és például tökéletes alany itt egy játék. Arra megnézik, hogy miképp működik a rendszer, esetleg hoznak bele egy-két effektet, amikor úgy látják, hogy jó, így kipróbálják élesben is. Ezért érdemes számukra most a DX12-n maradni. A Radeon Rays 4.0 egyelőre alkalmas arra, hogy a DXR intrinsics módot bevessék. Később lesz Vulkánra is ilyen, sőt, a Vulkan API-ra még az egyedi bejárásra vonatkozó Radeon Rays 4.0 mód is átmenthető, mert a DirectX 12-vel ellentétben a Vulkan támogatja a programozható bejárást, amit a processzormagok minden PC-n el tudnak majd végezni, nem számít, ha a GPU nem támogat programozhatóságot erre vonatkozóan. Ebből a szempontból a Vulkan egy komplettebb rendszer, ami figyelembe veszi, hogy ma már azért bőven vannak 16-64 magos CPU-k PC-n, amik nem kicsit tempósak. Ezekben olyan erő van, hogy ki tud váltani egy komplett fixfunkciós hardvert is a programozható bejárást nem támogatók GPU-kon belülről. Mire erre készítenek majd szoftvereket, addigra már 128 magnál is járhatunk asztali szinten. Nem véletlen, hogy ez bekerült a Vulkan API-ba, figyelembe vették a szabványalkotók, hogy az elkövetkező években komoly "magrobbanás" lesz.
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#41756
üzenetére
Támogatja a Vulkan API-t is, hiszen az kell a Stadiának, de a DirectX 12 lesz szállítva a PC-s verzióban.
Ezek a döntések az AMD miatt vannak, mert a Radeon Rays 4.0 még nem támogatja a Vulkan API-t, tehát a kísérletezéseket DirectX 12-n kell végezni. Így viszont a DirectX 12 az elsődleges API. Kettő API-t pedig felesleges szállítani, mert csak a karbantartási költségeket növelné.
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#41752
üzenetére
Csak ebből hibás következtetést fognak levonni. A DirectX 12 alapvetően ugyanolyan gyors API, mint a Vulkan, és itt is elérné a teljesítményét, ha szálszinten párhuzamos shader kódokat kapna.
A Stadia csak Vulkan API-t támogat, nyilván az az elsődleges opció.
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#41749
üzenetére
De az fontos, hogy azért nyer a Vulkan, mert ott subgroupokat is használnak. A DirectX 11 és 12 esetében elavult shader kódok futnak, amik nem használják a wave terminológiát. Persze, hogy a wave terminológiát használó kódok sokkal gyorsabbak a Vulkan alatt, hiszen nem mindegy, hogy a feldolgozás szálszinten soros vagy szálszinten párhuzamos. Óriási hátrány ám a DirectX 11/12-nek, hogy szálszinten soros feldolgozásra van kényszerítve (pedig a DirectX 12 támogat wave intrinsics-et). Így nem lehet hozzámérni az API-kat a Vulkan eredményekhez, mert már a shaderek szintjén ki van végezve a teljesítmény.
Az a baj, hogy Stadiára írt GLSL shadereket nem lehet ám egyszerűen visszaportolni másra. Ezért sem most érkezik a PlayStation 4 és az Xbox One port. Előbb vissza kell portolni a shadereket modern HLSL-be/PSSL-be. Így csalóka azért, mert az előny, amit a Vulkan ad nem azért van, mert maga a Vulkan API ennyivel gyorsabb.
-
Abu85
HÁZIGAZDA
Az IBM magjai lényegesen erősebbek az ARM és az Intel/AMD magjainál. És a rendszerük teljesítménye is nagyon magas. Olyannyira, hogy nem igazán tudja őket közelíteni az ARM vagy az AMD/Intel. A probléma leginkább az, hogy nem x86/AMD64 az ISA.
1. Az Intelnél ezt bárki később tudja szállítani, még az AMD is. Hiába tud a Cray adni egy másfajta rendszert. A leggyorsabban akkor van meg az Aurora, ha az Intel szállít nekik TSMC-nél gyártott gyorsítót. Mindenki más csak lassabban tudja összerakni a rendszert.
2. Ez a projekt már eleve csúszik. Évek óta kész kellene lennie, csak az Intel törölte a Xeon Phit.

3. Az 3 év legalább. Ha csak a pénzen múlna, akkor már megkérték volna, de a chiptervezés problémája az idő. Ráadásul mire raknak CXL-t az A100-ba, addigra ez a lapka rég elavul, és sokkal újabb rendszerek lesznek kész. Ez nem olyan dolog, hogy kell a funkció, és az NV megoldja fél év alatt. Le kell ülni a tervezőasztalhoz, és egy csomó mindent ki kell cserélni a dizájnban, ami kb. egy év meló, majd két év mire azt tömeggyártásra alkalmassá teszik.
Az, hogy Addison Snell mit szeretne az irreleváns. A DOE meg azt szeretné, ha az Aurora 2022-ben működne, és azt csak az Intel tudja biztosítani. Minden más lehetőség további csúszás. Az AMD ezt nem fogja tudni vállalni 2023 előtt, az NVIDIA pedig 2025 előtt.
Mondjuk a top Ponte Vecchio eleve 40 TFLOPS-ra lő, tehát ha abból 30-35 jön össze, akkor az is elég jó még. Ráadásul az Aurora konfigurációja az 6 GPU-s, tehát 50 TFLOPS-ot egy szerver node TSMC-vel is tudni fog. Az AMD-nek a CDNA-ja 40 TFLOPS körüli. FP64 ezeknek a számoknak a fele. Az NVIDIA nem tudni, hogy hoz-e valamit az A100 mellé, mert az általános számításban nem valami erős, csupán 19,5/9,75 TFLOPS-ot tudnak vele FP32/64-ben.
-
Abu85
HÁZIGAZDA
Az Aurora nem tud módosulni. Az Exascale rendszereknél nagy problémát jelent, ha nem koherens interfésszel vannak bekötve a gyorsítók. Egyszerűen túl nehéz ilyen szintre skálázni egy konfigurációt. Tehát marad az Intel gyorsítója, csak nem az Intel fogja gyártani hozzá a Compute Tile-t, hanem a TSMC. Ennyi lesz a változás. Ez valószínűleg kisebb teljesítményt jelent majd, így az Intelnek el kell döntenie, hogy több hardvert szállít-e, vagy azt csinálják, hogy marad a tervezett rendszer, és idővel ingyen kicserélik a gyorsítókat nagyobb teljesítményűre.
AMD-re, NV-re, akármire nem lehet váltani. Egyrészt azzal dobni kellene a host rendszert. Tud ugyan másik memóriakoherens platformot kínálni a Cray, de akkor nem teljesül a CORAL-2 program követelménye, tehát AMD-re nem tudnak átállni. NV-vel pedig a tervezett teljesítmény töredéke jönne össze csak. -
Abu85
HÁZIGAZDA
válasz
Petykemano
#41701
üzenetére
A fogyasztást a mai hardvereknél eleve a fogyasztási limit befolyásolja. Ha befogásra kerülnek a nem használt részegységek, attól a fogyasztási limit nem változik, maximum nem x MHz-es tartományban lesz az órajel, hanem x-200 MHz-esben.
-
Abu85
HÁZIGAZDA
válasz
Petykemano
#41690
üzenetére
Az 580-on és az 590-en eltérő lapkák vannak. Előbbin Polaris 20, utóbbin Polaris 30. A Polaris 30 nem is 14 nm-es node-on készül. Természetes, hogy két teljesen különböző lapka ebben eltér.
-
Abu85
HÁZIGAZDA
Olyan nincs, hogy 98%-os terhelés. Az maximum azt jelenti, hogy a parancsmotor a 100 ciklusból 98-ban beolvas valamilyen parancsot. De belül azt nem úgy dolgozza ám fel. A GPU-n erősen heterogén processzorok, tehát nagyon sok az üresjárat bennük, és ezeket afterburner nem fogja megmutatni. Érdemes inkább megnézni egy profilozóval, ott azért közel sem az látszik, hogy 98%-os a terhelés. Jó ha 50% megvan.
Minden dizájnnak van egy optimális hatékonysága, ahol arányaiban a legnagyobb teljesítményt adja le a fogyasztáshoz viszonyítva. Ezek gyártói döntések, hogy hogyan állítják be.
Például az AMD ezzel azért nem törődik annyira, mert ma már teljesítménytartományt szállítanak a Radeonokban. Van egy közepesre állított szint, amiből a power limit beállítással elérhető a legnagyobb hatékonyság és a legnagyobb teljesítmény is. A felhasználó egy -50 és +50 százalék közötti csuszkával kiválaszthatja, hogy mit akar. Általában -10-20% között van az optimális hatékonysági szint, de ez termékfüggő, valamelyiknél 12%, valamelyiknél 18%. Ezt azért vezette be az AMD, mert ezernyi igény létezik, és ezt csak teljesítménytartomány felkínálásával fedhetik le. Mindenki beállíthatja azt, amit magának akar.Az NVIDIA ezt még nem vezette be, de az Ampere már tett lépéseket felé, tehát később valószínűleg ők is bevezetik ezt a tartományos modellt, csak ahhoz még szükségük van arra, hogy gyorsabban váltson az órajellépcsők között a dizájn. Valószínűleg a következő körben elérik. Az Ampere annyiban előrelépés, hogy teljesen hardveres lett az órajel- és feszültségmenedzsment, tehát már nincs benne szoftveres tényező.
A gyártástechnológiát könnyű hibáztatni, de az esetek nagy részében nem ott van a gond.
Az undervolt azért nem ajánlott, mert a gyártók a beállításokat nem a programokra nézik, hanem egy szimulációra. Ez a szimuláció bekapcsol minden részegységet a lapkában, tehát egy eléggé worst case mérés. Egy játékban azért működik az undervolt, mert a legtöbb játék közel sem túráztatja a GPU-ban található összes részegységet. Egy adott pillanatban jó ha a teljes lapka 50%-a be van fogva. De ugye jöhet egy olyan feldolgozás, ahol be lesz fogva a 80%-a is, és akkor bizony az undervolt megadja magát, mert ahhoz az a feszültség kellene, amit a gyártók beállítottak, csak a felhasználó nem engedi elérni.
Ez ellen egyébként a Navi már védekezik. Ha túl kevés a feszültség, akkor nem fagy bele a munkába a GPU, hanem indít a rendszer egy fail-safe módot, ami azt jelenti, hogy a GPU az órajelet levágja 500 MHz körülire. Ezért van az, hogy ha valaki undervoltol egy Navit, akkor nő a mikroakadások száma, mert már nem fagy bele az alacsony feszültségbe a rendszer, de harmadolja a teljesítményt arra az időre, amíg a feszültséget alacsonynak tartja. -
Abu85
HÁZIGAZDA
válasz
Petykemano
#41686
üzenetére
Minden VGA-t alul tudsz feszelni, csak kérdés, hogy az az alulfeszelt eredmény átmegy-e a GPU-ra írt terhelésszimuláción. Nem véletlen van az a feszültség oda állítva, ahova. Ha egy GPU-t nagyjából 40-50%-osan terhelő játék lenne a mérce, akkor persze lehetnek alacsonyabb feszültséget alkalmazni, csak bajban lenne a termék, ha szembejön mondjuk a Strange Brigade, ami azért 60-70%-osan is leterheli a GPU-kat.
-
Abu85
HÁZIGAZDA
válasz
Petykemano
#41684
üzenetére
Mert 16 nm-en jött be FinFET, és elsőre marhára jól kezelhető volt. A gondok 10 nm-en kezdődtek vele. Majd a GAAFET is kezelhető lesz 3/2 nm-et. Aztán 1 nm-en már lehetnek vele problémák.
Az AMD is nagyon jól eltalálta a 14 nm-t. Ha nem találták volna el jól, akkor a Vega 20 jobban elhúzott volna már elsőre.
Ebben érzem, hogy mindenki a bérgyártót akarja belelátni, de nem sok közük van ehhez. Tapasztalat, tapasztalat, tapasztalat. Ez a három dolog kell a modern node-okhoz.
-
Abu85
HÁZIGAZDA
válasz
Petykemano
#41681
üzenetére
Ha megnézed az A100-at, ami a TSMC-nél készül, az se hatékonyabb ám. Sőt, FP32 számítási kapacitásban alatta van a GA102-nek, miközben fogyasztásban felette. A probléma nem igazán a gyártástechnológia, hanem az, hogy az NV akkor a 12 nm-t ismerte, mert a 16 nm half-node-ja volt, míg most a 7 és 8 nm-t nem ismerik, nem is vihették át a dizájnkönyvtáraikat rá, most van velük először dolguk. Ez nem igazán a bérgyártó mondjuk úgy felelőssége, a FinFET tényleg nehezen kezelhető alacsony csíkszélességen, és ki kell azt tapasztalni.
Ugyanezt rá lehetne húzni a Vega 20-ra is, ami 7 nm-en jött. Annál is hasonló lett volna a grafikon a Vega 10-hez viszonyítva. Aztán látod, hogy hova jutottak a Renoirral.
-
Abu85
HÁZIGAZDA
válasz
Petykemano
#41669
üzenetére
Persze. A mostani helyzetnek már lőttek. Mire megoldják rég a második 5 nm-es lapkáját hozza az AMD, és akkor ugyanott lesznek, mint ma. Ezt a problémát át kell ugraniuk. Nem is azt mondom, hogy a TSMC-nél, mert náluk azért nagy a licit az 5 nm-re. Mehetnek a Samsunghoz is. Csak legyenek ott a kezdésnél, mert akkor a második körben nem kerülnek hátrányba.
Jövőre az AMD csak szerverbe hozza a Zen 4-et. Amikor ebből lesz desktop, akkor bőven lesz új verzió, ha kell. Bele van tehát már tervezve, hogy a Zen 4-nek esetleg problémái lesznek 5 nm-en. Ha nem, akkor az még jobb, nem kell az új revízió.
-
Abu85
HÁZIGAZDA
válasz
Petykemano
#41667
üzenetére
Eleve az NV-nek már rég váltania kellett volna. Szóval a 7-8 nm már a késői váltással elúszott. Innen már előre kellene tekinteni az 5 nm-re.
Az AMD eleve a szerverrel megy először 5 nm-re. Kis Zen 4 chiplet, amit majd rádobnak az EPYC-ekre. Ebből baj nem lehet. A probléma a későbbi lapkáknál jöhet elő, de akkorra lesz tapasztalat.
Amíg a Windows nem bizonyítja, hogy képes jól kezelni az eltérő teljesítményű magokat, addig az AMD biztosan távol marad ettől. Az Intel azért megy erre, mert nincs más választása, de a Zen magok nem csak gyorsak, hanem keveset is fogyasztanak, ezért tudnak 64 magot belerakni akkora fogyasztásba, ahova az Intel csak feleennyit. -
Abu85
HÁZIGAZDA
válasz
Petykemano
#41658
üzenetére
Többször írtam már, hogy a FinFET közeledik a végéhez. Mi volt az AMD-nek az első 7 nm-es lapkája? A Vega 20. Nem volt valami jó a fogyasztásban, de utána mindegyik javult, és most a Renoir már igen nagy órajelen is keveset fogyaszt. A kettő közötti különbség a tapasztalat.
Az NV-re is ugyanazok a fizikai törvények vonatkoznak, így elsőre nekik sem sikerült jól a FinFET egy modern node-on. Ez van. Hozni kell jövőre egy másikat 8 nm-re, és az jobb lesz, majd egy harmadikat, és az már igen jó lesz, közel az elméleti maximumokhoz.Amíg a GAAFET nincs itt, addig elsőre nagy mázli kell, hogy összejöjjön egy lapka egy új node-on. Ez nem igazán a Samsung és a TSMC hibája, hanem az adott node-ra vonatkozó tapasztalat hiánya.
-
Abu85
HÁZIGAZDA
válasz
Malibutomi
#41657
üzenetére
Azért az RDNA1/2-t nem hívnám lightweightnek. Nézzetek meg egy multiprocesszort. 128 kB-os az LDS, négy darab, egyenként 128 kB-os regiszterterület, két 16 kB-os L0, és megosztottan 16 kB-os skalár és 32 kB-is utasítás gyorsítótár, illetve 128 kB L1.
Ha ez a lightweight nem tudom mi a szénné gyúrt.

Az Ampere esetében egy multiprocesszor az 128 kB L1, amiből 48 kB az LDS grafikai számításnál, tehát külön LDS nincs is, 32 kB az utasítás gyorsítótár, és van még négy darab, egyenként 64 kB-os a regiszterterület. Ez sokkal inkább lightweight azokhoz az izmokhoz képet, amit az AMD rak az RDNA-ba.
-
Abu85
HÁZIGAZDA
válasz
Petykemano
#41633
üzenetére
Ha a cloud gaming számítana, akkor az NV ennyi pénzt olyan világszintű hálózati infrastruktúra fejlesztésébe ölt volna, mint amilyen van a Google-nek és a Microsoftnak. És itt nem a szerver telepítése a lényeg, hanem az, hogy rakjál mögé egy szolgáltatást. Például a Google keresőt, mert attól, hogy kiépíted a szervert, még nem fog állandóan működni. A Google azért van előnyben, mert nekik ott a szervereket igénylő keresője, és a szabad kapacitásukat elhasználják cloud gamingre.
Na most egy szolgáltató nem fog csak azért szervereket kiépíteni, hogy legyenek, mert akkor nem működnek. Muszáj valami szolgáltatás rájuk, mert a cloud gaming időszakos, tehát amíg nem játszanak elég sokan a peremhálózaton, addig a szerver minden percben egyre több veszteséget termek. És itt mindegy, hogy ARM procit adnak-e ingyen, akkor sem fogják megépíteni, ha azt a tetemes veszteséget le kell nyelniük.
A TSMC nem veri fel az árakat. Van kapacitás, kiírják licitre, és aki többet fizet, az viszi. Ez sosem fog változni, mert a TSMC-nek elemi érdeke, hogy a gyárai teljes kapacitással működjenek.
-
Abu85
HÁZIGAZDA
válasz
Malibutomi
#41630
üzenetére
Konzolról tudnak számolni, tehát nyilván van egy elképzelésük arról, hogy mit tudhat az AMD generációja.
Viszont a fogyasztás valószínűleg független ettől. Ott elvileg azzal van probléma, hogy maga a dizájnkönyvtár, amit az NV használ egy high density lib. Ezeknek a tipikus előnye, hogy egységnyi helyre több tranyót engednek építeni, de ennek az ára, hogy rossz lesz a fogyasztási karakterisztika. Emellett nem tudni, hogy a Samsunggal milyen szerződést kötöttek. Nem biztos, hogy a Samsung olyan jó kihozatalt tud ezeknél a nagy lapkáknál, hiszen akkora tapasztalatuk azért ebben nincs. És általában jellemző, hogy nem a lapka lesz fizikailag hibás, a 8 nm itt azért túl kiforrott, hogy ilyen gondja legyen, viszont nagy lehet a variancia az egyes lapkák között, amiket gyártanak. Ez szokott lenni a tipikus gond a nagy lapkáknál. Ilyenkor úgy kell kialakítani a specifikációt, hogy ezt a varianciát azért tervezd bele a kihozatalba, hogy minél több waferen található lapka felhasználható legyen.
-
Abu85
HÁZIGAZDA
válasz
-STALKER-
#41558
üzenetére
Attól függ, hogy miképp írják meg a sugárkövetést Xbox Series X-re. Az a konzol két pipeline-t támogat. A DXR 1.1-gyel kompatibilis a PC is, a mono pipeline-nal nem. Itt a fejlesztőknek két opciója van. Vagy átírják DXR 1.1-re a PC-s verziót, ha a boxon monot használnak, vagy kiadják Radeon Rays 4.0-ra az Xbox-ra írt kódot. Ha tehát nem hozzák át PC-re, akkor az csak azért lehet, mert nem akarnak ebbe erőforrást ölni, de technikailag az Xbox mindkét pipeline-ja lefedhető PC-n, a DXR 1.1-es verzió ráadásul szabványos.
Egyébként ha DXR 1.1-t használnak Xbox Series X-en is, akkor nehéz átlátni, hogy miért ne jöhetne PC-re. Az gyakorlatilag csak kódmásolás. -
Abu85
HÁZIGAZDA
válasz
Petykemano
#41554
üzenetére
Úgy lehet, ahogy régen az AMD is ott volt tranzisztorsűrűségben az Intel nyakán, hiába volt 28 nm az AMD, és 14 nm az Intel. A Carrizo ugye 12,7 Mtr/mm2 volt, míg a Broadwell LCC 13 Mtr/mm2.
A legfőbb különbséget a dizájnkönyvtár adja. Ezt egy csomó mindenre rá tudod tervezni, és ugyan az áramkörök egyes elemei eléggé fixek, tehát a cache-ek esetében azért nem fogsz sokat hozni egy máshogy optimalizált dizájnkönyvtárral, az ALU-k, a buszok, illetve a vezérlést biztosító részegységek tekintetében azért nagyon is lehet a magas tranzisztorsűrűségre optimalizálni.
Van tehát egy viszonylag nagy tartomány, amit alapvetően lehet célozni a tranzisztorsűrűség tekintetében. Minél nagyobb ez az érték, annál rosszabb lesz az órajel skálázhatósága, illetve annál rosszabb a fogyasztási karakterisztika, de ha ezek nem zavarnak, akkor egy korábbi generációs node-dal megközelítőleg el lehet érni egy újabb generációs node tranzisztorsűrűségét. Az NV ez bevállalta, viszont nem tudnak egyszerűen 2 GHz fölé menni órajeleben, ahogy az AMD olyan egyszerűen teszi a PS5-nél az RDNA2-vel, vagy fixen 1,825 GHz-re sem képesek, ami az XSX paramétere. Az Ampere fail-safe órajele csupán 800 MHz, nagyjából a fele az XSX ilyen paraméterének. ilyen minden architektúrában van a power virusok miatt, ha esetleg a terhelés olyan extrém lenne, akkor a GPU nem fagy le, hanem visszavált egy nagyon alacsony órajelre, kb. soha nem következik be, de ha mégis, akkor ott van egy mód, hogy ne fagyjon a hardver, ugye AVFS nélkül a Microsoftnak ezt az alapszintű órajelet kell alkalmaznia az Xboxnál. A PC-s RDNA2 fail-safe-je 1,79 GHz lesz, picit kisebb, mint a boxé.
Az AMD a saját GPU-ira egy ideje már nem density optimized, hanem performance optimized dizájnkönyvtárat használ. Még az APU-k is úgy vannak megcsinálva, hogy van egy mixed dizájnkönyvtár, ami a CPU-ra density, míg a GPU-ra performance szinten dolgozik. Ezért van olyan veszettül megküldve a Renoir Vegájának órajele.
Ez ilyen balansz játék tehát. Ha nagyon szükséged van a tranyóra, akkor be lehet áldozni a fogyasztást és az órajelet. Ha annyira nincs, akkor érdemes valami ideális egyensúlyt találni. Ha magas órajelre és jó fogyasztási karakterisztikára van szükséged, akkor be lehet áldozni a tranyósűrűséget értük.
-
Abu85
HÁZIGAZDA
válasz
Kelleret
#41435
üzenetére
A tartalom minőségének javulása főleg memóriát eszik, azoktól a számítás ugyanaz, vagyis a fő sebességgyilkosok a shaderek lesznek, ahogy mindig. A PS4-es a legtöbb teljesítménygyilkos shader felezett vagy negyedelt felbontáson fut. Míg PC-n natív minőségben. Meg lehet nézni, hogy a cloud megjelenítése például mennyivel részletesebb lett, vagy az SSR, de az árnyékok is, de ezt nehezen veszed észre játék közben, ezért fut a PS4-en visszafogott minőségben. PC-n az original opció a barátod, ha ez a minőség megfelel.
-
Abu85
HÁZIGAZDA
Most az atmoszféra az nekem is tetszik. Azzal nincs bajom, sőt... csak a tartalmat hiányolom. De lehet, hogy én hamar feladom. A harcnak egyébként nem látom értelmét. Inkább kikerülöm az ellent. Lehet, hogy itt hibázok?
Az a baj, hogy jó néhányszor megaláztak már.
(#41433) Laja333: A Death Stranding kinézete koncepcióból sivár. Ezt nem lehet felróni neki, mert valahogy bele kellett rakni a játék dizájnjába a reménytelenséget, és ezt a legjobban egy kihalt és élettelen táj szemlélteti. Ilyen szempontból a Death Stranding egyáltalán nem rossz, inkább más. Az való igaz, hogy az ember számára egy paradicsomszerű táj sokkal szebb lesz, mint a Death Stranding pusztasága, de ha objektíven nézzük a grafikát, akkor nagyjából ugyanott vannak, csak a HZD-be a dizájn miatt sokkal nagyobb részletesség kell.
-
Abu85
HÁZIGAZDA
Engem elsődlegesen az motivált, hogy a kérdéseimre választ kapjak. Például az időeső miért roncsolja a szállítmányt, és minket miért nem? Tudom, a kabátunk miatt, de akkor miért nem húzunk ilyen kabátot a szállítmányra? A járművek a terepre abszolút alkalmatlanok. Motorral szinte mindig el lehet akadni, nagyobb szenvedés, mint gyalog. Fura, hogy erre senki sem gondolt.
Én alapvetően azt gondoltam el, amikor láttam a trailereket, hogy ez ilyen futárszimulátorkodós mellékküldetésekkel megtűzdelt játék lesz, ahol majd lesznek izgalmas küldetések. Erre az egész játék csomagküldésre épül. Nem ez a választható mellékes, hanem maga a nagybetűs játék. Na ekkor durván ledöbbentem. Egy darabig szentül azt hittem, hogy az elején cipelgetek, aztán majd kapok valami frankó küldetést, esetleg bejutok oda, ahol az emberek el vannak szállásolva, mert ugye elvileg nekik cipelünk, de marhára nem látjuk őket.
Arról már nem is beszélve, hogy a gyaloglás olyan szinten túl van bonyolítva, hogy az beszarás. Nem elég a sticket irányba helyezni, még két extra gombbal egyensúlyozni kell, és a lendület is meg tud tréfálni. Csodálatos.
És még az a hülye bakancs is kopik.Én ezt csak úgy tudom értelmezni, hogy félbe lett vágva az egész. Játéknak készült ez, de valamiért ki kellett venni a tartalmak nagy részét, ezért sem jutunk le az emberek közé a föld alá, és végül ezért lett maga a nagybetűs játék egy olyan játékmechanika, amit más címekben maximum mellékküldetésekben látunk: vidd a csomagot A-ból B-be. Nehezemre esik elhinni, hogy tényleg ezt akarta Kojima.
-
Abu85
HÁZIGAZDA
válasz
nubreed
#41423
üzenetére
Én úgy értem a félkészt, hogy dizájnban nem áll össze. Funkcionálisan működik, de egy tripla-A-s cím esetében többet várna az ember annál, hogy futár legyen órákon át. Valamivel oldani kellett volna az unalomba merülő szállítmányozást. Én nagyon sokáig csak azért futárkodtam, mert azt hittem, hogy valami végre történni fog. Aztán ránéztem a neten, hogy lesz-e itt egyáltalán izgalom, és lényegében nem. Az egész egy nagy futárkodás. Ez nem áll össze. Valamit rakni kellett volna bele, mert az első pár órában még az van, hogy visz előre a kíváncsiság. Aztán a következő pár órában a düh, hogy nem lehet csak ennyi ez a játék. Aztán már semmi. Ráunok ugyanarra a feladatra. Ezt nem tudom hova rakni, hogy senki sem érezte a fejlesztésnél, hogy ez baromira kevés? Sokkal inkább gondolom azt, hogy a kiadó asztalra csapott, és kiadták így, mert nem volt többre idő. Ha viszont Kojima ezt tényleg ilyennek akarta, akkor az döbbenet, úgy neki sajnos kicsengettek. De Kojimáról nem akarom elhinni, hogy tényleg csak ennyit akart. Régen tudott ő alkotni is.
-
Abu85
HÁZIGAZDA
válasz
huskydog17
#41421
üzenetére
Elég sok köze volt hozzá a Sony-nak. Ők adták hozzá a motort, ugyanis ugyanazt a kódot használja, amit a Guerilla csinált a Horizon PC-s portjához. Enélkül nem lett volna PC-s port, hiszen jelentős módosításra lett volna szükség. De nem kellett, a Guerilla munkáját felhasználták.
-
Abu85
HÁZIGAZDA
válasz
nubreed
#41418
üzenetére
Én nem látom a mélységet benne. Leginkább azt látom, hogy ez egy félkész játék, amire már nem akartak több pénzt áldozni, mert féltek, hogy az se hozza vissza, amit eddig elköltöttek rá, így kiadták ahogy van. Ebben a formában viszont sajnos unalmas. Ettől függetlenül örülök, hogy megjelent, mert marha jó paródiát csináltak rá. [link] - ezen például nagyon sokat röhögtem. Főleg az tud rajta nevetni, aki játszott az eredeti játékkal is.
(#41419) huskydog17: Én azért megnéznék egy játékot évekkel korábbról, ami így kezeli az átlátszóságot a vegetáció szempontjából.

Az animációkat nem mindig éri meg frissíteni. A legtöbb játékban ilyenek egyébként.
Az anizotropikus szűrés egy szimpla bug. A megatextúrázó miatt erre külön shaderek kellenek, és ezt le kell implementálni, ami pont az új meghajtókkal bugokat generál. Ez ki lesz cserélve az AMD kódjára egy patchben, csak ehhez előbb be kell építeni a D3D12MA-t.Nem áldoztak be semmit. Vissza lehet venni a grafikai minőséget a grafikai menüben. Minden original feletti szint egy extra. Nem kötelező bekapcsolni. Azoknak tervezték, akiknek megvan hozzá a hardverük, és azzal nem azt a tartalomminőséget kapják, amit a PlayStation 4. Ebben már valószínűleg az is benne van, hogy lesz egy PlayStation 5 port, amibe jól jönnek majd a feljavított tartalmak.
Az Ubi aktuális motorjai nem is kezelnek akkora részletességet, amiket itt kapsz. Majd az új AC kezelni fog. Az már jelenetenként 40 000 rajzolással dolgozik, és az közelít a Horizon jelenetenkénti 70 000 rajzolásához. A korábbi Anvil jelenetenként 3000 rajzolást csinált maximum, átlag inkább 1500-at. -
Abu85
HÁZIGAZDA
válasz
nubreed
#41413
üzenetére
Nem annyit, amennyit szerettek volna, másképp nem lenne PC-s port. Ilyen szempontból jól jártunk. Viszont a Sony nem fogja elérni a 10 milliós eladást még PC-vel együtt sem, ami egy exkluzív címnél erősen minimum target szokott lenni. De a költségeket legalább vissza lehet hozni.
A Sony is látta rajta, hogy az egész nem más, mint egy DHL szimulátor. A játékmenet kimerül abban, hogy csomagokat viszel A-ból B-be, közben küzdesz a tereppel, néha sír a gyerek, ilyenkor babázó szimulátorrá változik, stb. Ha eljutsz a csomagokkal a megfelelő helyre, akkor kapsz lájkokat. Ennyi. Ez ismétlődik sok-sok órán át. Felveszed a csomagot, egyensúlyozol a terepen, a gyereket megvigasztalod, kikerülöd a veszélyeket, lerakod a csomagot, és ugyanez újra. Egy idő után építhetsz utakat, amivel egyszerűbb lesz a járművekkel menni, a gond ezzel az, hogy még unalmasabbá változik a játékmenet. Én próbálom noszogatni magam, hogy vigyem még, de az első pár órában láttam mindent, azóta csak ismétlés. Ha pénzt adtam volna rá ideges lennék, de így csak az időm basztam el, azt meg túlélem.
-
Abu85
HÁZIGAZDA
válasz
Kelleret
#41407
üzenetére
Eleve azért jött PC-re a Death Stranding mert a Sony nem bízott abban, hogy PS-en vissza tudja hozni az árát. Ez egy betervezett kármentés. Ilyen formában már nem adnak pénzt a port áttervezésére, hanem kiadják a PS4-es tartalommal és ennyi. Arányaiban a munka olcsó volt, mert a motort a Guerilla már átültette PC-re a Horizonhoz, tehát a kódot oda tudták adni, és ezt elég volt hozzáigazítani a játékhoz. Minimalista költségvetésből hoztak egy másik platformot, és így van esély rá, hogy a játék visszahozza a befektetést. Csak PS4-en valószínűleg mínuszos lenne.
(#41408) nubreed: Erre vannak a grafikai beállítások. Ha pedig jobb hardvert veszel, akkor elérted a részletesebb szinteket. Ez mindig így volt PC-n, nem értem, hogy ezen miért lepődünk meg. Igen vannak olyan portok, például a Death Stranding is, aminek a tartalomminősége maximumon éri el a PS4 Pro tartalomminőségét, de leírtam, hogy ez miért volt így. Egyedül az effekteken tudtak gyúrni. Viszont a Sony pozitívba akarja rakni a játék mérlegét, és ehhez kell a PC is, mert a PS4 önmagában nem lesz képes nyereséget felmutatni. A PC-vel együtt viszont már jók lesznek az eladások, miközben a PC-re alig költöttek, a tartalom megvolt a konzolról, a motorra vonatkozó módosításokat pedig elkérték a Guerillától. A Horizon máshogy készült. Ott tényleg raktak bele részletességet is, volt idő rá.
(#41410) huskydog17: A VRAM-ot azért nem érdemes még nézni, mert ott csak a day0 patchben érkezik az AMD D3D12MA. Az előzetes verzióban ezt nem aktiválták, így nincs még defragmentáció sem, stb.
A TressFX fork a PC-s verzióban mindegyik karakterre aktiválva van. A PS4-ben csak Aloyra, és ott is csak szimuláció szintjén. PC-ben az OIT is működik.
A Shadow of the Tomb Raider egy szem karakter egy szem hajával kell dolgozni. Jóval kisebb az az erőforrásigény. De egyébként ki lehet kapcsolni ezt. Az original beállítás csak Aloy hajára csinálja a TressFX-et, bónusz, hogy az OIT megmarad, az PC-n shortcut algoritmussal dolgozik, és úgy olcsó.A portolási idő ahhoz kellett, hogy nagyobb részletességűre tervezzék a tartalmat. Ne a Death Strandingből induljatok ki. Ott a PC-s tartalom minősége megegyezik a konzolossal. Egyedül az effektek, illetve a post-process módosult. A Horizon tartalmai át lettek tervezve. Nem mellesleg a Horizon más terhelést ad ugyanannak a motornak. A Death Strandingnél nincs igazán vegetáció, így az ebből eredő geometriai terhelés ebben a játékban nem létezik. A Horizon viszont tele van vegetációval, ami geometriai részletesség tekintetében jelentősen nagyobb terhelés.
Sok szempontból a Horizon vegetációja máig egyedülállóan részletes. [link] - érdemes megnézni egy erre vonatkozó előadásukat, főleg az átlátszóság kezelése lényeges. Ez a részletesség sokkal nagyobb terhelés a motornak és a hardvernek is a Death Stranding pusztáihoz viszonyítva. PC-n ez a vegetáció csak jobb lett, mert bevezettek egy compute shader szimulációt rá, hogy élethűbb legyen.
-
Abu85
HÁZIGAZDA
Hiába ugyanaz a motor a Death Stranding és a Horizon Zero Dawn esetében. Előbbit sokkal rövidebb idő alatt csinálták meg, egészen pontosan fél év alatt, tehát a Death Stranding esetében fel sem merült, hogy kicseréljék a konzolra tervezett modelleket, textúrákat, egyéb tartalmakat. Ezek minősége korlátozott, mert futniuk kell a PlayStation 4-en. A Horizon Zero Dawn portolása két és fél éve kezdődött meg, és ilyen távon belefér az, hogy újratervezzék a tartalmat, vagyis a PC-s verzió jobb minőségű tartalmat használ, mint a PlayStation 4-es, meg az effektek minősége is jelentősen javult. Ezt meg is tették, és emiatt van egy original beállítás a játékban, ami gyakorlatilag megegyezik a PlayStation 4 szintjével. Itt megkaphatók az eredeti tartalmak, persze átkötegelve, de a részletességük nagyjából megegyezik a PlayStation 4 verzióval, ahogy ez a Death Stranding esetében is. Viszont a Horizon Zero Dawn esetében vannak részletesebb tartalmak, amelyeket magasabb grafikai szinten be lehet állítani. A vegetáció át lett rakva compute shaderre, ami így lényegesen részletesebb lett, a TressFX már nem csak Aloy haján van szimulálva, hanem mindenen, és nem csak szimuláció szintjén, hanem mindenre van OIT shortcut alkalmazva. Tehát a konzolhoz képest a tartalom minősége jelentősen nőtt, és ezért nő a gépigény is. De aki a konzol szinttel megelégszik, használhatja az original beállítást, és akkor a teljesítménye közel lesz a Death Strandinghez, amely port eleve nem használ részletesebb tartalmat. Tehát a motor működik ezalatt is, csak a részletesség fel lett húzva az egekbe, de ezt nem kötelező ám bekapcsolni, erre vannak a grafikai beállítások.
Az a baj, hogy sokan azt hiszik, hogy az a jó port ha gyorsan fut, pedig ez relatív. Mi fut gyorsan? Negyedannyi részletességgel nyilván nagyobb lesz ugyanolyan motoron a teljesítmény, de elfelejti mindenki, hogy a Horizon Zero Dawn részletessége is lecsökkenthető a Death Stranding szintjére, és akkor jön vele a teljesítmény is, hiszen a motor szintjén ugyanazokat az optimalizálásokat használja, amiket a Horizon. Lényegében ugyanaz a motort, csak itt nem adott a Sony két évet arra, hogy tervezzék át a tartalmat is PC-s szintűre. Utóbbi már üzleti döntés, nyilván ha lett volna akarat rá, hogy ebbe pénzt fektessenek, akkor a Kojima Production is meg tudta volna tenni, hiszen a motort készen megkapták a Guerillától, csak nem láttak annyi lehetőséget a PC-s eladásokban, hogy érdemes legyen bele pénzt ölni, inkább arra mentek, hogy egyáltalán hozza vissza maga a játék a befektetést. A Horizon Zero Dawn más tészta. Az rég megtérült már csak a PS4-es eladásokból, így ott lehetett költekezni, jó eséllyel visszajön PC-s szinten is az extra befektetés.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#41394
üzenetére
Igen, csak a másik játékot nem tervezték át, hanem copy-paste volt a konzolokról. A modellek és a textúrák nagyrészt megegyeznek a PS4 Pro verzióéval. Itt van egy original beállítás, ami azt jelenti, hogy azon kapod a konzol szintet. Minden más egy áttervezett modell, ami esetenként lényegesen nagyobb részletességű.
Ezért is jött hamarabb a Death Stranding, mert az csak egy sima konzolport. Itt viszont áttervezték a játékhoz használt tartalmat. De aki a konzolos szintet akarja, beállíthatja az original opciókkal, és akkor azon hasonlóan gyorsan megy a motor, mint a Death Stranding alatt.
Az effektek minősége is változott. A TressFX is lényegesen nagyobb részletességgel dolgozik. A Death Strandingben ugye a TressFX ki volt kapcsolva konzolon és PC-n is. Itt konzolon és PC-n is működik, ráadásul nem csak a főszereplő hajára. Nem ugyanaz a terhelésszint. Alapvetően a motor bírja, tehát ráküldték a PC-s verzióra a max részletességet.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#41363
üzenetére
Attól, hogy valaki kivonul egy régióból még nem köcsög. Nagyon sok cég PR cégeken keresztül oldja meg ezt. Ennek egyszerű az indoka: olcsó! Az ellenérv a rossz hatékonyság, ezért van az, hogy bizonyos cégek meg még a drága fenntartás mellett is dedikáltan szeretnének jelen lenni egy régióban.
Különösebben ez nem zavaró, mert szerencsére ezek a folyamatok hullámzók. Egy időben jónak tűnik a kiszervezés, de az mindig azzal jár, hogy az a cég növeli a régiós befolyását, amelyik nem szervezett ki. Például a balkáni régióban az AMD rendkívül erős lett. Némelyik kereskedőnél már 20:1-re verik az Intelt, tehát hamarosan eljön az a pont, amikor az Intel aktuális vezetősége rájön, hogy hiba volt anno felszámolni a helyi sajtóképviseleteket, mert a DIY-piacon mára összeomlóban vannak az eladásaik. Erre mindig az szokott lenni a válasz, hogy akkor mindent visszacsinálnak, és újra lesz direkt régiós kapcsolati rendszer. És ez rendszerint meg is hozza majd az eredményét. Szóval ez egy ilyen dolog. Pár évre kivonulnak, aztán rájönnek, hogy ez szar az eladásokra, majd visszatérnek. Az AMD is volt egy időben úgy, hogy kivonul a balkáni régióból, csak abban az időben jött Rory Read a vezetői székbe, akinek az volt a rögeszméje, hogy régiós kapcsolat nélkül nem működik jól egy világcég. És nemhogy beszántotta volna a régiós központokat, hanem bővítette azokat. Pedig ugyanazzal a problémával szembesült anno, amivel az Intel, csak az Intelnek erre nem a bővítés volt a válasza, hanem az egész rendszer központosítása, és egy rakás ember elküldése. Rory Read például azt mondta, hogy bővíteni kell, és a növekvő eladás majd kitermeli a bővítés költségeit. Persze utólag könnyű okosnak lenni, tehát attól még az Intel nem köcsög, hogy kivonult. Ők ezt a megoldást látták logikus lépésnek. Itt tényleg olyan döntésekről van szó, amelyek hatása legalább fél évtizedes léptékű. Akkoriban simán benne volt, hogy az Intel húzza ki az ászt a pakliból.Ezek mind alapvetően az adott cég vezetőségének a felfogásán múlnak. Mindig logikusnak hangzik a leépítés, csak az idővel nagyobb kárt okozhat, mint egy drágább régiós kapcsolat fenntartása. Ma már az AMD a saját balkáni hátterét bőven kitermeli azokkal a kiskereskedelmi eladásokkal, amiket pusztán a régiós képviselet létezése miatt be tudnak húzni ezen a területen.
Szóval különösebben nem kell aggódni. Egyik cég sem szeret a pénisz rosszabbik végére kerülni, így jönni fognak vissza.Ha az NVIDIA nem adna nekünk hardvert, akkor a tesztgépben nem GeForce RTX 2080 Ti lenne. Az ugyanis az övék, csak nekünk adták használatra. A tesztgépben egy csomó hardver nem a miénk, viszont hosszabb távú használatra hagyta itt az adott gyártó. Ezeket időnként visszakérik, például az AMD is visszakérte nemrég a korábbi alaplapot, de adott is helyette egy jobbat. Ugyanígy a Ryzen 2700X-ért kaptunk egy 3700X-et. Valószínűleg egyszer utóbbit is visszakérik, majd adnak még újabbat. A tesztgép frissítései ilyen gyártói cserékből vannak fenntartva.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#41355
üzenetére
Sokszor az összes készlet day1 el van adva a nagykerekben. A kezdőkészlet erre a piacra egészen minimális szokott lenni.
Nem mellesleg, az NDA-ra nem lehet NDA után tesztelni. Ezt a gyártóknak kell megoldaniuk. Régen ment az Intelnek és az NV-nek is, igaz régen volt dedikált csatornájuk is Magyarországra, ma pedig már nincs egyik cégnek sem. Túl kicsi lett a piac ahhoz, hogy foglalkozzanak vele, így lepasszolták az egészet PR ügynökségeknek.
-
Abu85
HÁZIGAZDA
Ez a gyártókon múlik, hogy küldenek-e a régióba hardvert. Az AMD valószínűleg, mert nekik van a régióban dedikált érdekeltségük, sőt, éppen bővítenek. Tehát mi sosem utasítottuk el azt, ha valaki NDA-ra küldött teszthardvert. Tudtommal más sem a régióban, láthatod is, hogy az AMD-ből mennyire sok teszt érkezik az egyes termékek megjelenése után. És most nem csak rólunk beszélek, hanem a többi hazai médiáról. Tehát ha a gyártócég küld hardvert, akkor vannak hazai tesztek is.
Az nyilván sajnálatos, hogy az AMD-n kívül mindenki kivonult a mi régiónkból. Ennek nagyrészt a YouTube az oka, amivel a gyártók már nem érdekeltek a részletes tesztekben, mert kiszámíthatatlanok. Elárulom, hogy az AMD érdeklődését is egy tech-geek ember tartja életben, aki a minőségi tesztek híve, ezért YouTube influenszerek ide vagy oda, ő direkt a szakértő médiáknak adja a hardvereket elsőként. Ha ő nem lenne, akkor az AMD-nél is valamelyik PR ügynökség döntene, és kapná a holmit valamelyik influenszer, leírják neki, hogy mit kell mondania egy tíz perces videóban, és ennyi.(#41351) Malibutomi: Tudok.
Nem hiszem, hogy a neten ezek az infók megjelentek már. Én is arra várok, hogy több OEM-hez eljusson, mert most még beazonosítható forrás. Bajt meg nem akarok neki.
-
Abu85
HÁZIGAZDA
Az RT-vel sokat nem érnek gépi tanulásnál.

A vezérlők, regiszterek és buszrendszer brutális tétel. A multiprocesszor nagy részét elviszik. Hitted volna?

A dedikált RT valamivel könnyebb. Az egy fixfunkciós blokk. Nem szükséges hozzá bonyolult belső busz, regiszter, a vezérlője is egyszerűbb, sokkal.
Majd meglátjátok ősszel mi lesz az RDNA2-Ampere viszony. Izgi lesz, sőt, soha ilyen izgi nem volt, na jó ez talán nem igaz, de az elmúlt pár évben semmiképp.

-
Abu85
HÁZIGAZDA
válasz
gejala
#41345
üzenetére
Majd nézd meg az Ampere-nél, hogy mennyire lesz hasznos az RDNA2 ellen.

Elég nagy munka implementálni. Ha könnyű lenne, akkor majdnem minden játékban lenne, de sajnos nem az, emellett az NV nem adja ingyen a neuronhálót, szóval rengeteg pénzt kell érte fizetni.
(#41346) b. : Bírom az ilyen összehasonlításokat, amikor csak az ALU-kat veszik számításba, de a szükséges vezérlőáramköröket kihagyják. Ha így nézzük, akkor a CUDA magok is csak a lapkaterület töredékét viszik el, de marhára nem működnek a lapkaterület nagy részét igénylő vezérlőáramkörök, regiszterek és belső buszrendszer nélkül. Ugyanez igaz a Tensor magokra. Ott sem maga az ALU a tranzisztorzabáló, hanem az, amitől egyáltalán működnek azok az ALU-k.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#41342
üzenetére
Úgy, hogy nagyon kevés alkalmazás használja azokat a hardvereket. Mellesleg az AMD-nek az RDNA2-ben sem lesz tensor magja. Nincs értelme elbaszni rá a tranzisztorok egyharmadát, ha az alkalmazások 1%-a használja. Az NVIDIA az Ampere esetében főleg ebbe a problémába esett bele. Ugyanaz a gond, mint az Intelnek az AVX-512. Alig használják a hardvert a programok, mégis elvered rá a tranzisztorok egy jelentős részét. Ezeket pedig lehetne költeni általános teljesítményre is, ami hasznosulna a programok 99%-ában. Ezzel a trükkel ver nagyot az Epyc a Xeonra. Lemondanak az alkalmazások 1%-áról, hogy a maradék 99%-ban alázzanak.
(#41343) FLATRONW: Az AMD írja az Apple-nek az eszközszint fölötti absztrakciós réteget, erre a rétegre az API implementációját viszont az Apple írja. Windowson ez is az AMD feladata. Ezért van az, hogy az AMD OpenCL meghajtója sokkal gyorsabb Windowson egy csomó feladatban. Az Applenek nem érdeke, hogy náluk gyors legyen az OpenCL, mert az hátráltatja a Metal terjedését. De az AMD ebbe nem szólhat bele. A platform az Apple-é. Ők szállítják a hardvert, meg az eszközszint fölötti absztrakciót, amire szerződtek. Abba se nagyon tudnak beleszólni, hogy az Apple az OpenCL és az OpenGL kivégzésén dolgozik a Macen. Az NV sem tudta megakadályozni a CUDA kivégzését. Az Apple eldöntötte, megcsinálta, és ennyi volt.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#41334
üzenetére
Nem az a lényeg, hanem az, hogy két eltérő OS fut a két gépen. A Macbook esetében az alkalmazásokat Metal API-ra optimalizálják, de pont ezért a többi API nem is élvez prioritást. Egyszerűen az Apple nem foglalkozik velük. Így viszont muszáj olyan alkalmazást keresni, ami a Metal API-ra van optimalizálva, hogy működjön a rendszerrel. Ha például raksz rá egy Windows 10-et, a hozzá való meghajtókkal, akkor például egy OpenCL ugyanazok a Macbookon sokszorosan gyorsabb, csak azért, mert a Windows 10-re még van nagy teljesítményű OpenCL meghajtó.
A Macbook előnye, hogy ami Metalra van optimalizálva az tényleg nagyon gyors a macOS-en. Egy külön liga ez a platform. Pont emiatt a különcködés miatt engedhetik meg azt, hogy az OpenCL és az OpenGL esetében már a támogatás kivezetését készítik elő. Egy-két frissítés, és nemhogy szarul nem fog futni egy OpenCL alkalmazás, hanem sehogy sem. Ellenben lesz Metal port, és azt már nem tudják visszamenteni Windows 10-be, vagyis akinek valami miatt a Metal port kell, például egy funkció, amit más port nem támogat, annak muszáj Macet vennie. Tipikus piaclezárás, megölöd a rendszereden a szabványos API-kat a teljesítménnyel, és mindenkit átkényszerítesz Metálra. Ezt koncepcióból csinálja az Apple. A CUDA-t is kivették, az OpenGL és az OpenCL is erre a sorsra jut nemsokára, csak előbb teljesítményben fogják vissza őket, ami nagyszerű a marketinghez, hogy "jééé mennyivel jobb a Metal" ... ugye, hogy ugye!
-
Abu85
HÁZIGAZDA
válasz
Petykemano
#41198
üzenetére
Azért 13 MB-ot nem neveznék kevésnek. És akkor még a CPU/GPU L1-eket nem is számoltam.
A Navi 10-ben például 4 MB L2 van. -
Abu85
HÁZIGAZDA
válasz
Petykemano
#41195
üzenetére
A cache-ből. A gyorsítótárakat miatt lesz nagy a tr/mm2.
-
Abu85
HÁZIGAZDA
Nem érné meg nekik, mert az AMD-től csak dizájnt kapnának és nem x86/AMD64 licencet. Ez nagyon fontos a semi-custom divízióban, hogy IP-t az AMD nem licencel a megrendelő felé, csak egyedi kérésre gyártat valamit.
Az RDNA2 7 nm-t használ. A 7 nm+ félreérthető. Ugye volt eredetileg az első 7 nm. Annak lett egy EUV-s verziója, de van egy nem EUV-s továbbfejlesztett 7 nm is. Tehát három node-ja van a TSMC-nek. Az AMD most az első, nem EUV-s 7 nm-es node-ot használja, míg az új lapkák a továbbfejlesztést, de nem az EUV-s verziót.
Az Advanced Node egyébként azt jelenti, hogy a TSMC egyedi node-ot tervez az AMD-nek. Ugye idén már ők számítanak a legnagyobb megrendelőjének a 7 nm-es node-ra, így a speciális igényeiket teljesítik. A proci kap egy 5 nm-es egyedi node-ot, és a GPU-k is egyedi gyártástechnológiát fognak használni. -
Abu85
HÁZIGAZDA
Bármire, amire 7 nm-t írnak, kétségekkel érdemes nézni, mert az NV-nek jelenleg egyetlen 7 nm-es lapkája van a TSMC-nél, az pedig a legnagyobb. A többi a Samsungnál látható egyelőre, és 8 vagy 10 nm-es node-on. Nem valószínű, hogy ezek pár hónapon belül portolhatók 7 nm-re. Azért az egy teljes full node. Egy ilyen portoláshoz kell legalább másfél év. A TSMC ugye nem a Common Platform része, teljesen más technológiával dolgozik, mint a Samsung.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#41065
üzenetére
De éppenséggel pont az lesz a célja. Az, hogy lesz Switch port leginkább annak köszönhető, hogy maga az új CryEngine már támogatja azt a konzolt is. A grafika pedig nagymértékben skálázható.
(#41066) b. : Nem tudnak régi CryEngine-t használni. A portolásnál pont az a lényeg, hogy az új verziókba építik bele a supportot. Mert grafikailag eléggé széles skálán lehet mozogni, elvégre PC-n is szoktak lenni very low és ultra high végletek, viszont ha a motor nem támogatja a célzott konzolt, akkor ennek nincs haszna. A Switch portot pont az teszi lehetővé, hogy az új CryEngine már támogatja. Szóval itt mindegyik platform ugyanazt a motorverziót kapja, de persze a szállított modellek, textúrák, illetve az általános grafikai minőség eltérhet. De ez már a dolog könnyebbik oldala.
(#41068) huskydog17: Meg lesz még egy csomó minden, elvégre a mostani CryEngine-ben már van SVOTI is, egy rakás effekt compute shaderre van portolva, ésatöbbi. Ez bőven elég a komoly grafikai szintlépéshez. Már az SVOTI az önmagában.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#41011
üzenetére
Annyival már nem limitáltabb az API. Ez a mostani generáció elején nagy gond volt, de manapság már nem az. Természetes persze, hogy konzolon esetleg lehetnek olyan hozzáférési módok, amelyek egy rajzolási parancsot talán 5-10 DWORD-ből is megoldanak, de annyival többe PC-n sem kerül már, így alig van különbség. Szóval az API gyakorlatilag már nem jelent problémát.
-
Abu85
HÁZIGAZDA
Igen. A föntire. Ott kell nézni a GPU memóriáját, ami 1.0/16.0 GB éppen. A grafikus egység megosztott memóriája nagyon pontos. A dedikált kiírás sajnos nem annyira pontos, innen származnak az eltérések a profilozókhoz képest. Ez az a rész, amit az OS nem igazán lát explicit API-val, és kb. semmi.
-
Abu85
HÁZIGAZDA
Ezek szerint valószínűbb, hogy az AMD/Intel/NVIDIA nem képes erre. Istenem de hülyék, hogy a saját rendszereiket sem tudják, hogy miképp működnek, és azokat sem szerződtetik, akik tudják ezt.

Úgy keverednek ide, hogy ha egy kicsit is pontosak lennének, akkor használhatók lennének fejlesztésre is, de megközelítőleg sem pontosak. Csak félrevezetésre alkalmasak. Emiatt az AMD/Intel/NVIDIA pontos megoldásokat fejleszt, csak azok sok-sok ideig készülnek, mert nem triviális a probléma, még azoknak sem, akik tervezték az adott rendszert. Ne hidd, hogy akik ebben a folyamatban részt sem vettek, azok okosabbak náluk.
-
Abu85
HÁZIGAZDA
Ezernyi cikk van arról, hogy a homeopátia hatásos. Most akkor az?
Gondolkodj mielőtt elhiszel valamit. Majdnem öt év telt el a DirectX 12 megjelenése óta, és még nem kapott az API memóriaképet biztosító profilozót. Ehhez képest gondolod, hogy egy csomó program, mindenféle komoly anyagi háttér nélkül, dokumentációk nélkül megmondja, hogy mi van a VRAM-ban, amikor az AMD-nek ez öt évbe telt, úgy hogy ők tervezték a hardvereiket, és a drivert is hozzájuk, vagyis ismerik a forráskódot. Eközben az Intel és az NV még nem kínál ilyen lehetőséget. Még nem, de majd egyszer fognak. Persze nem is értem, hogy miért nem szerződtetik az Afterburner programozóját, fenéket ölne ebbe éveket és egy rakás pénzt, amikor kint van egy ember, aki tudja és megmondja.
-
Abu85
HÁZIGAZDA
Tényleg elhiszed amiket ezek a programok kiírnak? Maga az operációs rendszer nem képes rá, mert az API nem támogat kernel szerver szálakat. De egy garázsban egy kisgyerek ír egy alkalmazást, ami kijelzi a VRAM-használatot, miközben az explicit API-k megjelenése után több évvel jön végre egy olyan profilozó, ami memóriaképet tud adni a fejlesztőknek. Ha ez a probléma olyan egyszerű lenne, akkor a fejlesztők nem könyörögnének a jobb, akár memóriaképet adó profilozókért, hanem izzítanák az Afterburnert, és hiba nélküli memóriamenedzsmenteket építenének a játékaikba, mert az Afterburner megmondja. De nem ez történik, mert rohadtul nem mond meg semmit. Maximum félrevezet.
-
Abu85
HÁZIGAZDA
Én egy oldalt se láttam, ami megnézte volna profilozóval. Más nem látja a memóriát, csak tippel.
A 3rd party cuccoknak DX12/Vulkan API-ban ne higgyetek, magának az operációs rendszernek is elvették azt a jogát, hogy lássa a VRAM-ot. Hogy látná már azt egy olyan alkalmazás, amely azt se tudja, hogy a meghajtó mit csinál?Várják meg amúgy az RGP 1.5-öt. Abban a világon elsőként lesz memóriakép. Nem csak leírja, hogy mi van a memóriában, hanem le is rajzolja, hogy miképpen van benne, hogyan helyezkednek el az allokációk, azaz milyen a fragmentáció. Az már egy eléggé pontos adat lesz, hogy egy program mennyi memóriát igényel valójában.
Ha az RGP nem opció, akkor a Windows beépített mérője a legjobb. Nem pontos, de nagyságrendekkel pontosabb, mint egy Afterburner, meg a többi jósda.
-
Abu85
HÁZIGAZDA
Nagyon nem dolgoztak rajta. Egyszerűen mindenre szokatlanul nagy felbontású textúrákat használnak. Ebben a tömörítésnek nincs szerepe. A DirectX API-ban eléggé szabványosítva van, hogy milyen BC formátumok vannak az egyes problémákra. Ha nagyon akarnának erre gyúrni, akkor használtak volna ASTC-t az AGS-en keresztül, de nem tették, mert ugye kétszer kellene szállítani a tartalmat. És annyira sokat ezzel amúgy nem nyernének, maximum -20%-ot, miközben a játék telepített mérete majdnem megduplázódna.
A játék és a 3rd party programok kijelzése között az a nagy különbség, hogy a játék eléri a VRAM-ot, míg a 3rd party programok nem is látják. Emiatt egy nagy kövér hasraütéses tippelés, amit csinálnak. Én ezeket szoktam nézni RGP-vel, és a közelében sincs a valóságnak DX12-ben vagy Vulkan API-ban az afterburner. A legközelebb a Windows 10 feladatkezelőjében beépített mérő jár. Nem annyira pontos az sem, mint egy profilozó, de tényleg nincsenek 50-60%-os eltérések, inkább 3-5%. Az meg ugye reális, mert a profilozó az mégis egy frame-ről ad információt, míg a Windows 10 mérője nem.
Az RE2 Remake egyszerűen ennyit kér. Az volt a koncepciója a Capcomnak a memóriamenedzsmenttel, hogy nyugodtan rá lehet adni az maxot, a játék maximum nem tölti be a legnagyobb textúrákat, ha nincs hozzá elég nagy memória. Ehhez egyébként az is kellett, hogy ne csökkentsék mesterségesen a textúrák felbontását, hanem úgy voltak vele, hogy leszállítják a natívot, ahogy elkészültek. A legtöbb játék esetében tudni kell, hogy messze nem kapják meg azt a minőséget, amin amúgy elérhető lenne. Egy csomó olyan döntést hoznak a kiadás előtt, hogy bizonyos textúrákból csak a megalkotott felbontású verziónak a felezett minőségét szállítják. Emiatt férnek bele a játékok jórészt a 8-12 GB-ba. De ha ezzel nem akarnak törődni, akkor ki lehet adni a tervezett minőséget, az bizony zabál rendesen. Ha jól működik a memóriamenedzsment, és képes kezelni ezt a problémát, akkor tulajdonképpen miért ne, akinek megvan a VRAM-ja élvezheti tényleg maximumon, akinek pedig nincs meg, annak a memóriamenedzsment megoldja a minőségcsökkentést.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#40889
üzenetére
Futtatni lehet a kódot bármin, maga a DXR úgy van felépítve, hogy ha van implementáció rá, akkor nem kellenek neki gyorsítást biztosító hardverek. Az a kérdés, hogy lesz-e 30 fps az új effektekből a mai hardvereken. Erre azért ne nagyon számítsatok. De lefutni lefut a kód.
-
Abu85
HÁZIGAZDA
A Vulkan az 1.2 óta eleve támogatja a HLSL-t. A shader modell 6.2-ig minden le van fedve a SPIR-V 1.5-ben. [link]
Egyébként új hardver nem kell. Az új DXR fejlesztések minden tudnak szoftveresen futtatni, ha az új lépcsőknek nincs hardveres háttere. Az egész DXR-nek meg van írva a teljes fallback compute shaderre. Ugyanígy a Vulkan API-ban is lesz egy compute shader fallback, ha a hardver nem alkalmas az egyes lépcsők gyorsítására. Vagy azért, mert nincs benne megfelelő célhardver, vagy mert az elavulttá vált.
-
Abu85
HÁZIGAZDA
Eleve nem lesz két memória a játékhoz. A másik arra szolgálhat, hogy a segédprocesszor futtassa az OS-t.
A konzolokon pedig van közvetlen memóriavezérlés. A PC-n azért kell sok RAM, mert az OS menedzseli az allokációt, elég rosszul. Egy konzolon az alkalmazásnak a feladata ez, és az sokkal hatékonyabb, mert alkalmazáshoz szabott allokáció van töredezettségmentesítéssel. -
Abu85
HÁZIGAZDA
Ennél sokkal több kell az exascale szintű skálázhatósághoz. Nem véletlen, hogy háromból egyben sincs NVIDIA. Ilyen méretben óriási hátránnyá válik a gyártók keverése, amíg nincs egy igazán jól működő szabványos megoldás a skálázhatóság problémájára.
Az IBM-mel pedig azért gyorsabb az NV, mert máshogy lehet összekötni a gyorsítókat ilyen formában, de ez nagyon kevés az exascale rendszerekhez. Ilyet tudni fog a Milan+CDNA is az AMD-nél, de mégsem erre építi a DoE az exascale megrendeléseit, mert úgy kell kialakítani a konfigurációt, hogy minden gyorsító össze legyen kötve a procival, és a gyorsítók is legalább egy gyűrűs kapcsolatra fel legyenek fűzve.
Ha tényleg csak annyi lenne, ahogy leírod, akkor a sok CUDA kód nyerné az NV-nek a tendereket, de baromira bonyolultabb a probléma ekkora méretben, ami más hardveres dizájnt követel, és ezért bevállalják a kódkonverziót is. Ugye nincs más választásuk. Nyilván nekik is sokkal egyszerűbb lenne az Intel és AMD procik mellé NV gyorsítókat kérni, csak a tervezett méretben sajnos nem működik.
-
Abu85
HÁZIGAZDA
Sajnos nem. Az exascale skálázhatósághoz nem elég csupán a GPU-kat összekötni egy gyors memóriakoherens interfésszel. Szükséges az is, hogy a CPU-kkal is meglegyen ez a kapcsolat. Na most a szuperszámítógépekbe használatos node-oknál nem igazán használnak ilyen megoldást, mert például az IBM-nek nincs nagy haszna abból, ha csak egy gyorsítóra korlátozza le a processzoraik használhatóságát, annyira általánosra tervezik a procit, amennyire lehet. Az Intel és az AMD azért tudja ezt megcsinálni, mert saját maguk csinálnak CPU-t és GPU-t is. Egyszerűen arra koncentrálnak, hogy legyen meg az általános gyorsító használatának a lehetősége, de azért hoznak kompromisszumokat, hogy a saját interfészeik előny élvezzenek. Ráadásul a többséget az is akadályozza, hogy a piac nagyon-nagyon-nagy része x86/AMD64.
Ha annyira egyszerű lenne ez, hogy mehetne az IBM/NV, akkor nem maradtak volna ki háromból három exascale projektból. Azért korábban ezeket az SC tendereket rendre behúzták. Ehhez képest az egyik projekt konkrétan kockáztat az Intel GPU-val, nincs más választás, ha a CPU is Intel.
-
Abu85
HÁZIGAZDA
Ez a szerverpiac. Az AMD CDNA-ba rak csak IF-et. Az RDNA nem valószínű, hogy valaha megkapja, legalábbis nem annyi linkkel, amennyivel a CDNA.
A lényeg itt az Intelnél és az AMD-nél is az, hogy csináljanak egy saját interfészt, amivel összekötik a CPU-ikat és a GPU-ikat. Ettől persze megmarad a PCI Express, de az nem lesz memóriakoherens. Majd talán a PCI Express 6.0-tól, de ez nagyon talán. Annyi viszont látszik, hogy máris nyerik az Exascale tendereket, és ehhez csak annyi kellett, hogy csináljanak egy-egy specifikus összeköttetést, amit csak ők támogatnak, és ettől a CPU kiválasztása eldönti a GPU kérdését is.
Ú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.
- Apple iPad Air 2 (A1567) 16GB Wi-Fi + Cellular Asztroszürke
- EREDETI NINTENDO Pokemon Go Plus autocatcher dobozban eladó
- HP Victus Gaming Laptop INTEL I7-14700HX / RTX 4070 32GB RAM 1TB SSD Gari
- Lenovo Thinpad üzleti kategóriás notebookok - i5 - i7 - Ryzen - nagy választékban számlával
- iPhone 8 64GB 100% (3hónap Garancia)- AKCIÓ
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Szimplán compute shaderben le van implementálva. Az új Call of Duty ezt használja, és minden DirectX 12-es VGA-n megy.


