Hirdetés
- TCL LCD és LED TV-k
- AMD vs. INTEL vs. NVIDIA
- Milyen billentyűzetet vegyek?
- Úgy állhat le a 16 GB-os GeForce RTX 5060 Ti gyártása, hogy közben nem áll le
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- CES 2026: ámulás és bámulás a Keychron háza táján
- Épített vízhűtés (nem kompakt) topic
- Apple asztali gépek
- CES 2026: árad a Panther Lake az Inteltől
- Milyen videókártyát?
Új hozzászólás Aktív témák
-
namaste
tag
A Forza Horizon 4-ben 4K felbontáson a 1080Ti jobb mint a Vega 64, 1440p ugyanez. Ez igen meglepő, mert mindig azt írod, az AMD driver így, a Vega úgy, az NV driver meg amúgy, de a magasabb felbontásokon mégis elfogy a lendület. És nem csak ebben a játékban, volt már több példa is erre. Tehát, amikor 3 éve elkészült az AMD DX12 driver, akkor nem gondoltak a nagyobb felbontásokra.
A wccftech tesztje szerint négy mag/négy szál felett az átlag FPS alig nő, ha engedélyezik az SMT-t az jó hatással van a minimum FPS-re. Hol van a 64 szálig skálázódó motor?
-
namaste
tag
válasz
Petykemano
#34807
üzenetére
Neked honnan jönnek a számok?
2018 2. negyedévben 11 millió kártyát adtak el, tavaly összesen 52 milliót.
-
-
namaste
tag
válasz
keIdor
#33731
üzenetére
Eltolódtak a kategóriák, de nem a kódnév számít, hanem a teljesítmény. Számít mit kínál a konkurencia, mindig egymáshoz igazodnak. Ha a GF104 felvette volna a versenyt a HD 5870-nel, akkor az lett volna a GTX 480.
Fermiből nem volt GF102, Maxwellből se volt GM202. Kepler, Pascal, Volta csúcs GPU-k nem jöttek ki játékosoknak, csak a pro felhasználóknak. (Igaz, nincs Volta játékos kártya.)
Ha már vs, az AMD csinálja jól, nem számozza a GPU-kat, hanem neveket ad és 1. vonalbeli GPU-t küld a 3. vonalbeli ellen.
(#33739) TTomax
A HPC és a gépi tanulás is vágott GPU-t kap, ráadásul prémium árat fizetnek érte. -
namaste
tag
A többszálú gyorsítás mértéke függ a játéktól, hogyan használják az API-t.
Azért nem tudják az NV GPU-k ugyanúgy kezelni a StructuredBuffert mint a GCN, mert a konstans pufferre 64 kB-os mérethatár van. Ezért a shader fordító csak akkor használja, ha cbuffert szerepel a shader kódban vagy driverből egyedileg megoldják. Ha eltörlik ezt a korlátot, az egy megoldás.
-
namaste
tag
Az API felépítése miatt nem lehet kihasználni a sok magot: soros feldolgozás, felesleges ellenőrzések, ugyanazt az adatot a CPU az egyik kezéből (játék) a másik kezébe (API/driver) teszi és közben a GPU vár.
A nyílt forrású Mesa OpenGL többszálú driverrel már vannak eredmények: nem működik, nincs érezhető hatása, lassul, illetve 5-10-20-...% FPS javulás. Egyelőre még fejlesztik.Másolás csak DX11-hez kell a DX11 korlátai miatt, mert nem tud egyszerre kezelni cbuffert és tömböt. És még másolással együtt is megéri, gyorsabb.
Megnéztem GCN-en, lényegében ugyanazt a kódot fordítja StructuredBuffer és cbuffer használata esetén. A GCN fordító felismeri, hogy csak olvasás történik és az adatok ugyanazok minden szál számára, ezért a skalár egységen keresztül olvassa be a skalár regiszterekbe. Ez megmagyarázza miért mindegy a GCN-nek milyen kódot kap.
Ha az AMD trükközik, akkor az NV-nek is lehet. De ez nem trükközés, hanem okos fordítás.
Ez egy két és fél évvel ezelőtti cikk, érdemes lenne megnézni, hogy a régi és a mai driverekkel mennyi a különbség. -
namaste
tag
Hogy is van ez? Egyrészt "a driver elveszi az erőforrást a programtól", másrészt "a zöld paca egy kihasználhatatlan CPU idő".
Ha a többszálú drivernek nincs értelme, akkor az AMD miért fejlesztett ilyet?Hol lehet megnézni ezt az előadást?
Azért kell a külön cache, mert ha az L1-en osztozik pl. a textúra adatokkal, akkor felülírják egymás adatait és többször kell a memóriából olvasni, valamint egyszerre lehet hozzáférni mindkettőhöz.
Konstans pufferbe a GPU nem ír, azért konstans, mert nem változik a tartalma. Az írható puffereket textúra, surface vagy egyszerű memória írással érik el.Még egyszer, a GCN a konstans adatokat a Scalar Data Cache-en keresztül éri el.
-
namaste
tag
A videóban is az van, hogy a program nem használja ki a magokat, tehát marad CPU idő a driver szálaknak.
Konstans cache a GCN-ben is van, Scalar Data Cache (K$) a neve, igaz ez írható.
A DX12-ben is van konstans memóriaterület (CBV), ezek gyors elérésére van a GPU-kban dedikált cache."Az OS nem ismeri, hogy van egy ilyen lehetőség a hardverben így nem is használja."
De, a hardverben be vannak drótozva az összeköttetések és azért van a driver, hogy az API absztrakciós szintjét leképezze a konkrét hardverre."Ez a DX12 egyik nagy újítása, hogy a Microsoft betervezte azt, hogy minden pufferelérés ugyanolyan gyorsnak kell lennie."
Akkor GCN Scalar Data Cache is megy a levesbe. -
namaste
tag
Sok DX11 játék nem használja ki a négy magot, így marad CPU idő a drivernek.
Az MS-t nem volt nehéz meggyőzni, hiszen az Xboxban AMD GPU van. Biztos az AMD mindig meglepődik, amikor negyedévente megkapják a csekket az MS-től.(#30376) Abu85
Nem kell diszkvalifikálnod a Geekbench Compute tesztet, csak azért mert az anandtech.com egy plusz 0-t ír az elért pontszám közepébe.
A Geekbench oldalán jelenleg 229763 maximum pontot kap a Vega.
Vega-val van a listában AMD Tambourine (Ryzen 5 2500U és Android), valamint AMD Mandolin.(#30379) Abu85
Mik azok a fast path-ok? -
namaste
tag
A GCN és a Kepler kb. azonos teljesítmény/fogyasztás arányúak voltak. Energiahatékonyságban a Maxwell hozott nagyot a Tiled Caching-el.
A kényszer nem technikai, hanem inkább fejlesztői fókusz, az AMD nem engedhette meg magának, hogy sokfelé próbálkozzon.
Készül a Mesa 3D nyílt forrású driver OpenGL többszálú működési módja, majd meglátjuk mire képes, de biztató. -
namaste
tag
Az a videó összemossa az utasítás ütemezést és a feladat (parancslisták) ütemezést.
A feladatok ütemezését a Keplerben is HW végzi, a GigaThread Engine, a CPU-n futó driver a várakozási sor végére teszi az elkészült parancslistát.Az AMD is megoldhatta volna a többszálú DX11 drivert, de ők inkább a Mantle irányába mentek.
-
namaste
tag
Attól még nem dobják ki a fix funkciós részeket, ha a plusz utasításokkal emulálnak valamit.
Ha sikerült megoldani a DX12 TIER3 bekötést, akkor sikerülhet megoldani a Metal 2-t is.
De ez megint lehet üzleti döntés, főleg ha KL-G valóban az Apple-nek készül és ezt a két cégtől rendelte. -
namaste
tag
De minden funkciójának megfelel az NV-ben egy fixfunkciós egység. Amennyivel esetleg többet fogyaszt az utasítások dekódolása, az jelentéktelen, a fixfunkciós egységeknek is kell energia.
Igazából csak a korlátozott számú erőforrásszám a probléma (64 UAV, 14 CBV), ha ez probléma, amit emulálni kell.Miből gondolod, hogy ez műszaki és nem üzleti döntés?
-
namaste
tag
Korábban azt írtad, hogy a vezérlés miatt fogyaszt sokat a GCN, most azt, hogy a skalár egység miatt. Ez már haladás, de ne állj meg itt, van még ott sok-sok tranzisztor.
Ha mindenképpen kis számú tranzisztorra akarod fogni, akkor az energiagazdálkodást szabályozó áramkörök a felelősök. És a Jolly Joker, a magas feszültség. -
namaste
tag
válasz
Petykemano
#25920
üzenetére
Azért tegyük hozzá, hogy sok tesztben a HairWorks-t kikapcsolják, így fair és nem sérül a valóság sem.
-
namaste
tag
Olyan nincs, hogy több ROP-ot igényel az NV és kevesebbet az AMD, a ROP igény nem függ attól, hol helyezkedik el a TBR-IMR skálán.
A programokon múlik, hogyan használják a hardvert és persze az API-tól is, mit enged meg. DX11 esetén sok marad a GCN-ben, a ROP lesz a korlát, még a compute shader sem segít, mert nem lehet párhuzamosan futtatni a grafikával. Ezt oldja meg a DX12 async compute, a nem használt ALU-kat munkára lehet fogni.
Az SM6 és az AGS nem önmagáért van, l'art pour l'art, hanem a hatékonyság növelése miatt, minél több hasznos számítást lehessen végezni. Azaz az elméleti FLOPS-ból minél többet kihozni.Erről a Tier 2 processzorterhelésről kérek egy API leírást.
-
namaste
tag
Akkor gyorsabb a GCN, ha van async compute, az AGS csak hab a torán.
Hasonlítsd össze az RX 480 - GTX 1060 vagy az RX 460 - GTX 1050Ti eredményeit, van összefüggés a számítási teljesítmény és az FPS között.
Az RX 480 +30% számítási és -30% ROP teljesítménnyel 20-30%-kal több FPS-t ad.
Az RX 460 ugyanannyi számítási és fele ROP teljesítménnyel 10%-kal kevesebb FPS-t ad.Bekötési modell: nem értem miért járna több processzorterheléssel. GCN-ben az az SGPR-ben vannak a leírók, NV-nél a konstans memóriában, mindkét cég hardvere úgy van felépítve, hogy optimálisan kezelje.
Tehát nincs kötelező RS szabály, akkor abba belefér az NV ajánlása is, ha valaki NV-re akar optimalizálni, akkor megteheti.
-
namaste
tag
Ez nem ilyen egyszerű. És ez alapvetően félre van értve.
A GCN azért tud jól alkalmazkodni ezekhez az explicit API-khoz, mert ...
... mert gyorsabb (FLOPS) mint a kategóriatárs NV kártya. DX11 alatt az ALU-kat nem tudja kihasználni, egy részük üresen jár.
Mindig kiválasztasz egy dolgot, amivel megmagyarázod miért jobb a GCN, pl. most éppen a skalár egység.
GCN feltételes elágazás: jó, működik, sokoldalú, de van valami előnye a hardveres vezérléssel szemben? Az elágazás vezérléséhez több utasítás kell: elmenteni a maszkot, beírni a kontroll regiszterbe az új maszkot, ugyanezt megcsinálni a másik ágra, majd visszaírni az eredeti maszkot. Ezek mind külön-külön utasítás, egy skalár utasítás végrehajtásához 4 órajel kell.
Az NV ajánlásai megsértik a DX12 előírásait?
Amikor az MS ajánlásokat tesz az RS használatára, akkor figyelembe veszi az Xbox GCN GPU-ját, azaz a saját hardverét.Az NV milyen formátumot nem támogat a Root Signature-ben?
-
namaste
tag
A program elküldi a shadert a drivernek, hogy fordítsa le, ilyenkor nincs rajta semmi DRM, teljesen szabványos HLSL binárist ad át a drivernek. Itt jön a csere: ezt a shadert nem kell lefordítani natív GPU kódra, ha van a driverben előre lefordított, optimalizált változat.
A GameWorks-t nem kötelező használni, ha valaki tud jobbat, írjon jobbat, még a GW játékokban is lehet alternatív megoldások közül választani a játékosoknak. -
namaste
tag
válasz
lezso6
#19139
üzenetére
A Pascal ugyanúgy vegyes ütemezésű mint a Maxwell, nyilván továbbfejlesztik.
"Nem ultramobil, csak azt mondom, hogy abba irányba ment el."
Jó, de odaért?![;]](//cdn.rios.hu/dl/s/v1.gif)
Még mindig nem értem, miért írod ezt.Persze, a Maxwell nem jó FP64-re, de nem is ajánlják HPC DP-re, viszont sok feladat van amire jó.
-
namaste
tag
válasz
lezso6
#19117
üzenetére
Régen minden jobb volt ... Nem szégyen visszatérni egy régebbi megoldáshoz, ha az hatékonyabb és ugyanúgy ellátja a feladatát. Viszont olyat még nem láttam máshol, ahogy megvalósították a Kepler-Maxwellnél.
Csak nem értem miért ultramobil. Írtam két példát mi jellemzi az ultramobil architektúrákat, ezek nem érvényesek a Maxwellre. Ha lefedik a teljes palettát, miért az ultramobilt választod ki? Miért nem a szervert? Pl. a Tegra az mobil szuperszámítógép.
A GP100-zal kapcsolatban nincs vita köztünk. A REG:ALU arány javítását megcsinálták a Maxwellnél is, mégis ultramobil. Pedig az igazi ultramobil GPU-knál még rosszabb az arány.
-
namaste
tag
válasz
lezso6
#19085
üzenetére
A statikus ütemezés miért visszafejlődés? Egyébként vegyes az ütemezés, van statikus és dinamikus része is. A shaderfordítást pedig mindig a driver végezte, az nem újdonság.
Miért ultramobil? Az igazi ultramobil GPU-k nem is hasonlítanak rá, pl. tile alapú renderelés, nincs LDS. Az új Mali-G71 lépett a SIMT működés irányába. Kíváncsi lennék meddig skálázódnak felfele.
Azért mert keveset fogyaszt az még nem ultramobil, tablettől a szerverekig mindenhol jól jön a kis fogyasztás.
Nem látom hol áldozták be a tudást. Kapott új utasításokat, jobban kihasználja a rendelkezésre álló ALU-kat mint a Kepler, azaz a hatékonyság nőtt. -
namaste
tag
válasz
lezso6
#19065
üzenetére
Kepler ütemező: szoftveresen a PCIe buszon keresztül vezérelni? Nem hiszem. A GPU-ban parancsfeldolgozók vannak, a driver feltölti az adatokat és a parancslistákat, a GPU pedig szétosztja az ALU-knak. Ilyenek szintek vannak:
- legfelül GigaThread engine / Grid Management Unit
- GPC - PolyMorph Engine
- SMX - Warp Scheduler.Maxwell: Igen, a Keplerben 2 db Warp Scheduler ütemez 3 db 32-es ALU blokkot és az LD/ST, SFU, TEX, DP egységeket. Míg a Maxwellnél szétszedték, egy Warp Scheduler egy 32-es ALU tömböt kezel, csak a TEX és a Shared Memory közös. Hívhatod trükknek, de végül is optimalizálás.
"de ennek megvannak a hátrányai is. Pl az 96 kB LDS miatt egyszerre csak 3 blokk használható ki."
... feltéve, hogy 3 db 32 szálat tartalmazó és 32 kB LDS-t használó szálcsoportot futtat. Ezt a szituációt nézd meg Kepleren és GCN CU-n is. -
namaste
tag
válasz
lezso6
#19054
üzenetére
Pedig a Ferminél és a GP100-nál a legjobb az REG:ALU illetve az Shared Memory:ALU arány, a Keplernek a legrosszabb. A Fermi azért fogyasztott sokat, mert 40 nm-en készült és az ALU-kat magas frekvencián működtették.
Keplernél kiherélték az ütemezőt? Hogyan?
A Maxwellben SMM-ben ugyanannyi regiszter(fájl) van mint a Kepler SMX-ben, viszont kevesebb ALU osztozik rajta.
Hogyan lett butább a Maxwell ütemező? -
namaste
tag
válasz
lezso6
#19046
üzenetére
Kepler - Maxwell
A Maxwell sokkal hatékonyabb ütemezővel rendelkezik, szinte minden területen történt előrelépés a Keplerhez képest. Csak egy terület maradt ki a fejlesztésből, az FP64 számolókat kispórolták, illetve nem készítettek belőle FP64 számításokra felkészített változatot. Helyette Keplerből kihozták a GK210-et, majd most a GP100-at. -
namaste
tag
"Ez egy nagyon hangzatos semmitmondás"
Ugye?
De abból az ábrából nem derül ki semmi a crossbarra nézve. Se az hogy szimmetrikus, se az hogy aszimmetrikus.
Nyilván semmi jelentősége nincs, a GPU-k működnek, ahogy működnek. Néha előjön ez a téma (most Abu #15296 hozzászólásában), olyankor rákérdezek, hátha van valami bizonyíték, mellette vagy ellene. De semmi.Abu
Egy kicsit elbeszélünk egymás mellett, a shader processzorok számára érzékelhető memóriasebességre gondoltam. DX11 alatt elfedi a driver (szerinted), viszont a többi API esetén detektálhatónak kell lennie.
DX11 esetén a lefoglalt memória és a szabad terület méretének összevetéséből lehetne észrevenni a többszörös memória használatot. -
-
namaste
tag
A CUDA, OpenCL, DX12 egy ideje elérhető, most már a Vulkan is, mind eléggé közvetlen memória hozzáférést biztosít. CUDA kóddal sikerült kimérni a 3.5+0.5GB-ot, a lehetőség adott.
"Jaj azt ne úgy képzeld el, hogy minden négyszer van benne."
Pont ez az ami nem tetszik: egyszer így működik, másszor úgy.Elég sok vörös bundás vérmókus rohangál fel s alá, hát hajrá!
gbors
Beszélünk valamiról, de nem tudjuk honnan indultunk és azt sem tudjuk igaz-e.Mi a keresztirány és mi az "egyenes" irány a különböző GPU-k esetén: GM107 (5 SMM), GM206 (8 SMM), GM204 (16 SMM), GM200 (24 SMM)?
-
namaste
tag
Crossbar: Ez így kevés. Csak te és gbors írjátok, hogy keresztbe felezett sebességű, máshol nem találkoztam vele. A memóriasebességet ki lehetne mérni, elég sokan foglalkoznak GPU programozással (grafika, számítások), valaki biztos belebotlott valami memóriasebesség anomáliába.
Többszörös memória használat: Ha igaz volna, valakinek már találkoznia kellett volna ezzel, óriási botrány lenne. Megint. Egy 4GB kártyára feltöltesz 1GB-nyi adatot és 4GB lett belőle. Ezt képzeld el 3.5GB-os kártyával.
AMD hub: AZ AMD egyszer hubot ír, másszor crossbart. Melyik igaz?
-
namaste
tag
"Az smm tiltás miatt esik a pixel fill rate?"
Igen. Egy SMM 128 bites busszal kapcsolódik a crossbarhoz és órajelenként 4 db 32 bites kiszámolt pixelt tud küldeni a ROP-ok felé. Két SMM letiltásával marad 22 SMM, ezek összesen 88 pixelt tudnak továbbítani egy órajel alatt. A ROP-ok órajelenként 96 pixelt tudnának feldolgozni, de csak 88-at kapnak. Tech Report GTX 980 Ti teszt
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Még mindig nem értem, miért írod ezt.
De abból az ábrából nem derül ki semmi a crossbarra nézve. Se az hogy szimmetrikus, se az hogy aszimmetrikus.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- TCL LCD és LED TV-k
- Milyen légkondit a lakásba?
- Gumi és felni topik
- PlayStation 5
- AMD vs. INTEL vs. NVIDIA
- Büszke apukák és anyukák topikja
- E-roller topik
- Milyen billentyűzetet vegyek?
- Úgy állhat le a 16 GB-os GeForce RTX 5060 Ti gyártása, hogy közben nem áll le
- GoodSpeed: Te hány éves vagy?
- További aktív témák...
- NVIDIA RTX 3080 Ti 12GB GDDR6X Founders Edition Eladó!
- Asus Dual Radeon RX 5500 XT EVO 8GB GDDR6 Számlás, dobozos, újszerű!
- GIGABYTE RX 9060 XT 16GB GDDR6 GAMING OC - Új, Bontatlan, 3 év garancia - Eladó!
- Gigabyte RTX 4070 Super Windforce OC 12 GB (2 év garanciával)
- NVIDIA RTX 3080 Ti Founders Edition
- GYÖNYÖRŰ iPhone 12 Pro Max 128GB Pacific Blue -1 ÉV GARANCIA -Kártyafüggetlen, MS3996
- LG 27GS95QE - 27" OLED / QHD 2K / 240Hz & 0.03ms / 1000 Nits / NVIDIA G-Sync / AMD FreeSync
- BESZÁMÍTÁS! GIGABYTE A520M R5 1400 8GB DDR4 256GB SSD 500GB HDD GTX 1050 Ti 4GB ZALMAN S3 400W
- HP Thunderbolt-dokkoló, 120W G4 (4J0A2AA)
- ÁRGARANCIA!Épített KomPhone Ryzen 9 5900X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest