- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Brutál akkuval érkeztek az Ulefone X16 modellek
- Betiltották a Pixel 7-et Japánban
- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- Android alkalmazások - szoftver kibeszélő topik
- Fotók, videók mobillal
- Magisk
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Szinte csak formaság: bemutatkozott a Pixel 6 és Pixel 6 Pro
Új hozzászólás Aktív témák
-
LionW
tag
Szerintem ez nem akkora probléma, a legtöbb játék aminél tényleg jó a grafika az vagy unreal engine, vagy id Tech, unity, vagy valami más nagyobb fejlesztő motorját használja, amiből van összesen kb 4-5. AMD-nek azt kellene elérnie hogy bekerüljenek az ő optimalizációi is ezekbe a motorokba, és le is fednék vele a játékok nagyrészét.
-
#71
namaste
tag
Petykemano
#70
namaste
tag
válasz
Petykemano
#70
üzenetére
Csak a saját véleményem, szerintem tudatos döntés. Lásd most a Vega M-et, 20/24 CU és 32/64 ROP, kíváncsi vagyok mennyi különbség lesz köztük. Ha akartak volna, korában is kihozhattak volna valami hasonlót.
-
namaste
tag
Igen, a SIMD16 vektor egységek így működnek.
A bekötés az csak a leíró betöltése és tárolása a skalár regiszterekben, illetve ha szükség van az erőforrásra, akkor regiszterekben lévő leírót elküldi a textúrázó vagy a load-store egységnek.
Pontosan erről van szó, a skalár egység egy kis része a CU-nak, ezért nem tehető felelőssé a magas fogyasztásért. A funkcióit az NV hardverek különféle részegységei ugyanúgy ellátják."Persze ha csökkentik a feszültséget, akkor először a skalár egységet kapcsolják le, ugye?"
Ezt nem kell komolyan venni, nyilván nem így működik. Arra akartam utalni, hogy a magas fogyasztásért inkább a magas feszültség tehető felelőssé.Már az első GPU-k is parancslistával működtek. Az NV1 (1995) gyakorlatilag csak textúrázni tudott, még semmi T&L, shader, vagy compute nem volt és az elvégzendő feladatokat parancs bufferbe kellett beírni.
A Kepler GK110-ben van Grid Management Unit és Work Distributor a compute feladatokhoz, a Fermiben csak Work Distributor.
Az Intel IGP-k leírása publikus, megnézném hogyan dolgozik össze a CPU-val.
Az AMD azért erőlteti az async compute-ot, mert raszterizálásban illetve ROP-ban korlátos, ezért ha grafika számolása közben compute feladatokkal is tudja etetni a CU-kat, akkor növeli a kihasználtságot és a teljesítményt. -
con_di_B
tag
"Nem a skalár egység miatt van a magas fogyasztás."
https://en.wikipedia.org/wiki/Graphics_Core_Next
Amennyire en ertem egy wavefront 64 szeles, amit ugy szolgal ki a rendszer, hogy egy valojaban 16 szeles SIMD mag 4 egymast koveto utasitasa lesz garantaltan ugyanaz. Ez egy eleg tipikus design, a szelessegben van elteres. Aztan egy CU-n belul van 4x ezekbol a SIMD magokbol, tehat osszesen 4x16 szeles feldolgozorol beszelunk (fizikailag), szoval osszesen 64 VALU CU-nknent.
Ehhez jon pluszba egy azaz egy darab SALU. 1/(64+1) logikusan nem kene, hogy annyira durva fogyasztast adjon ki, maximum akkor, ha vannak olyan extra funkcioi, amit a VALU-k nem tudnak, de a "bekotes" maga az nem egy ilyen komplikalt feature. Ha egy SFU (double-precision trigonometriaia fuggvenyek es hasonlo alig hasznalt dolgok) lenne fizikailag a SALU-ba epitve, az lehetne ilyen, de akkor az nem fair osszevetes, mert olyan meg van a tobbi hardverben is.
Es akkor ez egy szandekosan sarkitott, konzervativ becsles volt, mert ott vannak meg a TMU-k is stb. a CU-ban, amik szinten nem a SALU extra fogyasztasa fele billentik a merleg nyelvet.
Azt nem ketlem, hogy az AMD-sek tenyleg ezt mondtak Abu-nak, hogy azert magas a fogyasztas. De mondanak azok sokmindent, es sajnos nem mindig stimmel.
"Persze ha csökkentik a feszültséget, akkor először a skalár egységet kapcsolják le, ugye?"
A SALU esszencialis resze egy CU-nak, egyaltalan nem tud nelkule mukodni, szoval azt se lekapcsolni nem fogjak, se kulon nem lehet az orajelet, feszultseget allitani, semmi ilyesmi. Ez a narrativa, hogy a SALU az egy "bindless mode" gyorsito ennyiben kicsit santit, foleg, hogy mint mondtam, jo az masra is.
Visszaterve a fogyasztas reszere, bizonyos programoknal viszont a fordito nem fog semmilyen ertelmes modot talalni a SALU hasznalatara a bekotesen kivul, ebben az esetben viszont a SALU az ido 99%-ban konkretan idle. Na, ha ertelmesen implementaltak, akkor ilyenkor sem kene sokat fogyasztania...
"A bekötésnél pontosan hogyan segít a CPU? Mert renderelés közben (pl. texturázás) nincs idő a CPU-hoz fordulni."
Az igazi hardcore kobunkos GPU-knal ez annyira durva, hogy meg utemezo sincsen normalisan, hanem a driver a command buffer-be beforditja elore, hogy melyik reszegyseg mit fog csinalni, es igy, mar elore behuzalozva erkeznek a parancsok, nincs min gondolkodni ugymond. Bizonyos mertekig meg a Kepler is ilyen volt.
Nagy vonalakban abban van elteres, hogy mekkora merteku az utemezes szabadsaga a GPU-n, mert ahol keves, ott tobb parhuzamos task mellett rossz lesz a hatekonysag. (Ezert lovagol az AMD annyira az async compute-on, mert az o rendszeruk rugalmas, ebben jo.)
Es igen, amit mondtal, hogy nincs ido a CPU-hoz szaladgalni menet kozben, ez igy igaz, ezert praktikus okokbol kell elore eldonteni az utemezest. Amit Abu mond az Intelrol, azt nem tudom, siman lehet, hogy nekik belefer.
Ez az utemezes kozpontu nezet amit az elobb irtam ez persze inkabb a compute nezet, mert minket tobbnyire a maximalis savszelesseg erdekel, nem annyira az alacsony kesleltetes. Grafikaban ugyanezt onnan szoktak nezni, hogy ha minden vackot bele kell gyogyitani a command buffer-be, akkor gyakorlatilag semmit sem lehet skalazodni tobbszalu vegrehajtas mellett sem, mert a normalis driver oldali utemezeshez kb. elore kene latnod a jovobe, hogy a tobbi szal mit csinal majd, ez pedig nem valami eselyes. A masik baj, hogy ha tul sok globalis allapotod van, akkor meg felpercenkent le kell allni szinkronizalni, es emiatt erosen limitalt lesz, hogy hany rajzolasi parancsot tudsz kipreselni a rendszerbol egysegnyi ido alatt.
Az AMD rendszere elmeletben ez utobbiban is jo lehetne, csak a gyakorlatban inkabb savszelesseg orientalt a rendszer, szoval csak azert mert nem dobja fel a talpat a rendszer egy pillanat alatt, ha razuditasz par tizezert draw call-t, attol meg nem feltetlenul lesz nagyon bajnok a kesleltetese.
Ja es a vegere: ez a rendszer viszont utemezovel es mindennel egyutt viszont mar nyilvan fogyaszt. Lehet, hogy igy ertettek a SALU koltseget, hogy SALU + ACE + HWS + franctudja meg mik kellenek ehhez.
-
namaste
tag
Az ismert részegységekben (regiszterek, LDS, L1, L2, GDS) a Fiji 23 MB SRAM-ot tartalmaz, a Vega hozzátesz +2MB L2-t, így 25 MB jön ki. Ezekhez még hozzájönnek a különféle várakozási sorok és bufferek.
Nem a skalár egység miatt van a magas fogyasztás. Persze ha csökkentik a feszültséget, akkor először a skalár egységet kapcsolják le, ugye?
A bekötésnél pontosan hogyan segít a CPU? Mert renderelés közben (pl. texturázás) nincs idő a CPU-hoz fordulni.
#19
A HBM nem fogyaszt nagyságrendekkel kevesebbet mint a GDDR5, az legalább 100-szoros szorzó lenne. Valójában csak 3-4x az arány. -
#63
con_di_B
tag
Petykemano
#61
con_di_B
tag
válasz
Petykemano
#61
üzenetére
Megfeszulni es meg mindig alul maradni meg marketing szempontbol is sokkal kevesbe ertelmes, mint legalabb egy valamiben optimalisnak lenni.
Igy arrol beszelgetunk, hogy az NVIDIA technologiaja sokkal jobb. Ugy meg arrol beszelgetnenk, hogy masban jok.
Persze most is sokan szeretnenek utobbirol beszelgetni, csak nem nagyon all meg a laban. MAR nem jobb a GCN compute-ban sem.
-
#61
Petykemano
veterán
con_di_B
#57
-
#60
gbors
nagyúr
Petykemano
#53
válasz
Petykemano
#53
üzenetére
Nem a fogyasztásra gondoltam, hanem arra, hogy az x80Ti GPU-knak papíron (egységek számai + órajelek) 40%-kal többet kellene tudiuk, mint az x80-aknak, aztán csak 30%-kal tudnak többet.
A frekvenciával majdnem lineárisan nő a teljesítmény - feltéve, hogy a memória-frekvencia megy ugyanolyan ütemben felfelé. A Pascalban még lehetett növelni az ALU-k számát, mert bírta mind az infrastruktúra, mind a backend. A Volta 7 SM-jében már nem vagyok biztos, hogy annyira fasza lesz - de erre még várni kell.
(#55) Abu85: izoláltan teljesen érdektelenek ezek az adatok. Na jó, nem teljesen, de max. csak futó érdekességek. Az számít, hogy mennyit profitál a megspórolt sávszélességből a Vega, és a Battlefield 4-ben látott FPS-ek alapján egészen pontosan semmit (az előbb azt hittem, BF1-ről van szó, ott legalább valami minimális extra van az RX580-hoz képest - a 4-esben még az sem).
-
Abu85
HÁZIGAZDA
A cache-miss lehetőséges, de a Vega 10-ben ~45 MB-nyi SRAM van, ennek egy jelentős része csak a mozaikos feldolgozáshoz tartozik. Alaposan fel van tehát duzzasztva a korábbi GCN dizájnokhoz képest. A Fiji-ben például ~10 MB-nyi SRAM van.
Nem csak viszonylag. A HBM2 a Vega 10-en 6 wattos TDP keretet kap. Ugyanennyi egy 64 bites GDDR5-ös konfigurációra lenne elég.
A magas fogyasztásról alapvetően a skalár ALU-k tehetnek. Direkt megkérdeztem anno. Viszont ezeknek köszönhető az is, hogy a Vega 10 és úgy általánosan a GCN hardveresen támogatja a resources binding és heap legmagasabb szintjeit. Az Intel itt papíron jó, de tudni, hogy trükköznek. Nekik ugye annyiban könnyebb a helyzet, hogy ott a processzor ugyanazon a lapkán, ráadásul közös az LLC, tehát van lehetőség olyan turpisságokra az implementációban, amelyek dedikált GPU-val vállalhatatlanul lassúak lennének. Ergo vagy van skalár ALU és akkor megoldható a DX12 teljes támogatása, vagy nincs skalár ALU és akkor csak minimum szinten van resources heap, de persze ez meg kevesebbet fogyaszt. Az éremnek két oldala van. A választás persze messze nem egyértelmű, ha az lenne, akkor mindenki támogatná a DX12 összes funkcióját. -
#57
con_di_B
tag
Petykemano
#53
con_di_B
tag
válasz
Petykemano
#53
üzenetére
A nagy vonalakban lehet sejteni, hogy hol kiegyensulyozatlan a rendszer:
https://www.techpowerup.com/gpudb/2839/geforce-gtx-1080
https://www.techpowerup.com/gpudb/2871/radeon-rx-vega-64
https://www.techpowerup.com/gpudb/2877/geforce-gtx-1080-tia Vega ALU fronton meg az 1080 TI-nel is erosebb, raadasul ezek az ALU-k mint altalanos szamitasi egyszegek eleg popecul optimalizalva is vannak (nem veletlenul szeretnek veluk banyaszni), raadasul mostanra a texture mintavetelezesi teljesitmeny is korrekt, viszont a ROP backend teljesitmenye meg a sima 1080-et sem eri el. Gondolom ezt akarna jelenteni a pixel throughput.
Es akkor ez meg csak egy nagyon high-level nezopont volt, es nem mentunk bele, hogy ha a tranzisztorszama ekkora a Vega 64-nek es meg HBM2-vel is van sulyosbitva, akkor dragabb lehet gyartani, mint az 1080 Ti-t, az meg nem annyira effektiv, ha cserebe nem tudod ugyanannyiert vagy dragabban adni.
Low-level meg az van, hogy ha normalisan megirsz egy compute programot (na erre nem fogok tudni public benchmarkot mutatni most gyorsan) OpenCL-ben akkor ugyanezek a kartyak inkabb ALU alapjan skalazodnak, es az NVIDIA-nak nincsen semmifele varazslatos elonye, szoval a kulonbsegnek teljes mertekben a rendereleshez kotodo reszekbol kell eloallnia - vagy a TMU a ROP es a CU-k nem tul hatekony egyuttmukodesebol, de valahol mindenesetre el van asva a kutya.
Egyebkent ha mar valamiert muszaj lenne ragaszkodnia az AMD-nek ezekhez a high-level aranyokhoz, akkor meg kiserletezhetnenek olyasmivel mint amit anno a Kepler csinalt, csak ellentetes elojellel, hogy a CU-k jarhatnanak kulon orajelen, ami lehetne LASSABB mint a rendszer tobbi resze. Ez azert se volna rossz, mert akkor az ALU-kat nem volna muszaj speed racerre tervezni, "csak" a specialisan grafikai celu reszegysegeket. Ebbol aztan lehetne egy olyan rendszer, ami compute terheles alatt kellemes teljesitmenyt nyujt eros fogyasztas mellett, grafika alatt meg relative tobbet zabal, de legalabb nem bottleneck-eli az ALU-kat.
-
con_di_B
tag
Ez tok jol hangzik, de onalloan csak azert mert globalisan (osszessegeben) ennyivel kevesebb adatot kell mozgatni, nem feltetlenul jelenti, hogy a rendszer egesze a leheto legjobban fog belole profitalni, es a fogyasztas is ennek megfeleloen esik.
Elmeleti pelda: lehet h a VRAM savszel igeny 30%-al csokken, ami tok jo, de ha melle orrba szajba cache miss van, akkor meg mindig nem biztos, hogy annyira jo lesz a tortenet vege, mint egy olyan rendszeren, ami magasabb cache hit-et tudna produkalni. Aztan a mozaikos torteneteknek meg az lenne lenyege alapvetoen, hogy mindig minden eppen keznel legyen, minel alacsonyabb szintu cache-ben.
De ez csak tippelgetes, a konkret esetre nem lattam profilt soha.
A masik, szinten elmeleti fejtegetes, hogy mivel a HBM2 eleve viszonylag keveset fogyaszt mondjuk a GDDR5-hoz kepest, ezert lehet, hogy ezert sem latunk hatalmas kulonbsegeket a Vega-nal. Ennek nemileg ellentmond, hogy a Vega vs Pascal versenyben az ollo nagyobb mint amennyit a GDDR5 modulok osszesen fogyasztanak, szoval lesz ott meg mas baj is, lasd fentebb.
-
Abu85
HÁZIGAZDA
Így mérik a hatékonyságát a mozikos hardveres optimalizálásoknak. Elvégre ezek arról szólnak, hogy mennyi bájt/frame-et tud spórolni. Ha hozza a tipikus 25-35%-ot BF4-ben, akkor rendben működik a hardver. A BF4 azért jó példa, mert az direkten még nem optimalizált az efféle hardverekre, tehát mindenki nagyjából ugyanolyan hátrányból indul. A BF1 már egy kicsit más. Abban már van Pascalra és Maxwellre optimalizálás, míg a Battlefront 2-ben a Vegára is. Itt már erősen közrejátszik a szoftveres tényező, mert nem minden hardverre ugyanaz a paraméterezés. De persze itt is meg lehet nézni, hogy mennyit spórol, csak a szoftver is segít neki.
(#54) con_di_B: Az AnvilNext konzolon már úgy van megtervezve. Csak PC-re ez nincs átmentve, mert a port leragadt a DX11-nél.
-
#54
con_di_B
tag
Petykemano
#50
con_di_B
tag
válasz
Petykemano
#50
üzenetére
Grafikaban DX11-ben semekkora elonyt nem is tud jelenteni, DX12-ben meg akkor tudna, hogy ugy lenne megtervezve az engine, de ez techdemokon kivul nem hiszem, hogy akar meg manapsag is elfordul. De azokban a techdemokban tenyleg tok jol muzsikal!
Compute-ban tud ertelme lenne, mert ha eppen raerez a fordito akkor ki tud szervezni olyan muveleteket is amik az osszes lane-en ugyanazt adnak, pl. index kalkulaciok egy resze (van egy bazis ami ugyanaz, es az offset ter el) stb. Ezeken elmeletben lehet fogni nehany Joule-et, ami aztan a gyakorlatban abban mutatkozik meg, hogy tovabb birja a turbo-t, mert egyebkent kb. gyarilag tulhajtott parameterekkel jon minden GCN-es kartya. Ezert talalsz annyi hirt arrol, amikor alulfeszelve (nem feltetlenul underclockolva!) meg gyorsul is a kartya.
Amit meg leirtal tortenetnek, igen, pontosan ugyanigy kepzelem en is.
Ez a tortenet elegge tipikus egyebkent, torvenyszeruen ilyesmik tortennek minden cegnel ahol eroltetik az agile-t az R&D-re is. A jelentos ugrasok, amikre szukseg lenne, messze vannak, ezt a mernokok tudjak, de ha azzal allnak elo, hogy "ki kene vagni a mostani architekturat a kukaba", akkor az megkapja, hogy ez nagyon draganak es kockazatosnak hangzik, es visszazavarjak oket a tervezoasztalhoz, hogy inkabb csiszolgassak a mostani architekturat, hiszen "amikor kijott a GCN azt azert finansziroztuk, mert azt mondtatok, h ez annyira modern, h 10 evig megelunk belole, szoval hajra, csinaljatok tovabb".
Aztan amikor egy ideje ez lesz, akkor a mernokok elkezdenek alkalmazkodni, es rajonnek, h lehet ezt ugyis csinalni, h csak azert is megcsinaljuk amit akartunk, de lepesenkent, es akkor az egyes iteraciok kozott lehet amortizalni a koltseget, es akkor maris nem lesz olyan ijeszto, ezt meg a managerek is kepesek lesznek felfogni agyilag (akik persze nem eleg kepzettek, h egynel tobb fejlesztesi modszertant ismerjenek).
Aztan ebbol lesznek az ilyen semmire se jo oszvermegoldasok, mint a Vega. Ennek a fajta alkalmazkodasnak viszont az a nagy problemaja, h mivel a nagy terv valojaban nem feltetlenul volt soha kimondva meg cegen belul sem, eleg elmennie par kulcsembernek, akik ertettek, hogy mi miert van, es akkor csak az oszver marad a nyakukon, de a perspektiva eltunik.
Es akkor most imadkozzunk egyutt az AMD reszvenyeseiert, hogy ez az ember ne Raja Koduri legyen.
-
#53
Petykemano
veterán
gbors
#51
Petykemano
veterán
És ezek az arányok nem véletlenek. Teljesen nyilvánvaló, hogy azért compute nehéz az összes AMD architektúra, hogy ugyanaz eladható legyen compute célokra is. Vagy fordítva - az hogy mi mihez képest túlsúlyos vagy szűk, relatív.
Az világos, hogy a 980Ti is kajált rendesen, meg az 1080Ti teljesítménye sem lineáris az 1080-hoz képest - ha erre gondoltál.
A skálázódást én úgy értettem, hogy a 980Ti és az 1080Ti között azért mégiscsak volt lehetőség növelni a CUDA magok számát és ezzel együtt növelni a frekvenciát is valamivel úgy, hogy a leadott teljesímény ezzel skálázódott, vagyis arányosan növekedett.Ehhez képest olyannyira compute nehéz - értsd: annyira nem érne semmit - grafikai szempontból - további CU-k hozzáadása, hogy ha a Vega 56-ot Vega 64-es biossal futtatod, akkor pont ugyanolyan gyors. Vagyis a 8 plusz CU pont semmit nem ér.
Elnézést, mit fog ezen így gyorsítanni a Rapid Packed Math?
(Abunak elmondtad)Ehhez még annyit, hogy na majd az intelnek készült vega M, ahol 24 CU van csak és mellá nagyjából az a frontend, és backend, ami a Vega 64-ben van, na ott majd ez nem kicsit számíthat.
Ha neadjaég a saját Vega mobile is hasonló felépítésű, akkor akár sikertermék is lehet. -
Raysen623
addikt
Mind a két gyártó másra használja el az ALU-kat, ez már jó ideje látható. A piacot viszont az viszi el, aki nem csak legyártja hanem marketinggel meg is támogatja. A termék ugyanis nem fogja magát eladni, hiába pazarolnak el több ALU-t a hw képességek fejlesztésére. Ha nincs mögötte jó marketing és hw support, akkor nem lesz rá fejlesztés. AMD itt b@szta el évekkel ezelőtt és ezért is futnak jobban a zöldeknél a játékok.
-
#51
gbors
nagyúr
Petykemano
#47
válasz
Petykemano
#47
üzenetére
Mind az IPC növelésének, mind a skálázódásnak megvannak a maga nehézségei, amivel mindkét gyártó küszködik. A Fiji (és ugyanúgy a Vega) több faktornak is áldozata, mert hasonló arányokkal rendelkezik, mint a Tahiti és a Tonga, ezért örökli azok kiegyensúlyozatlanságát, és ezt még a skálázási gond is tetőzi. Megjegyzem, a 980Ti és az 1080Ti sem frenetikus a skálázódást terén, csak abban a szerencsés helyzetben vannak, hogy nem kell hová kapaszkodniuk.
A Pascal 4-5%-kal jobb "IPC"-ben, mint a Maxwell - teszt. A Maxwell kb. 10-15% előremozdulás volt a Keplerhez képest, ezt teljesen jól kimérni nem lehet, de több kártya összevetéséből kb. ennyi esik ki.Az pedig aligha van rendben, hogy a Vega még azt az architektúrális előnyt sem mutatja a Fijivel szemben, mint a Polaris a Tongával szemben. Akkor OK lenne, ha ez egy Prescott-jellegű órajelbooster architektúra lenne, de láthatóan nem az. Tele van jó ötletekkel, amik valamiért nem működnek.
(#49) Abu85: most őszintén, szerinted kit érdekel, hogy mennyi memóriasávszélességet spórol meg a BF1? Mi ez, valami diákolimpia takarékoskodásból?
![;]](//cdn.rios.hu/dl/s/v1.gif)
Az az érdekes, hogy hogyan hasznosul a felszabadított sávszélesség. Erre van kimutatás?
Ez megint olyan, mint amikor a rapid packed math-tal egyetlen játékban egyetlen algoritmus 50%-ot (vagy mennyit) gyorsult. És az egész képkockára levetítve ez kiadott 1.5-2%-ot... -
#50
Petykemano
veterán
con_di_B
#48
Petykemano
veterán
ez a programozható skalár ALU azért fura magyarázat mindenre, mert
- az hogy lehet, hogy ha ez így sokmindent elvégez magában, magának, más módszer meg sokmindent átterhel a CPU-ra - és eközben a másik gyártó módszerével a teljes rendszer fogyasztása is kisebb, meg nem nagyobb a processzorterheltség sem?
- milyen előnyt is hozott eddig ez?Lehet, hogy a vega egy ilyen két generáció közötti öszvér. Mármint nincs baj azzal, hogy ha beépítenek funkciókat a hardverbe, amivel kísérletezni akarnak, amit próbálgatni akarnak, fejleszteni akarnak, kipróbálni akarnak. Csak ne tessenek már egy kísérleti senki által nem adoptált és a piaci viszonyokból kiindulva várhatóan senki által nem adoptálandó megoldást - idő előtt - sikerhozó fícsörként reklámozni.
Vagy ez úgy ment, hogy odament a marketinges a mérnökhöz, hogy megkérdezze, mit tud a gép?
- Hát semmit, relatív nagy mértékben sikerült növelni a frekvenciát. finomítottunk pár dolgot, de semmi extra.
- 4 év alatt, ennyi? NEmá, öregem, így hogy adjam el? nincs benne semmi újítás? Mi a szart csináltatok ennyi évig? ENnek már 1 éve kint kéne lennie!
- Hát a főnök azt mondta, növeljük a compite teljesítményt, így bekerült a feles pontosság..
- Feles pontosság... ez nem hangzik valami jól. Mire jó ez?
- Matematikai műveletek. GYorsabban számol feles pontossággal. De ehhez az szükséges, hogy két műveletet egybecsomagoljon. Érted. Mert valójábnan 32 bites...
- tehát Gyors összecsomagolt matematika. Rapid Packed Math. Ez jó! Mi van még?
- Van ez a High Bandwidth Memory, ami most már..
- HBM. ennek ninsc jó PR értéke... igen, figyelek
- a fijinél problémát jelentett....
- ez akkor egy fiji leszármazott?
- hát... tulajdonképpen igen,
- GCN... mennyi is? 5..
- Igen 64 CU, mint a fiji, de megújítottuk és most már sokkal...
- NCU - Next Compute Unit
- Aham. Na szóval a HBM-re visszatérve, a fijinél prioblémát jelentett a memória mennyisége, és most már úgy működik ténylegesen, ahogy a fijinél szerettük volna, tehát hogy tulajdonképpena viszonylag kis mennyiségű fedélzeti memória képes amolyan Cache-ként működni. Nem kell minden adatot betölteni, hanem a rendszermemóriából tud lapozni. Ez kurva jó lesz, majd meglátod, amikor az SSD
- High Bandwidth... Cache! Hmm. kicsit összetéveszthető a micron HMC-vel. Meg most akkor a HBC az a memória?
- Nem, a memória az a HBM. EZ a képességet egy beépített Cache Controller csinálja, ami nem csak...
- HIgh Bandwidth Cache Controller. HBCC. Ez az. Na mi van még?
- Megújítottuk ezt, meg azt, megnöveltük az L2$ méretét...
- A vásárlókat nem izgatja a cache mérete, de mindegy, figyelek, mondd tovább
- Hát nem tudom, ez van kész.
- EZ van kész? Mi nincs kész?
- Figy, a főnöknek van egy terve, de ez még csak kísérleti stádium. Rájöttünk, hogy csinálta az nvidia, de még túl későn kezdtünk bele a beépítésbe. Még nem az igazi.
- Jó, de mi?
- Az egyik az, hogy raszterizáláshoz felosztjuk a képernyőt és hát oylan mint a Tile based rasterizer. DE még nincs kész.
- Jó, akkor legyen valami hülye neve, valami, amit senki se ért, de jól hangzik. Majd kitalálom.
- De ne, ezt ne írd le, ez még csak kísérletezgetés egy új technológiával. A múltkor is ,amikor a színtömörítéssel próbálkoztunk, úgy adtátok el, mint valami csodafegyver.
- Sajnálom, már kimondtad. Na mi a másk
- Na jó, szóval a főnök azt mondta, hogy nagy compute teljesítményű gép kell olcsón. DE a józsival kitaláltuk, hogy ha a képkockákat még a rajzolás előtt kivágjuk, akkor sokkal kevesebbet kell dolgoznia és gyorsabb lesz. Ez egy elég primitív módszer a shaderkapacitás felszabadítására, de működik...
- Primitive shader.. aha
- Csak hát ehhez sajnos a programot úgy kell megírni. Kiváló megoldás lenne, de nem tudom hogy fogjuk elterjeszteni
- Nyugi, megoldjuk. MAjd azt mondjuk, hogy minden kap driveres támogatást.
- De de az nem fog menni, vagy hát iszonyú sokat kellene dolgozni
- NCU, HBCC, DSRB, primitive shader.... kösz, Béla, ennyi volt, ez így már talán elég lesz, hogy eladjuk a hülyéknek a nagy semmit. Csak tudnám, mit csináltatok 4 éven keresztül.... jézus, ennek a fele kamu, mi lesz itt ha kiderül.
Mindegy, majd a bányászok úgyis megveszik. -
Abu85
HÁZIGAZDA
A programozható skalár egység azért elég fontos tényező. A fogyasztás egy jelentős részéért tényleg ez felel, cserébe hardveresen lehet támogatni a DX12-ből mindent.
Alapvetően jól működik a DSBR az eddigi mérésekből. BF4-ben megvan egy bő 30%-os megtakarítás a memória terhelésére (bájt/képkocka) vonatkozóan. Ennél nem igazán működnek jobban az egyéb mozaikos rendszerek. Sőt, 25-35% közötti a tipikus megtakarítás a BF4-ben, tehát a Vega a 33%-jával a takarékoskodóbb opciók közé tartozik, de ha csak 25% lenne, akkor is hatékonynak mondható a bevetett mozaikos technika. Tehát egyáltalán nem lehet azt mondani, hogy rosszul van kiegyensúlyozva itt a rendszer. Aztán persze per alkalmazás szintjén a fejlesztők is szoktak manapság optimalizálni a mozaikos leképezésre, tehát programfüggően lehetnek eltérések. De ezt az új programok megoldják.
-
con_di_B
tag
https://www.gamersnexus.net/guides/2977-vega-fe-vs-fury-x-at-same-clocks-ipc
Oke, ez a Frontier edition, de a lenyeg akkor is atjon: leginkabb csak a magasabb orajelbol van elony.
Ami pedig a programozhato skalar ALU-t illeti: ez csak az egyik tenyezo, de a GCN torteneteben ez nagyjabol addig all meg amig a Kepler volt az ellenfel, akkoriban pedig meg nem is volt ennyire szetnyilva az ollo.
Ami grafikaban a nagy kulonbseget jelenti, hogy a Maxwell ota az NVIDIA az egesz chipet egyfajta Tile Based iranyra kezdte el optimalizalni, ennek megfeleloen alakultak at/ki az SMX modulokban a gyorsitotarak illetve a regiszterterulet es a cache aranyai, valamint az, hogy lett normalis LDS. Es ez az uj felallas ennyivel hatekonyabb.
Erre ugrana a DSBR-rel az AMD is, de attol, hogy beteszik a feature-t, de semmi mast nem valtoztatnak, a jelek szerint nem fognak messzire jutni onmagaban. (Lehet, hogy a Navi-nal ezt jelento az uj memoriaarchitektura, h ezt javitjak?)
Aztan mindez nem lenne akkora baj az AMD-re nezvest, ha egyuttal nem sikerult volna a compute ollot is teljesen jol zarnia az NVIDIA-nak.
Szoval osszessegeben ez sokkal inkabb a "tobb R&D" penz kozeptavon leverte a "kevesebb R&D" penzt tortenet, es ebben konzisztens munka es sok optimalizacio van, nem szimplan annyi, hogy az AMD compute orientalt, az NVIDIA meg grafika.
Piaci eretelemben eleve az NVIDIA a sokkal sikeresebb compute vonalon is.
En amugy nagy 7970 hivo voltam amikor kijott, de az nem tegnap volt!
A Vega-ra nezve pedig, ranezesre ez sokkal inkabb ugy nez ki, mint ket rendes generacio kozott valamifele oszver, mint egy kerek egesz. Valoszinuleg a primitive shader meg a DSBR is azert kerultek be, hogy addig is lehessen tesztelgetni valamit, amig laba nem no. Es nem, ez nem mernoki elorelatas, hanem sporolas ezerrel.
-
#47
Petykemano
veterán
gbors
#43
Petykemano
veterán
AZzal sem feltétlenül lenne baj, hogyha a fejlődés skálázódással történik és nem "IPC" tekintetében. Az nvidia a maxwell-lel hozott nagy előrelépést az fps/W és fps/Gfops tekintetében. Onnantól azt látjuk, hogy skálázódik az architektúra a CUDA magok számával és a frekvenciával, miközben a fogyasztást szinten tartják.
(Ez nem bizonyosság persze, szívesen megnéznék egy tesztet nvidia kártyák tekintetében is, hogy volt-e fps/gflops fejlődés a maxwell óta, vagyis core to cure, clock to clock)Ehhez képest az AMD-nél az látszik, hogy a skálázódás nagyjából a Hawaiinál megállt. A Fijibe lehet, hogy több CU-t építettek, de az alig hasznosult. Hogy most persze mi a szűk kereszmetszet, mindegy, százszor átbeszéltük, de a fijinél mégsem csinált nagyobb/szélesebb architektúrát az AMD. Itt csak frekvencia emelkedést láttunk. Ha egy ilyen 2016-ban a polarisszal együtt jön, akkor persze "rendbe" lett volna (fiji shrink) a maga módján. De úgy, hogy még egy évet kellett várni rá valamit még virítani kellett volna horizontális skálázódást, vagy "IPC" növekedést.
-
Abu85
HÁZIGAZDA
Itt nem az architektúráról van szó, ami egyébként nem skalár, hanem SIMT. Maximum az ALU skalár. A vezérlésről beszélünk, elvégre minden GPU multiprocesszorában van egy fixfunkciós branch egység, ami ellát valamilyen előre betervezett funkcionalitást. Egyedül a GCN tér el ettől, mivel ennek a multiprocesszorában egy programozható integer skalár egység van, ami a CPU munkáját teljesen ki tudja váltani. Minden memóriahozzáférés, akár a szűrt adattal visszatérők is beleprogramozhatók a shaderekbe, mert lényegében erről szólnak a bindless szintek, hogy a CPU-t ne terheljék a fejlesztők ezzel a feladattal. Na most a programozhtóság megkövetelése miatt ezt nem tudod csak úgy fixfunkciós blokkal megoldani, ide kell egy olyan programozható integer skalár egység, ami megcsinálja a proci feladatát.
-
.LnB
titán
Az NV-sek röhötek, röhögnek, és még jó ideig röhögni is fognak az AMD-n ez miatt a Vega fiaskó miatt.
Fals elvárásokat csakis abunak köszönhetjük. A rengeteg (kamu)duma amit leírt itt a Vega-val kapcsolatban a topikokban...
A Vega tulajok szerint meg minden oké.
De sebaj most úgy látom a "Chill" az új duma. Az a világmegváltó. Amit a kutya nem használ ha nagy viszonylatban nézzük.
-
Vannak ilyenek:
Vega 64 / Fury X
RX 470 / R9 380XÉn amúgy nem kétlem, hogy a feature-ök benne vannak a chipben, csak ezekhez kell a szoftveres támogatás is. Meg persze a DSBR-hez a több ROP...
(#42) Raysen623: igen - pont annyi, amennyi az órajelből jön. Ld. még fenti első link.
-
-
válasz
Raysen623
#38
üzenetére
Igazából másodlagos a kérdés, hogy ki mit lapátolt hová, és hogyan lettek az elvárások gerjesztve. A lényeg (sajnos) az, hogy a Vega 64 kb. annyival meg egy kicsivel gyorsabb a Fury X-nél, amennyit a magasabb órajelek indokolnak, még a Polaris által hozott architektúrális javulások is sem mutathatók ki teljesen. Hol van akkor annak a sok feature-nek a hatása, amik a megjelenés előtt keringtek? Nem reális elvárás, hogy azok hozzanak 15-20%-ot - a Polaris felett?
-
Raysen623
addikt
Ezt a sok marhaságot néhányan lapátolták itt a topikba de már akkor sem volt igaz. Ezek azok az irreális elvárások, melyeket olyanok támasztottak a kártyák ellen, akik nem vesznek ilyet a büdös életbe. Hiába épít több változatot a konkurenciára ha azt sem lehet kapni. Az árak pedig már rég átléptek egy lélektani határt, amit már sokan nem hajlandóak megfizetni.
2018-ban az egész PC desktop gaming foghat egy padlót ha sokáig nem lesz VGA a piacon értelmes áron egyik gyártótól sem. Ez van. Vega-t meg közben belepakolják az APU-ba (igen jó fogyasztással) meg eladják intel bácsinak jó pénzért. Meglátjuk mit hoz a Navi és mennyire lesz más. Én a magam részéről leszarom az fps kergetést és remekül játszom azzal ami van.
-
do3om
addikt
válasz
Raysen623
#36
üzenetére
Hosszú lenne utána nézni de ha végiggondolod a megjelenés előtti, alatti és utáni árt dolgokat elég sok van.
A sebességnövelő dolgok amik végül nem hozta szinte semmit, a driverből támogatott dolgok amik végül a programra lettek bízva hogy kihasználják (nem csak a mostani ha jól emlékszem). A nem is pascal ellen jön hanem azt egyenes átugorja, a fogyasztás majd mérséklődig ha jönnek a gyártói karik, meg a sebesség nő.
Most hova jutottunk?
Kari nincs még most sem, gyártók alig adnak ki valamit (hasonlítsuk már össze mennyi változat épül a konkurenciára). Gyakorlatilag két termékre futotta :56, 64- ez a terméklista elég szegénye- a még ennél is elérhetetlenebb profi cuccokat ne keverjük ide.
A jövő meg ..... elég borús talán jobban mint eddig, bebukni látszik gamer részleg 2018-ban. -
Raysen623
addikt
-
#35
Abu85
HÁZIGAZDA
Petykemano
#34
Abu85
HÁZIGAZDA
válasz
Petykemano
#34
üzenetére
a) Szerintem az NGG helyére jó a GPGPU culling aszinkron compute-tal és az RPM-mel. Látszik a Wolf 2-ben, hogy működik, a Far Cry 5 is ilyet használ. Az NGG-vel szemben mindenképp az az előnye ennek a megoldásnak, hogy nem csak a Vega GPU-kon fut, hanem mindenen, mert szabványos compute shaderekrúl van szó. Ergo lehet, hogy több munkát kell belefektetni, de megéri, mert a Vega GPU-k mellett minden más hardver profitál az eredményből. Konkrét mérések nincsenek, de nem lepődnék meg rajta, ha egy ilyen GPGPU culling pipeline async compute és RPM mellett gyorsabb lenne, mint az NGG maga. Öszvér megoldás, de sebességben jobb és szabványos. A piac ezen nyer.
b) A konzolok nem támogatják a primitive shadert. A PS4 Proban van superstencil, erre épülhetnek olyan effektek, amelyeket normális sebességgel csak primitive shaderre lehet átültetni.
-
#34
Petykemano
veterán
Abu85
#32
Petykemano
veterán
-
#32
Abu85
HÁZIGAZDA
Petykemano
#30
Abu85
HÁZIGAZDA
válasz
Petykemano
#30
üzenetére
Az algorimusért. Ha valaki integrálni akarja, akkor az pénzbe kerül. Azért ilyen rendszert nem két perc kidolgozni, amit most látsz a Radeon Software-ben, az nagyjából négy év munka eredménye. De a többség bele sem fog, mert az AMD-nél vannak olyan szabadalmak, amelyekkel betámadható egy Chill-másolat.
A fejlesztőknek azért érné meg a programba való integrálás, hogy a Chill ne csak Radeonon működjön, de ehhez ki kellene fizetni az AMD-nek a licencet, vagy ha saját rendszert írnak, akkor a kapcsolódó szabadalmakról kell megegyezni.
Igen, azért fizet az Intel. Egyelőre csak a Kaby Lake-G-re. De igazából maga a rendszer üzemképes lenne Intel IGP-vel is, ha hajlandó a cég megfizetni. -
#31
smc
addikt
Petykemano
#30
válasz
Petykemano
#30
üzenetére
De.
A fejlesztők nem fizetnek a Chillért. És szinte biztos, hogy ha az AMD nem maga kezelné a Chill-t, akkor egy játékban se lenne beépítve. Lehet mondani, hogy de nem, de igen.
-
#28
Abu85
HÁZIGAZDA
Petykemano
#27
Abu85
HÁZIGAZDA
válasz
Petykemano
#27
üzenetére
A Chillnek simán lenne támogatottsága. Sokkal bonyolultabb AMD-only dolgokat beraknak a mai játékokba, lásd shader intrinsics, ami konkrétan alternatív shadereket igényel, vagy RPM, amihez specialis header kell. Itt a probléma tényleg a licenc lehet, mert amíg a shader intrinsics eszközei GPUOpen-en elérhető MIT licences megoldások, addig a Chillért keményen fizetni kell. Jól jelzi, hogy eddig erre csak az Intel volt hajlandó. A HiAlgo felvásárlásával ugye a szabadalmak is az AMD-hez vándoroltak, tehát lemásolni sem könnyű.
-
#27
Petykemano
veterán
Abu85
#25
Petykemano
veterán
Ez legalább nem lett eldobva. (a chill)
Képzeljük el, ha ehhez is fejleszőti támogatás kéne. Akkor ez is 100-ből 1 játékban lehetne aktiválva.
Meg is fordíthatom: beláthatná már az AMD, hogy nem tudja kikényszeríteni a fejlesztői támogatást ezekre a fícsörökre és mire szépszóval beépülnek a játékokba addigra (1) az a hardver, amivel elindult a fícsör, az már rég kuka, (2) a konkurencia is felzárkózik tudásban és így az egész küszködéssel semmilyen előnyt nem ér el. -
#25
Abu85
HÁZIGAZDA
Petykemano
#24
Abu85
HÁZIGAZDA
válasz
Petykemano
#24
üzenetére
Nem csak ez a lényege. A Chill nagyon bonyolult rendszer. Igazából olyan, mint a frame pacing a multi-GPU-knál, csak itt scene pacingről van szó. Egyszerűen a hardvert vezérlő szoftver még elég sok OS funkciót megpróbál befolyásolni, hogy maguk a jelenetek kontrollálva, egyenletesen érkezzenek meg a GPU számára. A kontrollt ugye maga az input befolyásolja. Ha akció van, akkor a jelenetszámítás nincs korlátozva, míg ha csak nézel előre, vagy maga az input látszólag lassú, akkor a jelenetszámítás vissza lesz fogva. Ez igazából több előnnyel jár. Egyrészt az a tapasztalat, hogy a játék során követik egymást a lassú és gyors részek, és a lassú részeknél nincs szükség 100 fps-re. Itt spórol a hardver. A scene pacinggel járó alacsonyabb késleltetés igazából csak egy mellékterméke a működésnek, mivel valahogy muszáj szabályozni a terhelést, és az az ideális, ha a jelenet számítása lesz kontrollálva. Mivel ez nagyon egyenletessé teszi a GPU számára is a terhelést, így minden inputhoz tartozó kép gyorsabban megérkezik a kijelzőre, mint a klasszikus, nem szabályozott dupla vagy tripla pufferes koncepcióval. Ezért szeretik az eSportolók, de ez tényleg csak az algoritmus mellékhatása, valójában nem volt cél a késleltetés minimalizálása.
-
#24
Petykemano
veterán
BenceShearer
#21
Petykemano
veterán
válasz
BenceShearer
#21
üzenetére
Abu a múltkor direktben erre a kérdésre azt felelte:
Az utalgatásai mögött arra vonatkozólag, hogy a túlfeszelt állapotot mi indokolja és hogy majd decemberben mi lesz, amitől megvilágosodunk, a Chill állt.
Valóban a Chill használata a Vega esetén képes harmadára csökkenteni az átlagfogyasztást.
Azt mondta, hogy a Chill működésének velejárója a nagymértékű váltások a működési paraméterekben és a váltások során a gpu-nak stabilnak kell maradnia, ezért muszáj túllőni a feszültséget. Valóban, a Chill lényege, hogy minél rövidebb idő alatt érzékelje, ha mozog/változik a megjelenítendő tartalom és szinte abbana szent minutumban feltekerje a paramétereket, de ha nem vagy alig történik valami a képernyőn, akkor letekerje a paramétereket (az fps-t) Ez bizonyára hirtelen nagy váltásokkal járhat.
Cask az nem világos, hogy ha a cHill igényli ezt a tartalékot, akkor ezt miért nem lehet csak akkor aktiválni, ha megy a Chill? Minden más esetben pedig egy másik táblát használni, vagy kisebb offsetet. -
#23
Petykemano
veterán
Abu85
#22
Petykemano
veterán
"beállítottam valamit és én úgy gondolom, hogy az általam használt programokban és driverbeállításokban, megfelelő eszközök híján stabilnak tartott", és "a ténylegesen stabil" között óriási a szakadék.
Valóban, kb 100-200W"beállítottam valamit és én úgy gondolom, hogy az általam használt programokban és driverbeállításokban, megfelelő eszközök híján stabilnak tartott", és "a ténylegesen stabil" közötti óriás szakadék [_] AMD és Nvidia eladási adatok közötti óriási szakadék
A megfelelő relációs jelet (<. >, =) írd be a rubrikába
-
Abu85
HÁZIGAZDA
Mert a "beállítottam valamit és én úgy gondolom, hogy az általam használt programokban és driverbeállításokban, megfelelő eszközök híján stabilnak tartott", és "a ténylegesen stabil" között óriási a szakadék. Az AMD nem csak egy meghajtómódot kínál, hanem hozzávetőleg egy tucatot. Ráadásul olyanokat, amelyek ugyanannak a kártyának a terhelés melletti átlagfogyasztását akár a harmadára is csökkentik. Tehát mondjuk a Vega 56-nek nem csak 210 wattos TDP mellett kell stabilnak lennie, hanem 100-230 wattos, gyakorlatilag majdnem 1 wattonként paraméterezhető tartományban. Hazaviszed a kártyát, de 200 helyett 100 wattos átlagfogyasztást akarsz? Az Adrenalin meghajtó óta a te döntésed. Ráadásul nem is fogod megérezni, mert akkor spórol, amikor nincs akció a jelenetben.
-
#21
BenceShearer
aktív tag
BenceShearer
aktív tag
Erre voltam kíváncsi én is. Mert úgy rémlik, azt mondták, azért van ennyire "felül feszültségelve" a kártya, hogyha majd aktívak lesznek egyes funkciók, akkor kell majd neki az energia.
-
A kérdés:
Így hogy már ready a vega driver ügyileg, miért van az hogy jelentős mértékben lehet alulfeszelni a gyári beállításokhoz képest. Miért lehet SOKKAL jobb perf/watt mutatót kihozni mókolással? Miért a felhasználónak kell ezt kitalálni? Miért éri meg az AMD-nek, hogy az összes teszt azt hozza le, hogy a geforce-hoz képest egy kazán? -
Abu85
HÁZIGAZDA
Akkor ezt tegyük tisztába. A fogyasztáson ez igazából nem sokat csökkenthet. Persze a sávszélkímélés játszik, de a Vega 10 HBM2-t használ. Nagyjából 4 wattos az innen keletkező igény. Ez nem GDDR5-GDDR5X, ami ~400 GB/s-os sávszél mellett lezabál 25-35 wattot, hanem nagyságrendekkel takarékosabb HBM2. Ahol az NGG mód segít az a hatásfok. Elvégre kivág egy csomó fals pozitív háromszöget, így alapvetően növeli a feldolgozás teljesítményét. Ez érthető, a GPU nem költ erőforrást a szükségtelen adatokra, de a szükséges adatokat kiszámolja. Viszont ha nincs szükségtelen adat, attól még a szükségeseket ugyanolyan párhuzamosítással kalkulálja a hardver, csak a munka lesz kész gyorsabban. Ami a fogyasztáson segít az az NGG IWD része, de az már be van építve a driverbe. Segíthet persze a fogyasztáson a primitive shader, ha eleve korlátozza valami a számítást, ilyenkor nyilván számít, hogy a szükségtelen adatokkal nem kell foglalkozni, vagyis több lehet az üresjárat. Ez mondjuk a gyakorlatban nem egy ritka dolog, tehát valamennyit ért volna.
-
Duddi
aktív tag
válasz
Televan74
#13
üzenetére
Ha árban nézed igen akkor jól sorba állnak de csak az áruk miatt amit a gyártó akaszt rájuk (a bányamanók művétől most tekintsünk el mert amiatt az árak mindenhol vannak)
Ha viszont az adott családban betöltött helyét nézed egy kártyának és az árát ahhoz hasonlítod más lesz a helyzet.
Valaha az xx80 as kártyák fölött csak a xx90 ek voltak manapság már 4 különféle típus is megelőzi teljesítményben a család közepén van. Ergó középkategóriás. És mivel az AMD még ha jobbat is csinálna se venné a kutya sem. így hiába gyengébb a cucca ugyan olyan drágán adja mert árban ez a teljesítmény felcsúszott.
Szerintem.
Egyszer ha lesz időm alaposan utána fogok ezeknek járni. Kíváncsi vagyok valóban igazam van e vagy csak így érzem. -
#16
Abu85
HÁZIGAZDA
BenceShearer
#14
Abu85
HÁZIGAZDA
válasz
BenceShearer
#14
üzenetére
Egyáltalán nem. A Vega és általánosan a GCN amiatt fogyaszt többet, mert egyedül a GCN-ben van skalárfeldolgozó, így amíg a többi hardvernek bizonyos API funkciókhoz (pure bindless bekötés, bővített erőforráshalmaz) a host processzor segítsége kell, addig a GCN önmagától képes elvégezni ezeket a feladatokat, mert van egy programozóható skalár egység a multiprocesszorokban. Az NV fixfunkciós egységeket alkalmaz a vezérlésre, amelyek nem programozhatók, így nyilván kevesebbet is fogyasztanak. Viszont emulálni kell bizonyos API funkciókat. Az Intelnél sok dologra eleve a CPU-magok vannak befogva, mert ugyanazon a lapkán találhatók, mint az IGP.
-
#15
Televan74
nagyúr
BenceShearer
#14
Televan74
nagyúr
válasz
BenceShearer
#14
üzenetére
Így is dolgoznak. Üresjáratban zabálják az áramot és hőt termelnek! Munkanélküli fixfunkciós egységek.
-
#14
BenceShearer
aktív tag
BenceShearer
aktív tag
Ez ok, hogy nem aktív, meg minden, de akkor a fogyasztással nem lehetne kezdeni valamit?
Mert gondolom amiatt fogyaszt annyit a VEGA amennyit, hogy ezt a funkciót is tudja majd kezelni . De ha úgyse aktív, akkor nem lenne értelme új BIOS-okat kiadni, és a fogyasztást emberi szintre hozni?Vagy ha játékból hozza a fejlesztő, akkor majd dolgoznak ezek az egységek is?
-
Televan74
nagyúr
Azért túlzásokba ne essünk! Hol lenne akkor a 1060/580 -as kártya a 40.000-50.000 Ft -os kategóriában(bányászat nélkül). Jó voltak a lépcsőfokok a bányászláz előtt.A középkategória(1060/580) 80.000-100.000 Ft -ig,ki ki vérmérséklete szerint vásárolhatott a neki tetsző portékákból,hűtés és memória mennyiség tekintetében. A Vega56 is jó lett volna a 120.000-140.000Ft -os ársávban. De nem így lett,és erről nem csak a gyártól tehetnek.
Primitive shader meg lesz,csak nem a driverben,hanem egyes játékokban,ha azt a fejlesztő elérhetővé teszi.Majd akkor lehet biggyeszteni a száj szélét,hogy ezt miért nem lehet általánosan alkalmazni.
-
SaGaIn
senior tag
Egyre kevésbé lehet hinni az AMD-nek a feature-ekkel, szolgáltatásokkal kapcsolatban. Ígérgetnek fűt fát aztán meg sunnyogva farkukat behúzva kihátrálnak.
Ha a VEGA témában csak az itt megjelent cikkeket sorba raknánk 2016 júliusától (ami nyilván AMD forrásra hagyatkozik) simán perre lehetne vinni dolgot a vásárlók félrevezetése miatt annyi a be nem teljesített teljesítmény ígéret és a nem működő feature, szolgáltatás.
Taps az AMD marketing részlegének, hogy leígérték a csillagokat és csak egy nyamvadt középkategória lett a vége és még nem rúgta rájuk senki az ajtót.
-
kikikirly
senior tag
Hivatalossá tették azt amiről fórumokon több hónapja beszélnek.Viszont nem értem hogy pár %-nyi gyorsulást hozna a driverből hackalt megoldás DX11-nél miért nem csinálják meg.Ahol meg van játék oldali direct támogatás ott azt a modot futtatják, azt Auf wiedersehen. Gondolom sok munkaóra lenne vele,pedig legacy apikkal jön még egy darabig játékok nagyobbik része.Ők tudják, magam részéről nem örülök.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Az az érdekes, hogy hogyan hasznosul a felszabadított sávszélesség. Erre van kimutatás?
Új hozzászólás Aktív témák
Hirdetés
- Diablo IV
- Bittorrent topik
- Real időjárásjelentés
- Hobby elektronika
- Forza sorozat (Horizon/Motorsport)
- Kertészet, mezőgazdaság topik
- Milyen joysticket vegyek?
- gban: Ingyen kellene, de tegnapra
- Autós topik látogatók beszélgetős, offolós topikja
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- További aktív témák...
- ÁRGARANCIA! Épített KomPhone i5 13400F 32/64GB RAM RX 7700 XT 12GB GAMER PC termékbeszámítással
- Bomba ár! Dell Latitude 7320 - i5-11GEN I 8GB I 512SSD I HDMI I 13,3" FHD I Cam I W11 I Garancia!
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
- Amazon Kindle 10th Generation ébresztős tok
- Samsung Galaxy S22 Ultra 512GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest