Új hozzászólás Aktív témák
-
Pug
veterán
Es vajon ebben sikerult azt javitani, hogy az early GCN verziokon (pl 290X) ne csak 30Hz legyen a max frissites 4K TV eseten....
Gyanitom nem.... csak tobb, mint fel eve issue...
-
siposz
aktív tag
Érdemes ezeket felrakni, ha amúgy nincs problémája az embernek? Ez lenne az első radeonos frissítésem, de elég sok parát olvastam róla. És hát szívtam meg nvidia frissítést is.
-
Cyberboy42
senior tag
-
Ennek mi értelme volt 2 nappal a 2004 kiadása előtt? Oda is kell majd egy WHQL és nagyon gyorsan!
-
Kansas
addikt
A HDMI 1.4 ami azokon a kártyákon van, nem tud többet, csak 30Hz-et 4K esetén, és gondolom a TV-n nincs DisplayPort csati... szóval nem értem, ez mitől lenne bug...
4K@60Hz-hez HDMI 2.0 kell, ami RX4xx-től van a Radeonokon...
Esetleg próbálkozz chroma subsampling-et beállítani, azzal elvileg mehet... vagy egy DisplayPort-HDMI2.0 konvertert.[ Szerkesztve ]
Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.
-
Kansas
addikt
Nem mintha az AMD, az NVidia vagy akár a board partnerek(ASUS, MSI, Sapphire, stb) megkönnyítenék a helyzetet, és könnyen elérhető helyen írnák a kártyák által támogatott HDMI és DP verziókat... mondjuk a spec. sheeten... szégyelljék magukat mind
[ Szerkesztve ]
Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.
-
Pug
veterán
DP-HDMI 2.0 converter-t használok a kezdetektől...
Konkrétan a 2020-as Adrenalin-nal baszarintotta el az AMD, a 19.9.2-es az utolsó driver amivel megy a 4K@60hz... (most is még mindig azt használom) szóval nem hogy bug, hanem eléggé nagy elbaszarintás. Nem kell mindig fanboy-ként védeni egy gyártót... (egyiket sem, nem csak az AMD-t)... Az még nagyobb blama, hogy nem elsőre pacsálják el (lásd vastagon szedett rész alant) és hogy most 6 hónap alatt sem sikerült megoldaniuk....
Adrenalin 2020 - Can't output 4k@60hz
"You may be asking, how does this guy know so much about this? Well, AMD has done this now a record total of 3 times in driver releases over the last few years. Their record to fix it was 17 releases later - yes, 2 years of time to fix a display resolution bug."
"I've been having the same issue as well, anything beyond 19.9.2 prevents utilizing TV's as monitors that are utilizing an display port to HDMI adapter that allows 4k 60hz over HDMI on a 1.4 output. AMD won't do crap to fix this, I've reported countless errors to them and they simply ignore them for YEARS. Looks like I have to switch back to a monitor."
"19.9.2 seems to be the only stable driver for GCN era cards right now. You can use this custom res fix to correct the bugs brought by the later drivers but, for me at least, it leads to certain games having problems."
Csendben maradtál volna, akkor biza okosabb is... kereken 20 éve az IT az elsődleges hobbim... szerinted nem jártam utána...
[ Szerkesztve ]
-
Kansas
addikt
Te meg megtanulhattál volna érthetően posztolni a 20 év alatt...
Ezek szerint nem a 290X 1.4-es HDMI portján nem tudod kiküldeni a 4K@60Hz-t, hanem a DP-HDMI átalakítón... az nem ugyanaz azért... az 1.4-es HDMI-n mindegy milyen verziójú a drivered, nem fog kimenni subsampling nélkül a 4K@60Hz.
Abból, amit írtál, nem derül ki, hogy nem azt kérted számon...
Gyanús is volt, nem mai csirke vagy errefelé, kinéztem belőled hogy tudod a Guglit működtetni...[ Szerkesztve ]
Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.
-
Pug
veterán
Alapvető logika megy? Miért kérnék számon egy olyan funkciót a kártyán, amit nem tud..
Az hogy te mit feltételezel (mondom, alapvető logika) és osztod az alapján magas lóról az észt, nah az hadd legyen már ne az én problémám...Vártam már, hogy mikor jön egy "it's not a bug, it's a feature" szintű meglátás. Mondjuk nem tőled vártam és főleg nem, hogy még az illető komolyan is gondolja...
Azért van egy olyan sanda gyanúm, hogy nem átalakítónként profiloznak, hanem mondjuk lapkákként... feltéve, ha van egy kis esze az adott Process Owner-nek az AMD-nél
Az feltűnt, hogy low prio a dolog, mondom, 6 hónap alatt nem sikerült megoldani (és ugye volt amikor 17 release kellett hozzá, kb 2 év, szóval én a 6 hónapommal kussolhatok, tudom.... nem bug, hanem feature... )
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
A DP-HDMI 2.0a konverzió mindig ilyen lesz. Arra kell egy külön kijelzőkezelés a driverbe, ami gyakorlatilag felismeri, hogy a DP portra egy átalakító van kötve, és a benne található aktív lapka alapján kezeli azt. Na most, ha a drivernek módosul a kijelzőkezelése, akkor per átalakító szintjén kell újraírni az egészet. Ezért volt az, hogy az egyes driverekben elmegy a támogatás, majd később visszajön. Tehát ez nem olyan, hogy írni kell rá egy általános támogatást, hanem venni kell az összes fellelhető átalakítót, mindegyikre külön kód, külön tesztelés, stb. És ezt annyiszor kell eljátszani, ahányszor módosítás éri a driver display részét, ami azért évente kétszer-háromszor megtörténik. Nem vagyok benne biztos, hogy ez jelenleg túl nagy prioritást élvez, mert bármit is írnak rá, a támogatás úgyis megszűnik megint a nyáron, amikor jön az új csomag. És akkor arra megint kezdődik az elejétől a munka. Szóval itt ez nem bug, hanem magát a támogatást kell visszaépíteni, csak ez maximum pár hónapig tart ki, és utána minden kezdődik az elejéről.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Kansas
addikt
Alapvető logika nekem megy, a fórumtársaktól már megtanultam, hogy nem várhatom el(lásd pl. "AM4 will be supported through 2020" != "az összes chipset támogat majd minden 2020 végéig megjelenő AM4 procit").
Én nem feltételezek semmit(már), abból indulok ki, amit írtál. A DP-HDMI átalakító nem szériatartozéka egyik kártyának sem, tehát nem feltételezem alapból, hogy használatban van.
Ebből pedig az következik amit írtam.
Az hogy te nem tudsz rövid hibaleírást adni, a te bajod, arra fogsz választ kapni, amit írsz, nem arra, amit gondolsz.[ Szerkesztve ]
Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.
-
Pug
veterán
Mondom logika, jobb szakokon még mindig tanítják
Mivel a HDMI 1.4 nem támogat 4K@60hz-et, az említett kártyán csak a DP kimenet támogatja ezt... így eléggé evidens, hogy melyik kimeneten kérem számon ennek hiányát, nope? Nah vajon melyikén, amelyik támogatja per specification, vagy azon, amelyik nem?
És még mindig azt állítod, hogy neked megy a dedukció?Not really...
További szép napot!
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Ha hiányzik maga a profilozás, az nem bug, hanem konkrétan a funkció nincs benne a driverben.
Sajnos nem elég lapkánként profilozni. Régen úgy volt, de sok kompatibilitási problémához vezetett. Azóta per átalakító alapon megy. Ez a DP-HDMI2.0 történet sehogy sem lesz jó már. Kb. azt várják, hogy mindenki váltson valami HDMI 2.0-s hardverre, és akkor le is lehet szállni erről a dologról. Elképzelhető, hogy a nem túl gyors frissítés is egy kényszerítés, lassan a userek megunják a szopást. Abban egyetértek, hogy ez nem túl szép megoldás, elvégre amikor kijöttek a DP-HDMI2.0-s átalakítók, akkor rárepültek ám a gyártók a lehetőségre. Persze lehet, hogy nem gondoltak arra, hogy mekkora szopás lesz velük, de ez az ő bajuk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Pug
veterán
"Ez a DP-HDMI2.0 történet sehogy sem lesz jó már. Kb. azt várják, hogy mindenki váltson valami HDMI 2.0-s hardverre, és akkor le is lehet szállni erről a dologról. Elképzelhető, hogy a nem túl gyors frissítés is egy kényszerítés, lassan a userek megunják a szopást."
Yepp, ezt pontosan így látom én is.Abban viszont nem fogunk egyet érteni, hogy ha van egy funkcióm, amit a korábbi driver verzióban támogatok, majd a következő release-zel már nem, de semmilyen changelog-ban nem szerepel annak a kikerülése, akor az ne lenne inkább bug&issue, mint support elhagyás...
-
Abu85
HÁZIGAZDA
Itt ki akarják kerülni azt, hogy egy korábban bevállalat, de azóta gigaszopatóssá vált fícsőrt hivatalosan kivegyenek. Ergo jobb az, ha a user bugnak hiszi, mintha visszatáncolásnak. Ettől viszont nem bug, hanem xy driverben nincs benne a funkció. Az egész ott előny nekik, hogy egy bug nem kap sajtónyilvánosságot, míg ha leírnák, hogy a funkció hiányzik, akkor azt megírnák sokan. Tehát az, hogy sokan bugnak hiszik, az csak előny számukra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Kansas
addikt
"Es vajon ebben sikerult azt javitani, hogy az early GCN verziokon (pl 290X) ne csak 30Hz legyen a max frissites 4K TV eseten...."
Ezt írtad.
Ennek alapján már a HDMI kapcsolat is feltételezés, de annak legalább alapja van. Innentől kezdve bocs de nem ugrok tovább még egy lépcsővel, mert akkor már gondolhattál DVI-HDMI kábelre is(én pl. azt használtam PC-TV viszonylatban, igaz, csak FHD-ra), vagy lehetne közte streaming deck, stb. stb.
Ha simán benéztem volna, azt nem lenne gond elismerni, de nem arról van szó. Szarul tetted fel a kérdést(abban sem vagyok biztos, hogy nem fikázó költői kérdésnek szántad), aztán amikor valaki válaszol, akkor meg belekötsz, hogy nem arra gondoltál.
Korrekten az úgy szólt volna, hogy "Köszi, de kifelejtettem azt, hogy DP-HDMI átalakítón keresztül megy a kapcsolat ..." Ehelyett nekiállsz személyeskedni...
Hát válaszoljon neked innentől a rézfaszú bagoly...[ Szerkesztve ]
Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.
-
-
-
-
Kansas
addikt
Én azt olvastam, hogy kézzel kell bekapcsolni...
[ Szerkesztve ]
Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.
-
-
Kupszi
aktív tag
Meg is jött a várva várt 20.5.1 driver beta [link]
Pipapapa strikes back again! Avagy újabb tégla a falba!
-
válasz #32839680 #36 üzenetére
Itt se.
Nvidiásoknak sem jobb:
If a user toggles on the Hardware-accelerated GPU Scheduling setting, the NVIDIA display driver will accept the users request however this feature is not officially supported with NVIDIA display driver 450.99. Official support will come with an upcoming Game Ready Driver update.
-
Abu85
HÁZIGAZDA
Nem jön vissza. Az csak arra kellett, hogy a PCI Express voltage spike-okat kezeljék bizonyos VGA-kon, de ezt megoldották egy másik módon, úgy hogy attól teljesítményt sem veszít a hardver, és megszűnnek a frame spike-ok, amiket a power efficiency beállítás okozott.
A hűtést más módon érdemes szabályozni, erre ott a Wattman, ott bármit be lehet állítani.
A többieknek: A Hardware-accelerated GPU scheduling nem igazán működik még a terveknek megfelelően. A gyártói implementációk pont fordított hatást érnek el, mint amire ez a fícsőr készült. Tehát effektíve, ha bekapcsolják, akkor sokszor rosszabb lesz az eredmény. Ezért nem nagyon törekednek még az aktiválásra. Általában onnantól javul a helyzet, ha 12+ magos processzora van a usernek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
paprobert
senior tag
Ez a beszélgetés pár hónapja lezajlott már.
Power efficency nélkül 2 dolog történik:
-duplájára nő a GPU idle fogyasztás
-Az órajel nem tud dinamikusan lefele váltani framerate cap esetén sem, ergo az órajelhez társított feszültség is fixen magas marad bármekkora 3D terhelés esetén.
Pusztán a multiprocesszorok load csökkenése pedig köszönő viszonyban sincs azzal a fogyasztási karakterisztkával, ami Power efficiency mellett tapasztalható volt.Én elhiszem hogy ez jó volt arra is hogy pár hibás kártya specen belül maradjon, de mindenki másnak ezzel megölték a normális energiagazdálkodást.
640 KB mindenre elég. - Steve Jobs
-
Abu85
HÁZIGAZDA
válasz paprobert #42 üzenetére
Ezekre mind kínál megoldást a Wattman. Vagy a Chill, vagy a Power Limit által. Per alkalmazás szinten lehet ezt szabályozni, és még a power efficiency nagy problémáját, a frame spike-okat sem kapod meg.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz paprobert #44 üzenetére
Olyan órajelskálázást az AMD PC-s hardverei nem is támogatnak. A PS5 lesz ilyen, de nem ez lesz az RDNA2 PC-s verzióiban sem, mert limitált órajelek beállítását engedi csak.
Amiket említettem egyébként pont arra tervezték, amiket felsoroltál problémaként.
A Power Limitet arra, hogy legyen egy kisebb limit, ha a default nem elég jó neked.
A Chillt pedig arra, hogy megszabj egy minimum sebességet, amit tart a hardver, ha nem mozogsz, de maximum sebességnél is hatékonyabban működik. [link] - ebben a tesztben láthatsz két videót a rendszer fogyasztásáról, miközben a képernyőn ugyanazt látod.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
paprobert
senior tag
Na ne már, akkor hazudik a hardver magáról a régi driverekkel?
Konkrétan ki lehet mérni a különbséget.Példa: közepesen terhelő játék, limitált képkockaszám mellett mindkét esetben:
Power efficiency-vel 60W, 990 Mhz, 0.97V, a load mindig közel 100%
Power efficency nélkül 85W, 1310MHz, 1.110V, a load sosem 100%PE. nélkül CSAK a kártya csúcsértékei érvényesülnek, míg PE on mellett tudja a hardver hogy mikor lehet visszavenni.
[ Szerkesztve ]
640 KB mindenre elég. - Steve Jobs
-
Abu85
HÁZIGAZDA
válasz paprobert #46 üzenetére
Power efficency egy dologra való az egyes hardvereken, amikre ugye engedélyezve volt. A PCI Express feszültség spike-okat csökkenti. De erre az új driver óta nincs szükség, mert talált az AMD egy olyan módszert, aminél ugyanezt a hatást elérik, miközben nem csökken a hardver teljesítménye, és nem kapsz játék közben mikroakadásokat az órajeltüskéktől sem. Amiket te szeretnél elérni, azokra sosem a power efficency volt a megoldás, hanem a Power Limit és a Chill. Elsődlegesen azért, mert a power efficency kapcsolónál mindkettő nagyságrendekkel hatékonyabb.
A Chillel pedig úgy ráveszt a 60 wattra, hogy öröm lesz majd nézni. A mi videónkban konkrétan feleztük a fogyasztást, miközben ugyanazt láttuk a kijelzőn.
Power efficiency mellett a hardver eleve nem mehet el a végsőkig. Azért csökken a fogyasztás, mert elkezdi vadul dobálni az órajeleket akár 600 MHz-es léptékekben, 10 ezredmásodperces váltásokkal. Ennek a hátránya, hogy iszonyatos mikroakadást eredményez, mert az egyik képkocka 1 GHz-en készül, míg a következő 0,5 GHz-en, majd megint 1 GHz-en. A Chill pont arra van, hogy ennél sokkal jobb hatást elérjen, miközben a képkockák számítása lényegesen egyenletesebb marad.
A loadot pedig halál felesleges nézni, mert ha valamire 100%-ot ír a program, akkor az ordas nagy bullshit. Az AMD saját bináris tesztprogramjai nem terhelik 100%-ra a GPU-t. Egy játéknál a Strange Brigade kb. 60%-os terhelés, és ez messze jobb minden más játék terhelési szintjénél.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
paprobert
senior tag
Szerkesztettem az előző kommentemet.
A Power Limit egy globális TDP limiter, a csúcsfogyasztást fogja vissza, és legtöbbször teljesítményvesztéssel jár. Nem terhelés alapú.
A Chill pedig tudjuk, input alapú képkockacsökkentés-növelés, frame pacinggel. Nem terhelés alapú órajelskálázás.Szerk.: Igen, az a 100% az az aktuális órajel melletti számítási teljesítményt tükrözi.
[ Szerkesztve ]
640 KB mindenre elég. - Steve Jobs
-
Kansas
addikt
válasz paprobert #46 üzenetére
Ezt én nem értem... egyikőtök azt mondja, nem működik az energiagazdálkodás egy konkrét setting nélkül, a másikótok azt, hogy úgy nem is kéne működnie... én meg azt látom, hogy nálam működik... még az a régi "feature" is javításra került, ami többmonitoros setup esetén max órajelen járatta a VRAM-ot.
(tudom, hogy nem ez a fő monitoring felület, de itt látni a legkisebb helyre összeszedve az infókat)Most akkor nem egyről beszélünk?
[ Szerkesztve ]
Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.
-
paprobert
senior tag
Egy dolgot nem értek akkor... Minek vannak lower state-ek a koppra járatott órajel+feszültség páros mellett, ha soha nem lesznek használva?
A Power Efficiency pont ezekre támaszkodott. A kecske is jóllakott full loadnál, a káposzta is megmaradt közepes loadnál. És igen, mellékhatásként néhány címben a stuttering jelen volt, nem sok vizet zavarva.
640 KB mindenre elég. - Steve Jobs
-
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
- Milyen egeret válasszak?
- Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
- Házimozi belépő szinten
- Spyra: akkus, nagynyomású, automata vízipuska
- nVidia tulajok OFF topikja
- Poco X6 Pro - ötös alá
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Steam, GOG, Epic Store, Humble Store, Xbox PC Game Pass, Origin Access, uPlay+, Apple Arcade felhasználók barátságos izgulós topikja
- BestBuy topik
- Gaming notebook topik
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen