A konzoloknál is hbcc-jellegű memóriamenedzsment/kihasználtság van és nagyon jó a hatásfokuk 8giga rammal is, -sőt régebben még töredékével is megoldották a ps3-as időkben.

"Többször látsz Game Over képernyőt, mint Michelle Wild f@szt." "It's not a Loop, it's a Spiral"

Üdv

Nvidia azért nem megy hbcc-re mert nem kapott x86 licenszet az inteltől, nem azért mert a jelenlegi megoldás jobbnak tűnik.

Hello.
Ezzel tisztában vagyok, de biztos vagyok benne, hogy ha akarnak, fejlesztenek más megoldást a Vram kezelési problémákra, amihez nem kell licencsz. Én úgy gondolom,hogy lehetséges még több megoldás, ami a hatékonyságot növeli, nem pedig a hozzáadott mennyiséggel orvosolja a problémát. ha esetleg mindkettő jelen lesz ( nagy mennyiségű Vram+ és azok hatékonyabb kihasználása) az szerintem a legideálisabb megoldás.

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Konzoloknál nincs (értelmetlen) HBCC, mivel egy koherens memória van.

Hitetetleneknek: ()

Ez a HBCC sokak számára olyan, mint az NVIDIA TurboCache vagy annak ATI megfelelője, a HyperMemory. De nagyon nem ugyanaz.

A TurboCache célja a költségkímélés volt. Tesco gazdaságos memória méret és sávszél (tehát nem turbo), ami kb arra volt elég, hogy a framebuffert tartalmazza, tehát az adatok a rendszermemóriában voltak, és ez ugye a PCIE-n keresztül ment át a GPU-ba. Rettenet rossz valami, nem csoda, hogy csak a kisebb GPU-knál terjedt el, mert ott nem volt akkora a büntetés.

A HBCC nagyon más, mégpedig azért, mert itt tényleg gyors a cache, és nem csak a framebuffer fér bele. Továbbá nem az a célja, hogy több memóriát emuláljon a GPU mellé, hanem hogy minél kevesebb felesleges adat legyen a VRAM-ban. Hisz a jelenlegi probléma az, hogy alkalmazástól függően csak 30-60%-a van kihasználva a VRAM-nak. Nem kell a HBCC miatt több sima RAM, mivel HBCC nélkül az adatok ugyanúgy benne vannak a rendszermemóriában is, a HBCC csak azt menedzseli, hogy a RAM és a VRAM között minél kevesebb másolás legyen.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Köszi az érthető megfogalmazást, így azért kicsit jobban átlátható a dolog. Probléma megint az,hogy már a cím is megint kétértelműen fogalmaz , és negatívumként kezeli szinte, ha egy kártyán sok ram van.
a HBCC megoldás lehet , hogy jó lesz és működni fog, de attól az, hogy egy kártyán sok Vram van már lassan negatívnak hat. Azért ne essünk át a ló másik oldalára, ez a "hitetlenek "( én is ide tartozom) egyik problémája többek között .Ráadásul az NV új gamer generációjáról Kb semmit nem tudunk.

[ Szerkesztve ]

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Hát a bruteforce megoldás az nem jó. De az NV mást nem is tehet. Csak erre érdemes felkészülni, hogy a több RAM nem feltétlenül több, mivel nincs kihaszálva. Tehát a jövőben valószínűleg az lesz, hogy pl 8 GB AMD VRAM = 16-24 GB NVIDIA VRAM.

Ez a vallásos analógia nálam vicc kategória. Én alapvetően jó indulattal állok hozzá az elmélethez, de ha vásárlásról van szó, akkor a gyakorlat alapján fogok dönteni.

De most a Volta is különösen tetszik, hogy egyszerű, külön Tensor, FP64, FP32 és INT feldolgozókat használnak, kíváncsi vagyok hogy ha a konzumer részleg Ampere lesz, akkor ez mit jelent. Szerintem az lesz, hogy a konzumer kártyákban csak FP32 feldolgozó lesz, ami ugye dupla FP16-ra lesz képes, s ezt végre engedélyezni fogják konzumer szinten is. Azaz a V100-hoz képest az egész GPU tök más feldolgozókat és ütemezést fog használni, innen jön a másik név.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Én is ezt tartom valószínűnek, Volta néven szerintem nem lesz gamer GPU. Ampere elméletileg ugye 2018 ban fog bemutatkozni, valószínűleg első konkrétumok Drive Px ben jönnek róla.

