Discussion in 'MSI AfterBurner Application Development Forum' started by Unwinder, Feb 20, 2017.
Unwinder has never officially supported notebooks.
However NVAPI is supported on 4.6.3 beta 2, so technically it's Nvidia responsibility now.
I posted that due to lack of information what error 22h is responsible for.
Of course it is issue of broken Afterburner. [Sarcasm mode off]
Technically it's still beta - everything could happen.
So - may I know what's this error responsible for?
If this is purely NV fault it might be worth posting some info for them, maybe they will add mobile support as well (if the drivers are lacking it at the moment).
Technically I do NOT work at NV to comment which platforms are fully supported in new API|, which platforms are planned to be supported in future and which ones are completely deprecated in new OC scanner. And it is not to wise to ask "is it broken in AB" if it fails to work via GFE as well.
Wow great work @Unwinder! This is a great update. Thanks!!
Hi, I just registered to report what seems to be a bug with the fan control on the newest beta 2 release, I've got a Palit RTX 3080 GamingPro which has the fan stop at idle function but if you try to use a curve in AB it won't let the fans turn off and has a minimum speed of 30%, also the fan control doesn't seem to work right - if I were to say, set it to 50% manually, the fans will actually spin at 35% and when following any kind of fan curve the fan speed seems to not follow the curve properly.
It's a fresh install of AB with latest Nvidia drivers, if there's any other info you'd like me to provide I'd be happy to help.
Lack of ability to "stop" fan manually is not a bug, you CANNOT set fan speed below BIOS defined minimum, it always worked this way.
> also the fan control doesn't seem to work right - if I were to say, set it to 50% manually, the fans will actually spin at 35%
Sounds like beta 1 is installed instead of beta 2.
Hi, as said I am using the latest beta 2 release (it has beta 2 written on the bottom left), I also mentioned this particular card does have a fan stop function which it does when not controlled by afterburner, so I'm unsure what you mean, Is this BIOS separate from the cards built-in fan controller?
In the other thread, being rude isn't exactly helpful, it's clear you didn't even read my initial message....
For the last time: fan stop is NOT supposed to work when manual fan speed is selected.
But it worked on my 1070ti, and 2070 super, why is it different for Ampere? There was no line forcing the fans to run at the minimum, fan stop worked in AB just fine.
Yes, I obviously do not read anything and have a fun wasting my single free weekend during the last weeks on being rude with Palit card onwers in non-official MSI AB soupport forum. Bye and welcome to my ignores list, search for someboody else to help you.
The only one in the wrong here is you, absolutely arrogant tosser, have fun getting more reports of the same problem because IT IS CLEARLY A BUG THAT YOU SHOULD FIX.
Talk this way somewhere outside this place. Bye.
Do you see constant writes toC:\ProgramData\NVIDIA Corporation\nvtopps\nvtopps.db3 with the new driver?
Periodic, not constant ones. I'm currently on 3090 based PC, the last write to nvtopps.log took place about a hour ago during system boot. I'd expect the writes there to be constant if it is contrsntly retrying/failing to initialize something.
It's reads that are constant for that bug, btw, if you were trying to dig on it. You can see the sawtooth pattern even in the OS I/O, and the numbers only add up for reads for the nvcontainer stuff.
My bad, Toyo is correct its a constant small reads thing, I guess nvidia forgot to keep the file contents in memory so its constantly reloading and parsing the contents from disk instead.
I forgot to document one more tiny but interesting feature of recently published 4.6.3 beta 2. GPU.dll monitoring plugin was upgraded and received 2 new performance counters: “GPU dedicated memory \ process” and “GPU shared memory \ process”, so you may give it a try. The counters are displaying local and non-local VRAM commits for foreground process, so you may use them to see how much VRAM is allocated by the game you’re currently playing and compare it with total system-wide VRAM usage. The counters were added to help you to compare apples to apples and oranges to oranges, because recently there was rather interesting post @ resetera (https://www.resetera.com/threads/vram-in-2020-2024-why-10gb-is-enough.280976/) dedicated to VRAM usage measurement. While it contains a few true statements, it also contains good porting of misunderstanding and false claims and in result it confuses readers even more. So the post claims that:
- Games use less VRAM than you see in GPU-Z, MSI AB, Precision, HwInfo etc. That’s correct statement. Games run in multitasking environment. Games do not own whole VRAM exclusively, it is shared between all running processes in the system. Even before you start your game, standard background applications of almost every modern PC like Steam, internet browsers, background video streaming/recording applications and even OS itself (e.g. DWM aka Desktop Windows Manager, OS component responsible for hardware accelerated desktop windows rendering) eat from few hundred megabytes to few gigabytes of VRAM. All that dedicated VRAM consumed by background processes also counts and displayed in total VRAM usage in tools mentioned above. Total dedicated VRAM minus VRAM consumed by all background processes form VRAM budget for a game, i.e. amount of VRAM the game can commit and use without causing VRAM evictions for other processes and degrading system performance. The budget is expected to be less (sometimes few gigabytes less) than total amount of VRAM installed on your graphics card.
- Misleading applications like GPU-Z, MSI AB, Precision, HwInfo display absolutely useless VRAM allocation value opposing to the only real usage reported by budget API and displayed by Special K. That’s false statement. First, there is no any “allocated VRAM” versus “real VRAM usage”. Real usage he is referencing is also nothing but exactly the same allocation, i.e VRAM commit but in context of single game process. Any form of VRAM usage monitoring (including the “real” one based on DXGI budget monitoring) is displaying you current amount of commited/allocated VRAM. DXGI budget monitoring API was added by Microsoft to help 3D application developers to avoid overcommiting VRAM. So it is just giving you your current VRAM commit limit (budget) and allows you to track how much you’ve already commited. While it is _extremely_ useful performance counter for a developer on game development stage, it doesn’t allow you to see whole system picture when your profile whole system performance, doesn’t allow you to see how much VRAM other applications commited, how much of this total commited VRAM is currently resident in local VRAM and how close to physical VRAM limit (and VRAM eviction related stuttering) we’re. So those are nothing but VRAM commits displayed on different (game/system) levels and both are useful.
New performance counters (“GPU dedicated memory \ process” and “GPU shared memory \ process” exported by GPU.dll plugin) just allow you to see this “real usage” (application specific VRAM commit in reality). But instead of using in-process DXGI budget API it uses more low-level and advanced D3DKMT API, which allows to peek into process specific D3D performance counters from different processes. Due to that reason new “GPU dedicated memory \ process” and “GPU shared memory \ process” are currently not supported for EAC/BattleEye protected games (as they require opening game process from external application, such request won't work for EAC/BE protected games). Here is the example of using new performance counters in MSFS 2020:
The first one in RTSS “Mem” line, 5290MB, is a total amount of VRAM commited by display driver + all running processes and residing in local videomemory. It is MSI AB’s built in “Memory usage” performance counter taking data from NVAPI on NVIDIA GPU (on AMD GPUs native VRAM monitoring is not exposed by their API so it is read via D3DKMT by MSI AB and matches with the second performance counter). The second one in RTSS “Mem” line, 5125MB, is total amount of VRAM commited by all running processes and residing in local videomemory. Unlike the first one, it doesn’t include internal display driver’s VRAM allocations. So it is expected to be a couple hundred megabytes lower. It is reported by “GPU dedicated memory usage” counter exported by GPU.dll plugin and comes from D3DKMT. The third one, 3446MB, is VRAM commited by foreground process (i.e. MSFS 2020 game). It comes from "GPU dedicated memory usage \ process" counter exporeted by GPU.dll plugin and duplicates GPU budget usage, displayed by MSFS developer overlay.
Really? i thought that's why processes had seperate Dedicated, System and Committed bytes in tools such as process explorer.
I see that the new counters expose the first and second but not the last.
Also just to note, given where these process reporters come from, they have the same 4GB wrap around as the existing reporters when run on less than W8.