- NVIDIA GeForce RTX 3060 Ti / 3070 / 3070 Ti (GA104)
- Egy vagy két tápkonnektor lesz az új csúcs-GeForce-on?
- Raspberry Pi
- Nvidia GPU-k jövője - amit tudni vélünk
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- TCL LCD és LED TV-k
- Drágul az EU-ban a GeForce RTX 4090
- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- Fejhallgató erősítő és DAC topik
- Kezdő fotósok digitális fényképei
Hirdetés
-
Unknown 9: Awakening - Amit a játékról tudni érdemes
gp A PC-re és konzolokra szánt alkotás jövő hónap közepén érkezik.
-
Hordozható NAS-sal készül novemberre a UnifyDrive
ph A két M.2-es meghajtót fogadó, kártyaolvasókkal és kétféle videokimenettel ellátott konstrukció működhet routerként, de a virtualizáció sem áll tőle távol.
-
Elstartolt az Ulefone 5G-s, hőkamerás strapatabletje
ma Mindent egyszerre kínál egy készülékben, hagyományos Armor 4 Ultra is akad.
-
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 daveoff #9365 üzenetére
Gondolom valaki használta az eszét is, amikor azt a táblázatot összerakta. Legalábbis megnézte, hogy miképp lehet 4 GB-nyi VRAM-ot építeni HBM-ből.
(#9366) Malibutomi: Attól, hogy pár motort direkt sávszélkímélőre tervezték vannak és lesznek olyan motorok, ahol ez nem igaz, és ott a Hawaii elhúz. Például Assetto Corsa. Itt a Fiji még jobb lesz. Aztán ugye ki tudja mit hoz a jövő, arra nem mindig lehet építeni, hogy majd a fejlesztők takarékoskodnak a sávszéllel.
(#9368) -Solt-: Nem mond sok újat, majd ha lesznek a VR projektről konkrétumok.
[ 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 #9371 üzenetére
Amin igazából változtatnak a low-level API-k az a többletterhelés és a többszálúsítás. Ami leginkább látszódni fog ebből az a rendelkezésre álló processzormagok kihasználása, tehát előtérbe kerül az adott processzor összesített teljesítménye és háttérbe az egyszálú. Erre az irányra jobban megéri több gyengébb, mint kevés erősebb magot venni. De ettől magának a processzornak a összteljesítménye nem változik meg, csak normálisan ki lehet használni az erőforrásait.
A Kaveri egy fekete ló ebben a mezőnyben, így azt a legnehezebb behatárolni, vagy általánosítani, mert ott az IGP-je, ami egy csomó dologra használható. Ha az IGP-je nincs használva általános számításra, akkor annyit ér majd, mint egy átlagos négymagos, de ha ki van használva (elég sok lehetőség van), akkor mindennél gyorsabb lesz.
A Kaveri esetében a fejlesztők gondja, hogy ezeket a képességeket hogyan tegyék elérhetővé úgy, hogy az ne küldje padlóra a többi processzort. Ebbel a low-level API-k kétségtelenül segítenek, de maga a rendszer inkább olyan dolgokra lesz használva, amit amúgy a dedikált GPU oldana meg és nem a processzor. Tehát a Kaveri IGP-je átvesz majd feladatokat a dedikált GPU-któl. Ezek a jelenlegi tervek szerint szimulációs feladatok lesznek. Emellett a tartalomkikódolás lényeges szerepet kaphat a jövőben, mert egyre nagyobbak a játékok, így egyre jobb tömörítés kell hozzájuk. Például az IGP az egyik legjobb lehetőség arra, hogy a kódolt tartalmakat a program futtatás közben tömörítse ki, úgy, hogy az ne kerüljön processzoridőbe. Ez PC-n jelentős gond, mert konzolon erről a lehetőségről dedikált fixfunkciós blokk gondoskodik.[ 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 lesznek egyedi hűtések az új csúcshardverre. Az a baj, hogy a HBM miatt most szuperbiztonságosra kell mindent tervezni. Mivel ez egy nagyon új dolog, így minden érintettnek sokkal biztonságosabb, ha a referenciahardvert másolnák. Sokkal jobb adatokhoz jutnak a Hynix is, hiszen csak a matricákban különböznének a termékek.
Persze amúgy érthető, hogy matricázás mellett kevés a lehetőség a gyártói marketingezésre, de meg kell érteni, hogy a második generációs HBM-et a mostani hardver alapján tervezik. Ha rosszak a visszajelzések, akkor nagyobb az esélye, hogy rossz lesz az új memória is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Malibutomi #9432 üzenetére
A melegedés és lehűlés bonyolultabb az interposerrel. Nem elég, hogy jól legyen hűtve, hanem az is kell, hogy a hőmérséklet-változás bizonyos időtartamon kívül következzen be.
Ilyet még senki sem csinált, így az egyetlen dizájn, ami ki van tesztelve az a referencia. Aki ettől eltér sokat kockáztat, mert kevés az adat erről a koncepcióról.(#9433) KillerKollar: Ezen a szinten 100000 rendelési mennyiség teljesen normális. Egy hónapos szinten ennél több ezekből a kártyákból nem fogy. Aztán rendelni lehet továbbra is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Minden bizonnyal a léghűtés is megoldható, csak a vízhűtés egy bizonyos szint után olcsóbb, főleg nagy mennyiségben rendelve. A járulékos előnyeivel együtt teljesen logikus vízhűtés felé menni. Főleg, hogy a memóriákat és az interposert nem érdemes nagyon magas hőmérsékleten tartani. Ezek azért ott lesznek a tokozáson, tehát mindent jól kell hűteni. Erre a víz a legalkalmasabb és a jövőben is az lesz. Ez a fél TB/s-os sávszélesség ára.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem is kell a VGA-gyártóknak tapasztalat. Elég az hogy az Asetek és a Cooler Master tapasztalata több évre nyúlik vissza a kompakt vízhűtés terén. Magát a hűtőt nem fogja érdekelni, hogy CPU-t, vagy GPU-t hűt. Ezzel is, azzal is ugyanúgy működik.
Ezekre a vízhűtőkre egyébként a gyártók adnak üzemidőre vonatkozó adatokat. Jellemzően egyébként 5 évig garantálják a működést. Erre konkrét garanciát is vállalnak a partnerek felé.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Menthirist #9507 üzenetére
Mi meg úgyis kapunk ingyen mint eddig. Köszönöm, hogy meghallgattatok. /trolloff
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 #9551 üzenetére
Nem állt meg, de erről majd később lesz szó. Most az a lényeg, hogy amelyik fejlesztőnek nincs olyan igénye, amit a DX12-ben vagy a Vulkanban ne lehetne kiszolgálni az válasszon magának egy alap szabványos API-t. Ez egyéni döntés kérdése. Nyilván, ha nem akarják magukat a Windows 10-hez kötni, akkor a Vulkant választják, de gondolom Redmondban van az a pénz.
A többi pedig egy rendkívül specifikus igényrendszer kiszolgálása lesz, ha tényleg olyan dolgot álmodott meg az adott fejlesztő, amit a DX12-ben vagy a Vulkanban nem lehet megoldani. Van ilyen, és ezért marad meg az AMD API-ja is, de az alapok szabványosak lesznek.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz #85552128 #9755 üzenetére
Nem valószínű, hogy a DX12 sok memóriát igényelne. A Frostbite 3 VRAM igénye folyamatosan csökken a BF4 megjelenése óta. A Hardline-ban már egy egészen új modell lesz, ami 2 GB memória mellett is elvan. Az explicit memóriamodell egyik előnye, hogy lehet tervezni a VRAM-mal úgy, ahogy a konzolban, ergo a teljes felügyelet mellett, ha előre lefoglalják az egyes dolgokra szánt memóriaterületet, akkor ingyenes lesz a defragmentáció, amit szimplán pointerkorrekcióval meg lehet oldani. Ma azért fogy el a VRAM gyorsan, mert a DX11-ben nem lehet komoly teljesítménybüntetés nélkül törölni a már régóta nem használt puffereket, így inkább otthagyják azokat, míg a low-level API-khoz még nincs kialakult menedzsment az ezt támogató motorok első verzióiban. De a második verziókkal már igen jó az eredmény. Főleg a Frostbite 3-on frissítésein. Vagy ott a Sniper Elite 3. Az már eleve a közvetlen vezérlésre épített.
Később ez szintén javulni fog. A GDC-n az MS és a Khronos már mondta, hogy szemeznek az új hardveres extrákkal, mint a tile pool és a Wang mozaikok hardveres kezelése. Ezekkel tovább javítanak a memóriahasználaton. Jelenleg létezik pár prototípus kód rá, mivel az R9 285 már támogatja ezeket az extrákat. A virtuális textúráktól függetlenül, 4K-ban gyakorlatilag 500 MB-ra lehet csökkenteni a textúrákra használt VRAM-ot, miközben hagyományos streaming textúrázással 2-3 GB-ot is elvinne. A fejlesztők újrahasználhatnak bizonyos mozaikokat, és egyedi textúratömörítéseket is írhatnak. Ez lesz a következő lépcső egyik nagy dobása.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mert semmilyen streaming optimalizálása nem volt low-level API-ra. Repi mondta még 2014-ben a GDC-n, hogy ez nem volt cél, mert olyan strukturális változást igényelt volna a motorban, amire három hónap alatt nem volt lehetősége. Viszont a Frostbite 3 már megkapta ezt a rendszert a Dragon Age: Inquisitonre (egy patchben), és ez fejlődik tovább. A Hardline már azt a rendszert menti át PC-re, amit a konzoloknál használnak.
(#9764) Menthirist: Abszolút. Sokan egyszerűen csak a legvégső esetben töröltek, mert akadás lett a vége. A DX11-ben maga a puffertörlés olyan ellenőrzési procedúrát von maga után, ami felvállalhatatlan állandó jelleggel. A legjobb stratégiát pont a Sniper Elite 3 használja. Annak van egy előzetes streaming eljárása, ami töltögeti a textúrákat, majd ha betelik egy bizonyos memóriaterület, akkor életbe lép a másodlagos streaming, ami tovább töltögeti a textúrákat, de már nem a beállított minőségen, hanem alatta. Ezzel húzza az időt, hogy minél később jusson el arra a szintre, hogy törölni kelljen. Ehelyett egy olyan low-level kódot kapott a rendszer, amely előre lefoglalja a textúráknak a helyet a kártyákon található VRAM mennyisége alapján. Ebben az előre allokált memóriarészbe ingyenes a betöltés és a törlés, viszont így is gond lesz a fragmentáció, hiszen az egyes kitörölt területere esetleg az új adat nem fér be, vagyis üres memóriaterületek keletkeznek. Erre a motor időközönként csinál egy defragmentációt, ami a lefoglalt memóriarészeket egymásra tolja. Mint a merevlemezen a defragmentálás, csak ezredmásodperces szinten belül. Ehhez pedig szükséges egy pointerkorrekció, hogy a címek még defragmentáció után is jó helyre mutassanak. Nem egyszerű rendszer, de rendkívül hatékony. Hasonlót vezet be szinte mindenki. A következő lépés pedig úgyis a virtuális textúrázás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Televan74 #9766 üzenetére
Jól megírt programokban nagyobb felbontáson is. A problémát és egyben a ma látható VRAM használatot az okozza, hogy a program utasíthatja a grafikus meghajtót az egyes létrehozott pufferek törlésére, de a meghajtó az nem hajtja végre csak úgy utasításra, hanem először engedélyt kér a WDDM-en keresztül. Ilyenkor a WDDM a DXGI környezetben elvégez egy csomó ellenőrzést, amely arra vonatkozik, hogy a törlésre kijelölt puffer szükséges-e még, így olyan parancsokat fog keresni, amelyek esetleg azt a puffert igénylik. Az esetek 99%-ában nem talál majd semmit, tehát kiadja a törlésre az engedélyt és a grafikus meghajtó végrehajtja azt. A gond az ellenőrzés. Ez ugyanis több esetben is 30-50 ezredmásodperces procedúra, vagyis biztosan meg fog akadni a feldolgozás, az ezzel járó többletterhelés miatt.
Az új API-k itt annyiban változtatnak, hogy ha a fejlesztő valamit törölni akar, akkor törölje. Tulajdonképpen zéró többletterhelés mellett megteheti. Csak arra kérik a fejlesztőket, hogy ésszel, mert ha olyat törölnek, ami kellene, akkor az ciki, és jellemzően crash to desktop hibával jár.[ 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 Menthirist #9771 üzenetére
A memória megvágásának kicsi az esélye. A VGA-kon azért alkalmazzák, mert egyszerűsíti a NYÁK-ot, de a 2.5D TSV esetében az interposer akkor is ugyanaz marad, ha arra csak három HBM-et raknak. Vagyis a legdrágább rész nem változik. Inkább a memória-órajel csökkentése valószínű, ha az X nélküli verziót picit korlátozni akarják.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz daveoff #9779 üzenetére
Persze. De a probléma jelentős volt. Egy adott program teljesítménye eddig mindig három tényezőn múlott. Az alkalmazás fejlesztőjén, az API fejlesztőjén és a hardverhez való driver fejlesztőjén. A legfőbb gond az volt, hogy évek óta látja mindenki a problémát, de amikor leültek tárgyalni, akkor mindig az volt a hibás, aki épp nem ült az asztalnál. Az új modell esetében az API fejlesztője és a hardvergyártók kihátrálnak, tehát minden probléma mostantól az alkalmazás fejlesztőjéé, ahogy egyébként a felelősség is. A fejlesztők azt mondták, hogy nekik ez sokkal jobb lenne, a gyártók és az API-t fejlesztő konzorciumok és cégek pedig nem ellenkeztek.
Oda kell adni a fejlesztőknek a kontrollt, ha fejlődést akar az iparág.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
- marad, de több belső felosztás kell
- ahogy eddig, csak a kontrollerek szélesebb memóriabuszt kínálnak
- megfelelőA legnagyobb gond nem a lapkán belül van a HBM mellett. Minden lehet úgy tervezni, ahogy a GDDR5-höz vagy DDR3-hoz, csak több kivezetés kell. A probléma az interposer, de még mekkora.
Egyébként a Fiji és a Tonga tape-outja azonos időben volt. Csak amíg a Tonga mehet ki a hagyományos tokozással, addig a Fiji esetében szopni kell az interposerrel és a HBM-mel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyébként aki ISA-ról akar találgatni ... elárulom, hogy az aktuális driverekben öt ASIC van megkülönböztetve. A GCN disassembler esetében a 110-es dword jelenti a GCN1-et, a 120 a GCN2-t, a 125 a GCN3-at, és a driverben még van kettő, ami a 130 és a 135. Tippem szerint sorrendben Pirates Islands és Arctic Islands. Ne kérdezzétek, hogy mi miben jön. De az AMD névadása annyiból szerencsés, hogy következetes, és mivel Fiji egy olyan sziget, amin vulkán van, így az ISA valszeg a GCN3. Persze volt olyan sorozat is, ahol Fiji a kalózokhoz volt köthető, de az erősen fantasy és sci-fi volt. Szerintem az AMD a Karib-tenger szigeteit veszi elő a Pirates Islands családhoz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A 20 nm még mindig nem tűnik vonzónak. Drágább és lassabb rajta ugyanaz a GPU, mintha 28 nm-en jönne. Ameddig ez fennáll, addig marad a 28 nm.
A 20 nm egyetlen előnye, hogy csökkenthető lenne a lapkaméret és ezáltal a tokozás mérete, de ugyanakkor ez egy VGA-nál nem fontos. Minden más szempontból hátrányos az új node.
A kicsi ultramobil SoC-oknál azért váltanak, mert ott előny a kis lapkaméret és a kisebb tokozás, és ezért megéri elfogadni azt, hogy a 28 nm-nél lassabb legyen a lapka, drágább legyen az előállítása és picit akár többet is fogyaszthat.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
2003 óta a csíkszélességnek egészen kicsi szerepe van a fogyasztás alakulásában. Addig volt életben tartható ez a norma, amíg a Dennard scaling működött, de mivel ma ez már teljesen halott, ezen belül is a 28 nm-t tartják a fizikai falnak, így minden fogyasztáscsökkenés 28 nm alatt a tervezésből és nem a csíkszélesség csökkenéséből adódik.
A legtöbb fogyasztáscsökkenés az automatikus dizájntervezésre használt libraryk fejlődése által érhető el.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz rocket #10029 üzenetére
A lehetőség ott van. Az AFR-Friendly profil megy, de a virtuális procedurális textúrák ghosting hibáját nem tünteti el, ahhoz egy patch kell. Az új Catalyst egyébként az AFR-Friendly profilt engedélyezi a Far Cry 4-re. Az Ubisoft júniusra írja át annyira a Duniát, hogy valószínűleg megoldják az AFR melletti grafikai hibá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 fontos, hogy a mai hardverek órajelvezérlése dinamikus. Ma azért magas ez, mert egy játék terhelése által belsőleg jó ha 40-50%-ra van kihasználva egy GPU. Nagyon jó példa lesz erre az AotS, amely belsőleg 70-90%-ra is terhel. Például az R9 290X hiába működik 1 GHz-en, a tényleges órajel 800-850 MHz közötti volt a GDC-n. A GTX 980 órajele is 900-950 MHz-re csökken. De vannak helyek, ahol GM204 is hajtható 90%-kal, és ekkor az órajel 800 MHz alá is beesik.
A low-level API-kkal azokban a programokba, amelyek erősen aszinkron DMA/compute-ra gyúrnak valójában mindegy lesz a beállított magórajel. Sosem fog azon a szinten üzemelni a GPU.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az aszinkron DMA/compute esetében ez a lényeg:
Látható, hogy az AotS-ban a DX11 és a DX12 pipeline megegyezik, de a DX11-ben az sorosan van futtatva, míg DX12-ben átlapolják egymást a feladatok. Innen jön az nagyobb terhelés, mert a GPU-nak is párhuzamosan kell futtatni az átlapolásokat. Ez növeli a fogyasztást és teljesítményt, amellett persze, hogy csökken az órajel. De végeredményben nagyobb lesz a sebesség még alacsonyabb órajel mellett is, mert ebből a kevesebbet veszít a GPU, mintha a shader processzorok fele kihasználatlan lenne.
Ma még ilyen program nincs, de a jövőben 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 Malibutomi #10301 üzenetére
A HDL már lassan 5 éve használatban van. Egyébként pont hogy a HPL-lel kísérletezik az AMD, ami jobbnak tűnik a GPU-kra, mint a megszokott HDL.
Például a Carrizo egy érdekes hibrid tervezés. A CPU-ja HDL, míg az IGP-je HPL. A Kaverinél pont fordítva volt.[ 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 velizare #10461 üzenetére
Több tucat ilyen per indul a világban. Ezen nem kell meglepődni. A Microsoftot is beperelték a Surface-ért. Sőt, hasonló alapon évente szinte minden cég ellen 20-30 ilyen per indul. Azért nem lesz egyiknek sem eredménye, mert a jognyilatkozatokban minden cég több oldalon leírja a kockázatokat. Aki nem bírja a kockázatos ügyleteket ne tőzsdézzen, vagy ne menjen Vegasba. Fektessen inkább valami alacsony hozamú, de rendkívül stabil, állami garanciával is rendelkező kötvénybe.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem az AMD ötlete az alacsonyabb absztrakció. Régen a Khronos is mondta, hogy érdemes lenne elgondolkodni ezen. El is kezdték 2006-ban a Longs Peak projektet, de sosem fejezték be. Megijedtek, hogy az alacsonyabb absztrakcióval a fejlesztők kiválasztanak majd egy domináns architektúrát, ami a többiekre káros hatással lesz.
A Khronos ARB és a Microsoft GAB sem béna, csupán konzorciumi keretek között működnek. A Longs Peaket az AMD is leszavazta, mert az NV dokumentálta a G8x/9x/2xx-et és nagyon ismerték ezeket a fejlesztők. Most azért akarják az új modellt, mert a konzol miatt a GCN lett a domináns, dokumentált, ismert architektúra. Az ARB és a GAB most is fél az olyan negatív hatásoktól, mint az optimalizálás kiszervezése, de már nincs választásuk.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Jelen pillanatban a friss roadmapben 4 DX12 játék szerepel erre az évre. Viszont lesz majdnem 10 Vulkan játék és 4 Mantle, bár utóbbi esetben nem tudom, hogy pontosan melyik Mantle verzióra vonatkozik, mert a mostani 1.0-s után lesz három új verzió is, és azok közül bármelyik lehet. Az is kérdés, hogy mekkora az átfedés. Egy játék akár mindhárom API-t is támogathatja és ilyen lesz biztosan.
A SteamOS lesz itt a nagyobb indikátor. Most mindenki a Vulkánra írja át magát, mert a SteamOS megjelenésére hajtanak, és a Vulkán ugye fut Windows 10-en is. Azt a Valve mondta, hogy több idén megjelent és még érkező játék kap Vulkán portot, amilyen hamar csak lehet, de legkésőbb a SteamOS megjelenésére.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az 1.0-s verzió tűnik el, illetve átalakul Vulkánná. De lesz egy VR, egy HSA és egy source verzió.
A VR verzió természetesen az AMD LiquidVR-hez kell. Nélküle ez az SDK nem üzemképes. Konkrétan ez a verziója az AMD API-jának bele lesz integrálva a SteamOS-be, míg Windows platformon a driveren keresztül jön. Persze az eredmény ugyanaz, csak a SteamOS esetében a frissítést a Valve végzi el.
A HSA verzió részben a driveren keresztül jön, bár itt maga a HSA Runtime egy külön csomag, amit a HSA alapítvány ad ki, de ez szállítva lesz a Catalysttel.
A source verzió arra szolgál, hogy a fejlesztők a játékban szállítsanak olyan hozzáférést, amely konkrétan egyedi. Ilyen esetben a játék futtatásához még driver sem kell, viszont ez a támogatási forma csak egy adott hardvergenerációra vonatkozik.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem. A Vulkan és a DirectX 12 szabvány. Ahhoz nem kell feltétlenül Radeon.
Az AMD-nél lényegében a saját API, ami nem szabványos, és formai szinten most már biztos, hogy sosem lesz az. Minden ami erre épül, például a LiquidVR, megköveteli a Radeont.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz #85552128 #10698 üzenetére
Pedig egy ideig csökkenni fognak a processzorigények. Manapság a driver elviszi az erőforrást. Tehát hiába lenne elég egy i7-2600K teljesítményének a 10%-a, a grafikus driver annyira soros feldolgozásra kényszeríti a rendszert, hogy muszáj a tervezésnél úgy dolgozni, hogy van az i7-2600K teljes processzorideje és abból nagyjából 10% használható. A low-level iránnyal a teljes processzoridő elérhetővé válik, vagyis effektíve nagyjából tízszer nagyobb számítási kapacitásra tervezhetnek a fejlesztők úgy, hogy senki sem cserél gépet. Viszont az elején ez nem lesz elterjedt, mert az aktuális motorokat nem így tervezték. 2016 végén már érdekes lesz a helyzet, ott már jönnek azok a motorok, ahova már bedobják a fejlesztők a low-level API-k miatt megindított AI fejlesztéseket, és hasonló dolgokat.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz #85552128 #10700 üzenetére
Nem érted a low-level irány lényegét. Az ilyen API-kkal a grafikus kernel driver eltűnik. Tehát jön egy játék, amelyet a Marika GPU architektúrára terveztek, de később érkezik a Marika 2 modernizált architektúra, amelyen ez a játék már nem fog olyan jól futni, mint az első Marikán. És mivel a grafikus driver eltűnt, így a programot kell frissíteni, hogy jobban fusson a Marika 2-n. Ezt egyébként a Thief esetében meg is tették.
Ez minden low-level API-val így lesz, azaz a DX12-vel és a Vulkan API-val is. Ez az egyik hátránya a koncepciónak, hogy a fejlesztő írja meg azt, amit eddig a gyártó szállított a driveren belül.
Ettől függetlenül van előny is. Nekem a DA: I DX11-ben 10 fps-sel megy maxon MSAA nélkül, míg az AMD API-jával 37 fps-t kapok ugyanazzal a beállítással.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz #85552128 #10703 üzenetére
Ha valahol lassabb és nem BF4 R9 285 kombóról van szó, akkor azt elrontották.
Nekünk is van erről tapasztalatunk a PH-s tesztekben, ráaádsul 4,2 GHz-re húzott procival. A minimum fps-ben a DX11-es kód nagyon lemarad. Az átlag nem igazán változik. Szóval alapvetően csak előny van. Ráadásul tényleg ott ahol a legfontosabb, a minimumok területén.Nekem megmagyarázható miért gyorsabb 3-4x. Q9550 limitálja a DX11-et, miközben amúgy maga a processzor teljesítménye bőven elég a DA: I játékra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz #85552128 #10713 üzenetére
A Frostbite 3 motorba be van építve egy memóriafigyelő. Azzal kiírathatod, hogy mennyi VRAM-ot igényel a program aktuális beállítása. Ezt azért rakták bele a tervezők, hogy mindig úgy állíthasd be a játékot, hogy a rendelkezésre álló memória alatt lehess.
A DA: I patch5 és a Battlefield Hardline alatt már a VRAM használat csak picit nagyobb, mint DX11-ben. A többi motor eleve előre allokálással dolgozik, tehát ugyanazt használják, amit most a Frostbite 3 új verziója.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Microsoft már 2014-ben mondta, hogy a processzorfejlesztést az új API-k átírhatják. DX12 alatt sokkal előnyösebb sok gyenge mag, mint kevés erős. A Nitrous motor erre nagyon jó példa. Gyakorlati környezetben 16 szálig lineárisan skálázódik, de a fejlesztők szerint van 72 szálas szerverük, amelyen ugyan már nincs lineáris skálázódás, de 55 szálig ez megmarad, tehát látható, hogy 55 szál szépen 90% fölött jár. Optimalizálással lehet több is.
Ha valaki gaming procit csinál érdemesebb sok picit magot rakni bele, mert jóval kedvezőbb az új API-knak.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azokat nem az új API-kra tervezték. Akkor még szó sem volt róla. Persze kétségtelenül az FX-eknek ez az irány nagyon előnyös, de ez inkább szerencse, mint tudatosság.
(#10736) TTomax: Mert early specifikáció. Vannak benne még hibák, és a stabilitás érdekében korlátozzák az API-t. De mindegyik új API pontosan ugyanazt a parancs feldolgozásos modellt használja, mint az AMD API-ja, tehát ha feloldják a limiteket, akkor ugyanarra képesek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem értem most mi a gondod. Biztosan nem a DX12-re tervezték az FX-eket. Az AMD ezt nem látta előre. Egyszerűen csak szerencséjük van. Ha bárki azt mondja, hogy az AMD 2005 környékén meglátta a varázsgömbben, hogy a DX12 már skálázódó API lesz, akkor az hazudik. A fejlesztés során a DX12 nem számított, de annak biztosan örülnek, hogy ez így jött ki.
(#10743) TTomax: Az AMD API-jában és a Vulkánban működik. A DX12-ben is működni fog, csak ennek az API-nak ez a része még nincs kész. Még ezernyi más dolog van letiltva benne. Ez megszokott dolog a specifikálásnál.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz #85552128 #10745 üzenetére
Mert a Microsoft a DX11-be rakott multi-thread támogatást, csak az meg tényleg nem működött. De 2005-ben már látták, hogy a Microsoft mit akar. Amilyen szerencséjük van most, olyan pechük volt a DX11 esetében.
(#10747) do3om: Minek kellene nevezni? Vannak nyolcmagos procijaik egy olyan DX11-hez, amely még mindig egy szálon adja át a parancsokat a GPU-nak. A DX12 pedig ezt többszálúsítja, ráadásul teljesen függetleníti a feldolgozást. Az, hogy ez így alakult semmi más csak kőkemény mázli. Jó persze egy saját API-val ők is hozzájárultak ehhez, de a mázlifaktor benne van.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egészen egyértelművé is tehetjük ezt. Az ilyen elméleti alapoknál mindig a Pollack szabály az irányadó. [link] - ez konkrétan kimondja, hogy ugyanarra a szilíciumterületre nagyobb teljesítmény építhető több maggal.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz stratova #10889 üzenetére
A VR-hez hardverek is kellenek. Anélkül csak a szöveget lehet nyomni. Ezt sokkal nehezebb kampányolni. Főleg úgy, hogy az NV szerint nem lehet 1,5x-ösnél jobb skálázódás VR SLI-vel, majd négy órával később a Valve bejelenti, hogy az AMD Liquid VR-jével Affinity AFR-rel 2x-es skálázódást értek el. Azóta a VR-t az NV leadta. Még a VRLA szponzorálás mögül is kiléptek. A Pascal majd sokkal jobb lesz. Az már több fontosabb területen úgy fog működni, ahogy a GCN, így a VR is jobban fog menni neki.
Az is fontos, hogy az Oculus ott van például a Redditen, és volt olyan hsz-e az egyik programozónak, hogy az NV VR-je a gyakorlatban rosszabb mint az AMD-é. Ha nem lennének ott az Oculustól a közösségi csatornákon, akkor könnyebb lenne a VR mellett kampányolni, de így jobb a háttérbe húzódni.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz joysefke #10892 üzenetére
TrueAudio elterjesztése nem olyan nehéz. Nézd a VR-t. Már az Oculus is elővette, hogy a hangot meg kell oldani, mert ha füled nem azt a információt kapja, amit a szemed lát, akkor az kellemetlen lesz az agyadnak. Nem tudja majd összerakni, és jön a fejfájás. Éppen ezért lesz a végleges Riften füles, illetve hozzá lesz egy fejlesztőcsomag, amelynek a része a TrueAudio támogatás is, mert processzorból baromira drága megoldani a problémát. Ebből majd a Tensilica sokat fog profitálni, mert az Oculust már megkérte őket, hogy készítsenek egy gyorsan implementálható IP-t, amit a többiek be tudnak dobni, hogy ne a hangon csússzon el a VR.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Malibutomi #10952 üzenetére
Azért az durva lenne. Elég nagy hátrány már az is, hogy kihagytak mindenkit a fejlesztésből. Gyakorlatilag van egy AMD-re kialakított rendszer, rájuk kigyúrt interposerekkel, szoftveres háttérrel, mindennel. Ez nem elég nagy hátrány? Mire eljön a HBM2, addigra az AMD már tudja, hogy mire kell figyelni, mik a limitációk, és mi kell a jó teljesítményhez. A többieknek ez csak a HBM2-nél derül ki, és a HBM3-nál reflektálhatnak rá.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Malibutomi #10957 üzenetére
Amit mutattak az egy pár dolláros makett volt.
Nagyjából az ami a Tongában van. Az NVLINK egy szerveres dolog, mert csak az IBM támogatja.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz regener #10964 üzenetére
Ki nem hagyja ki? Mi értelme lassabb és nagyobbat fogyasztó lapkákat hozni 20 nm-en, amikor a GPU-k esetében a lapkaméret nem olyan kritikus. Inkább hoznak gyorsabb és kevesebbet fogyasztó 28 nm-es lapkákat.
Azt megértem, hogy az Apple rámegy, mert telefonban nem mindegy, hogy mekkora a lapka, hiszen kisebb lapka, kisebb tokozást tesz lehetővé, ami nagyobb aksi beépítéséhez vezet, de egy VGA-nál ez nem téma.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az elérhetőség attól is függ, hogy mennyi lesz az ára. Ebben még nincs megegyezés. Az AMD 799-et akar, míg a gyártók 959-et. Valszeg 899 környékén megegyeznek.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Fiji teljesítményét nehéz körvonalazni, mert sok mai hardverrel ellentétben nem limitálja a memória-sávszélesség. Valahol szimplán az élmezőnyben lesz, valahol pedig elhúz mindentől, még a 295X2-től is. Főleg azokban a játékokban, ahol a sávszél limitál.
A VR-ben meg egy külön kategória. Ott nem lesz ellenfele. Hasonlóan működik, mint a Tonga, csak a Tongának a VR-hez nincs akkora ereje, a Fijinek pedig lesz.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
AFR mellett vannak memóriamásolások, amelyek azért nincsenek ingyen. Ez egy GPU-nál nincsen. A másik meg az, hogy a kényszerített AFR egy fos. Majd ha a fejlesztők vezérlik, akkor haszna lesz a két GPU-nak. Addig egy alig működő valami.
[ 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 Menthirist #10993 üzenetére
A Vulkan és a DX12 egyáltalán nem VR-ready API még. Azért jönnek specifikus környezetek a gyártóktól. Az persze igaz, hogy az AMD a VR-ben előnyét részben szoftverből nyeri azzal, hogy a LiquidVR funkciókat a Mantle alatt működtetik, ami már egy VR kiterjesztésekkel megtömött API.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen