- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Dragon Ball: Sparking! Zero - Mester és tanítvány
gp Egyelőre még mindig nem kaptunk megjelenési dátumot a játékhoz.
Új hozzászólás Aktív témák
-
lenox
veterán
Nyilvan a tobbi verzio meg kesobb jon, de szerintem eleg nyilvanvalo a hasonlosag a gf104/gf114 fele, a nevrol nem is beszelve. De ahogy irod az LDS mennyisege is latszik. Szerintem az LDS abszolut mennyisege, az egy shaderre juto mennyiseg, az osszes LDS bandwidth es az egy shaderre juto LDS bandwidth egy tablazatban jol mutatna a cikkben, eleg jol leirja az eroviszonyokat compute powerben.
Jatekbeli teljesitmeny az eleg meglepo, de amugy architekturalisan ez egy masodik vonalas gpu. -
lenox
veterán
A fejlettseg alatt pontosan mit ertunk? Csak mert pl. ket proci, amik csak l2 cache mennyisegben kulonboznek egymastol nekem fejlettsegben nem kulonbozik. A 680-ban meg leginkabb a kulonbozo egysegek aranya az, ami miatt nem annyira jo compute-ra. Pl. ha negyed ennyi shader lenne benne, de minden mas ugyanennyi, szoval 8 smx, ugyanennyi cache meg shared memory, akkor azt mondanam, hogy ez szuper, ebbol kerek egy 512 bitest 32 smx-szel. Nyilvan ezt nem tudnak legyartani gamer arert (vagy leginkabb egyelore sehogy), nem is ilyet csinaltak, de amit en ertek fejlettseg alatt, vagyis az alkalmazott technikakat, abban nem kulonbozne, csak mennyisegben.
Driverrel valamennyit biztos lehet majd javitani a sebessegeken, de az a teny nem fog valtozni, hogy tul sok shader lett bezsufolva, es nincs ami etesse oket, szoval egyszeru feladatot gyorsan fog csinalni, ahol meg tobb shared memory, cache, vagy ezek savszelessege kell, ott ehezni fognak. Ettol persze gamer kartyanak kivalo, es az is rendben van, ha az nvidia a gamer vonalon compute-ra kevesbe alkalmas gpu-kat arul, ha mar tudnak kulonbozo chipeket gyartani, legalabb lesz valami ertelme, amikor a quadrokat vagy teslakat tizszeres aron probaljak eladni. -
lenox
veterán
Nem, azt irtam, hogy a kulonbozo egysegek aranya miatt nem jo, nem csak az l2 cache miatt, az kb. a legkevesebbet szamit. A l2 cachet, azt az egyszeru proci peldanal emlitettem, hogy az alapgondolat ertheto legyen. Valoban van olyan osszefugges, hogy a gk104-ben kisebb az l2 cache, de nyilvan ertheto volt, hogy nem csak ezt a kulonbseget fedeztem fel a gpu-k kozott.
Viszont azt kerdeztem, hogy mit ertesz a fejlettseg alatt? Nyilvanvaloan jobban teljesitene compute-ban a gk104, ha tobb shared memory lenne rajta pl., persze csak ha megfelelo kodot irna ra az ember, mert a fermire irodott kodokat nagyreszt at kell irni, hogy ezen optimalisan fusson, viszont egy shaderre vetitve sokkal kevesebb shared memory hasznalattal, ez eleg gaz szerintem. Persze a masik oldalrol is lehet nezni, hogy milyen jo, hogy sokkal tobb szamolast tud vegezni. Persze akkor erdemes a megfelelo fermihez, tehat a gf114-hez hasonlitani, mert ez kb. annak megfelelo compute-ban. Szoval a compute tesztekben azt kene nezni, hogy ahhoz kepest mennyivel jobb.Nem tudom, szerintem a jatekosok nem nagyon fognak bonyolult szamitasokat csinalni a kovetkezo 1-2 evben, lathatoan az nvidia is ezt gondolta. Lehet, hogy ez rovid tav, de 2 ev mulva varhato azert uj gpu azt gondolnam.
-
lenox
veterán
Azt irtad, hogy a gcn fejlettebb, mint a gtx680. Kerdezem, hogy mit ertesz ez alatt.
Szerintem ugyanis azert alkalmasabb compute-ra, mert pl. egy shaderre tobb shared memory jut. De ez nekem nem fejlettseget jelent, hanem konfiguarciot. Egy peldan keresztul illusztralva ugyanaz a cpu ketszer annyi cache-sel nem fejlettebb, csak mas konfig.GF114-nek megfelelo multiprocesszorok szamaban, shared memory mennyisegeben. Megirtak a kodot fermire, annak megfeleloen vannak a blockok meg a shared memory szervezve, kb. ugyanugy fog futni. Persze az orajel meg meg szamos mas dolog is beleszol, de az a resze, hogy szepen fogja a blockokat, es lefuttatgatja oket a rendelkezesre allo multiprocesszorokon, az ugyanaz. Ha eleg sokat szamol az ember, akkor gyorsabb lesz valamivel, de a gf110 meg egyszerre ketszer annyi blockot tud futtatni, nem valamivel lesz gyorsabb, hanem ketszer. Erre gondoltam.
Vagy inkább azt, hogy ha ebben úgyis a GCN a jobb
Szerintem meg azt, amit irtam, vagyis hogy jatekokhoz nem kell, aki compute-ot akar, az meg fizessen tobb penzt, es vegyen quadrot meg teslat.
-
lenox
veterán
Az 580-asnál is jóval nagyobb arányban gyorsabb compute-ban, mint ami a peak FLOPS-ból következne, pedig az még nem volt "lebutítva".
Peak flops-ban kb. ketszer olyan gyors, melyik compute teszt alapjan gyorsabb nagyobb aranyban, mint az 580-as?
7970-nel 2 MB shared memory van, ennel meg 384 KB. Pont, mint egy 560-ban.
Nyilvan olyan feladatnal erdekes a szamoloegysegek szama, ahol ez a bottleneck. Bonyolult feladatnal tippem szerint alig lesz ilyen a 680 eseteben.
1. Persze. De azert egy 560 szintu kartya sem annyira rossz, csak teny, hogy egy ligaval (esetleg kettovel, ha ugy alakitjuk ki a ligakat) lejebb jatszik.
2. Szerintem sem. Meg szerintem nem is fog kelleni...
3. Hat ha a gpun beluli teljesitmenyre akarjuk kihegyezni, es jo az opencl, akkor jelenleg igen. Errol jut eszembe, hogy nemreg az nvidia elkezdte cache-elni az opencl kodokat, szoval csak az elso inditaskor kell varni, amig fordul, utana mar nem, szoval pl. fejleszteshez hasznos feature, kene amd oldalon is. -
#637
lenox
veterán
prime_adam
#632
lenox
veterán
válasz
prime_adam
#632
üzenetére
Ket monitorig multimonitorhoz mindegy mit valasztasz. A gpgpu meg tag fogalom, mit jelent pontosan? Ha konkret program, akkor keresni kell benchmarkot, ha fejleszteshez, akkor futni mindketton fut, ugyhogy en az ujabbat valasztanam, ha komolyabb szamitasok vannak benne, es a teljesitmeny szamit, akkor meg 580.
-
lenox
veterán
Ja ertem, azert is ilyen jo compute-ban, mert alu is van eleg, meg ami eteti, az is van. Hat ez magaert beszel szerintem. De a valosagban meg az alu ero 2.5-szeresere nott, a memory bandwidth csak 1.5-szeresere, szoval a relativ bandwidth 60 %-ara csokkent, az egy alura juto shared memery mennyiseg negyedere csokkent, a savszelesseg meg a felere, az egy alura juto regiszterek szama ugyancsak felere csokkent, csakugy, mint a tex. Bovennek nem mondanam, inkabb azt mondanam, hogy az egy alura juto eroforrasok jol lecsokkentek. Vagy masik oldalrol: bele lett zsufolva egy csomo shader, es nincs amit etesse oket.
-
lenox
veterán
vissza kellene venni ebből a stílusból
Pontosan mi nem tetszett? A reality check?
ha egyszer a Fermiknek az alacsony ALU-kapacitás volt a gyengéje
Computeban? Ezt ki mondja, es milyen feladatnal? Nekem mar ott is a shared memory es a regiszterek mennyisege volt a problema.
az alu:tex arány ugyanannyi, mint a GF114-ben
384:64 = 1536:128 ? Nekem nem egyenlo...
és effektíve a shared memory arány sem negyede, hanem a fele - tekintve, hogy a GF114 ALU-k dupla órajelen mennek.
??? Ezt magyarazd meg legyszives. Kisebb orajel hogy helyettesit shared memory mennyiseget?
Nem tudom, szoktal-e komolyabb cuda vagy opencl kodokat irni, az elozo sorbol nekem ugy tunik nem, de azt szerintem konnyu belatni, hogy mivel ezekben a gpu-kban limitaltak az eroforrasok, ahhoz, hogy eleg jol ki tudja az ember hasznalni oket, eleg komolyan optimalizalni kell. Egyszeru feladatnal meg konnyu olyan kodot irni, ami a kulonbozo reszek megvaltozott aranyat figyelembe veve eleg jol futnak uj architekturan is, de pl. a luxmark szerintem nem ilyen. Szoval konnyen elkepezelheto, hogy optimalizalt kod javitani fog az eredmenyeken, de a shared memory es a regiszter mennyiseget nem fogja potolni semmi. En az utobbi par evben eleg sokat buveszkedtem vele, szerintem szinte lehetetlen lesz ellatni az alukat adattal. Amugy a fermi 1580 GLOPS-ot tud max, ez meg 3090-et, szoval ha a fermi sp-it 60-70%-osan tudta valami kihajtani, akkor a gtx 680-on akkor is gyorsabb lenne, ha csak 40%-ot tudna. Szoval ha valamiben nem 2-szer olyan gyors, mint a fermi, akkor jobban eheznek az sp-k. Ezt erdemes figyelembe venni, amikor azt allitja valaki, hogy nem eheznek...
-
lenox
veterán
De a texture cache is dupla orajelen megy, meg a shared memory is. A shared memory mennyisege nem a megkeresesek szama miatt erdekes. Az az erdekes, hogy ha belefer a szukseges mennyisegu adat, akkor nem kell global memoryt hasznalni. Ha threadenkent pl. 128 byte-ot hasznal az ember, es egy blockban 256 thread van, akkor ugye 32k shared memory hasznalsz, gf114-nel 48 sp-re jut 256 thread, valoszinuleg jol ki lesz hasznalva a multiprocesszor. Ha hasonlo aranyt akarsz fentartani gk104-nel, akkor 1024 thread kell, es maris nem fersz be a shared memoryba. Vagy lehet csokkenteni a threadek szamat, es nagy valoszinuseggel az sp-k kihasznaltsaga is csokkenni fog. Ebbe az orajel nem jatszik be kozvetlenul.
Szerintem a gtx580-as osszehasonlitassal alapvetoen nincs gond. Ha nem tudod nagyobb blockokba szervezni a feladatot, akkor a gf110-ben ketszer annyi multiprocesszor van, ezert azon gyorsabban fut le ugyanaz a feladat. Az meg, hogy tudod-e nagyobb blockokba szervezni a feladatot, az a feladaton mulik, bonyolultabb feladatnal automatikusan nem, tehat ugyanaz a kod mindenkepp lassabb lesz, ha nem irjak at kezzel, es feladattol fuggoen esetleg kezzel sem lehet gyorsabbra irni. A gk104-nek 1 TB/sec shared memory savszelessege van, ha jol szamolom, a gf110-nek meg 1.5 TB/sec, szoval aminel ez limital, annal ilyen arany varhato.
-
-
lenox
veterán
Az sem mellekes, hogy GF104 es GK104 csak 8 multiprocesszort tartalmaz, GF110 16-ot, a Tahiti meg 32-t. Szoval amikor eljutunk oda, hogy tul vagyunk a multiprocesszoron beluli sokkon, hogy alig jutnak az sp-k adathoz, akkor jon meg, hogy a Tahiti 4-szer annyi multiprocesszoron futtatja ugyanazt a feladatot. Annyi trukk azert meg van, hogy a Tahitinel elvileg egy kernel csak a shared memory felet hasznalhatja, szoval ennyi elonye talan van az nvidianak, de kb. ki is merult. Az a fura nekem, hogy egyebkent egy duplazott gf110 28 nm-en tok jo lenne/lett volna uj memvezerlovel, akar 384 biten, akar 512 biten, es ezt nem latom at, de szerintem siman meg lehetne csinalni. Szoval szerintem ha ennel barmiben gyengebb lesz az uj chip, akkor az csalodas...
-
lenox
veterán
Amugy ez ugy mukodik, hogy a vga kartyanak van egy framebuffere, amibol sorban nyomja ki a pixeleket a dvi kanocon keresztul. Ha 60 Hz-re van allitva, akkor masodpercenkent 60-at nyom ki. A monitor pontosan azokat a frame-eket jeleniti meg, amit a vga kinyom, nem szedi szet, nem tori ossze, hanem pont azokat. Minden szettores a vga-n belul tortenik.
A vga kartya a jatek egy kepehez egy csomo muveletet csinal, ami kozben a memoriajaban nem vegleges kep van, ezert nem szokas kozvetlenul a framebufferbe rajzolni, hanem egy masik bufferbe (double buffering, van triple is, lasd kesobb). Amikor a kep elkeszul, akkor lehet berakni a framebufferbe. A valosagban persze valojaban csak megcserelik a buffereket (atirnak 2 pointert), de a lenyeg az, hogy ilyenkor a mar elkeszult, de meg nem a framebufferben levo kep a framebufferbe kerul. Ket lehetoseg van: vagy engeded a vga-nak, hogy ez a csere akkor tortenjen, amikor epp a kep kinyomasa kozben vagy (vertical sync off, ekkor lesz tearing, mivel a kep egyik resze meg az egyik masik resze a masik idobeli allapotbol jott), vagy ilyet csak akkor engedsz, amikor epp uj kep kezdodik (vertical sync on, nem lesz tearing). A masodik esetben, ha csak ket buffered van (double buffering) a vga var, hiszen az egyik kepet meg kuldi ki a monitorra, a masik kesz, nincs hova rajzoljon. Ha van egy harmadik buffered is, akkor ilyenkor is tudja folytatni a rajzolast (triple buffering). Ez pl. olyankor fordulhat elo pl. ha 40 fps-sel tudsz renderelni. Ilyenkor az egyik kep 1, a masik 2 frame-nek megfelelo ideig lesz kirakva. Ha a vertical sync ki van kapcsolva, akkor double bufferinggel is kimegy a 40 kep, csak szettorve. Double bufferingnel bekapcsolva a vertical sync-et azonban ilyenkor csak 30 fps-t tud kirakni a kartya, erre jo a triple buffering, hogy megis legyen 40 fps. Persze a triple bufferingnek problemaja is van, pl. a 40 kep nem egyenletesen van kirakva (egyik kep 1 frame ideig, masik 2 ideig van kirakva), illetve nagyobb a lagja, hiszen ha egy kepet epp latsz a monitoron, egy meg var a kirakasra, egyet meg renderelsz, akkor a user input csak majd a kovetkezo negyedik kepnel lesz figyelembe veve. Szoval programtol es usertol fuggoen masik megoldas lehet a jo.
-
lenox
veterán
Lehet, hogy csinal valami processinget a monitor (nem lehet, hanem biztos), de tearinget egy consumer monitor biztos, hogy nem detektal abbol a celbol, hogy kiszurje. Lehetne ilyet csinalni, csak nincs semmi ertelme. Te mire hasznalnad? Ha mondjuk 70 fps-sel tud a geped egy jatekot renderelni, akkor egyik kep sincs meg teljes egeszeben, ilyenkor nem rakna ki semmit a monitor? Vagy ha mondjuk 55 fps-sel tud, akkor nagyon ritkan van egy teljes kep, neha valtozna, amit latsz, ennek sincs semmi ertelme...
Új hozzászólás Aktív témák
ph Szinte minden szempontból kiveséztük az NVIDIA Kepler architektúrájára épülő, GK104 kódnevű újdonságát.
