- A jövő hónapban párban jönnek a Sony gaming monitorok
- A SteelSeries felfrissítette az Apex Pro sorozatú klaviatúráit
- Egységesíti a terméktámogatást az Intel?
- Kreatív hobbistáknak és profiknak szánt beviteli eszköz(pár) jött a Logitechtől
- Kétféle interfésszel érkeznek a Klevv, jövő hónapra datált M.2-es SSD-i
- AMD GPU-k jövője - amit tudni vélünk
- Kormányok / autós szimulátorok topikja
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Melyik tápegységet vegyem?
- Hobby elektronika
- Milyen TV-t vegyek?
- Házimozi belépő szinten
- Apple notebookok
- Milyen videókártyát?
- Kétféle interfésszel érkeznek a Klevv, jövő hónapra datált M.2-es SSD-i
Hirdetés
-
Mozgásban a Hell is Us
gp Ahogy arról már korábban szó volt, a megjelenést 2025-re halasztották a fejlesztők.
-
Miniatűr csúcstelefonnal készül a Vivo
ma Persze lehet, hogy az X200 Pro mini képernyője nagy lesz, csak nem túl nagy.
-
9 Lives to Defend bemutató
lo Jó sok dolga akad a macskánknak, míg távol vagyunk az otthonunktó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 Petykemano #25443 üzenetére
Igazából csak azt a drivert fejlesztik. Az AMD explicit meghajtója részben univerzális, vagyis nincs külön teljes értékű Mantle, D3D12 és Vulkan implementáció. Mindegyik implementáció egy PAL nevű rétegen keresztül működik, ami lényegében a Mantle driver. E fölé van húzva ICD réteg, ami tartalmazza az egyes API-k specifikus implementációját. Ez azért lényeges mert így az AMD egy univerzális meghajtóstackkel lekezel három explicit API-t is. Sokkal kisebb így a hibalehetőség. Persze a hátránya ennek, hogy nagyságrendekkel nehezebb jóra megírni, mint a különálló implementációkat, de ez az AMD-t már nem érdekli, mert a Mantle idejében már megírták. Járulékos előny, hogy a PAL fejlesztésével mindhárom API-ra hatnak.
[ 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 #25459 üzenetére
Ez minden HDMI 2.0-s kártyára igaz. Nincs elég sávszál a HDMI 2.0a-ban, hogy kinyomja a 10 bitet 4K-ban. Ahhoz DisplayPort 1.4 kell. Ezt lassan egy éve lehet tudni.
Ezt az AMD kihangsúlyozta a Polaris megjelenésekor is, hogy a 4K HDR HDMI 2.0a-n keresztül limitált, mert az interfész nem elég gyors. DisplayPort 1.4-re adtak meg minden HDR-re vonatkozó specifikáció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 Jack@l #25463 üzenetére
Csak nem 60 Hz-en. Ha ez nagyon zavar DisplayPort 1.4-et kell használni. 30 Hz-en egyébként megoldják a kártyák, arra elég a sávszélje a csatolónak.
Egyébként, ha elolvasod a Guru3D hírét és nem csak a címet, akkor ők is leírták ezt.
[ 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 #25465 üzenetére
Semmi baj a kábelekkel és az AMD-vel. A gond a HDMI 2.0a sávszélessége. Ennyi. Nem tud vele senki sem mit kezdeni. Majd jön a következő aljzat és megoldja. De mint írtam ez nem újdonság. Az AMD már a nyáron elmondta, hogy minden, amit a HDR-re megosztottak az a DisplayPort 1.4-re vont igaz. A HDMI 2.0-n limitáltan fog működni a kevés sávszélesség miatt.
A tévégyártók mozizásra dolgoznak és nem játékra. Nekik megfelel a HDMI 2.0, mert a probléma a 30 Hz fölötti frissítéshez kapcsolódik. Csak 4K 60 Hz-en kell trükközni, mert akkor lesz szűkös a sávszé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 Jack@l #25470 üzenetére
Mert a HDR10 formátum, ami nem köthető az aljzathoz.
Maga a Polaris sorozat HDMI 2.0b és DisplayPort 1.4a kimenetekkel rendelkezik. Ezek közül a HDMI 2.0b alatt a határ 4K-60Hz-10 bit-4:2:2. A DisplayPort 1.4a interfészen a határ 4K-96Hz-10 bit-4:4:4.
Az már amúgy egy másik kérdés, hogy amikor a játékok tonemaping futószalagját eleve nem HDR-re tervezik, akkor mennyire éri meg 10 bitet használni, mert bőven lehet, hogy a mai tapasztalatot nélkülöző futószalagon többet ér a 4:4:4 8 bit, mint a 4:2:2 10 bit.
A konkurencia is ugyanezektől a limitektől függ. Az NV is 8 bittel dolgozik jelenleg, ezért nem volt különbség az RX400 és a GTX1000 HDR képminősége között a Heise.de szerint. De nyilván az NV is képes lenne beállítani 10 bitet 4:2:2-vel, csak ma annyira rossz a tonemaping futószalagra vonatkozó tapasztalat, hogy nem lenne a legjobb döntés. Inkább romlana, mint javulna tőle a képminőség. Majd fél év múlva sokkal jobb tonemaping futószalagokat kapnak a játékok, mert folyamatosan gyűlik a tapasztalat.
A legtöbb játékos egyébként HDR monitort fog venni, mert ott a DisplayPort 1.4a miatt nem kell meghozni a HDMI2.0b áldozatait.A Heise.de tesztjében az egész azért merült fel, mert a HDR-től az RX400 szinte nem veszít semennyi sebességet, míg a GTX1000 igen, ráadásul viszonylag sokat. De ennek az oka pusztán hardveres. A Polaris tartalmaz pár fast path futószalagot HDR-re, így alig kell sebességvesztéssel számolni, míg a Pascalban ilyen trükkök nincsenek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez az átalakítótól függ. Lehet, hogy pont az lesz a szák keresztmetszet, mert ezek rendszerint aktív megoldások. Valószínűtlen egyébként, hogy egy ilyen átalakító minden esetben átviszi a HDR-t.
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 #25502 üzenetére
Nyugodtan mérget vehetsz rá. Nem támogatja a GDDR5(X) memóriákat. Annyira eltérő memóriavezérlő kell a HBM-hez, hogy nincs lehetőség az átjárhatóságra. Vagy az egyik, vagy a másik, de mindkettőt nem lehet beépíteni a lapkába.
[ 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 Petykemano #25505 üzenetére
Majd kiderül. Én csak arról tudok, hogy egy szoftveres bejelentés jön.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz schwartz #25563 üzenetére
Csak nem veszitek észre, hogy egy ROP nem mindig egyenlő egy ROP-pal. Maga a ROP pont olyan egység, mint a multiprocesszor. Belül lehet formálni, más kialakítást adni neki, több gyorsítótárat, stb. A GCN3 ROP-ja legalább 30%-kal hatékonyabb, mint a GCN2 ROP-ja. A GCN4-ben ez még hatékonyabb, bár a GCN3-as ROP-hoz képest csak pár százalékkal. Belerakhatnak 96-128 ROP-ot a Fiji-be, vagy 64 ROP-ot a Polaris 10-be, de egy dekával nem lesz gyorsabb, mert a sávszél a limit.
Ezt a ROP dolgot architektúránként itt picikét részletesebben kifejtettem: [link]
Az új Tomb Raider nem a ROP-tól szenved, hanem attól, hogy nem a Microsoft előírásai szerint csinálták a bekötést. Nem véletlenül ajánl dolgokat az MS a saját API-jaira.
[ 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 Petykemano #25566 üzenetére
Kell neki a sávszél, mert a GCN3 az ilyen volt. Sávszélzabáló. A GCN4 annyira nem zabál.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Amúgy durva lesz a december Radeon szoftveres oldalról. Alig fért bele egy órába az újdonságok ismertetése, pedig csak átrohantak rajtuk. De a célkereszt a homlokomon, inkább nem írok többet.
[ 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 #25579 üzenetére
Mantle-ből kaptunk egy Vulkan API-t. Azzal mi a baj?
A HSA már létezik. Az AMD-nél ROCm néven fut. Egy éve elérhető a meghajtó.
TrueAudio 2 nincs. Csak TrueAudio van, de az valóban nem futott be, mivel nem nyitották meg. Sajnos a Sony-é volt a rendszer. Ugyanakkor a TrueAudio Next már szabványos API, ami akármilyen OpenCL 1.1-es hardveren fut, és máris bele van integrálva az Unreal Engine 4-be és a Unity 5-be.A DX12 terjedése egyébként nem hiszem, hogy a fejlesztőkön múlik. Sokkal inkább annak a következménye, hogy a Microsoft kihúzza a talajt a DX11 alól, és a fejlesztőeszközeiknél átrakják legacy státuszba. Ilyenkor már akkora többletköltség egy API, hogy megéri továbblépni. Ez egy kikényszerített átállá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 Jack@l #25582 üzenetére
Ezért is remélem, hogy ráperecelnek, és nem a DX12-re mennek a fejlesztők, hanem a Vulkan API-ra. Sokkal kiszámíthatóbb a piac, ha a Microsoftnak nincs ekkora kontrollja felette. És a Vulkan már nem is olyan fos, mint az OpenGL. A DX12-t csak azoknak kellene megfontolniuk, akiknek tényleg kell valami olyan funkció belőle, ami a Vulkan API-ban nincs.
(#25583) gyiku: hülyék lennének utána.
[ 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 Petykemano #25588 üzenetére
Erre nem tudok válaszolni. Illetve tudnék, de akkor megsérteném az NDA-t.
Egyedül annyit írhatok, hogy a DX12 egy nagyon AMD-re tervezett API, tehát a terjedése nyilván csökkenti az NV sebességét, mert nem tudják használni a hardverbe épített fast pathokat. Vulkan alatt sem, de a Vulkan annak ellenére, hogy egy direkt Mantle leszármazott mégsem kötődik annyira az AMD-hez, mint a DX12. De persze ez koncepció. A Khronos úgy építette fel a Vulkan API-t, hogy igazodjon a mai hardverekhez és majd kiegészítik a jövőben. Tehát a kiterjeszthetőséget beletervezték. A Microsoft úgy építette fel a DirectX 12-t, hogy legyen egy jól megtervezett alap és majd az új hardverek igazodnak hozzá. Nyilván nem mindegy ez a különbség. Különösen a programozható skalárfeldolgozó nélküli hardvereknek.
[ 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 Petykemano #25603 üzenetére
Semennyi. A szintetikus mérések a geometriára azért csalókák, mert nem reprezentálják a valós játékot. Nem veszi figyelembe, hogy a hardver egy komplex jelenetnél mennyi limitációba fut. Viszont a primitive discard accelerator csökkenti a sávszéligényt, tehát az segítene, kivéve a compute culling motorokat.
(#25605) TESCO-Zsömle: Már 12. generációs a tesszellátor. De a limit úgyis a négypixeles raszterizáció.
(#25607) HSM: A sok háromszöggel nincs baja az AMD-nek. Jelenetszinten a legtöbb háromszöggel a Deus Ex: Mankind Divided dolgozik. Mégis az AMD kártyák erősek benne. Nem azért, mert jobban tesszellálnak, vagy jobb a geometriai pipeline-juk, mint a GeForce-oknak, hanem azért, mert hatékonyabban raszterizálnak, ráadásul a GCN4 óta kevesebb háromszöget. Nem véletlen, hogy az NV már kerüli a túltesszellást, mert valós játékon belül túl erős benne a Radeon. Helyette nem raszterizált háromszögeket tesszellá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 Jack@l #25646 üzenetére
Nem igazán. A compute gpu igazából arra vonatkozik, hogy a GPU bekötése teljesen programozható, vagyis a rendszer egy memóriaalapú architektúra. Nincsenek benne fix slotok, hanem egy programozható egység gondoskodik arról, hogy minden API-hoz tökéletesen igazodhasson. Ezt eredetileg az Intel hozta fel még a Larrabee kapcsán, amikor a magokon belül erről a skalárfeldolgozó gondoskodott. Ma ilyen rendszer az AMD GCN, illetve az ARM Bifrost.
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 #25648 üzenetére
Nem kell megmagyarázni. A gyártóknak joguk van saját definíciót írni a cGPU-ra. Az NV definíciója jóval engedékenyebb, míg az AMD-é például nagyon szigorú, ugyanis az AMD konkrétan csak azt tekinti cGPU-nak, ahol a teljes címtartomány feltölthető erőforrásokkal. Nyilvánvaló, hogy ezzel a definícióval csak a GCN a cGPU.
A legelfogadottabb definíció azonban az Intelé még a Larrabee időszakából.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Jack@l #25651 üzenetére
Akkor leírom részletesebben. Az NV a cGPU-t a Fermi megjelenésekor definiálta. A definíció szerint azok a GPU-k tartoznak ide, amelyeknél egy tömbnyi szálcsoport ugyanazt a kernelt futtatja, és az adatokat a globális memóriából olvassa és a globális memóriába írja.
Az AMD definíciója tulajdonképpen ugyanez, de ki van egészítve azzal, hogy az erőforrások kezelésére a teljes elérhető címtartományt fel lehet használni.
Az Intel definíciója a Larrabee esetében ezeknél annyiban eltérő, hogy nem ennyire architektúraspecifikus, hanem sokkal inkább egy általános leírást ad meg. Nevezetesen egy futtatott kernel, akármilyen körülmény között tudjon olvasni a globális memóriából és írni oda, illetve a multiprocesszor erőforrás-kezelése legyen teljesen programozható.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz huskydog17 #25653 üzenetére
Mert az NV cGPU-ként hivatkozott rá. Nem feladatom eldönteni, hogy kinek a definíciója helytálló. Ma sincs igazából problémám az NV definíciójával. A lényeg az, hogy definiálják, hogy szerintük mi a cGPU. Kb. annyira értelmes, mint az AMD definíciója. Úgy van megírva, hogy csak a saját architektúrára legyen ráhúzható. Amikor az NV megírta a saját definícióját, akkor még TeraScale 2 volt.
A definíciónál a legjobb az általánosságra való törekvés, mert annak nincs sok értelme, hogy kiválasztasz egy extrém dolgot az architektúrádból, és arra ráhúzod a definíciót. Lásd GCN-nél a teljes memória címzése az erőforrások kezelésénél. Az Intel a Larrabee idején megpróbálta eléggé általánosan definiálni, hogy mi számít, nem úgy, hogy csak a Larrabee-re legyen jó.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz huskydog17 #25656 üzenetére
Én arra írom oda, amely az Intel régebbi definíciójának megfelel. Az egy nagyon jól megfogalmazott, láthatóan nem arra kiélezett definíció, hogy csak a gyártók kis részére legyen ráhúzható. Az NV és az AMD definíciója ebből a szempontból sokkal szarabb, nagyon specifikusan saját hardverhez igazított leírás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az mindegy. A részegységek száma csak a teljesítményre és a parancslisták számára van hatással. Ettől maga funkció nincs kikapcsolva, nem is létezik rá lehetőség DX12 alatt, maximum a compute parancslisták száma lesz alacsony, ezáltal nem lesz hatékony a rendszer.
Itt igazából nem is az egység a lényeg, hanem a parancslisták, mert az egység önmagában mindegy. A GCN1 két független compute parancslistát támogat. A GCN2/3/4 64 darabot.[ 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 #25685 üzenetére
Nem lehet kikapcsolni DX12-ben az aszinkron compute-ot. A Microsoft szándékosan építette fel így a rendszert, ugyanis ilyen formában az API sokkal hibatűrőbb. A Vulkan is át lesz dolgozva ilyen modellre az 1.1-ben, mert a normál támogat-nem támogat modell nagyon kedvezőtlen.
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 #25715 üzenetére
A játékba semennyit nem ölt az AMD. A Nitrous motorba öltek, de többet adott az Oxide-nak az NVIDIA. Illetve az Intel is támogatta ezt a rendszert némi munícióval. [link] - itt volt a cégek közötti egyezmény bejelentése.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz TTomax #25719 üzenetére
Publikusan nem fogják nektek elárulni. De a lényeg az, hogy a Nitrous motort nem csak a csoda hozta össze, hanem a gyártók pénze és technológiája. Főleg az NV pénze, az AMD technológiája és az Intel mérnökeinek szakértelme, ha az arányok érdekelnek.
Az mutatja, hogy mindenki nagyon elégedett volt ezzel az egyezménnyel, hogy a Nitrous továbbra is az Oxide-Intel-AMD-NV kooperációban fejlődik. Ki pénzt rak bele, ki szakértelmet, ki technológiá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 TTomax #25721 üzenetére
Nem nekem árulták el, hanem a GDC-n vázolták fel, hogy ki hogyan segített. Gondolom eleve nem hitted el, hogy pár ember rakta össze a kor legjobb motorját. Okos emberek, de csak vezették a fejlesztést.
Ez az egyezmény a játékokra egyébként nem terjed ki. Tehát az AotS esetében már külön egyezményeket kell kötni. Viszont az említett cégek a Nitrous licencekből bizonyos arányban részesülnek.
Az AotS az AMD-t érdekelte, míg az Intelt és az NV-t nem. Ettől a Nitrous fejlesztését továbbra is segítik. Ez két különböző dolog. Az AMD csak azért zsákolja be a nitrousos játékokat, mert mindegyiket a Stardock adja ki.[ 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 #25723 üzenetére
Nyilván nem rövidtávú befektetés ez. A Nitrous az első motor, ami arra épül, hogy valósítson meg valós időben egy Reyes-szerű leképezést. Ezzel tulajdonképpen közelebb kerülhet a valós idejű grafika a trükkmentes CGI-hoz. Nem kell eltérő fényforrásokat kreálni, nem kellenek trükkök százai a jó eredményhez, hanem a rendszer egyszerűen csak jót számol, és nem csak jól, hanem nagyon gyorsan is. Ennek a megtérülési ideje cirka 10 év minimum. Emellett a gyártók maguk is licencelők, tehát házon belül megvan a Nitrous, és ezt akárhogy módosíthatják, illetve hozzáigazíthatják a jövőben érkező hardvereiket. Tipikus win-win szituáció mindenkinek.
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 #25726 üzenetére
130-an voltak részei a Mantle Access programnak. 100 volt ismert, de többen voltak, viszont a harmadik kört nem nyitották meg, ugyanis akkor már tudta az AMD, hogy a Mantle-t odaadják a Khronosnak, hogy Vulkánt csináljanak belőle. Viszont ezek a csapatok megcsinálták magát a leképezőt, amiből nagyon könnyen tudnak DX12 és Vulkan leképezőt csinálni. Nem az API-k közötti váltás jelenti a gondot, a legtöbb motor kezeli majdnem mindet. De nem mindegyik API igényli ugyanazt a motorstruktúrát. A DX11 és OGL hasonlót követel, míg a Mantle/DX12/Vulkan mást. De utóbbi három API-ban az a különleges, hogy ugyanazok az igényeik a motorstruktúrára. Tehát aki részt vett a Mantle Access programban már új struktúrájú motort használ. Ezek a fejlesztői programok nagyon fontosak a gyors terjedéshez. Máig ugye 27 explicit API-t támogató játék jelent meg, és jövőre egy egészen friss adat szerint 50+-t várunk csak DX12-ből. Ha most állnának neki a cégek a motorstruktúra átírásának, akkor 10-et nem várhatnánk jövőre.
Egyébként nem valószínű, hogy a Nitroust valaha is odaadják egy konzorciumnak, hogy csináljon belőle egy nyílt rendszert. A Mantle esetében ez logikus volt, mert a Khronosnak kellett valami a Vulkan megvalósításához, de a Nitrous egy üzleti konstrukció. Ezt licencelni lehet pénzért, nem kevés pénzért.
[ 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 Petykemano #25767 üzenetére
Az a táblázat egy Chipchell felhasználó agyszüleménye. Ne foglalkozzatok vele. Már a memóriabusznál hibás.
(#25730) leviske: A SEGA nem, mert ők három motort is fejlesztenek kifejezetten stratégiai játékokhoz. A 2K-nak a stratégiákkal foglalkozó stúdiói is saját motort terveznek. A Blizzard pedig a minimum igények miatt nem fog a Nitrousra menni. Nekik nagyon fontos, hogy a játékaik két maggal és IGP-vel is fussanak. A Nitrous minimum négy, de inkább hat magot igényel. Persze ha aktív lesz a GPU-s terepdeformáció, akkor az aszinkron compute leviszi a CPU-igényt, de így sem fut majd két magon.
[ 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 Szeszkazán #25772 üzenetére
Ezek közül nem mind VEGA. Csak kettő.
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 #25839 üzenetére
A Deep Learninget az Intel tarolja folyamatosan. A gyorsítók még csak most kezdenek bejönni, de egyelőre a teljes piac egy nagyon kis szeletéig jutottak el. A GPU-k nem is igazán alkalmasak tréningre, mert nagyon kevés a memóriájuk hozzá. Úgy 1 TB-nál kezdődik az a memória, ami alkalmassá tenné őket erre. Akár lassú memória is jó, csak legyen ott a kapacitás. Ahol a GPU-k jók az csak a dedukció.
[ 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 #25842 üzenetére
Az önvezető autók nagyrészt VeriSilicon IP-vel furikáznak. Az NV-nek ez azért nem látszik igazán a bevételein, mert a sok reklám ellenére ezen a piacon még mindig 10% alatt van a részesedésük, és elég nehéz növelni ezt olyan versenytársakkal szemben, mint a VeriSilicon.
De a tréningnek csak olyan területei vannak. Ezért használnak Xeon CPU-kat tréninghez és a gyorsítók igazából csak a dedukcióhoz jók.
A Xeon azért erős itt, mert rakhatsz mellé 1+ TB rendszermemóriát. Ennyi. Valójában se a CPU, se a GPU nem túl ideális ide, mert leszámítva az extrém memóriaigényt a futtatott kódok 95%-a GEMM, tehát a legjobb egy erre kialakított célhardver.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Ren Hoek #25848 üzenetére
Elsődlegesen azért nőttek meg számban a deep learning piacra szánt megoldások, mert jelenleg ezt a területet az Intel uralja úgy 95%-ban. A maradék 5%-on osztozik egy rakás más konstrukció, ideértve a GPU-t, a dedikált hardvereket, egyéb architektúrára épülő processzorokat, illetve más gyorsítókat. Ha ez nem így lenne, akkor nem érdekelné a piac az új szereplőket, mert jelenleg kb. van ebből egy picike bevételük, de ha befut mondjuk a konstrukció, akkor nem csak az az 5% lesz elérhető, hanem a maradék 95% is. Az NV sem azért az évi 200 millió dollárért csinálja, amit ma behúznak ezzel. Ezt ki tudnák váltani jobb piacokkal is, de mondjuk úgy 5 éves távlatban már ebből könnyen lehet 3-4 milliárd dollár, ugyanis még a piac 1%-át sem sikerült lefedniük.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Jack@l #25847 üzenetére
Mert nem kapsz embedded JPR jelentéseket erről. Nem vagy előfizető. Innentől kezdve csak arról hallasz, amiről a média ír, és nem arról, amit el is adnak. Az NV ennek az automotive dolognak nem a kitalálója, csak beugrókról van szó. Valójában a piacot az NXP uralja. Az IP szempontjából pedig a VeriSilicon az első, de ők is azért, mert megvették a Vivantét.
Az NXP-t is most akarja felvásárolni a Qualcomm, mert egyszerűen be akarja vásárolni magát a piacba. Sokkal egyszerűbb így bekerülni, mint nulláról fejleszteni, mint ahogy azt teszi az NV.[ 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 #25852 üzenetére
Hát akkor meg is vagyunk. Ha ezeket nem olvasod, akkor nem tudod, hogy miket vásárolnak a gyártók, és mely platformnak mekkora a piaci részesedése.
Azt is jelzem, hogy ha az NV az automotive piacon akkora sztár lenne, akkor a Qualcomm a Tegra üzletágért fizetne ~40 milliárd dollárt és nem az NXP-ért. De a Qualcomm elsődlegesen nem üzletágra vagy technológiára vágyik, hanem a nyers piaci részesedést, és a kiépített üzleti csatornának akarja megvásárolni ennyi pénzért.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Ren Hoek #25854 üzenetére
Az adatközpontok piacának, ahol eddig is létezett a gépi tanulás, elég régóta. Csak eddig Intel procikon csinálták. Gazdaságos volt? Nem. De működött. A gépi tanulás gyorsítása egy új dolog, de ettől a már kiépült piac nem szűnik meg. Nem fogják kidobni az erre vásárolt Xeon procis szervereket, mert az eleve egy drága beruházás volt.
Ami most történik az megtörtént korábban más szegmensben. Jöttek valamire a gyorsítók és elkezdték kiváltani a CPU-kat. De a gépi tanulásnál még csak elkezdték. Még van egy rakás probléma, mint a memória kapacitása, a virtualizálás minősége, stb.
A kapacitás pedig attól nem lesz elég, hogy rákényszerít a hardver a spórolásra. Ez nem egy irány, hanem egy korlát okozta következmény. Szóval, ha valaki hoz 1 TB memóriát egy gyorsítóra, akkor az lesz a sztár.
Ki beszélt Phi-ről? Az Intelnek Knights Crestje lesz. Ők észrevették, hogy se a CPU se a GPU nem hatékony tréningre. Ezért vettek egy speciális dizájnt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Yutani #26018 üzenetére
Semmi köze a fogyasztáshoz. Azért eszik sokat a GCN, mert minden CU-ban van egy skalár egység, amivel a rendszer működése teljesen programozható. Egy API támogatása ezen az architektúrán annyi, hogy a skalár egységhez írsz egy szoftveres rutint, amivel rámappelhető minden az adott API-ra. A többi architketúra egy jóval egyszerűbb branch egységgel rendelkezik, amelyre jóval nehezebb minden API-t rámappelni, mert nem programozható ez a része a rendszernek.
Ott van példának a shader model 6.0. A GCN-re simán rámappelhető az új függvények zöme. A többi architektúra pedig emulálja ezeket.
[ 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 #26036 üzenetére
A CU dizájnban nyilván kevesebbet, mert eleve a GCN4 egyik képességére épül a VWL, de az uncore rész erősebb. Most még nem írható le, hogy mennyire. De nem azok számítanak, amiket gyiku összefoglalt a hsz-ében. A draw stream itt a lényeges előrelépés. A többi csak adalék, amiket a GCN4-be épített fejlesztések miatt tudnak alkalmazni.
[ 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 #26038 üzenetére
CU-ban kisebb. Ezt korábban is írtam. Uncore-ban nagyobb. Összességében pedig programfüggő. A jól optimalizált DX12 programokban a VWL nem sokat ér. A rosszul optimalizált programokban viszont hasznos.
Az uncore rész pedig általánosan jót tesz a rendszernek, mert csökkenti a memória-sávszélességre vonatkozó igényét az architektúrának. Ez nyilván annyi előnyt jelent egy programban, minél érzékenyebb a sávszélre a rendszer. A többi újítás pedig funkcionális, ezeket direkten támogatni kell, hogy működjenek. Sok újításra API sincs felhúzva. Ezek a PS4 Pro és a Scorpio Xbox PC-s verziói. Lesz hozzájuk nem szabványos elérés, hogy az említett konzolok újításait használó effektek portolhatók legyenek.[ 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 Petykemano #26035 üzenetére
Nem. Az előny a mappelhetőség. Ez nagyon fontos azokban az időszakokban, amikor az API-k ömlenek a piacra, mert ezekre az API-kra rá kell illeszteni a meghajtót. Az AMD-nek a GCN-nél ez csak egy szoftver. Mindegy, hogy milyen egy API, akkor is rá tudják mappelni a hardverre. Ezért váltott teljesen GCN-re az Apple a dedikált GPU tekintetében, mert náluk a Metal egy baromira mobil projekt volt baromira a PowerVR-re. Ellenben a GCN-re a programozható skalár egység miatt rá tudják mappelni úgy is az API-t, hogy köze nincs a GCN-nek a TBDR dizájnhoz. Az Intel emiatt lassú Metal alatt. Rájuk már nem lehet normálisan mappelni, ahogy NV-re sem, és ki is estek az Apple dizájnokból.
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.
- AMD GPU-k jövője - amit tudni vélünk
- Elden Ring
- Itthon is elérhető a OnePlus 11 és a Buds Pro 2
- Háztartási gépek
- Asszociációs játék. :)
- Vicces képek
- BestBuy topik
- Anglia - élmények, tapasztalatok
- Ingyen kellene, de tegnapra
- Hivatalosan is bejelentették a Horizon Zero Dawn Remasteredet
- További aktív témák...
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Ozeki Kft
Város: Debrecen