Ezt a Vram dolgot nagyon fenntartásokkal kell kezelni mindkét oldalról,ugye pont az Új Assasinban történ lassulás a bekapcsolt HBCC miatt és ez nem is igazán használta ki , csak a felületét karcolta a dolognak. Később persze driver szinten jött rá megoldás. Mint írtam x86 Licensz nélkül is dobhat NV fejlettebb memóriakezelés megoldást, azért a világ egyik legjobb IT csapata van most ott és pénzben sincs hiány. Ez nem hinném, hogy hasonlóan fog működni, mint anno az Athlon xp időkben mikor azt írták a CPU ra melyik Intel procival van egy szinten, nem a valós órajelet.
Nekem tökéletesen megfelel, ha a valódi gyors DDR6 vagy 5 Vram fizikailag rajt van a kártyán és a GPU dolgozhat vele..
persze a fogyasztáson majd így biztos jól fog mutatni AMD nél a dolog, ezzel a húzással máris lefaragtak 20 % ot kb a csúcskártyájuknál, mert nem lesz rajt 16 GB HBM, de az ára szerintem benne lesz

[ Szerkesztve ]

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Nekik nem kedvez, mert pont ugyanannyira lényeges a rendszermemória HBCC-vel, mint HBCC nélkül. Az allokációk ugyanúgy ott lesznek mindkét megoldással a rendszermemóriában. Tehát a rendszermemória terhelése nem fog lényegesen változni HBCC-vel vagy HBCC nélkül.

