Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Ha nem követelne dedikálást nem állítanák be a drivereket dedikálásra. Még az AMD is úgy használja a GCN-t, hogy a dedikált 64 kB-os blokkból 32 kB-ot dedikált a compute-ra. A többit másra használja. Az Intel is dettó így csinálja a 256 kB-os URB-nél. A maradék 224 kB-ot alkalmazásspecifikus célokra használják, de van olyan program, ahol semmire. A Microsoft követelménye a gyártók felé leadott specifikációkban, hogy legyen egy dedikált 32 kB-os LDS shader tömbönként.
A Mantle jó példa egyébként arra, hogy ez csak egy API limitáció. Ott a GCN működését a játék határozza meg, tehát lehet LDS a teljes 64 kB, vagy csak 48 kB, vagy csak 8 kB. Ahogy tetszik. -
namaste
tag
API dedikálást követel Erről hol lehet olvasni?
A DirectCompute 5.0 32kB shared memoryt ír elő, de azt nem, hogy nem lehet kevesebbet használni.
Maxwellnél az SMM négy blokkja osztozik az SM-n, ha a szálcsoport 32kB SM-t használ és legalább 4x32=128 szálat tartalmaz, akkor egyszerre futhat a négy blokkon. -
Abu85
HÁZIGAZDA
Dinamikus parallelizmus már az első GCN-ben volt. Azóta annyi változott, hogy több ACE lett a hardveren belül, ami nyilván javít a hatékonyságon. Ez azonban önmagában nem elég arra, hogy a hardver megszakítson egy folyamatot kényszerből egy másik folyamat kedvéért.
Ha szoftveres szinten van egy sokáig futó kerneled, akkor az gáz, ha közben lenne egy olyan feladat, ami jó lenne ha eredményt adna. Ez az újítás arra szolgál, hogy a futó kernel félbeszakítható legyen a hardver által, addig amíg le nem futnak a fontosabb feladatok.A grafika azért került elő, mert a HSA koncepciója, hogy a grafikai feladatok élvezzenek alapvető prioritást. Ha futtatsz valamilyen mondjuk OpenCL-es GPGPU-s dolgot, és közben mondjuk elkezdesz játszani, akkor az eredmény elég gyér lesz a játékélmény szempontjából, bármelyik mai hardveren. Ezzel a megoldással a játék élvez elsőbbséget, így annak a sebessége jó marad, miközben a GPGPU-s feladat szorul a háttérbe, de közben lassacskán lefut.
Az már más tészta, hogy ezt a hardveres fícsőrt mire lehet még használni, de a fő koncepció a grafikai feladatok elsődlegessége. -
Abu85
HÁZIGAZDA
A Kepler engedi a 64 kB-os memória 32-32kB-os L1-LDS bontást. Azért építették ezt be, mert a mai PC-s játékokhoz ez jobb, mint a Fermi 16-48 kB-os bontása. A Keplernél csak ezt alkalmazzák a driverben. Később lehet, hogy lesz olyan játék, ahol a compute nem csak lepkefingnyi terhelés lesz, és akkor arra menni fog a 16-48 kB-os bontás a Keplerben is.
Csak a Maxwell esetében nem osztozik a 64 kB-os LDS az L1-gyel. Ott ugye az van, hogy négy tömb között van az a 64 kB megosztva. Egyszerre csak kettő tömb érheti el, és ez úgy van beállítva ma, hogy 32-32 kB-ot kaphatnak. Ilyenkor a másik két tömb malmozik, hacsak nincs más olyan feladat, amit futtathatnak.
Az a baj az LDS-sel, hogy annak a működését nagyban befolyásolja az API. DirectX 11-ben rendkívül kötött működésre van rákényszerítve a hardver. Mondjuk CUDA alatt már párhuzamosan elérhetik az LDS-t a Maxwell SMM-en belüli tömbjei. Nyilvánvaló, hogy utóbbi esetben nem jelent problémát, hogy az LDS négy tömb között van megosztva, maximum a kapacitása lehet gond, de ez meg feladatfüggő. DirectX 11-ben az API működése miatt is gond a megosztás, mert az API dedikálást követel, tehát oda kell adni 32 kB-ot minimum egy-egy tömbnek és akkor a másik két tömbnek nem jut semmi. Ilyen körülmények között, ha csak olyan feladat van, ami LDS-t használ, akkor a Maxwell teljesítménye a felére esik, mert az API működési követelményei miatt csak a feldolgozók fele dolgozhat. Ez viszont nem hardveres limitáció. Az NV számára is célszerű lenne egy saját low-level grafikus API, mert azt úgy paraméterezhetik, ahogy az architektúrájuknak jó, míg erre a Microsoft sosem lesz hajlandó.
-
-
tocsa
senior tag
Fontos lenne hozzairni a cikkhez, hogy mindez csak az AMD vilagat tukrozi. nVidia eseteben mar egy ideje letezik preempcio es scheduling tobb szimultan futo szamitasi kernel miatt. Ugye az nVidia eleg jol nyomul a todomanyos szamitasi es HPC szegmensekben, es ott nagyon regota hianyzott mar ilyen funkcio, kb. mint egy falat kenyer.
Az elso probalkozasok CUDA 5.0-nal jelentek meg, es CUDA 5.5-nel teljesedtek ki. 2012-ben mar vannak white paper-ok es tech brief-ek a "CUDA Dynamic Parallelism API"-rol. Hardware es szoftver szintjen az architektura kepes kezelni tobb feladatot is mostmar (persze felteve ha ujabb egy bizonyos generacional), de ez az nVidia-nal mar valosag 1-2 eve, foleg a top szegmensben. (Igy pl konnyeb lesz GPGPU-s HPC MPI clusterek-et is utemezni, esetleg a jovoben GPGPU-s berelheto cloud instance-ek-et a szolgaltato konszolidalni tud. Vegfelhasznalonal meg olyan elonyei lehetnek a kepessegnek mint egy mellekhataskent, amit a cikkben leirt AMD-s technologia kinal).
Tehat csak szolok, hogy olyan kijelenteseknel, mint hogy "Mint ismeretes korábban egy GPU architektúrára nem volt képes más, feltételezhetően fontosabb feladat kedvéért felszabadítani az erőforrásokat" - AMD-re vonatkozik csak. Vagy "A legnagyobb újítás a GPU grafika preempció támogatása" - AMD-nel igen. "amelyre vonatkozóan az AMD már régóta folytat kutatásokat, tehát meglepetésnek nem lehet nevezni" - valoban nem, lasd. nVidia "Dynamic Parallelism API". Mindezeket fontos megjegyezni ahhoz, hogy a tajekoztatas szeles koru legyen es egy nagyobb perspektivaba is belehelyezze ezt a hirt. Azt is mondhatnam, hogy ez fontos, hogy a tajekoztatas mind nVidia mind AMD fuggetlen maradjon.Ezek mellet nagyon udvozlendo az ujitas az AMD-tol, mert a piaci versenyt segiteni fogja!
ui: tudom, hogy a scope-ja az AMD itt leirt funkciojanak egy kicsit mas, mint az nVidia, de mindketto esetben a lenyeg, hogy ki kellett fejleszteni hardware es szoftver tamogatast a preempciora. Erre a preempciora aztan sokmindent lehet majd epiteni, jelen esetben a hir csak holmi gyermeteg grafikai szamitas prioritizalast hangsulyoz, de a jovoben ez fogja lehetove tenni azt is, hogy komplexebb es "multi-tasking" legyen egy GPU.
-
-
#06658560
törölt tag
Nem. A lényeg, hogy ne hibázzon a program, ne boruljon össze a helyi infrastruktúrával, aztán jöhet csak az extra sebesség.
Mondom, nem ártana, ha már példálózol vele, utána járni a Dassault balfaszkodásainak, mikor elvileg mindig minden gyorsabb lett a fejlesztéseiktől. Valamint nem ártana megnézned a piaci reakciókat is. piac még mindig és továbbra is, nem a konkurenseket jelenti, ahogy te képzeled, hanem azokat, akik fizetnek a termékért. -
polika
senior tag
Azért tegyük hozzá, hogy mission critical alkalmazásokban pont szerver oldalon nem fognak csak úgy belevágni azonnal az ismertből az ismeretlenbe...ott simán eltelnek évek amire mindenféle hülye cornercase esetre vonatkozólag letesztelik, __ÉS__ a felhasználókban is lesz elég bizalom a kipróbálás után a váltásra.
Mondanék egy analógiát, nálunk pl genetikai adatok masszív paralell feldolgozásánál az idő brutálisan fontos tényező mert olyan adathalmazzal és olyan bonyolult algoritmusokkal van analizálva több adatbázis+minta nyers meg mindenféle származtatott adatai, hogy mondjuk 12 minta az elmegy 1 nap 24-es load averagével a workstationunkon (24 mag xeon,128g memória, 1 tera ssd). Bejött vmi újjítás a szoftverben ami kihasznált vmi speci legújabb xeonokban levő featurét, amit intellel együtt hegesztett a szoftverfejlesztő, kb 1 évig experimentál volt a cucc. Mert a sebesség fontos, de fontosabb az hogy nem tévedhetsz, mert jogilag basznak meg ha hibás leletet adsz ki egy ilyen "gyorsítási manőver" következményeképpen...azaz kb 1 évig a kétféle binárissal leszámoltad duplán a cuccost, és nézegetted, meg olvastad a fórumokat hogy a hatalmas warningok mellett vkinek volt-e bármilyen esete amikor nem ugyanaz az eredmény jött ki a két algoritmussal...és nem tirviális a dolog, mert lehet hogy nem is az amit változtattak bukik meg mondjuk, hanem a szoftver egyéb eleme nem működik együtt valami speciális esetben úgy mint a másik verzióval, stb...
Véleményem szerint az exakteredményt megkövetelő alkalmazásoknál nemlesz ilyen gyors a váltás egy teljesen új API, szoftveres alkalmazások és minden szinten változást követelő dologra. Persze emelett elhiszem lesz egy csomó alkalmazási terület ahol belefér az ha hibázik az ember.
-
Abu85
HÁZIGAZDA
32 kB inkább. A Kepler már képes 32-32 kB-ra osztani az LDS-t. A driver ezt használja már.
A 4 32 magos blokkból egyszerre csak kettő érheti el az LDS-t. A többinek ki kell várnia a sorát. Ez azért nem ugyanaz, mintha mindegyik blokknak lenne dedikált erőforrása.
Viszont az a regiszterszám még mindig nem sok. Dupla annyi lenne ideális. De a Kepler extrém regiszterhiányát leküzdötték.
Egész számításoknál inkább a Kepler volt túl gyenge. -
namaste
tag
A Maxwell is áldozott, mert több mag éri el ugyanazt az LDS-t.
A Keplerben 48 kB Shared Memory jut 192 magra, a Maxwellben 64 kB SM 128 magra. Javult a regiszter/ALU arány is.
Gyakorlatban, a compute tesztekben a 750 Ti gyorsabb mint a 650 Ti, pedig elméletben a 650 Ti kicsit gyorsabb. Egész számításoknál is egész sokat javult, bányászat, SHA. -
-
Abu85
HÁZIGAZDA
-
#06658560
törölt tag
Akkor is rosszul fogalmaztál korábban.
Na, ez a válasz mutatja tökéletesen miért ülsz fordítva a lovon. Mert a szoftvert mint olyat önmagáért levőnek tekinted, aminek egyetlen célja, hogy minél gyorsabb legyen. És így látszik, mennyire nem is értetted meg a kommentem. Hiába gyorsabb a szoftver, ha a vevő igényeivel nem találkozik. Akkor jönnek olyan pofára esések, mint Dassaulték CATIA V6-ja.
-
Reggie0
félisten
Az a teszt szar es ertekelhetetlen ebbol a szempontbol, mert ok a TELJES RENDSZER fogyasztasat merik tapegysegestul procistul winyoval stb.. Marpedig idlehez->load eseten nem csak a gpu kezd el fogyasztani, legalabb a cpu is.
Tessek itt egy korrektebb meres: [link]Szerk: rossz link volt, javitva.
-
-
sb
veterán
válasz
HeavyToys
#15
üzenetére
Igen, az új szériának magasabb a fogyasztása. Teljesítmény/fogyasztásra a 7850/7870 sok tesztben jobbnak tűnik sokkal.
Áltag 85W ill. 110W körüli fogyasztással.Arányosan ehhez képest viszont jóval jobb a Maxwell. 750Ti 60W és az a 8% előny sem jön ki sok tesztben a 7850 javára. Inkább 4-5% max. Nagyobb modellekkel van viszont igazán gond:
7870: +20-25%, 110W, majdnem dupla fogyasztás.
270X: +30-35%, kb. 125W, több mint dupla fogyasztás.
7970: +60% 3x fogyasztással, 160-170W körül?Ha a Maxwellből kijön egy nagyobb modell és jól fog skálázódni (miért ne?) ott már nagyon nem lesz mindegy, hogy +25-30W-tal fogyaszt többet az AMD vagy +80-100W-tal.
Reggie0
Egy kicsit azért jobb a helyzet, mert a refmodellel ellentétben a többire inkább 60W körül mérnek a 750Ti-nél. Ennyi a TDP-je is. De 60W vs 85-90W vs 110W sem túl jó arány. -
Abu85
HÁZIGAZDA
Több regisztere van egy feldolgozóra. A Luxmark nem igazán GPGPU tesztprogram, csak egy GPGPU-ra átrakott amúgy CPU-khoz fejlesztett rendszer. Ezért húznak el benne a GCN-es Radeonok, mert azok jobban hasonlítanak egy CPU-hoz, mint a többi GPU.
De egyébként a regiszter/ALU az kritikus a legtöbb GPGPU programban. -
-
Reggie0
félisten
Ezt senki sem vitatta, ha figyeltel latod, hogy csak a fogyasztasrol volt szo.
(#34) Bici: Kb. ja. Az a baj, hogy szarok ezek a meresek, mert nem a tenyleges fogyasztast merik. Ahhoz kene x16 riser es a tapkorben merni arammerovel(meg feszmerovel). Egy rendes tesztet lattam 750ti-rol, ahol ugy mertek, hogy a 6 kartya mellol kivettek egyet es ugy mennyit csokkent a fogyasztas, ugyanis ekkor mar a tapegyseg hatasfoka sokkal kevesebbet valtozik mivel a csucsterheleshez kozeli szakaszban van, de meg mindig benne van es extra bizonytalansagot visz be.
-
pakriksz
őstag
66w-ot, a 7850-meg 101-et max... és majdnem 2 év van a kiadási idők között.
Egyébként igen, a maxwell kevesebbet tud mint a kepler, nem rég volt a cikk valami új AA módszerről, ott is le volt írva hogy gcn-en megy, kepleren meg, fermin megy, de maxwellen már nem. Nem ingyen volt az a fogyasztáscsökkenés...
De más témában is volt ilyen hogy valamit az előbbi generációk tudtak a maxwell meg nem.Az AMD maxwellje a VLIW volt, amit a GCN-re cseréltek le
-
Janus27
tag
A 750Ti kártya lehet hogy jóval kevesebbet fogyaszt, de azért nézzünk már a dolgok mögé 1 kicsit. A 7850-ben lévő GCN architektúra mennyivel előbb kijött mint a Maxwell??? Mégis FEJLETTEBB!!!! A 750Ti egy belépőszintű kártya MOST mikor piacra dobták, a 7850 a maga idejében mikor piacra került akkor volt egy erős középkategóriás cucc. Egy átlag user az esetek nagy részében nem terheli a GPU-t "szarrá", a GCN is elég jó az órajelek állításában. Éves szinten nagy különbség szerintem nincs a kettő között villanyszámlában.
-
-
Rive
veterán
-
#29
Diocles
aktív tag
Meteorhead
#28
Diocles
aktív tag
válasz
Meteorhead
#28
üzenetére
100 Windows userből hány futtat szerinted a gépén SQL lekérdezéseket? Talán egy. A nagy befektetési igényű fejlesztésekkel a legnagyobb fogyasztói csoportra lőnek. Nem éri meg 99 ember élményét rontani azért az egyért.
Az oprendszer meg úgy általában nem tud mit kezdeni a GPU-val, ahogy egy tipikus webalkalmazás sem.
-
#28
Meteorhead
aktív tag
Meteorhead
aktív tag
Én személy szerint baromira örülnék neki, ha a gyártók kollektíven a GPU architektúrák okosítására gyúrnának, mégha ez teljesítmény vesztést is okozna egyes esetekben. Hiába lesz lassabb egyes letisztult esetekben (pure grafika), ha cserébe aktívan támaszkodhatna rá az operációs rendszer és a programok úgy általában. Mindent összevetve kevesebbet fogyasztana egy mobil APU is, ha tényleg minden adatpárhuzamos feladatra befognák az IGP-t. Ehhez viszont az kell, hogy ne legyen feature szintbeli eltérés, hanem egyetemesen okos architektúrákat tervezzenek a gyártók.
Ha ez megvan, csak akkor kezdődhet el az olyan fejlesztői eszközök fejlesztése, amikkel emberi időben le is lehet kódolni egy adatpárhuzamos SQL-t mondjuk.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#23
üzenetére
Hiába alacsony a pJ/FLOP, ha a bájt/FLOP nem elég magas. Ennek a kettőnek az aránya adja a hatékonyságot, mivel a feldolgozóknak adat is kell, hogy dolgozzanak.
(#24) Kopi31415: És szerinted hányan fogják azt nézni, hogy lényegesen gyorsabb szoftvereket csinálnak. Ha elkezdik, menni kell utánuk, mert 4 évet nem lehet várni az új OpenGL-re. Ha egy szegmensben bárki elkezdi, mindenkit magával ránt a low-level elérés felé, mert szoftveres szinten lényeges előnye lesz.
-
Abu85
HÁZIGAZDA
Semmit. A CUDA kód megvan, azt meg nem tudják máshol futtatni. Drágább átírni a kódot, mint elfogadni a változásokat.
A workstation piac pedig a Mantle felé menetel. A Dassault Systèmes szinte minden cuccát átrakja Mantle-re. Erre reagálniuk kell a konkurenseknek is, mert mire megérkezik az új OpenGL, addigra nem lesz a régi OpenGL-en maradó szoftvereknek piaca.
Nem véletlenül volt téma a SIGGRAPH-on, hogy ki vált, mert ha egy szegmensben valaki használja a Mantle-t, akkor kényszerűen mindenkinek használnia kell. Egyszerűen nem megengedhető, hogy a konkurens program sokkal jobb legyen azért, mert egy régi API akadályozza a fejlesztést. -
leviske
veterán
És akkor most az Iceland és a Wani lesz a Tongán kívül az egyetlen V.I.-s GPU a termékpalettán, míg a 2x (ill 5x) annyiba kerülő R9 290-esek nem kerülnek leváltásra egy C.I.-nél újabb verzióval?
Bár, ha jól emlékszem, akkor beszéltétek tán korábban is, hogy ezek a fejlesztések inkább a Carrizo üzleti felhasználhatóságát javítják és gondolom az Iceland akkor a Carrizo mellé érkezik dual graphics-nak notikba.
(#20) Jack@l: Egy olyan piacon, ahol fullHD-ba egy R9 270/GTX760 is elég mindenre, miért kéne sietnie bármelyik cégnek? Jóval kényelmesebb helyzetben vagyunk, mint anno a G80/R600 időkben, amikor csak high-end cuccok voltak képesek játszható élményt nyújtani.
-
Abu85
HÁZIGAZDA
Valahol mindenképp áldozni kell. A Maxwell is áldozott, mert több mag éri el ugyanazt az LDS-t. Az erőforrások közös használata a pJ/FLOP növekedésével, de a compute hatékonyság csökkenésével jár. Ha a Maxwellt akarják követni, akkor a CU-kból ki kell venni az LDS-t, és a CU tömbhöz kell egy 64 kB-os blokk, amit a tömbben található 4 CU elérhet. De ennek az lesz az eredménye, mint a Maxwellnél. Egyszerre csak az egyik CU számára mehet az elérés, míg a többi három CU pihenőn lesz, vagyis a negyedére csökken a compute hatékonyság, hiszen négy erőforrás között osztod meg azt a "gyorsítótárat", amivel ma mindegyik dedikáltan rendelkezik.
-
Lehet, hogy rosszul kérdeztem, mert nem így értettem.
A kérdésem inkább arra irányult, hogy a Radeon-oknál van-e lehetőség olyan racionalizálásra (a tudás és teljesítmény beáldozása nélkül), mint amit a Kepler -> Maxwell váltásnál láttunk?Vagy a Maxwell is butább/gyengébb lett bizonyos területeken, mint a Kepler?
-
HeavyToys
senior tag
Nekem nem is ez a gondom vele. Hanem az üresjárati és normál használati fogyasztás. Nyilván nem ez váltja meg a világot, de ha full hd, esetleg komolyabb bitrátával rendelkező 3d-t nézek, akkor radeon esetén igencsak megugrik a fogyasztás, a maxwell-nél pedig pár százalékkal. Legfőképpen ezen kéne javítania az AMD-nek. Bár lehet nincs is a prioritások között.
Az újabb R9 270 és R9 260X-es kártyák sajna rosszabb képet festenek a 7850-nél, szóval azért erre is kellene figyelmet fordítani.
-
jedis
senior tag
Most lehet hogy meg leszek kövezve, de ahogy a PH-s teszteket néztem, egy 7850-es kb 20%-al fogyaszt többet egy 750TI-nél, de átlag 8%-al gyorsabb is nála ( Game ) ! Ok, elismerem hogy valamivel jobb a teljesítmény/fogyasztás mutatója, de annyira nem, hogy ennyire kellene "hájpolni" ! Ha mondjuk ugyan azt a teljesítményt hozná 2/3 annyi fogyasztással, no az már nem lenne semmi !
-
Abu85
HÁZIGAZDA
Igen. Bizonyos egymás utáni utasítások után kötelező üres ciklus.
(#8) Sir Ny: Itt most GPU-król van szó, nem CPU-król. Egyébként a GCN is in-order a multiprocesszorok szintjén, ahogy mindegyik más architektúra. Az ACE-ben van OOO logika.
(#10) Bici: Az NV számára a váltások logikusak, mert eldöntötték, hogy nem akarják a konzolba fejlesztett effekteket PC-n látni, míg az AMD akarja. Ennyi igazából a különbség. Az NV logikája is nagyon egyszerű. A GPU PhysX-ből indulnak ki. Ha nem tudják a tesztelők bekapcsolni a GeForce-on az effektet, akkor az apple-to-apple összehasonlítás miatt kikapcsolják Radeonon is. Nem kötelező követni az AMD-t, ahogy az AMD sem követi az NV-t. A Microsoft is jóval barátibb már. Nem kötelező támogatni a DirectX 12-be épített tudást, elég az alap is.
-
Abu85
HÁZIGAZDA
Nem hiszem, hogy örülnének az AMD fejlesztőpartnerei, ha visszabutítanák az architektúrát. Rengeteg funkciót ki kellene vágni belőle, hogy nőjön a pJ/FLOPS érték, ahogy a regiszterek méretét is is legalább a negyedére kellene csökkenteni. Ez elég nagy beavatkozás lenne ahhoz, hogy a Mantle támogatói az API-hoz fejlesztett exkluzív effektekbe ölt pénzt kidobottnak tekintsék. Nem célszerű a partnereidet hátba szúrni.
-
Abu85
HÁZIGAZDA
A mikrolagok többsége szoftveres eredetű. Azokkal ez sem tud majd mi tenni, mert a lag esetleg egy shader újrafordításnál keletkezik. Az ellen nincs ismert gyógymód, csak egy új API. De valóban vannak olyan lagok, amiken ez tud segíteni, viszont azok annyira picik, hogy inkább csak mérhetők, mintsem érezhetők. Persze kihangsúlyozva azt, hogy a GPU csak egyetlen programot futtat. Ha kettőt, akkor máris sokat segít ez a funkció. Ebben az esetben a megállapítás korrekt.
Új hozzászólás Aktív témák
- Eladó karcmentes Xiaomi Redmi Note 10 5G 4/128GB / 12 hó jótállással
- Tisztelt Érdeklődő! Jelenleg kínálatunk frissítés alatt áll.
- Xiaomi Redmi Note 13 Pro 5G 256GB 1 év Garanciával
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Dell 7400 Intel Core i7-8665U
Állásajánlatok
Cég: FOTC
Város: Budapest