Új hozzászólás Aktív témák
-
Kupszi
aktív tag
A 20.5.1 driverrel valami gond van, 3x kaptam zsínórba kékhalált a Youtube-n ugyanannál a szituációnál Chromium edge alatt. Vissza kellett tennem a 20.4.2-t így tökéletes. Remélem javítják a hibát.
Pipapapa strikes back again! Avagy újabb tégla a falba!
-
-
Kupszi
aktív tag
Más lehetett, 3x ugyannál a videólistánál akadt meg és AMDMGP.DLL vagymilyen névvel volt az eset. Tehát valami probléma lehetett ott. A másik driverrel nincs ilyen gond.
Remélem csak egyedi eset volt és csak nálam, nálad ne legyen ilyen probléma mert elég idegesítő voltPipapapa strikes back again! Avagy újabb tégla a falba!
-
Abu85
HÁZIGAZDA
válasz paprobert #50 üzenetére
Azok idle-re vannak. De a hardverek kezdeti beállításait az AMD szereti módosítgatni. A mai driverek nem úgy működnek, mint régen. Ilyen asztali/multimédiás terhelés mellett inkább brustolnak. Ez egy régóta ismert energiahatékonysági stratégia, csak nehéz olyan hardvert csinálni, amin megvalósítható, de a lényege annyi, hogy nem egy fix low power state-en megy a hardver, hanem brustol egy nagyot, gyorsan végez a feladattal, és visszatér a legalacsonyabb state-re. Régen azért volt ez más, mert egyrészt nem volt AVFS a GPU-kban, nem volt ennyire sűrű a powertune átmenet, nem volt lehetőség többszáz MHz-es ugrásokra 10 ns-on belül, vagy esetleg az adott, például multimédiás részegység nem bírta a magas órajeleket. Ma ezek már nem problémák, egyik sem, ezért sokkal jobban megéri brustolni, megcsinálni a feladatot, majd idle-be állni, amíg jön a következő feladat. Többet nyersz vele a konnektorból felvett energia tekintetében, mintha beraknád a GPU-t egy állandó alacsonyabb state-re. Amit látsz az nem igazán maga a működés, hanem annak a problémája, hogy a szoftver nem olvas ki adatot olyan sűrűn, amelyen sűrűn maga a hardver órajelet és feszültséget vált. Tehát van egy kiolvasási ciklus, legyen mondjuk 1 másodperces, ami alatt a hardver beállít egy rakás órajelet és feszültséget, és azokból a high clock average paramétert eltárolja, amit a meghajtó kiolvashat. Na most, ha abból az egy másodpercnek a 90%-ában idle volt a hardver, de 10%-ban dobálta fel az órajeleket, akkor nem a 90%-os idle órajelet kapod meg, hanem a 10%-os high clock average-ot. Itt se az abszolút maximumot, hanem a nem idle órajelek közül a jellemző átlagot. Tehát effektíve te azt látod, hogy magas az órajel, miközben a hardver az esetek többségében lehet, hogy idle van. A probléma tényleg ott keletkezik, hogy sokkal gyorsabban vált órajelet maga a hardver, minthogy azt a szoftver követni tudná, minden állapotot viszont nem lehet kiolvasni, mert 10 ns-onként kellene egy mintavétel, ami azért erősen lezabálná a procit. Szóval azok a szinten használva vannak, csak kiolvashatatlanul gyorsak a változások.
A power efficiency igazából nem ezekre támaszkodott, hanem egy speciális power limit volt, ami megtiltotta a hardvernek, hogy egy bizonyos energiamennyiségnél többet felvegyen. Semmiben nem volt több annál, mintha te állítanád be a Power Limitet a Wattmanban, csak az AMD pontosan kiszámolta, hogy hol van a terhelhetőségi határ, míg manuálisan állítva te százalékos értékeket tudsz csak behozni. Viszont miután megoldották ezt egy sokkal következetesebb teljesítményt biztosító móddal, teljesen szükségtelenné vált ez a beállítás. Egyrészt a power limitet te is eléred, másrészt ahogy tapasztaltad te is, mikroakadásokat okozott.
(#56) morgyi: Brustol folyamatosan. Modernebb a hardver, így nem kell már fix órajelszintre dolgozni, hanem lehet race to idle modellt alkalmazni, hogy kevesebbet fogyasszon. Ez a normális, részben ezeknek köszönhető az, hogy annyival hatékonyabb 2D/multimédia terhelésnél egy mai rendszer. Alapvetően a race to idle modell a legjobb, ha a hatékonyságról van szó, mert egy lapka mindenképpen az idle szinten fogyaszt a legkevesebbet, tehát akkor spórolsz a legtöbbet, ha a legtöbbször van idle-ben, de nem idle órajelen, hanem olyan állapotban, amikor az ALU-k csak NOP-okat kapnak, vagyis effektíve malmoznak. Ha már valamit csinálnak, akkor még az órajel növelése nélkül is jelentőset ugrik a fogyasztás. Viszont a race to idle modell nem egyszerű, és emiatt nem mindenki foglalkozik vele. Kb. az ultramobil lapkák privilégiuma, mert ott azért minden apró milliwattocska számít.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
paprobert
senior tag
Köszönöm a részletes leírást. Ez így kerek és logikus első olvasatra.
Ha a szoftveres mérést pontatlannak tartjuk, én el tudom fogadni. Van viszont egy sokkal pontosabb indikátora pl. az idle fogyasztásnak. A hőmérséklet. Ez analóg, és egy adott időtartam alatt a kumulált fogyasztás megjelenik hőként egy passzív kártyánál.Azaz ha a race to idle valóban jobb PE nélkül, a hőmérsékletnek nem kéne nőnie. Ellenben sb kolléga is arról számol be, hogy a PE-vel egyébként passzív kártyájának hőmérséklete elkezd felfele kúszni, majd a tresholdot elérve be-be kapcsolja a ventillátort az új driverekkel.
Itt már nem lehet a mérés pontatlanságára hivatkozni, egyszerűen többet fogyaszt a cucc.
Én úgy vélem, hogy csak cél nélkül van készültségben a kártya, ami triggerelődik bármilyen apró terhelésre (pl. böngésző görgetés, ablak váltás), teljesen felesleges köröket futva, robbantva a teljesítményt a közel 0 feladatra, többet fogyasztva.[ Szerkesztve ]
640 KB mindenre elég. - Steve Jobs
-
sb
veterán
Ez a beszélgetés is lezajlott már, de akokr még egyszer.
Windows 10 Desktopon vagyok, egy TotalCMD ablakot húzok jobbról-balra.
Mit állítsak és hova, hogy NE 1100MHz-re boostoljon a GPU?Chill? Hány fps kell hozzá? 2D-ben.
Power limit? Mennyire ,15W? Nincs a skálán és talán nem is igazán válna be.Azt is hagyjuk, hogy ez nem okoz átlagfogyasztási különbséget.
Mint írtam kártya 60 fokra kúszik, PE-vel pedig 48 fok.Játék pedig nem futott a gépemen 2 éve. Desktop appok + Firefox böngészésre, utóbbiban van hw accel ami hajthatná a gpu-t... de érdekes módon PE mellett ott is elég a 300MHz mindenre.
@paprobert
Load helyett ott a hőfok. Ráadásul amit ítam, nálam játék nélkül. Ebbe k*va nehéz belemagyarázni, hogy vagy van terhelés ami igényli vagy ugyan nincs, de változatlan a fogyasztás és csak viccből melegebb.@Abu
Ez egy régóta ismert energiahatékonysági stratégia, csak nehéz olyan hardvert csinálni, amin megvalósítható, de a lényege annyi, hogy nem egy fix low power state-en megy a hardver, hanem brustol egy nagyot, gyorsan végez a feladattal, és visszatér a legalacsonyabb state-re.Ma ezek már nem problémák, egyik sem, ezért sokkal jobban megéri brustolni, megcsinálni a feladatot, majd idle-be állni, amíg jön a következő feladat. Többet nyersz vele a konnektorból felvett energia tekintetében, mintha beraknád a GPU-t egy állandó alacsonyabb state-re.
Látható, hogy nem működik. Ez elvben működik. Még cpu-k esetén is, pedig ott már régóta alkalmazzák. Ami miatt megy az inkább a terhelés alapú jó energiamenedzsment a cpu-knál. A burst technika ott is indokolatlanul nagy órajeleket eredményez, bár kimérni nehéz, de vélhetően átlagban is. Ami miatt a fogyasztáson nem látszik az az, hogy terheletlenül hiába magas az órajel/fesz, nem ugrik meg a fogyasztás.
Ezt gpu-nál nem látom. Egyértelműen magasabb az átlag órajel/fesz és itt megy vele a fogyasztás is. És hiába mondjuk rá, hogy milyen gyorsan kapcsolgat, az átlagot elrontja.
Ott a fogyasztás és a hőfok egyértelműen.[ Szerkesztve ]
-
-
válasz #32839680 #61 üzenetére
Kb. mintha egy kis étkű cingár gyerek nézné a feladatokat, de mindegy hogy fagajjat kell felvenni a földről vagy 500 kilós vasat, mindig Fekete Laci teleportál a hibernációjából emelni de előtte bedob egy kondér babfőzeléket mindig.
EZ de hülye, szakadok!
[ Szerkesztve ]
-
őstag
-
sb
veterán
válasz #32839680 #65 üzenetére
Én kézzel állítgatom de ez nem elvárható és nem is megoldás, mert a frekik sem állíthatóak szabadon.
Nálam most 300/1000 a 2D + PE On a régi driverben, így 300-on marad a gpu és a ramot ugráltatja le-fel. Játék nincs így nem kell feljebb állítanom sűrűn. Ill. a madvr-t is kilőttem, annak pl. nyilván nem volt elég ez az órajel, ott is lehetett volna kézzel szórakozni.Itt a példám, hwinfo, de nyilván a fizikai melegedésből továbbra is látszik, hogy ez valós probléma. Még mielőtt oda kanyarodnánk, hogy ez "csak" sw mérés és semmit nem ér.
GPU VRAM GPU power GPU temp VRM temp
1 300MHz 378MHz 8,5W 44 44,5
2 781MHz 918MHz 20W 62 58,5
3 514MHz 514MHz 12,5W 50 49,2Az 1-2. eset böngészés közbeni átlag PE On ill. Off állásban. 44 vs 62 fok lekapcsolt ventivel. Nem kell sokat magyarázni...
A fogyasztás is csak a gpu, mellette a vram-ot is sokkal jobban megküldi láthatóan, az ebben még benne sincs.
szerk: Sőt, még a PCIe-t is hajtja.
HWInfo szerint átlag 2.5GT/s - 7.7GT/s - 4.4 GT/s az átvitel.A 3. eset pedig egy idle képernyőn hagyott ph fórum oldal. Tehát a gép magára hagyva és semmi nem történik.
Így is vicces a különbség az 1. pont aktív böngészéséhez képest.[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Bonyolult, de leegyszerűsítve az a lényeg, hogy a Windows OS-nek van egy alapvető memóriakezelési és ütemezési modellje a GPU-kra. Ez elég sok komponensből áll, de összességében három sys fájl (dxgkrnl.sys, dxgmms1.sys, dxgmms2.sys) leírja, hogy miképp vannak kezelve a memóriaszegmensek, a DMA pufferek, a kiadott parancsok, maga a preempció, az eszközinterfész gyorsítása, az egyes memóriavezérléssel kapcsolatos funkciók, stb. És ez egy olyan kvázi sztenderd modell, amire a gyártók építik a GPU driver ütemezését. A hardver viszont ezalatt lehet, hogy másképp működik, tehát esetenként nem optimális a Windows sztenderd modellje, amit elsődlegesen a maximális kompatibilitás indokolt. Ez a Hardware-accelerated GPU scheduling lényegében annyi, hogy a gyártó rászabhatja az ütemezést a hardverre, és a GPU driver ütemezése sokkal szabadabb lehet. Az előny nyilvánvaló, hiszen a hardverhez közelibb modell jobb teljesítményt jelenthet, elméletben persze, a gyakorlat egyelőre ennek az ellenkezőjét tudja csak felmutatni. De lehet, hogy pár hónap múlva már jobb lesz az új modell, ezt egyelőre nem tudni.
Az elsődleges probléma persze az, hogy a Windows sztenderd modellje szénné van optimalizálva, tehát a legutolsó teljesítménymorzsa is ki van belőle szedve, így nagyon nehéz jelenleg gyorsabbnak lenni nála egy új modell kezdetleges drivereivel.[ 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 #32839680 #68 üzenetére
Leginkább semmi. Az főleg a swap chain változások miatt van.
Ettől a hw acc. ütemezéses témától tényleg kb. annyit lehet várni, hogy jobb lesz a minimum fps, de ne úgy képzeljétek el, hogy minden, amit mostantól megnyittok 10%-kal gyorsabb lesz, hanem szökőévente nyerhettek 3-4%-ot. Mert maga a program nem mindig fut ám limitekbe, és itt a limitek kezelése a lényeg. Tehát a gyorsulás is csak a limit kiütésénél jön. Meg a legtöbb mai program azért nyilvánvaló okokból nincs is rábökve a limitre. A jövőben ez azért módosulhat, tehát nem haszontalan fejlesztés ez, csak nem pont a mának készült.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Microsoft nem promózta, maximum az újságok, de az MS még csak meg sem említi ezt a fícsőrt az új frissítés listájában, de a WDDM 2.7 újításainak leírásában sincs benne.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Melyik újítás vagy konkrétan mi felelős ezért
[link]
you have ever used multi-monitor setups with differing refresh rates, say 144 Hz and 60 Hz, any window movement in the 60 Hz monitor meant that stuttering would be observed even in the 144 Hz display as well until the window movement is stopped. This is because the Desktop Window Manager (DWM) — the display compositing component of Windows — draws on both monitors together instead of individually compositing each display. Therefore, the monitor with the higher refresh rate gets pulled down to match the lower refresh rate monitor causing micro-stuttering and frame-skipping.Ez akkor most a dwm 2.7-el javításra került? Nálam egyébként nagyon hülyén viselkedik az UFO test, de be tudom annak hogy egyszerre használok intel igput meg 5600 xt-t, nem éppen problémamentesen, de ezt most nem részletezem.
Lényegében az ufo test egy 60 hz.-es másodlagos van és így fut rajta [link]Intelen. Az Amdn egy 75 Hz-es monitor van ami így fut [link]
(=mindkettőn 75 hz-et ír.)[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
A kompozitor folyamatosan javul az egyes Windows frissítésekkel. Nagyrészt ez felel ezekért.
A Youtube streamingnél a stutter pedig nagyrészt egy CPU-ból eredő probléma. Ha vesznek a userek sokmagos procikat, akkor az megszűnik. Külön ez volt a Ryzen 3950X selling pointja, hogy mostantól nem kell ezzel a problémával foglalkozni, mert van elég processzormag arra, hogy egy gép tudja magát a játékot és a streaminget biztosítani. Alternatív lehetőség a GPU fixfunkciós kódolóját használni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Kupszi
aktív tag
Második menet, 20.5.1 driver , kékhalál megint youtube videók alatt atimgpu.dll hibával. Mindig ugyanabba a szituba, és játékok alatt szintén. A 20.4.2 minden tökéletes. Tudom user error, de még soha nem volt problémám AMD driverrel.
Ez most a WDDM miatt lehet vagy mi egyéb?Pipapapa strikes back again! Avagy újabb tégla a falba!
Új hozzászólás Aktív témák
- Újabb Samsungok telepíthetik a Galaxy AI-t
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Mindent megtudtunk az új Nokia 3210-ről
- Kerékpárosok, bringások ide!
- Milyen billentyűzetet vegyek?
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- nVidia tulajok OFF topikja
- Vezetékes FÜLhallgatók
- Léghűtés topik
- Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
- További aktív témák...
- Hibátlan - PALIT GTX 1650 StormX 4GB GDDR5 VGA videókártya - tápcsatlakozó nélküli !!!
- XFX RX 6600 XT SPEEDSTER SWFT 210
- PCX Garancia! MSI RTX 3080 Ti 12GB GDDR6X Gaming X TRIO Videokártya! BeszámítOK
- ASUS ProArt GeForce RTX 4080 SUPER 16GB GDDR6X OC (ASUS-VC-PRO-RT4080S-O16G) Bontatlan új 3 év gar!
- Geforce GT 730 -4 gb videokártya
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen