- Crypto Trade
- A Google segített az Apple AI-modelleket betanítani
- Letartóztatták, mert AI segítségével csalt az egyetemi vizsgán
- ASUS routerek
- Max
- Aliexpress tapasztalatok
- DIGI internet
- A Biden-kormányt is zavarja a big tech és az adatközpontok energiaéhsége
- AI-alapú, mobilos lopásgátlót tesztel a Google
- Nem szavazza meg Musk 56 milliárd dolláros csomagját a norvég állami vagyonalap
-
IT café
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Unity-hez már van DLSS és FSR is. De a DLSS-nek ott is van pár limitje, amit csak a készülő motorverzió üt ki. Nyilván ezek a limitek az FSR 2-re is vonatkoznak, meg az XeSS-re is. De ezek az év későbbi részében már nem számítanak, mert reagálnak rá.
A néhai Frostbite Team az ma már Embark Studios, ha érted mire gondolok. Nagy volt a lelépési hullám.
Nem tudom, hogy a Frostbite-tal mi lesz. Abban sem vagyok biztos, hogy az EA nem dönti be a picsába a motort. Akkora lekváros bukta volt az új Battlefield, hogy a lekvár is odaégett.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57307
Abu85
HÁZIGAZDA
Komplikato
#57306
Abu85
HÁZIGAZDA
válasz
Komplikato
#57306
üzenetére
Tekintve, hogy magához az eljáráshoz nem nyúltak hozzá, így valószínűleg kompatibilis marad mindennek, mert gyakorlatilag ugyanaz a kód, mint a 2.33.
#57305 b. : Úgy gondolták, hogy vannak már olyan magasan, hogy pofára essenek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az 5 nm-es node-on lesznek vágások. De a Navi 33 az 6 nm. Annak a kihozatala pedig szinte tökéletes. Azon nem kell vágni. Ez egy stratégiai lépés az AMD-nél, hogy a sorozat alja marad 6 nm-en, és a két gyorsabbik lesz csak átrakva 5 nm-re. Ennek az oka, hogy a Navi 33 meg tudja célozni a 400 dolláros sávot, és onnan ugye lehet menni felfele 450-re, ha több memória kell valakinek, stb.
5 nm-en a waferár háromszoros, tehát jelentősen nagyobb költség ezen a node-on gyártani, így ezt már az AMD és az NV is 650 dollárra lövi minimum. És itt mindkét cégnek a 256 bites dizájnja lesz a legkiesebb, és erről a 650 dollárról skálázódnak majd el 2000 dollárig.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57333
Abu85
HÁZIGAZDA
Petykemano
#57329
Abu85
HÁZIGAZDA
válasz
Petykemano
#57329
üzenetére
Az UE5 a mostaninál majd jobban fog futni. Az Epic igazából nincs kész a motor nagy újításaival PC-re, mert lényegében az összes kód RDNA-ra optimalizált. Ez hátrányos igazából mindenen, ami nem RDNA. Emiatt nem ad ki más hozzá meghajtót csak az AMD, mert annyira RDNA-ra van szabva a kód minden egyes pocikája, hogy értelmetlen most optimalizálni. Meg kell majd várni az Epic optimalizálásait.
A motor aktuális verziója csak arra jó, hogy fejlesztőként el tudj indulni, ha veszel mellé Threadrippert és RDNA 2 hardvereket. És ez nyilván hasznos egy készülő projektnél, de amint jönnek a frissítések, akkor frissítik a fejlesztők a motort, és úgy fog egyre jobban futni a nem AMD hardvereken.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57395
Abu85
HÁZIGAZDA
Petykemano
#57394
Abu85
HÁZIGAZDA
válasz
Petykemano
#57394
üzenetére
Nem véletlenül lesznek akkorra időzítve amikorra. Többet nem mondhatok, de nem igazán a hardver a fontos. Régen állítólag legendák szóltak róla, valami wundertreiberizé.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57405
Abu85
HÁZIGAZDA
Petykemano
#57401
Abu85
HÁZIGAZDA
válasz
Petykemano
#57401
üzenetére
Igazából az FPGA nem ezekre való. Nem olyan formában, hogy berakod csak úgy a GPU-ba és működik. Az pazarlás lenne.
Az RT-nek az alapvető problémája a divergencia kezelése. Ez a bejárás és az árnyalás szempontjából is gond.
Az árnyalás tekintetében a helyzet nehézkes, mert ez nem raszterizálás, itt csak az elsődleges sugarak koherensek, a többi meg szopás. Ezt a jelenlegi kutatások szerint nem igazán tudjuk majd hardveresen kezelni. Ahhoz nulláról újra kellene kezdeni a DXR-t, mert rossz irányba kezdte a Microsoft a fejlesztést. Tehát marad a szoftveres kezelés, amire van lehetőség, de oda meg shader powa kell.
A bejárás tekintetében valamivel kedvezőbb a helyzet, mert arra lehet fixfunkciós hardvert tervezni, de ez valójában csak akkor működik, ha kurva sok VRAM-od van. Amint rájössz, hogy ebből a szempontból komoly limitek vannak, és bizony még a 32 GB VRAM is komoly limit, onnantól kezdve kell valami alternatíva. A jelenlegi alternatíva az, hogy ne lődd messzire a sugarakat, mert nem fogod bírni VRAM-mal. De ez amúgy csak most elfogadható, amíg csak PR-ben használatos az RT, de ha később ezt használni is akarjuk, és nem csak marketingért fejlesztettük, akkor előjön az a gond, hogy a fixfunkciós hardver hátrányossá válik, akkor a megoldás egy új programozható struktúra lesz. Tehát a messzire kilőtt sugarak esetében vagy lemondunk a fixfunkciós hardverről, vagy elkezdünk minimum 128 GB-nyi VRAM-ot rakni a VGA-kra.
#57404 Petykemano : A sok cache az hasznos, de csakis az elsődleges sugaraknál. Amint másodlagos sugarakról van szó, már hasztalanná válik. Az RT mag nagyrészt adattár, de van benne feldolgozó is, de ennek a képességei eléggé limitáltak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57410
Abu85
HÁZIGAZDA
Petykemano
#57407
Abu85
HÁZIGAZDA
válasz
Petykemano
#57407
üzenetére
A késleltetés nem fontos. A probléma maga az adatmennyiség. Nagy sávszél kell és sok memória. Az SSG valós idejű számításra nem igazán jó, rosszul cache-selhető ez a jellegű probléma.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57412
Abu85
HÁZIGAZDA
Petykemano
#57411
Abu85
HÁZIGAZDA
válasz
Petykemano
#57411
üzenetére
Ilyenhez csoda kellene. De honnan jöhet a csoda?
![;]](//cdn.rios.hu/dl/s/v1.gif)
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#57413
üzenetére
Ez attól függ, hogy egy pixelből mennyi sugarat lősz ki és meddig számolsz. 80-120 TFLOPS ide a belépő, de kellene hozzá 2-3 TB/s-os sávszél is, ha vannak másodlagos sugarak. Ha nincsenek, akkor az 1 TB/s elég.
Sosem lesz nem trükközgetős RT valós időben.
#57416 Petykemano : Nyilván a csoda a régi hardverkre is érvényes, csak még nem találkoztak vele. Ezért hülyeség ezt így összemérni most.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57419
Abu85
HÁZIGAZDA
Petykemano
#57418
Abu85
HÁZIGAZDA
válasz
Petykemano
#57418
üzenetére
Ez egy ARM szerverprocesszor.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#57420
üzenetére
Ugye ez a co-issue képesség. Ilyet csinálhat az AMD is, de azt nem tudom, hogy csinálnak-e.
Az a helyzet, hogy a pletykák szerint több SIMD32 lesz egy WGP-ben. Állítólag 4 helyett 8, de nem tudni, hogy miképpen lesz beépítve. Ha ugye mindegyik SIMD32 kap skalár egységet, akkor ott ugye nincs co-issue, mert különállók. Ha két SIMD32 kap egy skalár egységet, akkor az sem feltétlenül jelent co-issue modellt, mert ettől még a SIMD32-höz tartozó regisztertár lehet különálló, lásd GCN. Akkor lehet ebből co-issue, ha két SIMD32 lesz egy regisztertáron és egy skalár egységen.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#57423
üzenetére
A vektor ALU annyira sok tranyót nem igényel, de a külön adatút, a regiszter hozzá, és a skalár egység azért nem olcsó.
A TFLOPS az egy csalóka adat manapság, mert a felépítést nem ismerni. Emellett ugye az is nagy kérdés, hogy az Infinity Cache mekkora lesz. A 128 MB az nem túl sok, de ha mondjuk lesz 512 MB, akkor az már elég kemény lenne, és az durván az egekbe lőné a tiling működését. Fél giga cache már 4K-n 64 bájtot tud tárolni pixelenként, az kurvára acélos, és ez például bőven nagyobb súllyal ad bele a teljesítménybe, mint a nyers TFLOPS.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az Intel még a Resizable BAR-t se implementálta végleges formában. Egyelőre lassít a megoldásuk a teljesítményen. Ők majd hoznak rá egy új mikrokódot, de nagyon messze vannak attól, amit mondjuk az AMD-féle SAM tud. És még az NV-féle Resizable BAR teljesítményét sem érik el, pedig azt igazán nem nehéz behozni.
A Smart Access Storage-hez annyit, hogy az nem igazán szabványos megoldás. Ryzen és Radeon kell hozzá. Más kombóval nem fog menni. Talán az Intelhez is megoldják egyszer, de nehezebb a probléma, mint a Resizable BAR esetében, így nem elég csak a mikrokódot optimalizálni. Magát a hardvert kell úgy tervezni, hogy optimálisan működjön, és erre az Intel évek múlva tud reagálni. Ez nem fog ám működni minden Ryzenen, mert nem mindegyik van erre tervezve.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57457
Abu85
HÁZIGAZDA
Petykemano
#57456
Abu85
HÁZIGAZDA
válasz
Petykemano
#57456
üzenetére
A 22.10-es alapverzió az a driver, ami ezeket a változásokat tartalmazza.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57462
Abu85
HÁZIGAZDA
Petykemano
#57459
Abu85
HÁZIGAZDA
válasz
Petykemano
#57459
üzenetére
A driverrel bárki tesztelhetett. Mi is a 22.10.01.02-es batch-ből teszteltük a kártyákat, de ez béta állapotú, és végleges majd valamikor a hónap vége felé lesz, vagy nyár legelején. De tesztelni már lehet vele.
[link] - itt vannak az AMD saját összehasonlításai a 22.10-es batch és a 21.50 között.
Állítólag ki lesz adva egy preview csomag hamarosan, azt majd megírom.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57467
Abu85
HÁZIGAZDA
Petykemano
#57466
Abu85
HÁZIGAZDA
válasz
Petykemano
#57466
üzenetére
[link] - Itt az új driver preview verziója.
Pont látszik az új driver hatása, mert már feltűnt, hogy nem nőtt annyival az órajel, mint amennyivel gyorsult a hardver. És ennek nyilván az oka az, hogy az új VGA-k a 22.10-es batch-csel voltak tesztelve, míg a régiekre a béta nem ment fel. A mostani publikus preview már felmegy, csak későn jött.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57486
Abu85
HÁZIGAZDA
Petykemano
#57480
Abu85
HÁZIGAZDA
válasz
Petykemano
#57480
üzenetére
Mivel az AMD régóta egy közös PAL implementáción keresztül támogatja az összes explicit API-t, így elég sok szabad erőforrásuk van másra, például a DX11 fejlesztésére. Ezért nem írnak külön implementációt a DirectX 12, a Vulkan, a Mantle és a Metal API-ra. Mindegyik ugyanazon a PAL rétegen fut. Olcsóbb és hatékonyabb. Ergo ugyanannyi emberrel hatékonyabb munkát tudnak manapság csinálni.
Az Intel is erre megy a driverrel, mert a Vulkan implementációt már kettévágták platformabsztrakcióra és kliensmodulra, és valószínű, hogy idővel a DX12-nek is erre a platformabsztrakcióra raknak be egy kliensmodult. Ugyanaz a háttere ennek, ami az AMD-nél. Olcsóbb a munka és hatékonyabb.
Megoldható amúgy az is, hogy minden explicit API különálló implementációt kap, de az drága és nem hatékony.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57493
Abu85
HÁZIGAZDA
Petykemano
#57492
Abu85
HÁZIGAZDA
válasz
Petykemano
#57492
üzenetére
Valószínűleg maga a driver működne GCN-eken, de nincs rájuk tesztelve, mert csak preview a csomag, így inkább nem írták bele a GCN-t a kompatibilis hardverek listájába. Ugyan az AMD mondhatná, hogy béta, és próba cseresznye, de azért valamilyen szinten felelősséget vállalnak a previewért is
Amúgy az RDNA és az RDNA 2 jobb parancsmotorral rendelkezik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57500
Abu85
HÁZIGAZDA
huskydog17
#57499
Abu85
HÁZIGAZDA
válasz
huskydog17
#57499
üzenetére
Az OpenGL-be már senki sem öl erőforrást, mivel a Microsoft azon dolgozik, hogy kizárja az API-nak a támogatását a Windows operációs rendszeren. A helyére egy olyan interfész kerül, ami az OpenGL-t implementálja DirectX 12-re, tehát minden OpenGL program kvázi a DirectX 12 meghajtón fog futni. Ezzel egyébként rákényszerítik a szoftverfejlesztőket is arra, hogy javítsák ki a nem szabványos OpenGL kódjaikat, mert a gyártók innentől kezdve nem tudják megtenni drivermachinálással. Amelyik cég nem csinálja meg, annak az alkalmazása futtathatatlan lesz.
A probléma egyébként onnan ered, hogy a Khronos teljesen elengedte az OpenGL kezét, így ha nem lépnek a platformtulajdonosok, akkor egy kibaszott szemétdomb lesz az egész. Annyit tudni még, hogy a Microsoft OpenGL 3.3-ig implementálja le az API-t. Tehát az ennél többet igénylő programoktól búcsúzni lehet.
Egyébként ugyanezt megcsinálta az Apple, és a legjobb döntésüknek tartják, szóval ragadós lesz a példa.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57503
Abu85
HÁZIGAZDA
huskydog17
#57502
Abu85
HÁZIGAZDA
válasz
huskydog17
#57502
üzenetére
Elárulom, hogy a Microsoft mindig ezt csinálja. Amint vége egy API támogatásának, hoznak rá egy layert. Ezért fut minden DirectX 5-6-7-8-9 játék a DirectX 9.L-en. Ezért fut minden DirectX 10 játék DirectX 11-en. Egyszerűen a legacy API-kat hasznosabb kiszedni a rendszerből, mert arra nem lenne direkt támogatás, és így lesz ez az OpenGL esetében is, csak az a DirectX 12-re lesz implementálva, mert az az optimális választás hozzá.
A natív támogatást így a gyártók ki tudják vezetni, mert költséges az egészet karbantartani egy maréknyi programért.
Az OpenGL problémája egyébként nem a driver, hanem a program. A gyártók másképp értelmezik a specifikációt, ami addig jó, amíg a Khronos támogatja az API-t, és korrigálják az értelmezési problémákat, de mivel az OpenGL mögül kivették a supportot, így már senki sem egyértelműsíti a vitás kérdéseket. És ilyenkor mi van? Az AMD implementált egy funkciót x módon, az NVIDIA y módon, az Intel pedig z módon. Ki mondja meg, hogy melyik implementáció a szabványos? Senki. Végeredményben a fejlesztőnek mindhármat támogatnia kell, kivéve, ha maga az OpenGL API le lesz implementálva DirectX 12 API-ra, és akkor az AMD, NVIDIA és Intel hardverek is ugyanazt a kódot képesek futtatni, vagyis nem kell háromszor megírni ugyanazt, mert a Khronos már nem foglalkozik a kérdéssel. Na pontosan ezért csinálja ezt a Microsoft.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57505
Abu85
HÁZIGAZDA
huskydog17
#57504
Abu85
HÁZIGAZDA
válasz
huskydog17
#57504
üzenetére
Sose jelentette be a Microsoft előre, amikor kivonta a rendszerből az egyik DirectX API-t. Ettől még megtették. A Windows 10 és 11 OS-ben három DirectX API van, 9.L, 11 és 12. Ezeken fut minden, ami DirectX. A dolog úgy működik, hogy létrehoz egy erőforrást az alkalmazás, amelyet becsatol a Windows a kompatibilis layerbe. Emiatt van az, hogy az OpenGL on DirectX 12 esetében is simán OpenGL-nek írják a programok az API-t, de nem azon fut natívan, csak egy olyan erőforrást hoz létre, amit becsatol a Windows a kompatibilis layerbe.
Ugyanaz a problémája a Microsoftnak, mint az Apple-nek volt az OpenGL-lel. Meg amúgy az OpenCL-lel is. Annyira le se szarja a Khronos ezeket, hogy a gyártók nagyon szabadon értelmezik a lehetőségeket. És ez leginkább az AMD-re igaz, amely vállalat a szabványos implementációk mellé tökre nem szabványos alternatívákat is csinál. Lásd OpenCL 2 funkciók 1.2-ben, OpenGL binárist shadert engedő kiterjesztések, stb. Ez a Microsoft és kb. az összes OS fejlesztő oldalán elég nagy baj, mert ugyan az AMD arra hivatkozik, hogy fejlesztői igényeket fed le, de ezekkel közben saját magához láncol programokat. És kurvára sokszor csinálják ezt Embedded és HPC szinten. Ez pedig probléma a Microsoftnak, mert elvileg ugye az OS támogatja az OpenGL-t, egy másik gyártó is, aztán a bináris shaderrel szállított programok meg se nyikkan rajta, sőt sokszor az új AMD hardvereken sem. Ezzel a marhaságával tarolta le az AMD a casino gaming piacot, mert drágább átírni 400 ezer sort, mint kompatibilis hardvert venni legközelebb. De a megoldás az, ha az OpenGL specifikációját a Microsoft egységesíti. Nem lesznek többet ilyen bináris bezárások, specifikáció által tiltott ajtók kinyitva, lesz egy implementáció a DirectX 12-re, és ha arra dolgozik egy szoftverfejlesztő, akkor futni fog a program a DirectX 12-es implementációkon.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azt használja ki az AMD, hogy leginkább az NV-t vitték a bányába, és nekik innen nehezebb visszaállni a piacra. Tehát az AMD sokkal gyorsabban normalizálni tudja az árakat, mert nem volt annyira kitéve a bánya hatásainak, mint az NVIDIA. Ezért is hülyeség ezt így mérni, mert az NV VGA-k ára még zuhanni fog, csak a bolti GeForce készletek komoly áron lettek megrendelve, és nem lehet egyik napról a másikra megfelezni az eladási árat, mert az kurva nagy zakó a boltnak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Korábban írtam erről itt: [link]
Tényleg függ attól az egész, hogy miképpen építik be. Az, hogy dupla SIMD még nem sok adat. A VLIW2 már valami. A klasszikus értelmezés tekintve itt két egymástól nem függő SIMD operáció kerülne egy VLIW-be. Tehát klasszikus co-issue rendszerről lenne szó, de nem kizárt, hogy a "cross linked" az cross-lane akar lenni, és akkor ez már trükkös, mert elvileg működhetne kétciklusos kihasználtságlimittel is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57611
Abu85
HÁZIGAZDA
Petykemano
#57609
Abu85
HÁZIGAZDA
válasz
Petykemano
#57609
üzenetére
Ha a hit erős, akkor a profit másodlagos.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57624
Abu85
HÁZIGAZDA
huskydog17
#57623
Abu85
HÁZIGAZDA
válasz
huskydog17
#57623
üzenetére
Egyrészt az AMD meghajtójának OpenGL drivere egy workstation driver. Nem pedig performance. Másrészt az OpenGL baja az, hogy ha ezt átrakják performance driverré, akkor keletkezik kismillió bug, mert maga az OpenGL nem jól működik. Hiába szabvány, ha mindenki úgy értelmezi a specifikációt, ahogy akarja. Ergo minden egyes OpenGL program úgy van megírva, hogy van külön kód minden gyártóra. Erre mondjuk a kódcsere áthozható, de amint hozol egy új programot, rögtön ott fogja találni magát a fejlesztő, hogy kell egy külön kód az új AMD driverre, és egy másik a régire. Emiatt értelmetlen az egész OpenGL, mert egy ilyen drivercsere már gyártón belül is gyakorlatilag kompatibilitási gondokat eredményez. Az AMD tudna erről mesélni, mert ők rendelkeznek a legfrissebb OpenGL driverrel. 2004-ben döntötték el, hogy újraírják a nulláról, és 2007-ben lett kész. Ekkor csinálták meg azt, hogy a régi performance drivert kicserélték workstation driverre, hogy masszívan a szabvány specifikációját kövesse a rendszer. Viszont a játékok többsége szart a szabványra, emiatt ennek haszna nem volt, maximum annyi, hogy ha valaha is szabványos kódot akartál OpenGL-re, akkor nem mentél tovább az AMD OpenGL driverénél. A performance driverek mások. Azoknál szabadabb a szabvány értelmezése, és ezt ki is használják a cégek, mert teljesítményt nyernek velük. Persze annak az árán, hogy a saját értelmezésük eltér a konkurens értelmezésétől, és cserébe két kód kell, vagy több, ha per driverben is gondolkodsz. Ezért döglött meg az OpenGL, nincs senkinek sem türelme 5-6 különböző kódutat fenntartani, amikor Vulkan API-ra elég egy kódút.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57629
Abu85
HÁZIGAZDA
huskydog17
#57625
Abu85
HÁZIGAZDA
válasz
huskydog17
#57625
üzenetére
Évek óta ismert problémát írtam le. Ez végezte ki az OpenGL-t.
#57626 Hellwhatever : Leginkább úgy, hogy amikor az OpenGL-t specifikálták, akkor már a fejlesztésébe bele volt kódolva, hogy el lehet szarni.
Rich elég sok előadást tartott anno, amikor a Valve motorját portolta natívan OpenGL-re. A lényege ezeknek mindig az volt, hogy hiába beszélünk egy API-ról, a gyártók az egyes függvényeket másképp implementálják. Egyszerűen a specifikációban leírtak nem egyértelműek.
Többször utalt rá, hogy az NV-vel gyorsan működhetnek a dolgok, de a kód, amit így megírsz nem lesz szabványos, és az NV-nek a fejlesztőeszközei pontosan ezért használhatatlanok, mert a debug eszközökkel összevesznek, ugyanis a debug nem azt várja, amit kap, egy nem szabványos kódot. A fejlesztéshez tehát nem tudott a Valve mást használni, csak AMD hardvert, mivel a GPU PerfStudio és a CodeXL eléggé szabványos eszközök voltak, és kompatibilisek szabványos debug eszközökkel is, illetve az AMD workstation drivere is szabványosan kezeli az API-t, de ha erre megírsz egy kódot az nem jó az NV-nek, mert az meg más kódot vár. Olyat, ahogyan az NV értelmezte a szabványt. Emellett az AMD workstation drivere pont azért workstation driver, mert arra van kigyúrva, hogy a specifikációknak megfelelően kezelje az API-t, és ilyenkor nem csinál olyat, amitől az alkalmazás összeomolhatna, nem értelmezi szabadon a függvények specifikációit, hogy kihagyjon teljesítményigényes ellenőrzéseket. Utóbbitól lesz egy performance driver gyors, egyszerűen a nagyon lassú munkafolyamatokat koncepció szintjén kihagyja, még akkor is, ha a specifikáció előírja az erőforrások ellenőrzését, annak érdekében, hogy ne alakulhassanak ki hazardok. Viszont ilyenkor nagyon sok múlik a játékra szabott meghajtón, mert ott kell olyan ellenőrzési rutinokat beépíteni, ami ezt megakadályozza, ha már az API működését nem követik. És ez az, amiért a performance driverekkel lehetetlen a nagy OpenGL alkalmazások debugolása és profilozása. Egyszerűen a meghajtó még nem ismeri az alkalmazást, és az ellenőrzések kihagyásával tele lesz az egész munkafolyamat hazarddal.Ezen túlmenően nagy gond volt még a shader fordítás. Az OpenGL programban magát a shader forrást kellett szállítani, és azt a meghajtó fordította le a GPU-nak. De az egyes meghajtók más kódokat igényeltek, attól függően, hogy miképpen értelmezték a specifikációt, ezért kellett külön shader az összes gyártónak, sőt, az egyes architektúrák sem mindig fogadták el a gyártóspecifikus shadert, így hiába beszéltél szabványról, akkor is egy gyártóra két-három kódutat szállítottál OpenGL-ben, vagyis mindent kb. 7-9-szer kellett megírni. És mivel más megoldás nem volt, ez egy leülős-gépelős feladat volt.
Nem véletlen, hogy a Vulkan API már sokkal egyértelműbben fogalmaz a specifikációk tekintetében. Kevésbé félreérthető. Alapvetően a dokumentációját az AMD-től emelték át, és azt módosították, tehát helyből már egy olyan alap állt rendelkezésre, amit hozzáértők írtak meg. És így már jól lehetett építeni erre az alapra. A shader fordítást is megváltoztatták, mostantól nem lehet forrást szállítani, hanem IR-t kell, és az IR-re gyári fordító van, vagyis nincs olyan, hogy az NV/AMD/Intel "véletlenül" máshogy értelmezte a specifikációt. Az IR-ig hozzá sem tudnak szagolni a fordításhoz, tehát ők már csak az IR után dolgozhatnak, és ez a köztes nyelv nem magas szintű, így sokkal-sokkal egyértelműbb, mint magas szintű nyelvről gépi kódot fordítani.
Röviden, az volt a gond, hogy OpenGL-re nagy applikációkat lehetetlen volt írni egy kódútból. Egyszerűen több kellett. Emiatt meg is pusztult az API. A Valve is áttért később a Vulkan API-ra, mert igazából nagyon-nagyon drágává tette az OpenGL mód karbantartását az, hogy 7-8-szor volt megírva minden.
#57628 morgyi : Igazából a gyártóspecifikus kiterjesztések egyszerre voltak hasznosak és katasztrofálisak. Az egyik előadáson Rich meg is említette, hogy ARB kiterjesztésekkel lehetetlen gyors kódot írni, egyszerűen azok túl rosszak. Emiatt a Valve is a lehető legtöbb dologra gyártóspecifikus kiterjesztéseket használt. Ha ezek nem lettek volna, akkor az OpenGL a DirectX leképező teljesítményének a huszadát sem szedte volna össze, annyira el van szarva az egész. A kiterjesztésekkel lehet hozni bele teljesítményt.
Nincs azon mit csodálkozni, hogy manapság nem igazán jön OpenGL-re semmi. Néhányan a régi kódutakat még karbantartják, de a Vulkan akkora átütő siker, és a Khronos annyira leállt az OpenGL fejlesztésével, hogy ez a kérdés már rég eldőlt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#57631
üzenetére
Igen, bele van rakva egy rakás munka. A Valve előadásai nagyon jól mutatták ezt. Ők ugye kényszerűen AMD hardveren fejlesztettek, mert akkora kódmennyiséget az NV debug eszköze nem tudott kezelni. Szétfagyott az egész a picsába.
Itt van a dia, ami azt írja le, hogy miért az AMD fejlesztőeszközét használták:
Ezt az előadást láttam is, és Rich azt is hozzátette, hogy ha nincs a GPU PerfStudio 2, akkor sose lett volna OpenGL módja az említett két játéknak. Egyszerűen kivitelezhetetlen lett volna egy ekkora kódbázisra az egész, mert egyénileg kellett volna minden egyes függvényt ellenőrizni, hogy az hogyan fordul le xy hardverre, és ott pontosan mit csinál. Az pedig akár 5-6 évnyi munka is lett volna, és olyan időtávban felesleges dolgozni, mert mire ellenőrzik xy hardverre, addigra két-három generációval későbbi hardverek jönnek, amelyekre szintén ellenőrizni kell, vagyis ismét jöhet a munka, bár nem 5-6 évnyi, de folyamatosan patch-ek kellenének, amelyek az érkező hardvereket 1-2 év csúszással támogatják csak.Ezen túlmenően a szabványos kódjuk, meg se moccant az NV hardvereken. Egyszerűen sűrűn szétfagyott, illetve kaptak egy rakás stallt. Ezt úgy oldották meg, hogy a kódot mindig elküldték az NV-nek, amely cég egy új driverrel együtt visszaküldte a kívánt módosítást. Tehát nem csak egy másik kódút kellett, hanem egy specializált driver is, amit mindig használtak, mert ha nem, akkor a módosított kódút is szétfagyott a picsába, és a teljesítménye is kb. a tizede volt annak, amire szükség volt.
Alapvetően ezek voltak az OpenGL bajai, és évek óta ismertek, csak a Khronos egyszerűen nem fordított erőforrást a kijavításukra, mert feltettek mindent a Vulkan API-ra. Ezzel együtt pedig a Valve is befejezte az OpenGL mód supportját. A Vulkan mellett nem volt értelme.
Tehát amikor valaki OpenGL-re dolgozik egy igen nagy programot, akkor igazából gyártói segítség nélkül azt nem fogják összehozni. És a gyártók is egyedi kódokat javasolnak, gyártói kiterjesztésekkel, amit a Valve szintén említett, hogy használják is bőven, mert az ARB-vel sokkal lassabb a program. Ilyen szintű együttműködés ugyan megoldható, de végül lesz gyártónként két-három kódút, és specializált driverek, és a kódutakat úgy kell karbantartani, hogy új driver kell a módosításokhoz. Ma már ezzel nem éri meg foglalkozni. Az egyetlen működő OpenGL debugert sem fejleszti már az AMD. Persze a forráskódját kiadták, hogy aki szeretne dolgozni, az elmaszatolhat vele, de sokkal-sokkal könnyebb Vulkan API-ra váltani.
#57632 b. : Ami ugye Linux alatt megint úgy sikerült, hogy a Valve a saját programjaihoz módosította a meghajtót, vagyis ez sem szabványos teljesen.
A szabványhitelesítés lényegtelen OpenGL alatt, mert az a gond, hogy maga a dokumentáció nem fogalmaz egyértelműen, hogy mik a követelmények. Egy-egy dolog implementációjára több út is van, és a gyártók ezt ki is használják. Itt változott nagyon sokat a Vulkan. Amikor átvették a Mantle API-t, akkor vele átvették az AMD dokumentációját is, és az nagyon szigorúan fogalmazza meg, hogy mit hogyan lehet implementálni. Ezt a Vulkan vitte tovább, tehát alig van olyan tényező, hogy valamiben kérdés merülne fel. Ha van is, azt is nagyon gyorsan egyértelműsítik, hogy ne álljon be az a helyzet, ami az OpenGL-nél.
Az OpenGL dokumentációjával simán lehet olyan meghajtókat írni, amelyek mind átmennek a hitelesítésen, de eközben ugyanazokat a kódokat nem úgy értelmezik. És ez az API hibája, nem egyértelmű a specifikáció, és ezt a gyártók szándékosan félreértelmezik, hogy gyorsabb legyen a meghajtó, csak nem eszi meg a szabványos kódot.
Érdekes módon a workstation piacon mindenki tudja, hogy mi a szabványos és mi nem. Ott eléggé egységesen van kezelve minden, akármilyen gyártói drivert dobsz fel, megeszi a szabványos kódot. Tehát nem hülyék a gyártók sem, csak tetetik, hogy hülyék, mert csak az AMD hozza át a workstation meghajtóját Windows alatt a gaming driverbe. Ez változik meg a következő nagy batch-csel, de ezzel együtt már az AMD meghajtója sem lesz szabványos.#57633 Petykemano : Igen jól érted. Az új meghajtóval a régi játékok OpenGL módja problémás lehet, de mivel alig van OpenGL program, így nagyon egyszerű per alkalmazás szintjén leprofilozni az egészet, és akkor az új meghajtó problémáit célirányosan lekezelni úgy, hogy az AMD még a fordítás előtt kicseréli a programkódot egy olyanra, amit a nem szabványos meghajtó megeszik. Ezt csinálja az NV is. Csak ugye az ilyen modell megöli az API-t, mert így fejleszteni lehetetlen rá, lásd fentebb Valve.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Közben volt 3D matyi futás. Egyelőre eredmény nélkül, de a maximum elért órajel 3,8 GHz volt.
Ez amúgy lehet reális, ha tényleg ugyanazzal a performance library-vel készül, amivel a Zen 4, az is tud 6 GHz-re turbózni.
Valszeg a tipikus órajel az AMD-nél prociban 5-5,5 GHz közötti lesz, míg GPU-ban 3-3,5 GHz közötti.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57646
Abu85
HÁZIGAZDA
Petykemano
#57641
Abu85
HÁZIGAZDA
válasz
Petykemano
#57641
üzenetére
Fene se tudja, de ugye a saját performance libjük manapság erőteljesen órajelre megy. Szóval ez bele van tervezve a dizájnba. Valószínűleg 5 nm-en már lehet rá elég tranzisztort áldozni. Alapvetően az órajel is egy dizájnkérdés manapság. Rá tudsz tervezni egy lapkát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57648
Abu85
HÁZIGAZDA
Petykemano
#57647
Abu85
HÁZIGAZDA
válasz
Petykemano
#57647
üzenetére
Mert van olyan performance libjük, amivel ezt megtehetik, ellentétben az Apple-lel, amely cég a gyári libeket használja.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57650
Abu85
HÁZIGAZDA
Petykemano
#57649
Abu85
HÁZIGAZDA
válasz
Petykemano
#57649
üzenetére
Mert olyat akarnak csinálni, amit el tudnak adni. Olyat nem, ami csak az Apple-nek jó, de az Apple nem veszi meg.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A TSMC-nek az 5 nm-es node-ja (plusz ennek a 4 nm-es half-node-ja) azért elég jól sikerült. Igen kellemes már a kihozatal is a kisebb lapkáknál, a nagyobbaknál nem tökéletes, de ez benne van eleinte. Sokkal több baja van a 3 nm-en a TSMC-nek. Ott már kezd visszaütni, hogy a FinFET túlment a határon.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Lényegében igen. A 3 nm problémája az, hogy a Samsungnál GAAFET van, ami ismeretlen, tehát kockázatos, míg a TSMC-nél még nincs GAAFET, miközben a FinFET már nem skálázódik ilyen csíkszélességre, ami megint kockázatos. Nyilván átváltanak majd, de most nem túl jó döntés ezt elsietni.
Egyébként a Samsung 3 nm-je jobban áll, ami nyilván azért van, mert ők már nem FinFET-et használnak. És valószínű, hogy gyorsabban is fog javulni nekik a kihozataluk.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57723
Abu85
HÁZIGAZDA
Hellwhatever
#57720
Abu85
HÁZIGAZDA
válasz
Hellwhatever
#57720
üzenetére
Ezért kell konnektorból mérni. Abban még az is benne van, hogy mennyire hatékony a meghajtó a CPU többletterhelését tekintve.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#57728
üzenetére
Milyen anti-consumer tevékenység. Az AMD hardverei régóta így működnek. És azért működnek így, mert így sokkal gyorsabb lehet egy hardver. Amikor bevezették az AVFS-t, akkor sokszor hangsúlyozták, hogy 15 éve dolgoznak egy ilyenen, és a célja ennek az, hogy ne csak 1 perces turbókat kapj, hanem kitartott, 4-7 percig dolgozókat is. A DVFS-hez viszonyítva az AVFS +10-20%-os extra teljesítményt is jelent a felhasználónak. Az, hogy nem lehet normálisan kimérni? Sosem tervezték arra, hogy ki lehessen. Aki valós fogyasztási adatokat akar, olvassa a fogyasztásmérőt a konnektorból. A többi megoldásban mindig is sok volt a hibalehetőség. De nem fognak 10-20%-nyi teljesítményről lemondani azért, mert a user nem tudja pontosan mérni a fogyasztását a hardvernek.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Specifikusan külön ilyen egység nem lesz benne. Egyszerűen nincs értelme egy feladatért tranzisztorok tízmilliárdjait elkölteni, amit lehet, hogy xy cím alatt be sem lehet kapcsolni. Ráadásul ezek az eljárások jó darabig gyártóspecifikusak lesznek, tehát face-to-face tesztben be sem fogják őket kapcsolni, ami azért nagy baj, mert tranzisztorok tízmilliárdjai rögtön mennek a kukába az irányadó teszteknél. És akkor jöhet a gyártó azzal, hogy nem jól tesztelsz, mert amúgy a hardver gyors.
Az RDNA 3 egyszerűen csak kap egy úgynevezett WMMA operációcsoportot. Ez ugyanaz, mint ami a CDNA architektúrákban van, azzal a különbséggel, hogy sokkal korlátozottabb a mátrixok kezelése, de ugye az RDNA csak grafikai dizájn. Ennek a módszernek az az előnye, hogy mindössze csak a dekódolót és az ütemezést kell átalakítani, külön ALU-t nem igényel, vagyis az operációk futhatnak a normál számításra használt SIMD motorokon. Ilyen formában ezért a képességért nem tízmilliárdos, hanem inkább százmilliós nagyságrendben kell tranzisztorral fizetni, így a megnyert tranyókat el lehet költeni olyan feldolgozókra, amelyeket minden program hasznosít, és amelyekre majd a tesztekben is építenek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Meg az Intelről is. Ők is külön egységgel oldják meg. Nagyon messze is vannak a versenyképességtől.
Én sem, de megvan a maga átka. És nyilván nyomós indokkal nem akar az AMD tranzisztortízmilliárdokat költeni egy olyan dologra, aminek a hatása a tesztekben nem fog látszódni.
Az Infinity Cache csak egy egyszerű victim cache. Eleinte voltak particionálási kísérletek optimalizálás gyanánt, de az AMD egy ideje egyáltalán nem ajánlja. Egyszerűen csak az a javaslat, hogy hagyják automatikusan dolgozni, ne is foglalkozzanak azzal, hogy van, tudja a dolgát magától.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#57735
üzenetére
Akkor leírom még egyszer. Mindig azt mondtuk a PH-n, hogy ezekben a mérésekben nem lehet bízni. Ezért mérünk fogyasztásmérővel. Az, hogy az igazunk rendre újra és újra bebizonyosodik, hát basszus, ezért mondjuk jó ideje azt, hogy csak a konnektorból mért fogyasztási adat a megbízható. Minden más potenciálisan tévúthoz vezethet. Ha van valaki, aki még 2022-ben sem értette ezt meg, nos, ő már sosem fogja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#57737
üzenetére
Az nem zavar, hogy mi évekkel korábban is azt mondtuk, amit Igor, csak korábban még kinevettek?
Persze lehet bízni 2022-ben szoftveres mérésben, de már régóta nem mérvadó. És ennél világosabban nem tudom leírni. Mi már évekkel korábban is azt mondtuk, hogy csak a konnektorból mért adat a mérvadó, mert az vesz figyelembe mindent. Az, hogy valakinek ez 2022-ben esik le... hát, jó reggelt.
Persze felőlem rácsodálkozhatunk minden évben, hogy szoftveresen a fogyasztás nem kimérhető, csak ne tegyünk úgy, hogy ez nem 10-15 éve ismert tény.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Pakmara
#57745
üzenetére
A konnektoros mérés azért messze a legjobb, mert abban ugyan vannak torzító hatások, de ha minden más hardver ugyanaz, akkor ez minimalizálható, illetve a konnektorból felvett fogyasztás nem csak a kártya fogyasztását méri, hanem a processzor többletterhelését. Ez kifejezetten fontos, mert a különböző meghajtók különböző többletterhelést eredményeznek, és ez nem mindegy a processzor fogyasztását tekintve. Ha valaki ezt nem méri ki, akkor pont úgy nem ad teljes képet, mint a szoftveres mérések.
Rácsodálkozhatunk erre évente/félévente egy cikkben, de ettől a fenti tényező már legalább tíz éve nem változott.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az adaptív skálázás természetesen sokkal jobb, mint a dinamikus, mert figyelembe veszi a környezetet. Ezért adaptív. Alkalmazkodik a körülményekhez, míg a dinamikus erre képtelen.
Az más kérdés, hogy sokan túl bonyolultnak tartják az adaptív skálázást, ami egyébként reális is lehet, mert az AMD-nek is 8 évbe telt, mire összerakta az első ilyen rendszerét. Tehát nem egy könnyen megoldható problémáról van szó.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#57761
Abu85
HÁZIGAZDA
Petykemano
#57759
Abu85
HÁZIGAZDA
válasz
Petykemano
#57759
üzenetére
A réjtrészing az mindenhol memória/sávszél probléma. Igazi réjtrészinget eleve nem láttunk még, mert ahhoz kellene a programozhatóság.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Semmit. Ugyanazokat a problémákat, amiket mindenhol. Egészen rövid sugarakat, és másodlagos sugarakat alig-alig. Amíg nem lesz programozhatóság, addig ezeket nem lehet megoldani. Esetleg úgy, hogy elkezdünk 100 GB-os VRAM-okat pakolni a VGA-kra, de az overkill, akkor már igazán jobb megoldás, ha programozható lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Nem tudom, hogy a Frostbite-tal mi lesz. Abban sem vagyok biztos, hogy az EA nem dönti be a picsába a motort. Akkora lekváros bukta volt az új Battlefield, hogy a lekvár is odaégett.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ú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!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- Autós topik
- VR topik (Oculus Rift, stb.)
- Politika
- Redmi Note 12 4G - valaki fizetni fog
- Crypto Trade
- Kerékpárosok, bringások ide!
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Kínai, és egyéb olcsó órák topikja
- Computex 2024: Mini-ITX alaplapokat vár a Fractal két új háza
- Kormányok / autós szimulátorok topicja
- További aktív témák...