De akkor induljunk ki egy gyakorlati példából. Van egy játék, ami a képkockák számításához tegyük fel, hogy 7-8 GB adatot igényel. Ez már eleve egy olyan tényező, ami ma még felfoghatatlannal tűnik, mert a tipikus adatigénye a játékoknak 2 GB körüli, de nyilván eljön ez az idő is. Talán nem is olyan sokára. Itt már ezek a játékok minimum 32 GB-nyi rendszermemóriát fognak igényelni, mert rengeteg adatot streamelnek. Tehát van mondjuk egy 32 GB-os géped, amiben van egy Vega 8 GB lokális memóriával.
A program igényel magának úgy kb. 5-7 GB CPU által elérhető területet, és úgy 18-20 GB CPU+GPU által elérhetőt területet. Az összes memóriaigény így 27 GB körül lesz, de ugye a dual channel miatt a hardverben muszáj 32 GB-ra ugrani, mert az a következő kétcsatornás lépcső.
A lényeg itt a 16-18 GB-nyi, GPU és CPU által is elérhető terület, ugyanis onnan kerülnek az allokációk a GPU lokális memóriájába. Ha HBCC-d van, akkor beállítasz a meghajtóban egy ideális HBCC szegmenst, és akkor a kijelölésre kerül a Windows számára, hogy hova kell helyeznie fizikailag a CPU+GPU által elérhető adatokat. Innentől kezdve az OS oda helyezi, és ebből 7-8 GB-nyi 4 kB-os lap átkerül a lokális memóriába, és ennek a menedzselése zajlik folyamatosan és hardveresen. Jobb esetben a program elvégzi az inicializálást maga, és akkor inkluzív cache módban fut az alkalmazás, ilyenkor még a meghajtót sem kell megnyitni.
Ha nincs HBCC-d, akkor egy kicsit problémásabb a helyzet, mert ugyanúgy szükséged van arra a 7-8 GB-nyi 4 kB-os lap, de ezeket nem tudod csak úgy betölteni. Ilyenkor a konkrét allokációk kerülnek betöltésre, és itt bele kell számolni, hogy egy allokációnak esetleg csak a 30-70%-a szükséges. Ilyenkor viszont be kell tölteni a teljes allokációt a 70-30%-nyi szükségtelen adattal együtt. És itt még számolni kell a különböző hardveres problémákkal, mint a csatornák keresztbe címzése, vagyis az az ideális, ha egy allokációt akár többször is elhelyezel a VRAM-ban, ugyanis ezzel a módszerrel lesz a feldolgozás a leggyorsabb. Ezt nagyrészt a programozó (program vagy driver) határozza majd meg, mivel teljesen szoftveresen menedzselt rendszerről van szó. Emiatt itt általánosítani nagyon nehéz, már csak azért is, mert a gyakorlatban tipikusan az a jellemző, hogy a program feltölti a VRAM-ot, amíg csak lehet, és amikor betelt, akkor kezdi a probléma menedzselését. Ez nem szerencsés több dolog miatt sem, például a WDDM-nek sem ideális ez a forma, de a rengeteg nehezítő körülményt beszámítva ez tűnik mégis a leginkább működő megoldásnak. Mondjuk úgy, hogy a jobb alternatívák implementálása sokkal nehezebb, és emiatt erre nem feltétlenül éri meg pénzt áldozni. Persze vannak kivételek, például a Sniper Elite 4 motorja akkor is szokott törlést kérni, amikor a terhelés egy rövid időre alacsonyabb lesz, illetve ilyenkor valós időben defragmentál is, hogy egymásra tolja a VRAM-ban található allokációkat, ezzel is helyet nyerve. Mert ugye az sem mindegy, hogy az allokációk mennyire töredezettek. Simán van olyan, hogy a memóriában van még 400-500 MB szabad hely, de esetlegesen nem tudod felhasználni, mert az nem egybefüggően van meg, hanem szétszórtan, így hiába férne be például egy 100 MB-os allokáció 4-szer is, akkor sincs 100 MB-nyi egybefüggő allokálható terület neki. A Rebellion szerencséje, hogy független stúdióként nem mondja meg egy kiadó, hogy a hatékony memóriamenedzsmentre nem ad pénzt, hiszen a játék ugyanúgy eladható a sokkal olcsóbb és bénább megoldás mellett is. Tehát végeredményben hiába kér a program csak 7-8 GB-nyi 4 kB-os lapot, azzal neked hardveres szinten legalább ~16 GB-nyi VRAM-mal kell fizetni. De ha a tipikus optimalizálási modellt nézzük, vagyis a betelik aztán majd menedzseljük koncepciót, akkor már ~24 GB-nyi VRAM kell. És a programnak nem lesz kisebb memóriaigénye a rendszermemória oldalán, ugyanúgy ajánlott lesz hozzá a 32 GB, mert a PC az nem csak egy hardver, itt nem tudsz egyetlen egy memóriakonfigurációra rátervezni mindent. Itt van egy rakás hardver, egy rakás memóriakonfigurációval, vagyis a program igényeit is teljesen általánosra kell szabni, annak érdekében, hogy valamilyen beállítással minél több memóriakonfiguráció mellett működjön. Emiatt van az, hogy amíg régebben a rendszermemória kapacitására vonatkozó igény jóval nagyobb volt, mint a VRAM-ra, addig ma már szinte ugyanannyi VRAM kell, mint rendszermemória. A programok komplexebbek és a bevált menedzsmentrendszerek hatásfoka drámai mértékben romlik.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

ezek a számok még évekig nem fognak beköszönni, nem akarlak megsérteni, de ez megint egyfajta megmagyarázása a bizonyítványnak és pánik keltés. A jelenben és még 2-3-4 évig nem fog gondot okozni, ebben szinte biztos vagyok.Ettől még ez lehet jó megoldás , nem vitatom, csak egyenlőre ebből hasznot csak az AMD élvez, senki más.

[ Szerkesztve ]

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Ezekről a spekulációkról már tud az AMD és az nVidia is? (bocs!)

Az Oroszországnak küldött iráni drónszállítmányok csak elnyújtják a háborút.

Konkrétan a a 2 GB / frame többszörösére értettem.( 6-8 GB/ frame). Attól, hogy radeon kártyák kijönnek ilyen felállással, attól még a PC piac nem fog átfordulni, a konzolok meg máshogy kezelik ezt a dolgot. 4 K ra alkalmas kártyákon azért nem 4 GB van, hanem 8 ,vagy több jelenleg is.4 GB már valóban néhol szűkös lehet,( pl Rx 480- 580) ha a GPU elég erős FHD-n ,de nem jellemzően.

