Hirdetés
-
Érkezik a Cooler Master X Silent Edge Platinum tápja
ph Betartva előzetes ígéretét, június végén kezdi szállítani 850 wattos passzív tápját a cég.
-
Az USA tisztifőorvosa figyelmeztető címkét ragasztana a közösségi médiára
it Figyelmeztető címkéket szeretne látni az USA tisztifőorvosa a közösségi médiában, ami főleg a serdülők számára lenne emlékeztető a platformok súlyosan káros hatásairól.
-
Alan Wake II: Night Springs teszt
gp Hirtelen, egy E3-pótlék rendezvényen került bemutatásra az Alan Wake II első kiegészítője. A Night Springs három játszható karaktert is ad – de egész biztosan nem azokat, akikre gondolnál.
-
PROHARDVER!
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#16120
üzenetére
Úgy, hogy az utasításarchitektúra nem csak utasításokból áll. Annak része a memóriaarchitektúra is.
Az NV a Pascalban implementált először egy hasonló rendszert, de annak az volt még a hátránya, hogy CUDA-specifikus volt. Emiatt csak CUDA programnyelven üzemelt, illetve csak a GP100 tudta. A GV100 az első NV hardver, ami tulajdonképpen rendszerszinten, vagyis nem specifikusan egy programnyelvre/API-ra vonatkozóan oldja meg a GPMP-t, mint fícsőrt. Ez azért fontos, mert így OpenCL-re is működni fog, ami lényeges tényező egy olyan piacon, ahol kvázi kész szoftverekre vásárolnak hardvereket. Viszont ehhez már kellett az ATS a multiprocesszorokba.
A Volta és az Vega GPMP-je között csak annyi az eltérés, hogy a GV100 Power9-cel kompatibilis, míg a Vega 10 x86/AMD64-gyel, illetve a GV100 csak blokkszintű elérését támogat, míg a Vega 10 blokk- és bájtszintűt is. Ezért van ugye az SSG termékvonal.
Egyébként a Vega 10 is üzemképes Power9 mellett, ahogy a GV100 is x86/AMD64 procival. Csak egyik GPU sem tudja lefordítani a memóriacímet, mivel nem ismeri az ATS egység a host processzor memóriaarchitektúráját.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#16122
üzenetére
Mondták a HBCC-ről, még a decemberben, hogy csak Intel/AMD host CPU-val működik. Ha IBM mellé rakod, akkor üzemképtelen, mert nem támogatja annak a memóriaarchitektúráját. Na most ebből világosan következik, hogy az ATS-nek az x86/AMD64 memóriaarchitektúrára fordít, vagyis minden ilyen hardverhez szükséges az x86/AMD64 licenc legalább a memóriaarchitektúrára vonatkozóan.
Az NV-nek nincs is más választása. A Power9 licencelhető, míg az x86/AMD64 nem az. Az AMD licencelhetné a Power9-et, de nyilvánvaló, hogy a saját processzoraikhoz szeretnének dolgozni.
Radeon vonalon annyi jelentősége van, hogy nem kell az AMD-nek 30-50 GB-os memóriákban gondolkodni. Elég kicsire tervezni a HBC-t és a HBCC majd megoldja a többit. Ugyanígy a Radeon Pro vonalon a HBCC megkíméli a filmstúdiókat az assettek feldarabolásától. Egyszerűen csak beállítanak a driverben egy 512 GB-os szegmenst, vagy ha nincs elég rendszermemóriájuk, akkor vesznek egy SSG-t.
Gaming vonalon az NV-nek sem lesz ebből semmi gondja. Raknak 24 GB-ot a hardverre is ellesznek. Pro vonalon meg mehet a 48 GB. Nem létszükséglet a HBCC, csak marha sok memória kell nélküle.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#16124
üzenetére
Inkább mond el, hogy szerinted hogyan tud egy ATS x86/AMD64-es laptáblákat elérni licenc nélkül?
Az NVIDIA része az OpenPower konzorciumnak, így joga van felhasználni a Power9 egyes részeit. A Power9 lényegében úgy licencelhető, hogy az adott cég az OpenPower alapítvány tagja lesz. [link] - alul megtalálod a tagokat.
Az IBM-mel van egy szerződése az NV-nek, hogy a kölcsönösen támogatják egymás törekvéseit a HPC vonalon. De itt sincs az NV-nek más választása. Az Intel és az AMD nem fog NVLinket építeni a processzoraikba, míg az AMD mondjuk megoldja magának a GMI-t.
Azért forgalmaznak Intel CPU-t, mert nagyon sok helyen x86/AMD64-re van szükség. Nyilván ha tehetnék, akkor már rég ott lenne a Voltában az x86/AMD64-gyel kompatibilis ATS, de nem ad nekik licencet az Intel és az AMD. Egyelőre tehát a Volta ilyen: On IBM Power platforms, new Address Translation Services (ATS) support allows the GPU to access the CPU’s page tables directly. [link]
[link] - Akkor nézd meg, hogy meddig juttat el a HBCC, és meddig egy szimpla VRAM konstrukció.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem biztos, hogy annyi lesz, mert az SM száma GPC-nként változhat a Tesla és a sima dizájnok között.
A GV104-en, már ha követik a korábbi kódjelzést, akkor 384 bit és GDDR6 memória lesz. A HBM2 nekik azért nem jó, mert kicsi lenne a VRAM. Az AMD-nek elég, mert bevágod a driverben a HBCC szegmenset 16 GB-ra és bőven elvagy akkor is, ha a kártyán fizikailag csak 4 GB van. Az NV-nek mindenképpen fizikai memóriában kell gondolkodni, tehát bármennyire is csábító a HBM2, a GDDR6-tal nagyobb kapacitást lehet építeni, és ez jelenleg fontosabb.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Benne van a gyártóknak leadott roadmapban. MR-Volta lapka van benne. Nem tudom, hogy mit jelent az MR. De 384 bites memóriabusza van, GDDR6 memóriákat támogat GDDR5 backfall móddal (GDDR5X nincs, legalábbis nincs jelezve), illetve az van mellé írva, hogy 24/48 GB. Ez eléggé tuti forrásból való infó, korábban az early Intel dolgokat is nagy pontosságból megmondta.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
janos666
#16134
üzenetére
Pont az a baj, hogy az Intelnek nem tetszik az NV ténykedése ezen a piacon. Ha haszna lenne belőle, már adtak volna nekik licencet, de mivel az NV az Intelre nézve inkább kártékony, így soha semmit sem fognak nekik adni. Még a régi szerződésüket sem újították meg, hogy az NV nehogy alkupozícióba kerüljön. Az Intelnek az az elsődleges érdeke, hogy az NV innen tűnjön el. Nyilván ezt nehéz elérni, de ha lehetőségük van rá, akkor tesznek azért, hogy gyengítsék őket. Az Intelnek úgy általánosan is baja van a dedikált GPU-kkal, nem akarja ezek létezését, mert veszélyeztetik a hosszabb távú terveiket.
Azt is számold bele, hogy mit nyernének vele. Aki akar ilyen hardvert vesz magának Vegát. Az Intelnek olyan mindegy, hogy milyen dGPU-t veszel, semmiféle előnyük nem származik belőle, hogy Vega helyett valamilyen GeForce-ot vásárolsz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ugyanazt, amit az AMD. Csak a lapokat mozgatná komplett allokációk helyett. Ez azért előnyös, mert ha például csak 4 kB-nyi információ kell, akkor elég azt beírni a GPU memóriájában, míg ma ugyanezért lehet, hogy 100-200 MB-ot is mozgatni kell a PCI Express buszon keresztül, hiába kell ebből csak 4 kB. Emellett a hardveres menedzsment is előny.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A HBCC-nek a konzolokban nincs haszna. Az a probléma amire ez reagál csak PS-specifikus. A konzolon nem létezik.
A GPGPU-ban sincs igazából haszna, maximum a HPC környezetben. Ahol ez még hasznos az a sugárkövetés, illetve minden olyan grafikai feladat, amire nem elég a VRAM. Tipikusan ide tartozik a valós idejű leképezés is, vagyis a játék.Pont az lényeg, hogy felesleges 100 MB-os allokációkat másolgatni a VRAM és a rendszermemória között, ha abból csak 4 kB-nyi adatra van szükség. Egyszerűen a maradék adat csak állni fog, de nem tudod kidobni, mert kell belőle egy nagyon aprócska szeletecske.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A konzoloknál a HBCC azért nem előnyös, mert ez a rendszer arra a problémára reagál, hogy a GPU memóriája, illetve a CPU és a GPU által is elérhető memória között kell mozgatni az adatokat, és ma ennek a hatásfoka rossz, elsődlegesen azért, mert a szoftver menedzseli ezt a folyamatot, és csak allokációkat tud mozgatni. A konzoloknál maga az alapprobléma sem létezik. Nincs több különálló memória, illetve a memória vezérlését sem két OS folyamat (Mm és VidMm) felügyeli, hanem maga a program, ráadásul úgy, hogy az OS ezt a memóriát még csak nem is látja, maga a virtuális memória sem létezik. Tehát minden olyan probléma, amit a HBCC kezel egy nem létező tényező a konzolokon. Ergo nincs mit kezelni ott.
A PCI Express busz is része a problémának PC-n, mert akkor is nagy adatmennyiséget kell mozgatni a GPU memóriája, illetve a CPU és a GPU által is elérhető memória között, ha csak kis mennyiségű adatot igényel a GPU. Ugyanis a szoftveres menedzsment csak az allokációkra tud kiterjedni, vagyis nem tudod megmondani az operációs rendszernek, hogy az adott allokációból neked csak egy-két lap kell és csak azt töltse be. Muszáj a teljes allokációt betölteni a GPU memóriájába.
Már ma jóval nagyobb adathalmazokkal dolgozhatnak a játékok, mint amennyi VRAM van a VGA-k többségén. Ezt kínálja a streaming. Persze a fejlesztők nyilván ügyelnek arra, hogy sose szállítsák le az elkészített legjobb minőségű tartalmat PC-re, mert úgy sem futna semmin, ergo kiválasztják azt a minőségi szintet, amivel még jó a program 12 GB VRAM-mal és 16 GB RAM-mal. Ez ugyanakkor csak döntés kérdése. Akár megtehetnék azt is, hogy az elkészített tartalmat a legjobb minőségben is letölthetővé teszik és majd egyszer lesz olyan hardver, amin elindul.
Amit linkeltél az tartalomvizualizáció. Nem számít, hogy akadozik, mert ehhez hozzá vannak szokva az érintettek, ugyanis a cél az, hogy betöltse a GPU, és meg tudják nézni, hogy az offline renderen hogy néz majd ki a készített tartalom. Ha rosszul, akkor dolgoznak még rajta, és újra ellenőrzik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem így van. Eleve nincs a konzoljátékoknak 8 GB memória. 5-6 GB közötti terület van, illetve az XOX-en 8 GB. Ezt a program konkrétan lefoglalhatja. Elküld az operációs rendszernek egy igényt, és az OS ahhoz a területhez többet nem nyúl. Nincs se virtuális memória, se semmilyen OS folyamat. Ezt a legtöbb program, úgy a megjelent játékok 95%-a egybefüggő területként foglalja le. Ennek azért van jelentősége, mert az allokáció a már lefoglalt memórián belül sokkal gyorsabbá válik, illetve ezáltal olyan dolgokat tudnak tenni a fejlesztők, hogy az egyes blokkok között felszabadított részekre egyszerűen rátolják a következő blokkot. Ez tulajdonképpen a defragmentációs stratégiákat teszi nagyon hatékonnyá. Persze van olyan program, ami fix blokkméretekkel dolgozik, de olyan is, ami a blokkokat a memória végére és elejére pakolja, így a lefoglalt terület fizikailag középen telik meg, ami kedvezőbb, mintha csak egy irányból történne a blokkok lefoglalása.
Másolgatni azért nem másolgatna, mert minek. Ugyanazt a lefoglalt memóriát ugyanolyan sebességgel éri el a GPU és a CPU is. Csak akkor érdemes az OS virtuális memóriáját használni és az OS menedzsment folyamatait igénybe venni, ha nagyon nem számít a játéknak a teljesítmény, mert ez a módszer sokkal lassabb.Abban a működési modellben, ahogy a konzolon futnak a programok a HBCC egyszerűen nem tud segíteni. Igazából erre PC-n is csak azért van szükség, mert az OS menedzseli a memóriát és a VRAM-ot két teljesen általánosra paraméterezett folyamaton keresztül. Ha mondjuk elérhető lenne az PC-n, hogy az OS-től kérjen a fejlesztő x GB memóriát és y GB VRAM-ot, amit az OS nem is lát, akkor ide sem kellene HBCC. Csak erre a Windows nem ad lehetőséget. Nyilván jó okkal, mert ilyenkor a fejlesztőnek egyenként kell lekezelnie minden lehetséges memóriakonfigurációt, amiből azért van pár száz. Konzolon ez azért reális alternatíva, mert egy géptípusra csak egy konfiguráció van. Nem tudod tetszőlegesen bővíteni a memóriáját.
Igazából eléggé jellemző. A frame-ek között rendkívül kevés új adatra van szükség, mert nagyon keveset változik a jelenet.
Nyilván olyan játékra gondoltam, amelynek a motorja képes kezelni 1kx1k-nál nagyobb textúrákat is. A Destiny 2-be hiába raknának nagy felbontású textúrákat, a motor nem támogatja őket.
A konzolok teljesen más menedzsmentet kapnak, mint a PC. Egymást ez a két platform ma már nem limitálja, mert a tartalom szempontjából nem igazán drágább mindenből jobb minőségűt csinálni, majd azt a platform igényeire leskálázni.Nem tudták megnézni. Eddig az volt a bevált recept, hogy a tartalomvizualizálásnál a tartalmat több kisebb szeletre bontották, akár ezerre is, hogy beférjen az a kis szelet a VRAM-ba. Ezután egyenként töltötték be ezeket és egyenként ellenőrizték. A HBCC ezt szükségtelenné teszi, mert elméletben 512 TB-ig a hardver automatikusan lekezeli a problémát. A gyakorlatban még csak 7 TB-ig próbálták ki, ezt látod a videóban. Eredetileg ezt a 7 TB-os adatot fel kellett osztani 16 GB-os részekre, és azokat egyenként tudtad betölteni, ha az egyiket ellenőrizted, nézted a másikat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De ő a koherenciáról beszél, nem arról, hogy különálló területet csinál. A memória egységes, de kérheted, hogy a lefoglalt részt csak a CPU, csak a GPU, vagy a CPU és a GPU együtt, vagy teljesen koherensen a rendszer érje el. Ez a négyféle megoldás van. A konzoljátékok zöme nagyrészt a CPU+GPU-t kéri, mert így mindig a leggyorsabb a hozzáférés, viszont a memóriaterület nem lesz koherens, de a másolgatást így is teljesen megúszod. A régebbi játékok ezzel még nem éltek, mert csak később adták hozzá a lehetőséget a firmware-hez (ezért írtam 95%-ot). Amelyik játék teljesen koherens területet is akar, az nyilván kialakít egyet. Annak az elérése nagyon lassú, viszont roundtrip nélkül tud a GPU dolgozni a CPU adatain, ami egy frame előny, tehát valamikor megéri.
A memóriát mindenképpen a memóriavezérlő éri el, és az fixen teljes sávszélességű. A korlátozás onnan kezdődik, hogy hova megy az adat, és aszerint van limitálva a belső adatbusz. Egyetlen esetben van korlátozva a GPU, mégpedig a teljesen koherens hozzáférésnél, mert akkor az adat a GPU felé is a CPU adatbuszán keresztül közlekedik.
A Forza 7 pedig 100 GB. Nőnek a lehetőségek.
Az az adat a Baahubali filmhez használ város adata. Az pedig 7 TB. Ez még kicsinek számít a filmek tekintetében. Ennél többet is dolgoznak Hollywoodban. Azt hiszem A barátságos óriás a csúcstartó 3 PB-tal, de a Hobbit harmadik része is 2,3 PB körül van. Ebből a nagy csatajelenet alapjául szolgáló terület 50 TB körüli.
Ez csak vizualizáció. Itt nem fogják szerkesztgetni. Arra szolgál az egész, hogy lássák az offline felhasználás előtt, hogy a modell miképp néz ki. Nyilván az az előnyös, ha egyben látják az egészet, és emiatt van az, hogy Hollywood nem is nagyon dolgozik GPU-kkal, hanem vesznek több tucat CPU-t a feladatra. Ezt Hollywood megteheti, de Bollywood nem, mert egy nullával több lenne a tartalom előállításának végösszege.[ 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
Looserke
#16416
üzenetére
Ilyen általános bányászcuccot nem is igazán lehet fejleszteni. SHA256-ra csinálhatsz ASIC-ot, de mondjuk Ethashre vagy Cryptohashre már rohadt nehéz. Főleg úgy, hogy az NV ezerszer elmondta, hogy a bányászat őket nem érdekli, csak a blokkláncra fókuszálnak. Persze a média egy része ehhez a technikai részhez iszonyatosan süsü, tehát lassan bevesznek bármit, amit eléjük rak egy random informátor.
Inkább az lehet, hogy sokan benyalták ezt az Ampere dolgot, mert egy hsz-ben leírta egy random regisztrált tag. Értsd úgy, hogy nem csak egy hírt írtak róla, hogy egy random ismeretlen tag elejtette az Ampere nevet, így ez a pletyka van, ami egyébként még elfogadható, hiszen belefér az alapvető tájékoztatásba, maximum kiderül, hogy nem igaz. Viszont nagyon sokan ütötték tovább ezt a vasat (ennyi légy nem tévedhet ugye
![;]](//cdn.rios.hu/dl/s/v1.gif)
), majd most, hogy jött egy szavahihető forrás, és nem az Ampere nevet hozta, hanem a Turingot, mindenki elkezdte keresni a logikát, persze jelen esetben abszolút kizárva azt, hogy az Ampere csak kamu volt, mert túl sok hírt írtak róla. 
Az igazság az, hogy senki nem tud semmit, viszont a hírek egymásnak kegyetlenül ellentmondanak. A legvalószínűbb eshetőség, hogy a Turing az a következő architektúra neve, és ennyi ami biztosnak tűnik. Minden más csak hozzáköltött adat. Másrészt Turingot nagyon sokan csak a kódtörésről ismerik, de a valóságban sokkal több köze volt a mesterséges intelligencia kutatásához.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#16422
Abu85
HÁZIGAZDA
Németh Péter
#16420
Abu85
HÁZIGAZDA
válasz
Németh Péter
#16420
üzenetére
A HMC-t elhiszem, csak legyen bányász aki meg tudja fizetni.
Technikailag biztos megoldható, mert a mérnökök problémákat kezelnek, és bármire képesek megoldást találni. A kérdés az, hogy market friendly lesz-e a végeredmény.(#16421) golya87: Nem tudom. Én az Ampere-ről sose halottam semmit az OEM csatornákon. Igaz a Turingról sem, de utóbbit jobban elhiszem, mert a Reuters mondta, nem egy fórumozó.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#16427
Abu85
HÁZIGAZDA
Németh Péter
#16423
Abu85
HÁZIGAZDA
válasz
Németh Péter
#16423
üzenetére
Csak ennyivel azért tuti nem tud gyorsabb lenni. Ha lehetne, akkor már rég sorra készülnének az ASIC-ok. Régen az is szerencse volt a BitCoin ASIC-oknál, hogy a programom még nem voltak kigyúrva GCN BFI-re és az alignbitre, vagy az újabb NV architektúráknál a lop3-ra. Ma már azért alapvetően célirányos az optimalizálás, tehát nem csak egy szimpla GPU ellen kell küzdeni, hanem pár olyan speciális utasítás ellen, ami kifejezetten jól használható a blokkláncra.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#16430
Abu85
HÁZIGAZDA
Németh Péter
#16429
Abu85
HÁZIGAZDA
válasz
Németh Péter
#16429
üzenetére
Olvastam. Nekem is van ötletem: 2 MB/thread+5 GHz. Kész.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az a baj ezzel, hogy pont volt egy erre vonatkozó kérdés nemrég az egyik előadáson. Hogy miért nincs ROP vagy textúraszűrő nélküli Tesla. A válasz az volt, hogy ezek a részegységek igazából egymáshoz igazított blokkok. Konkrétan azt mondták, hogy olyanok, mint a legók, csak bonyolultabb összerakni őket, de a cél ugyanaz. Viszont a tervezésük eléggé sok pénzt és időt emészt fel. Emiatt az egyes blokkokból nem csinálnak sok verziót, mert például a textúraszűrőket ki lehet ugyan venni, de rengeteget kell rákölteni, miközben alig nyernek vele a tranzisztorok oldalán, és növeli a hibalehetőséget. Ugyanez a ROP-oknál. Le lehet butítani őket, de sok pénzbe kerül, és elenyésző, amit nyerni lehet. Végül egy ultimate ellenérv, hogy ajánlott a lehető legkevesebb lapkát tervezni a lehető legkevesebb blokkvariánssal, mert olyan ez, mint programot írni (és ezt is így mondták), csak itt egy "fordítás" 70 millió dollárba kerül. Tehát nincs sok lövés, lehetőleg egy vagy maximum két "fordítósából" kell megcsinálni. Emiatt a legtöbb blokk az egész skálán egységes, mert az első lapkánál kiderül, hogy jó-e. Ha van egy másik blokk, akkor az aránytalanul növeli a hiba kockázatát, ami végül pénzkidobás lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A HBCC-nek a játékosok szemszögéből akkora jelentősége nincs. Lazán lehet ellensúlyozni azzal, hogy 8 GB helyett raknak a VGA-ra 24 GB memóriát. A gyártók számára persze ez fáj, főleg a mai memóriaárak mellett, de majd belerakják az ajánlott árba ezt a költséget. A professzionális piacon inkább probléma a HBCC hiánya, hiszen amíg az AMD tud 2 TB-os fizikai kapacitású, összesen 512 TB-nyi tartalmat kezelő VGA-t kínálni a filmgyártóknak, addig más megáll 24-32-48-64 GB-nál, ami azért baj, mert fel kell bontani a tartalmat ilyen apró részletekre, hogy egyenként beférjen a memóriába, és ez eléggé megnöveli a vizualizálásra fordított időt. Az AMD-nél ezt nem kell megcsinálni. Az egész betölthető darabolás nélkül, méghozzá addig, amíg a tartalom mérete nem lépi túl az 512 TB-ot, bár azt tudni kell, hogy az AMD alkalmaz egy szoftveres korlátot, így az egyes Radeon (Pro) VGA-knál 256 TB a maximum. Itt egy kicsit terelik az extrém igényekkel rendelkező vevőket a legdrágább hardver felé.
Az Intelnek nincs nagyobb hatalma a PCI Express szabvány felett, mint bárki másnak. Ugyanolyan jogokkal rendelkező tag, mint az AMD vagy az NV. Persze alapító tag, de ez nem jár kiemelt jogkörrel. A probléma tehát alapvetően azzal van, hogy az FTC határozata túlságosan rövid ideig kötelezte az Intelt arra, hogy a VGA-k felé x16-os PCI Express sávot vezessen ki. Ma már a mobil platformokban csak x8 sáv van, és nyilván, ha ezekre kötik a pGPU-t, akkor még kevesebb lesz kifelé. Ezért lenne jó, ha az FTC beavatkozna újra, mert biztos van valamilyen kompromisszumos megoldás. Akár egy olyan, hogy az NV fizet az Intelnek és az AMD-nek egy FTC által meghatározott összeget lapkánként, hogy az említett két cég kifelé biztosítson x16-os PCI Express interfészt. Az Intelnek és az AMD-nek, így az ezzel járó anyagi teher meg lenne térítve, míg az NV kifizetné a saját piacának fenntartását.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az FTC alapvetően nem szeret beavatkozni a piacba. Nekik alapvetően nem ez az elsődleges céljuk, illetve egyszer már adtak időt az NV-nek, hogy álljanak saját lábra. De ha az NV mondjuk megkeresné őket ezzel a panasszal, és tényleg javasolna egy olyan megoldást, hogy állja az AMD és az Intel felé az összes többletköltséget, ami a piacuk fenntartását célozná, akkor talán lenne miről beszélni. De ez biztos nem egy kötelezés lenne az Intel és az AMD felé, hanem inkább egy egyeztetés, aminek keretében ezek a cégek végre leülnek egy asztalhoz.
Na most végeredményben az Intel és az AMD azzal nem járna anyagilag semmiképp sem rosszabbul, hogy ha az NV átvállalja a költségeket. Egyrészt minden extra munkát kifizetnek külső forrásból, másrészt a tokozáson úgyis eladják a pGPU-t, akár letiltja az OEM, akár bekapcsolja. Tehát pénzben ugyanott lesznek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
2015-ig kényszerítette az Intelt az FTC, hogy legyen a platformjaikban x16 sáv a VGA-k felé kivezetve. Ezt azért tették meg az előző évtized végén, mert úgy ítélték meg, hogy az NV 2015-ig képes lesz kihozni egy saját platformot, ami mellé társíthatják a VGA-ikat, így nem függnek majd az Intel és az AMD platformjaitól. Ez a döntés is igen sok bírálatot kapott, mondván túl erős beavatkozás a piacba, de nagyjából elfogadta mindenki.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Gondolom saját nagy teljesítmény processzorra. Alapvetően az FTC-t nem különösebben érdekli az, hogy az adott kényszerítés kedvezményezettje él-e azzal a lehetőséggel, amit adnak nekik, vagy sem. Ők csak megpróbálják törvényes keretek között szabályozni a piacot. Úgy, hogy egyik fél se szenvedjen a döntésekből jelentős hátrányt.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem azért, de az Intel és az AMD útitervében nem csak a GPU CPU-ra helyezése szerepel 3D-s tokozással, hanem ott lesz a CPU-n a felejtő memória és a nem felejtő memória is. Szóval igen, ebből is lesz majd idővel probléma. Leginkább azoknak a memóriagyártóknak, akik pont lemaradtak vagy az Intel, vagy az AMD hardvereiről.
(#16532) Loha: Teljesen mindegy, hogy az Intelnek versenyképes-e ez alternatívája. Ez a cég teljesen másképp működik, mint az NV és az AMD. Egyszerűen saját gyárai vannak, amelyeket ki kell használni, tehát még ha a lapka nem is versenyképes, akkor is nagy mennyiségben legyártják, és betolják az OEM-ek segge alá. Azt, már leszarják, hogy az OEM aktiválja-e, felőlük le lehet tiltva ma is az IGP, mert azt az OEM már kifizette, te pedig kifizeted az OEM-nek a gép megvásárlásánál. A pGPU-val sem lesz másképp. Kifizettetik, aztán nekik olyan mindegy, hogy az adott gépben dísz lesz-e vagy sem, arra elég volt, hogy a gyárakat jó hatásfokkal kihasználják.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Hogy ne legyen találgatás ... erről az előadásról van szó. A Microsoft bemutat egy Ray Tracing API-t, ami a DirectX compute shaderre épít, plusz ennek lesz egy közvetetten kapcsolódó kiegészítése az új DirectX verzióban, ami a ray tracinghez optimális memóriamenedzsmentet teszi lehetővé. Nyilván API interoperability mellett nem feltétlenül van DX-hez kötve, lehet Vulkan is.
Ehhez a gyártók bemutathatnak különféle DXR kiegészítéseket. Ezek is ott vannak már a GDC adatbázisában: AMD és NV
Maga a DXR API szabványos. A gyártói DXR kiegészítések szabványossága attól függ, hogy megoldhatók-e magából a szabványos API-ból, vagy mellé lesznek szervizkönyvtárak (AMD AGS, NV NVAPI). Egyébként ezekhez nem feltétlenül kell új hardver. Maga az implementáció nem igazán követel többet, mint a shader modell 6.0, de az egyes hardvereken nem feltétlenül jó a hatékonyság, így a gyártók dönthetnek úgy, hogy még elméleti működés mellett is inkább az újabb, erre a feladatra jóval alkalmasabb hardverekre korlátozzák a technikát. Ha nem korlátozzák mesterségesen, akkor maga a Microsoft DXR API az NV Maxwell és újabb, vagy a teljes AMD GCN palettán működhet, legalábbis az előzetes specifikáció alapján nem igazán látom, hogy ezeknél újabb hardverek kellenének. No persze világos, hogy sebességben az újabb dizájnok jobbak lesznek.[ 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
Televan74
#16544
üzenetére
Nézd papíron, már ami eddig kiszivárgott, én nem látom akadályát, hogy működjön Maxwellen és Pascalon. De az adott IHV egyedi döntése, hogy a régebbi hardverekre csinálnak-e implementációt, vagy sem. Szerintem ezt nagymértékben befolyásolja, hogy milyen a sebesség. Ha használhatatlan, akkor nincs értelme a régebbi hardverekre implementációt csinálni, még akkor sem, ha elméletben amúgy lehetséges ... úgyis maximum diavetítésre tudnád bekapcsolni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Csakhogy a félreértéseket elkerüljük. A DXR egy API. Kb. olyan, mint a DX12. Persze picit épít rá, de mindegy, a lényeg, hogy ez csak egy interfész a programozásra. Ehhez aztán még kellene az effektek shaderekben, amelyeket nyilván hoz a Microsoft, hoz az AMD, hoz az NV, tudtommal a Futuremark is, stb-stb. Itt is szállítható az effekt szimplán forráskóddal vagy egyszerűen middleware-en keresztül. Ha úgy tetszik gondoljatok rá úgy, mint egy DX12-re sugárkövetéssel.
Bár ez azért eléggé leegyszerűsíti a dolgokat, de legalább egyszerű megérteni is. De most már nem spoilerezek tovább. 
[ 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
Crytek
#16579
üzenetére
Ezt utólag nem lehet megállapítani. A gyártó képes nagy pontossággal megmondani a kártyára rótt terhelés mértékét, de azt ők sem tudják megmondani, hogy a user bányászott vagy esetleg 3DMarkot futtatott.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az LDS kezelése. Össze van vonva az L1 és az LDS, így elég nagy a tár, amibe lehet nyomni az erőforrást. Persze megosztott meg minden, de úgy 40-50 kB per multiprocesszort ki lehet nyerni a dizájnból, amit tényleg fel lehet használni valós shaderekhez is. A korábbi dizájn 32 kB-ban eléggé nyersen volt limitálva. Ugyanígy az AMD-nél is a Vega előtt 32 kB volt a fix, mesterséges határ, míg a Vega óta dinamikus az LDS felosztása, így itt is elérhető úgy 40-50 kB per multiprocesszor. Ez azért elég lényeges, mert jelenleg a compute shaderek teljesítményét erősen az LDS kihasználása korlátozza. 32 kB mellett nincs elég wave, hogy a hardver hatékonyan működjön, de például 48 kB mellett már sokkal több konkurens wave futhat, így átlapolja a rendszer a memóriaelérést. Ez azért is lényeges, mert azokon a szemét konzolon szintén a fejlesztő dönthet az LDS méretéről, és például az Xbox One mono API-ját használó játékok előszeretettel használnak olyan compute shadereket, amelyek akár 44 kB-nyi LDS-t is felzabálnak a statikus particionálás során. Ezek ugyan futnának a régebbi dizájnokkal is, tehát nem feltétlenül igényelnek Vega és Volta architektúrát, de a régi rendszereken a wave-ek száma kisebb, így lassabban is futnak le a programok. Na most azzal, hogy a Vega és a Volta lépdel a hardveres alap tekintetében is az Xbox One elvei felé, és van már shader modell 6.0 is, ezeket a shadereket nem kell külön átírni PC-be, hanem egyszerűen a konzolra írt shader lefordítható, és kész, nincs vele többletmunka. Ezeknek egyébként elég nagy hatása van a real world teljesítményre. Nem mindegy, hogy egy hardver a maximum konkurens wave negyedét vagy felét futtatja, utóbbi jóval kedvezőbb teljesítményt ad, mert ha egy wave vár is az adatra, van egy csomó másik wave, ami futhat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az önmagában neked is jó, ha az Xbox One shadereit kapod meg PC-n. Ezek ugyanis már a befektetett munkaóra miatt gyorsabb kódok. Amiért ezeket nem lehet alkalmazni az a shader modell 6.x-től való függőség, illetve a hardveres nehézségek.
Ha az RPM-re gondolsz, akkor azt nem lehet kimérni, mert nincs szabványos kód Radeonra, így mindenképpen csak a gyors kód fut a GCN-eken. De volt a GDC-n előadás, aminél a vízről volt szó, és ott az RPM a kikerült infók alapján 9%-ot gyorsít a teljes frame-en. De persze nem csak a víz használ RPM-et, hanem a GPU-culling is, szóval ez azért torzítja az eredményt.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igazából nem. Egy konvertált kódot kapsz, amibe értékelhető humánerőforrást nem ölnek. Egyszerűen írnak rá egy programot, ami source-to-source alapon átnyomja és kész. Ezért van az, hogy sok fejlesztő akár külön kódot is ad ki Radeonra, mert az AMD ezt megcsinálja nekik. Ennyi még belefér, mert max két IR-t szállítasz.
A Wolf2 esetében volt róla szó régebben, hogy csak a gyors kódok miatt például a Vega ~20% pluszt kap a teljes frame-re. Effektíve ez azt jelenti, hogy nagyjából ennyivel, jó mondjuk az RPM előnyét leszámítva, de legalább ~10-15%-kal gyorsabb lehetne minden nem Radeon hardver, ha nem csak egy szimpla konvertálás lenne a munka konzolról PC-re. Szóval abszolút nem kevés teljesítményt lehet ebből nyerni.
A közhiedelemmel ellentétben iszonyatosan nincs optimalizálás. Az AMD csak odaküldi a saját embereit, hogy csinálják meg nekik, mert a munka nagy része a konzolból, ezen belül is a PS4-ből származik, erre felépítettek egy külön rendszert PC-be is, amivel a konzolos PSSL kódot igen kis befektetés árán tudják portolni HLSL extre, tehát végeredményben megéri, ha a játék DX11, DX12 vagy Vulkan API-t használ. Például az Intel és az NV nem küld erre a munkára senkit, mert náluk nincs hozott anyag a konzolból, de nagyobb gond, hogy ehhez kialakított rendszerük sincs, arról nem is beszélve, hogy nincs egy HLSL exthez hasonló modern shader nyelvük sem, amibe dolgozhatnának. Nekik egyértelműen csak a shader model 6 a kiút.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Miért mit gondolsz mit csinálnak? Például egy préselésnél, ha megszakadnak sem tudnak mbcnt és bollat nélkül gyors kódot írni. Mindenképpen lesz egy rakás atomic operáció wave-enként. Ha szénné optimalizálják a kódot, akkor is az atomic miatt lesz lassú, mert ez teszi ki a futtatási idő ~90%-át. A probléma az, hogy a régi specifikációjú PC-s HLSL-ből azok a függvények hiányoznak, amivel a lassú operációk tömeges alkalmazása elkerülhető. Ha ötmillió embert raknak rá, akkor is csak ~10%-nyi futtatási időt tudják optimalizálni, de az atomic operációkat mbcnt és bollat nélkül mindenképpen vállalni kell. Nincs menekülőút. Emiatt értelmetlen arra a 10%-ra erőforrást áldozni, mert a sebességet azok a lassú atomi operációk viszik el, amelyek HLSL 2017 vagy újabb specifikáció nélkül nem kiválthatók.
Persze. A Polaris és lényegében az összes GCN részesül ezekből a gyors kódokból, még az RPM-ből is, mert a register pressure sokkal kedvezőbb lesz, vagyis több wave futhat párhuzamosan. A Vega esetében persze már az alapvető tervezés szintjén is ezek voltak képben, például már nem csak több wave futhat, hanem az operáció költsége is feleannyi. A gyorsulás mértéke emiatt eltér az egyes GCN dizájnok között. De maga a kód működik, és mindenképpen gyorsít.
Bizonyos gyors kódokat már lehet szabványosan is írni a Vulkan 1.1-re is, a subgroup operációkra. Ilyenkor ezekből az előnyökből minden Vulkan 1.1-es implementációval rendelkező hardver részesülhet, nem csak a GCN-ek. Ebben a pillanatban ez nyilván mindegy, mert csak az AMD-nek van végleges Vulkan 1.1-es implementációja, de mondjuk úgy fél év múlva, már érdemesebb szabványos kódot írni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A fejlesztők döntő többsége Radeon GPU Profilert és GPU ShaderAnalyzert használ. Annál nagyobb tudású profilozók nem léteznek PC-re. Még a többi, akár fizetős megoldás is kevesebbre képes. Szóval a user oldalon is ugyanaz áll ma rendelkezésre, ami a fejlesztői oldalon.
A DX11 nem azért szar, mert sokat kell vele dolgozni, hanem azért, mert a meghajtó egy rakás teljesítményt befolyásoló tényezőt elrejt a fejlesztő szeme elől. Tehát nem látják, hogy hol vannak a problémák az alkalmazással, de igazából még ha látnák is, akkor sem tudnának vele mit kezdeni. Emiatt van az, hogy amíg nem volt explicit API, addig egyetlen gyártó sem biztosított nyomkövetést használó profilozót PC-re. Ilyet csak a konzolok kaptak, mert ott lehetett befolyásolni a működést a program oldaláról (az első ilyen konzol az Xbox 360 volt, de az új gépek közül már a PS4 és az X1 is tartalmaz nyomkövető hardvert). A Radeon GPU Profiler az első nyomkövetést használó PC-s profilozó, és nem véletlen, hogy csak az explicit API-kat támogatja, mert ezekben már lehet is valamit kezdeni a felfedezett limitekkel.
A Vega nem a többi GCN-hez képest élvezi ezt az előnyt, hanem ahhoz képest mérve, amikor nem a gyors kódok futnak rajta. És tényleg nem mindegy, hogy például a sűrűn használt préselésnél 64 atomi operációt futtat a kód, vagy csak egyet. Nem véletlenül hozta az MS át PC-re a shader model 6-ot, mert abban ugyanez megoldható.
A Volta ezeket a képességeket azért tudja, mert ahogy a Vegába, ebbe is bele van tervezve, hogy az elkövetkező másfél évben a shaderek csak bonyolultabbak lesznek, vagyis az LDS pressure csak nőni fog. Már csak azért is, mert a két konzol megengedi az LDS dinamikus felosztását, és a fejlesztők előszeretettel írják manapság 50kB-os terhelésre a compute shadereiket. Ha egy PC-s architektúra inkább 30 kB-ra van optimalizálva, mint mondjuk a Pascal, a Polaris és minden régebbi hardver, akkor a kódot ugyan képesek futtatni, de olyan alacsony lesz a wave-ek száma, hogy nem tudják a memóriaelérést átlapolni. A Polaris ezért vezette be a prefetchet, hogy ezt a helyzetet enyhítsék, csak időközben a prefetchet megkapta a PS4Pro és az X1X is, tehát a PC-s oldalon csak az előremenekülés marad. Az, hogy a Volta és a Vega ezeket levédi teljesen normális dolog. Az AMD és az NV is arra számít, hogy a shader model 6-tal a fejlesztők egyszerűen áthozzák az Xbox One (X) shadereket, tehát ahhoz az igénybevételhez kell igazítani a hardvert, amit a konzolokból kapni fognak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#16640
üzenetére
Van csak nem nyomkövetést használó. A teljesítményszámlálós megoldások rengeteg problémát nem mutatnak meg. Erre jó példa az Unreal Engine fejlesztése, amiben egy bő 10%-os lassulást okozó hibát addig nem vettek észre, amíg a Radeon GPU Profilerrel meg nem nézték. Persze sok fejlesztő eleve konzolon profiloz, de ez mondjuk ez például az Epic számára rendkívül körülményes lenne, mert le kell fordítani Xbox One-ra, ott megnézni a szintén nyomkövetést használ konzolos PIX-szel, majd a hibák javítása után újra konzolra kell fordítani, és megnézni, hogy mennyit javult, és ha nem elég, akkor menni kell még egy kört. Sokkal egyszerűbb a Radeon GPU Profiler, aminél a konzol kihagyható a képletből, miközben az eredmény ugyanaz lesz.
Erről eléggé hosszan beszélt a GDC-n Rolando Caloca, az Epic programozója, aki a Vulkan renderert írja a motorhoz, ha van hozzáférésed, akkor már beszerezhető innen: [link][ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#16642
üzenetére
Segítek. A nyomkövetést használó profilozóhoz nyomkövetésre képes hardver kell. Ezért nem elég szoftvert kihozni, mert nem tud miből olvasni. Amit linkeltél az egy teljesítményszámlálókat használó profilozó, illetve inkább egy teljes csomag. Olyan, mint az AMD-nek a CodeXL-je. Pontosan emiatt a működés miatt nem látta az Epic a linkelt csomagban található Range profilozóval az Unreal Engine bugjait. Ugyanúgy CodeXL-lel sem látták volna, mert az is teljesítményszámlálós megoldás.
A Radeon GPU Profiler igazából nem egy nagy dolog szoftveresen. Gyakorlatilag csak kiolvassa a Fiji és újabb GPU-kba épített nyomkövető hardverek elmentett adatait. Effektíve, amit ezek a szoftverek régebben megoldottak, azt az AMD nagyrészt átrakta hardverbe, így a szoftver már nem implementálja magát a trace folyamatot, mert azt a hardver csinálja.(#16643) gbors: Mivel a Microsoft shader model 6-ja tényleg a konzolokról való shader szállítást szorgalmazza, így amelyik program erre épít ott a Volta és a Vega kifejezetten kedvező lesz. Kedvezőbbek, mint a korábbi rendszerek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Sony nagyon x86/AMD64-en akar maradni, mert nem akarják újrakezdeni a szoftveres munkát. Ez a PS4-nél elég nagy kiadás volt. Szóval vagy AMD vagy Intel lesz. Attól függ, hogy melyikőjük hajlandó egyedi lapkát tervezni nekik, és persze mennyiért.
A Microsoft nem zárja ki az ARM-ot, mert a Windows kódbázisa azt is támogatja. Az IBM az abszolút kizárt. Arra biztos, hogy senki sem akar OS-t és teljes ökoszisztémát portolni. Főleg úgy, hogy a fejlesztők egyre inkább kiszámíthatóságot akarnak konzolon is, vagyis amit írnak egy új gépre, azt egyszerűen vissza szeretnék portolni a régiekre. Ezzel maximalizálják a vásárlóbázist.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Én nem hiszem, hogy az IBM-re annyira vágynak a fejlesztők. Azt nagyon utálták régen is. Nem véletlenül történt a váltás. Figyelembe véve, hogy mennyi munkával jár az átállás én ezt eleve kizárnám. Az ARM-nak abból a szempontból van realitása, hogy a Microsoftnak viszonylag kis munka lenne, és azért fejlesztői tapasztalat is van bőven. A Sony nem hiszem, hogy ARM-ra vágyik, mert nekik nem származna belőle túl sok előny. Inkább csak költségekbe vernék magukat.
A megrendeléstől függ, hogy az NV játszik-e. Ha a megrendelő egyedi lapkát kér, akkor biztos, hogy nem vállalják el. Nem rendezkedtek be erre. Még a Nintendonak sem javították ki a Tegra processzorbugját. Ha licencet vásárolnak, akkor azt természetesen tudnak adni, de kérdés, hogy akar-e valaki saját magának tervezni manapság, amikor meg tud bízni olyan cégeket, akik felvállalják ezt a kockázatot.
Attól, hogy binárisan nem kompatibilis, még a portolás lehet egyszerű.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A júliusban nem tudom, hogy mennyire érdemes bízni. Azért az ilyen rajtokat az NV nem két nap alatt hozza össze. A sajtónak, így nekünk is jó előre szólnak, legalább arról, hogy hol lesz valami bemutató, hogy legyen időnk megszervezni egy esetleges utat, ha esetleg megyünk. De egy büdös szó nincs egyelőre semmi ilyesmiről.
Én egyedül a Computex 2018-as rendezvényről tudok, ami GTC Taiwan néven fut. Ez a leírás alapján két részből fog állni. Az egyik AI, míg a másik valami "ultimate gaming experience". Utóbbi nem tudom, hogy mit jelent, de hallottam olyan pletykákat, hogy a BFGD-ről fog szólni. Erre vonatkozóan viszont nincs még részletes leírása az NV-nek.[ 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
Dyingsoul
#16933
üzenetére
A probléma annyi volt, hogy az eredeti G-Synchez tervezett FPGA-konfiguráció nem akart működni HDR mellett, ezért át kellett programozni. Ez tovább tartott a tervezettnél. Mivel másik hardvert nem akartak erre bevetni, így meg kellett oldani, hogy az öt éves modullal is működjön.
Itt már minden áthidaló megoldás, mivel új hardverre öt év alatt nem állt át az NV, annyi pénzt nem akarnak belerakni, de ettől még működik. Az élettartamra nem hiszem, hogy ez kihatással lenne. Az FPGA átprogramozható, ez a lényege.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A 12 nm azért nem hozott sokat, mert az egy half node. Tényleg nem sokat ér a 16 nm-hez képest. A 7 nm-re azért startoltak sokan, a TSMC 50 tape outról beszélt, mert az valós előrelépés, elvégre full node. Ráadásul van még egy nem használt full node is előtte ami a 10 nm. Ezt nem minden gyártó vetette be, de ez például lényegesen nagyobb előrelépés a 12 nm-hez viszonyítva, mint a 12 nm a 16-hoz viszonyítva. Szóval ezek a számok csalókák.
A hardvereknél a problémát sokszor a konzolok is jelentik. Nem a teljesítményük, hanem a bennük alkalmazott hardverek dizájnja. Például a raszter:ALU arány, amihez a PC-s hardverek leginkább a középkategóriában igazodnak. És ez sem igazából működik egy bizonyos szint felett. Meg lehet nézni, hogy a csúcs-GPU-k a gyakorlatban nem annyival gyorsabbak az egyel kisebbnél, mint amennyivel elméletben ezt lehetne várni. Nem véletlen, hogy ráment az AMD és az NV erre a raytracing irányra, mert igazából haszna nem sok van, azért valljuk be, hogy sok motor raszterizálásból is kihozott már iszonyatosan jó AO-t, reflectiont, meg a többit, és azokra a nüansznyi különbségekre nem fogsz figyelni, miközben lövöd szét az ellen hátsóját. A dolog annyi itt, hogy a raytracing iszonyatosan kedvez a PC-n a fenti problémának, vagyis alapvetően a csúcs-GPU-k picit eltolt raszter:ALU aránya jóval kisebb probléma lesz, mert maga a sugárkövetés egy szimpla compute feladat, ami ráadásul aszinkron fut a többi grafikai számítással. Már egy szimpla raytracing AO effekttel betömsz annyi idle rést a multiprocesszorokon, hogy simán a TFLOPS lesz az elsődleges limit. És mindegy, hogy milyen módon csinálod, DX12 vagy Vulkan, vagy a már elérhető speckó GPUOpen megoldás a Vulkan fölött, a hatása ugyanaz lesz a hardverre nézve. De amúgy látható eredménye azért megkérdőjelezhető lesz, még a hype hatására is. Egyszerűen arra jó, hogy a csomó idle ALU kapacitást be tudják fogni a gyártók, ezzel a teljesítmény is újrarendeződik TFLOPS-ok szerint.
(#17029) Keldor papa: A tensor az jó denoisingra a raytracinghez. Az más kérdés, hogy másra nem igazán.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Vegának ugyanannyit hoz, mint a többinek.
Nyilván a három megoldás közül kettő még el sem érhető, tehát persze ez rontja a kihasználás lehetőségeit.
Egyedül a GPUOpen konstrukció van bevethető állapotban.
Azt tudni kell azért a sugárkövetésről, hogy arányaiban piszok egyszerű, ha már van rá támogatás az API-ban, vagy az API felett. Emiatt is áll az AMD és az NV cerkája rá, mert oda tudnak menni a stúdiókhoz, hogy ugyan dobjanak már egy kis aszinkron feladatot az idle ALU-kra.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez sugárkövetés nélkül is lehet realitás. Ha egy leképező texel shadinget használ, akkor a shading függetleníthető a raszterizálástól. Innentől kezdve annyi GPU-ra osztod el ezt a munkát, amennyire akarod.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#17044
üzenetére
Ezek valójában 8 bites integer ALU-k a legkisebb egység szintjén, de mátrixba vannak rendezve. Ha kiveszik, akkor természetesen az összes ALU tranzisztorköltségét megspórolják. A tensor elnevezés a többdimenzionális tömbökből jön.
(#17043) Keldor papa: Annyira, mint a többire. Az explicit API-k azért eléggé leegyszerűsítették ezt a részt. Még ha az NV nem is dolgozik teljesen univerzális réteggel, API szinten csak egy absztrakció van az összes hardverre, és efölött vannak a kliens oldali különbségek, amelyeket külön lekezelnek hardverenként, ideértve a shader fordítót is. Amúgy a Vulkan és a DX12 implementáció hardverhez közeli absztrakciós szintjénél abszolút kezelhető egy felülettel a Maxwell-Pascal-Volta. Nem különbözik az architektúra annyira, hogy ebbe bele kelljen nyúlni. A Kepler és a Fermi igen, de ezekre már nem igazán koncentrálnak.
[ 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
BullKoxa
#17090
üzenetére
Az API frontján nagyjából látni lehet, hogy mi lesz. A Vulkan 1.1 az kész. Implementációk vannak rá. Ehhez lesz két raytracing kiegészítés. Egy GPUOpen, ami futni fog minden Vulkan 1.1-et támogató hardveren. Az NV készít egy másik kiegészítést, az csak Volta architektúrával működik. Kivéve persze, ha a kiterjesztésre írnak meghajtót a többiek, de már most megmondom, hogy az Intel és az AMD nem fog, az NV-nek pedig jó a Volta-only megoldás. Emiatt ha valaki Vulkan API-t használ biztos, hogy a GPUOpen kiegészítést használja majd raytracingre, mert azzal minden hardvert elér, a tiedet is.
A DirectX esetében a DXR bonyolultabb. Ennek lesz egy Microsoft által támogatott szoftveres rétege, ami minden olyan hardveren fut, ami támogatja a DirectCompute API-t. Illetve lesz egy natív réteg, ami szintén DirectCompute-ot igényel, de a gyártók adhatnak ki meghajtót, amivel bizonyos funkciókat gyorsíthatnak. Az NV már bejelentette, hogy ők a Volta architektúrára adnak ki meghajtót, míg a régebbi a Microsoft szoftveres rétegén fog működni. Az AMD-nél is lesznek megszorítások amúgy. GCN3-tól lesz meghajtó, míg a GCN1-2 a szoftveres réteget fogja használni.Az egyéb képességek tekintetében annyit lehet tudni, hogy az NV támogatni fogja a baricentrikus koordinátát a Voltán, de a régebbi architektúrákra még nem döntötték el. Technikailag lehetséges, a kérdés inkább az, hogy akarnak-e humánerőforrást mögé rakni. A minfloat16-ot támogatni fogja a Volta, de a Pascal nem. Mondjuk ez kevésbé fájó, mert az AMD-nél is csak a Vega fogja támogatja ezt, régebbi dizájn nem. A többi képesség nem változik.
(#17092) Jack@l: DX12 van. 12.1 nincs. Lehet, hogy egyszer lesz, de még nincs.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az NVIDIA éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
