MSI AB / RTSS development news thread

Of course it is issue of broken Afterburner. [Sarcasm mode off]

 

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.

 

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.

 

For the last time: fan stop is NOT supposed to work when manual fan speed is selected.

 

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.

 

Talk this way somewhere outside this place. Bye.

 

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.

 

All

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.