[ Szerkesztve ]

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Mi ez a sok értetlenkedés? Azt a 8gb-ot triviális megtölteni egy teszt erejéig. Ezt valószínűleg az AMD meg is csinálta. Én is kipróbáltam cryengineben kíváncsiságból (igaz 8k*6k felbontással sok textúra helyett) és nagyon jól működik a hbcc. Pár év alatt nem változnak annyit a motorok, hogy ezt ne lehessen tesztelni.

Nem kell direkten optimalizálni? Az elmúlt 20 évben a fejlesztők 99%-ban a kis textúrákat egyetlen egy nagy fájlba töltik be és azon belül virtuálisan bontják azt kisebb részekre hogy ne kelljen lapozgatni jobbra-balra és memóriakezelő se duguljon be a reserve-commit hívásoktól.

És nem olyan nincsen hogy egy fájlt kétszer raknak be a VRAM-ba, egyszer betöltik és utána csak a hivatkozások mutatnak ugyanarra a memóriarészre, így lesz egy nagy textúrából több kicsit.

A nvidiát meg lehet bashelni de ők legalább tömörítik a memóriában az egyszínű pixeleket, és mindezt úgy hogy nem a többi komponenstől szívnak el erőforrást mindeközben.

Az meg a legviccesebb az egészben hogy miután a 970 hogy le lett húzva a lassabb elérésű memórialapkái miatt, erre most az AMD eladja kvázi ugyanezt feature-ként ami még sokkal lassabban is fog működni, valamint extra terhelést dob a rendszer többi részére, csak azért hogy lespúrkodjanak pár extra gigabájtot.

[ Szerkesztve ]

Egy teszt erejéig lehet,de azzal kb semmire nem mennek a felhasználók...

★★★★★ I got too much soul, rhythm and blues R&B ya see, all that's cool, but hip-hop and rap yeah that's where my heart's at Even back when I used to break on a box ★★★★★ "Chief Rocka"

Azt azért tegyük hozzá, hogy a HBCC gyakorlatilag az oprendszerek jól bevált memória-menedzsmentjét (lapkezelés) másolja. Csak itt swap és RAM helyett RAM és VRAM között megy a dolog. Pont azok a problémák merültek fel most a VRAM kezelését illetően, mint ami anno a RAM kapcsán 30 évvel ezelőtt az x86-os PC-knél. Ugye a lapozófájlról van szó, ami a Windows 3.0 óta létezik, s ennek célja az, hogy a RAM hatékonyabb használatával kevesebb RAM-mal is biztosítható legyen ugyanaz az élmény.

Csak persze a lapozófájl (főleg HDD esetén) az egy bűnlassú valami a RAM-hoz képest, míg a VRAM és RAM között nincs ekkora nagy különbség. Illetve a HBCC egy hardveres valami, nem szoftveres.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Hát most semmire nem megyünk vele. Nem is érdemes csak ezért Vegát venni, hisz most nincs ebből profit. Ez a jövő szempontjából lehet érdekes. S könnyen lehet, hogy csak a Vega utódjánál lesz majd igazán hasznos a HBCC.

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Már aki, fejlesztőként nekem nagyon jól jön.

@Resike A megatextúrákat már az id sem használja, nem hogy a fejlesztők 99%-a.

[ Szerkesztve ]

Ez rohadtul nem a MegaTexture technológia hanem ésszerű spórolás. Ha egy textúrának az egyik részét nem használják akkor oda még be lehet szúrni egy vagy több másikat és virtuálisan felosztani azt annak szub-koordinátái szerint.

De a legtöbb egybetartozó textúrát már alapból így rajzolják meg, ha kell 16 ikon akkor nem fogsz 16 külön textúrát csinálni, hanem létrehozol egy nagyobbat és felosztod, és ezzel még azt is eliminálod hogy egy objektum textúrái nem egyszerre töltődnek be vagy jelennek meg.

És még miért csinálják mindezt a memóriaspórolás és a fregmentációkezelés mellett? Hogy ne kelljen load on demand szerint kismillió kis textúrát töltögetni.

[ Szerkesztve ]

Amiről beszélsz (texture atlas) ma a kivétel, nem a szabály. Teljesen vállra fektetné a streaming rendszert ha minden random objektumot összevissza nagy textúrákba összezsúfolnánk, és a vram igény is masszívan megnőne. (pedig már így is problémás pc-n, a sok 1-2-3 gigás kártyával.) Nem beszélve arról, hogy mekkora fejfájás lenne ezt menedzselni fejlesztés közben. Az ikonok (és pl apróbb növényzet) speciális eset, ezek mindig be vannak töltve, és egyszerre jelennek meg.

A HBCC-nek nem számítanak ezek. Ez a rendszer teljesen az eszközszinten működik. Immunis bármilyen eszközszint feletti programozói ténykedésre, legyen annak hatása jó vagy rossz.

Pedig gyakori trükk, hogy egy sűrűn használt allokáció többször is bekerül. Ennek az oka, hogy a crossbar a mai rendszerekben keresztbe csak felezett sávszélességű, vagyis kétszer gyorsabban tölthető be a GPU-ba az adat, ha nincs keresztcímzés. Emiatt a meghajtó nagyon sűrűn fordul ahhoz a trükkhöz, hogy a sűrűn használt adatokat duplikálja a VRAM-on belül, méghozzá úgy, hogy csatornánként egy partícióban ott legyen.

A színtömörítés manapság teljesen általános technológia.

Messze nem ugyanerről van szó, de ha eddig nem sikerült megértened, akkor ezután sem fog sikerülni.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Alapvetően igen, csak az eszközszinten oldja meg. Nyilván az AMD nem talált fel semmilyen spanyolviaszt, csak egy évtizedek óta bevált módszert terjeszt ki a GPU-ra. Megtehetik, mert a hardveres igénye lényegében kimerül egy multiprocesszorokba szerelt AMD64-es címfordítóban.

(#171) Kristof93: A megatextúrát, illetve virtuális textúrázást használja még az id, csak nem úgy, ahogy az id tech 5-ben. Programfüggő, hogy miképp valósul meg, de a Doom 16k x 8k-s textúrákat helyez el a memóriában, amelyek 128 x 128-as lapokra vannak felosztva. Ezek lesznek feltehetően szükségesek képszámításhoz, és ha valami új kell, akkor a motor tud 128 x 128-as lapokat cserélni, mivel ehhez van szabva a fix méretű allokáció, ezzel a töredezettség is jól kezelhető. Nagyon hasonló megvalósítást alkalmaz a Frostbite is a terepre.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ha eszközszintű megoldást akarnak, akkor ahhoz kell a licenc. Ha API szintűt, akkor arra már most ott van a Pascalban a megoldás, ami csak a CUDA mellett működik. A Volta is azért ment tovább az eszközszint felé a Power architektúra támogatásával, mert nincs igazán köztes megoldás erre a problémára. Az egyik lehetséges alternatíva az lenne, ha a Microsoft és a Khronos kiegészítené a DirectX és a Vulkan API-t, de annyira át kellene ezeket alakítani, hogy egyhamar ezzel nem végeznének. Hosszabb távon persze mindenképpen érdemes majd bevállalni egy átalakítást.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ennek az oka, hogy a crossbar a mai rendszerekben keresztbe csak felezett sávszélességű, vagyis kétszer gyorsabban tölthető be a GPU-ba az adat, ha nincs keresztcímzés.

Ezt fejtsd ki egy kicsit bővebben, mert alapvetően ellentmond az interleavingnek, ill. az is meglepne, ha PCIE-buszról jövő adat nem 32-biten menne le a kontrollerek felé.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Itt már a memóriába betöltött adatokról van szó. A PCI Express már nem játszik. Az a probléma, hogy a VRAM is partíciókra van osztva, és nem minden partíció érhető el ugyanolyan sebességgel a GPU belüli blokkoknak. Egy ideje ezzel spórolnak tranzisztort a crossbart használó gyártók, mert maga a probléma kezelhető azzal, hogy a sűrűn használt allokációkat többször berakják a különálló partíciókba, így mindegyik GPU-s belső blokknak lesz egy gyors elérése ugyanahhoz adathoz. Tehát tranyót spórolsz vele, miközben extra memóriával fizetve nem lassulsz semmit. Jelen formában kedvezőbb többletmemóriával fizetni, mint többlettranzisztorral hozni ugyanazt a teljesítményt.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ki gondolta volna, hogy egyszer az AMD fog valamit megoldani ésszel és az nVidia meg erővel.

Továbbra is az a kérdés, hogy szerinted bizonyos funkcionális egységek (pl. SMM) 16-bites csatornán érik el az egyes ROP/memória-blokkokat?

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Nem. A ROP blokkok azok teljesen a partíciókhoz tartoznak, és a multiprocesszorokhoz nem tartozik partíció. Az történik, hogy a multiprocesszorok nem minden ROP blokkal vannak teljes sebességgel összekapcsolva. Emiatt bizonyos partíciók címzése hátrányosabb, mint más partícióké. A dolog igazából nagy problémát addig nem jelent, amíg van elég warp átlapolni az adatelérést, de vannak bizonyos szituációk, amikor nincs elég warp, és akkor a meghajtó manuálisan trükközik. Erre van egy felépített rutin a driverben, így a problémás alkalmazásokban a sebességért cserébe több memória kerül felhasználásra. Végeredményben ez hasznosabb megoldás, mert kevesebb tranyót igényel maga a lapka, és a problémás szituációkat a meghajtó oldalán le lehet kezelni, és ennek a hátránya csupán a nagyobb memóriaigény.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

OK, tehát akkor igazából a ROP-okhoz menő kapcsolatról beszélünk. Továbbra is kérdés az interleaving, tudtommal az adatok szét vannak szórva a blokkok között a nagyobb sávszélesség érdekében.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Mert melyik lesz a gyorsabb: megjeleníteni valamit amit már ott van a memóriában vagy azt amit még be is kell húzni oda előtte?

Igen mindez így nagyon szép leírva, de mégis milyen hatással lesz ez az input lagra és a frametime-re amikor valaminek már ott kéne lennie a VRAM-ban de még nincs ott és be kell húzni oda? És mekkora erőforrás használatra és extra időre kell gondolni amikor erről az extra virtuális memóriakezelésről beszélünk?

Ugyanis a töltő képernyőknek pont ez a feladata hogy ne kelljen 3 fps-el ülnöd a scene előtt amikor épp egy új zónát töltesz be.

Kedvező hatással van rá, hiszen maga a menedzselés lapszinten történik, ami lényegesen kisebb adatok mozgatását jelenti a rendszermemória és a GPU lokális memóriája között. Mindemellett a WDDM kellemetlenségei HBCC-vel nem is léteznek. A meghajtó a WDDM egyes parancsait automatikusan kezeli. Például explicit cache módban a WDDM adhat utasítást az allokáció törlésére, de arra vonatkozóan a rendszer nem fog lefuttatni egy ellenőrzést. A meghajtó visszahazudja, hogy kell az allokáció, méghozzá anélkül, processzoridőt vett volna igénybe. Persze a valóságban lehet, hogy nem kell, de hát arról a hardver majd az eszközszinten dönt.

Az eszközszintű működés miatt van, hogy HBCC mellett folyékonyabban futhat ugyanaz a program. [link] - itt egy példa. A felső sarokban láthatod, hogy a frame time grafikonon kisebbek a tüskék aktív HBCC-vel.
Az AMD is a szűk frame time-ot hangsúlyozta, mint aktuálisan tényleg tapasztalható előnyt.

A töltőképernyő azért nem sokat ér. Maximum ad egy alapot az indításhoz, de rengeteg folyamat valós időben történik már. Ez igazából nagyon logikus. Amit nem látsz, annak nem kell a memóriában lennie. De lehet, hogy pár másodperc múlva látni fogod, így akkor majd be kell tölteni. A mai rendszerek egyáltalán nem töltenek be előre mindent a videomemóriába. Az az erőforrás nagymértékű pazarlása lenne.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

"Viszont ehhez előre definiálni kell bizonyos paramétereket, hogy a HBCC lapalapú vezérlése az adott memóriaszegmensre működjön"

Bocsánat de ez megint a kabitas jövőben való kimagyarazasanak lehetősége...

Nagyon profi politikus marketing jogi szöveg.

Majd a programozók azert az 1%os vga lefedettsegert megcsinálják ugye?

Pont ez a szöveg volt a mantle VR DX12 es társai a részedről amikből nem lett semmi az általános gyakorlatban...

A crossbar nem így működik, teljesen szimmetrikus. Ezt már többször írtad, de eddig semmi bizonyítékot nem írtál, se valami leírást, se mérési eredményt.
A többszörös memóriafoglalásra sem adtál még bizonyítékot.

Ehhez semmi közük a programozóknak. Az explicit cache mód egy meghajtó szintjén kezelhető funkció. A program fejlesztőjének ezzel semmi dolga nincs.
Az implicit cache mód, amit a program fejlesztőjének kell engedélyezni, mivel szükséges hozzá egy előzetes inicializálás a program indításakor. Itt a programfejlesztő természetesen választhat, hogy rábízza magát a hardverre egy pár soros kóddal, vagy ír egy nagy architektúraspecifikus optimalizálást a Vegára, ami még nem is biztos, hogy gyorsabb lesz az implicit cache módnál. Minden fejlesztő maga eldöntheti, hogy mennyi erőforrást fektet bele. A legtöbben valószínűleg az implicit cache módot fogják választani, mert az sokkal gyorsabban megvan, és az erőforrásukat olyan hardverek optimalizálására fordíthatják, amelyeknek nincsenek eszközszintű menedzseléssel dolgozó hardveres adottságai.

Nem tudom, hogy melyik fejlesztő számára realitás egy Vega-specifikus menedzsmentet optimalizálni, amikor a hardver meg tudja oldani ezt magától. Csak az idejüket rabolná le egy szoftveres optimalizálás, mert a user bármikor kiütheti a meghajtóban a HBCC szegmens aktiválásával. Viszont elköltöttek rá teszem azt jó két hetet, így a többi hardverre való optimalizálásra ennyivel kevesebb idő maradt, ezeknek pedig már számít, hogy mit csinál a fejlesztő. Ezt a legtöbben mérlegelni fogják és tök logikus döntés a hardverre bízni a feladatot, mint erőforrást ölni az optimalizálásába.

(#190) namaste: Egy olyan gyártóról beszélünk, amelyik a hardvereit még abszolút minimális szinten sem dokumentálja. A legtöbb fejlesztő abból él, hogy a Twitteren hallotta, hogy valaki egy sarkon kihallgatta az NV mérnökeit, hogy xy textúraformátumnál mekkora a mintavételezési sebesség az egyes szűrési típusokhoz. Merthogy az NV ezt hivatalosan aztán nem mondja el, bármennyire is fontos kérdésről van szó. Én is abból élek, amit az NDA-s briefingeken elmond az NV. Azt, hogy te ezt elhiszed-e a te egyéni döntésed, engem nem különösebben érdekel.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ez nem valami meggyőző.

Pedig ennek nyílt titoknak kellene lennie, van a világon sok játékfejlesztő, sok CUDA fejlesztő, valakinek már találkoznia kellett volna memóriasebesség vagy memóriafoglalási problémával.

Az lehet hogy a Maxwell sorozat így működött, specifikusan a 970 biztosan. De mivel a Pascal rendelkezik HRD támogatással, nincs az az Isten hogy csak felezett sávval el tudná látni a HRD képek feldolgozását úgy hogy pont ugyanannyi ROP egység van a 1000-es kártyákon mint a 900-as elődeiken.

Amúgy amióta én megvettem a jelenlegi kártyámat annyira nem követtem az új VGA ficsőröket, de itt van egy közel 1.5 éves cikk a CUDA 8-ról ami már érinti a Pascal szériát:

https://devblogs.nvidia.com/parallelforall/cuda-8-features-revealed/

"Memory page faulting support in GP100 is a crucial new feature that provides more seamless Unified Memory functionality. Combined with the system-wide virtual address space, page faulting provides several benefits. First, page faulting means that the CUDA system software doesn’t need to synchronize all managed memory allocations to the GPU before each kernel launch. If a kernel running on the GPU accesses a page that is not resident in its memory, it faults, allowing the page to be automatically migrated to the GPU memory on-demand. Alternatively, the page may be mapped into the GPU address space for access over the PCIe or NVLink interconnects (mapping on access can sometimes be faster than migration). Note that Unified Memory is system-wide: GPUs (and CPUs) can fault on and migrate memory pages either from CPU memory or from the memory of other GPUs in the system.

With the new page fault mechanism, global data coherency is guaranteed with Unified Memory. This means that with GP100, the CPUs and GPUs can access Unified Memory allocations simultaneously. This was illegal on Kepler and Maxwell GPUs, because coherence could not be guaranteed if the CPU accessed a Unified Memory allocation while a GPU kernel was active. Note, as with any parallel application, developers need to ensure correct synchronization to avoid data hazards between processors."

Valahogy ismerősen hangzanak az itt leírtak...

[ Szerkesztve ]

Vajon 1,5 éve kezdte el "fejleszteni" az amd az új killer feature-t?

[ Szerkesztve ]

A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

A Pascal működése az NV-nél nagyon titok. Nem igazán reagálnak egyetlen hardverre irányuló kérdésre sem. Arra vonatkozóan általánosan semmit sem lehet mondani. Legjobb esetben is csak következtetni lehet a Maxwellből, hogy talán ugyanúgy működik, de semmi garancia erre.

[link] - itt említettem, hogy a Pascalnak van hasonló API szintű megoldása a CUDA-ra. De más API-val ez nem üzemképes. A Volta helyezi ezt eszközszintre, ahogy a Vega tette az AMD-nél, de a host processzor architektúrájához kötött a működés. A Vega esetében x86/AMD64 a követelmény, míg a Volta esetében Power9. Amúgy egyébként nagyon hasonló a két megoldás, leszámítva a host processzorra és az interfészre vonatkozó igényeket.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Igazából az NV beszélt először magáról az alapproblémáról még az előző évtizedben. Az alapvető kutatások valószínűleg elkezdődtek már úgy 2007 környékén. És ez mindkét gyártóra igaz lehetett, hiszen a Vega és a Volta támogat eszközszintű, lapalapú memóriamenedzsmentet a kompatibilis host processzorok és host interfészek mellett.
A korábbi megoldások zárt API-khoz voltak kötve, tehát az elterjedt API-kkal üzemképtelenek voltak. De hardveres támogatás mellett már az API is lényegtelen, egyedül a beépített technológia hardveres követelményeit kell teljesíteni a működéshez.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Akkor rohadtul nem értem az egész cikket, a nVidiának már van rá megoldása, igaz hogy jelenleg csak CUDA alatt, de valószínűleg a Volta alatt ez már ki lesz bővítve. Mégis az AMD van piedesztálra emelve egy olyan funkcióért amit még csak fejleszt, és az nVidia a balfasz hogy több VRAM-ot mer rakni a kártyáira.

És mindez olyan két termékből lett lekövetkeztetve amiről még hiteles hírmorzsák sincsenek... Még jó hogy csak a tények alapján írunk cikkeket.

NV-nek nem lesz ilyen rövid távon, mivel x86 licensz kéne hozzá. Ha lenne neki, már ő is rég megcsinálta volna. De ezt jópár hsz-szel le lett írva. Olvasol is vagy csak írsz?

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Volta alatt már ki van bővítve. A Telsa V100 multiprocesszoraiban van egy-egy címfordító egység, ami képes direkten elérni a Power9 CPU-k laptábláját. De PC-ben ehhez olyan címfordító egység kell, ami az x86/AMD64 ISA-ban meghatározott memóriamodellhez igazodik, ez pedig pont annyira licencköteles, mint a Power9 ISA esetében. Csak amíg az IBM-nél ott az OpenPower konzorcium, addig a PC-nél nincs semmi, vagyis meg kell győzni az Intelt és az AMD-t, hogy licencelje nekik az x86-ot és az AMD64-et. Az AMD megoldása például pont a Power9 ISA memóriamodelljét nem támogatja. Így pont annyira nem ér semmit IBM host proci mellett, mint amennyire az NV megoldása nem ér semmit x86/AMD64-es host proci mellett.
A Pascal által alkalmazott CUDA-s megoldást meg lehet őrizni, csak azzal semmire nem mennek a DirectX, Vulkan, OpenCL és OpenGL API-kra írt programokban.
Egyébként nem tudom miért tartod balfasznak az NV-t a több memória miatt. Ez is csak egy kezelési módja az alapproblémának. Nincs leírva a hírben, hogy ez rossz lenne.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.