Discussion in 'MSI AfterBurner Application Development Forum' started by Unwinder, Feb 20, 2017.
I cannot guess without seeing the game.
Tried turning FG on/off and yes, with RTSS active you get this error.
Quitting RTSS, toggling the option and launching it again seem to work fine though.
Not a big loss honestly b/c despite what some people are saying FSR FG remains completely broken and useless here just as in the previous titles.
Like you get better perceived motion fluidity with FSR3 Native without FG than with it.
Turn on frame generation without RTSS.
After that, restart game, turn on RTSS and set FPS.
Do not turn off FG option afterwards or you will have the same message.
It works that way.
Abysmal implementation of frame generation by AMD, be aware. If you go even 1 fps below your desired lock, it will stutter like mad.
I planned to publish RTSS 7.3.5 beta 6 early in December, but decided to delay new beta launch a bit. The reason of delay is my new hardware, which I just received. I've just installed new 240Hz GSync-compatible display so I'm analysing if I can add something specific to it and VRR in general to this beta. I've already added simple dynamic refresh rate counters to OverlayEditor's internal HAL, so you can use them to determine if GSync is active. Dynamic refresh rate monitoring in OverlayEditor's internal HAL is VBlank counting based and currently it is supported for displays connected to NVIDIA GPUs only, because neither AMD nor Intel GPUs provide similar VBlank counting functionality inside their APIs.
Cool new feature! Does this plot every single vblank, i.e. the "display frame time graph" wouldn't smooth out/average any outliers?
Nope, it won't plot every single vblank. NVIDIA provides access to driver's internal per-display VBlank counters, which are monotonically increasing per every single VBlank event. So using it you can periodically sample VBlank counters and monitor how many frames were scanned by associated display during this sampling period, but you cannot extract per-VBlank timings from it.
Decided to add new layout for OverlayEditor called VRR.ovl. I used pixelated fonts on purpose to simulate look of monitor's own "FPS counter", the layout will display both monitor's dynamic refresh rate and 3D application's framerate. You can use it to check if GSync is currently active (refresh rate will dynamically follow framerate in this case if you're inside VRR range). You can also use it to detect LFC range.
One more tiny but useful GUI enhancement. Those who used scanline sync in multimonitor environment know, that scanline sync is configured to synchronize with the very first display device by default, so for such systems you needed to configure target display device for scanline sync via configuration file and SyncDisplay field. Now there will context menu when you right click scanline sync field, allowing you to select target display device there.
Also to simplify setup of hybrid scanline sync, similar context menu will be added to framerate limtier edit field. You'll be able to use it to set framerate limit to exact refresh rate of each connected display. Previously you could also do it by holding <Alt> and clicking framerate limiter edit field (in this case the limit is set to exact refresh rate of monitor displaying RTSS window).
And one more new tiny but useful GUI feature. Now framerate limiter's context menu can be used to select VRR cap limit for each display. VRR cap is calculated as 95% of real refresh rate, for 60Hz it is RR-3 FPS limit.
Any ETA for Beta 6? Really looking forward to that DLSS3 Limiter.
Will refresh rate be available as an OSD monitoring item in AB later (for NV GPUs) or will it be for custom overlays only?
Yeah they do and honestly why do you even bother with reddit?
I understand wanting to shoot down misinformation but let these "experts" handle things on their own and focus on what's meaningful for you.
I plan to release it this month, till the end of 2023.
No plans to add it to AB too, sorry.
I'm currently preparing beta 6 to release and working on documenting the changes. Changes list may change a bit if I forgot to document something at this stage, but currently it contains the following:
- Improved hypertext format:
o Added new rendering style for embedded graph objects - bar range graphs. New style is the subset of previously existing barchart, but it is aimed to visualize the range instead of a single value. Please take a note that bar range graphs cannot be attached to arbitrary data sources, it requires specifically encoded data sources containing both min and max range limits packed inside each data sample. Currently NVIDIA reflex timespan data sources group (see below) are the only ones using such packed data format, compatible with bar range graphs.
- Added new framerate limiting mode : NVIDIA Reflex mode. In this mode RivaTuner Statistics Server completely disables its own precise framepacing implementation and uses NVIDIA's own framerate limiter instead. This mode is mainly intended to be used in conjunction with DLSS Frame Generation, which is generally not compatible with any third party framerate limiters. However you can also use this mode in the games with no native NVIDIA Reflex support, because enabling NVIDIA Reflex framerate limiter in such titles will also enable Reflex low-latency mode as a side effect. Please take a note that NVIDIA Reflex framerate limiting mode is currently supported on NVIDIA GPUs and in Direct3D11/Direct3D12 applications only. If you try to enable it on unsupported hardware on in unsupported applications, RivaTuner Statistics Server will fall back to default async framerate limiting mode.
- Added NVIDIA Reflex latency markers monitoring for Direct3D11/Direct3D12 applications with native NVIDIA Reflex support. Reflex latency markers are embedded into the games as a part of NVIDIA Reflex technology integration process. The markers are allowing game developers and NVIDIA Reflex software infrastructure to track precise timings of different stages of rendering pipeline and estimate the effect of enabling Reflex low-laterncy mode. Now such markers can be also analyzed via RivaTuner Statistics Server. Furthermore, RivaTuner Statistics Server also exports raw NVIDIA Reflex latency markers as is via shared memory to third party client applications (e.g. HwInfo, AIDA64 or CapFrameX), so such applications also get easy access to Reflex latency markers and can visualize them or calculate additional statistics based on raw markers.
- Added NVIDIA Reflex latency markers injection for Direct3D11/Direct3D12 applications with no NVIDIA Reflex support. Please take a note that injected simulation related latency markers can be inaccurate if the game is not starting simulating world in render thread immediately after presenting the previous frame.
- Added ID3D11DeviceContext::ClearRenderTargetView hook for render submission start related NVIDIA Reflex laterncy markers injection in Direct3D11 applications.
- ID3D12CommanQueue::ExecuteCommandLists hook is now always active and used for render submission start related NVIDIA Reflex laterncy markers injection in Direct3D12 applications. Now this hook forcibly uses Detours injection mode to improve concurrent command queue hooking reliability.
- A few improvements in delayed injection implementation, aimed to minmize cases when delayed injection needs to wait for keyboard or mouse input event to be triggered:
o Now delayed injection events are excluded from filtering by minimum allowed reinjection interval
o Now delayed injection events are invoked by dummy window creation instead of posting dummy system message
o Added EOSSDK-Win64-Shipping.dll to the list of delayed injection trigger modules to enable delayed injection for the games compiled with Epic SDK, but using delayed loading of Epic overlay hook module
o Improved IgnoreDXGIInterop profile entry functionality. Previously this entry was used to ignore interoperability DXGI flips in OpenGL/Vulkan presentation environment, now it can be set to 2 to achieve opposite effect: ignore OpenGL/Vulkan presentation and favor DXGI instead. Such mode can be used if you prefer to use Direct3D overlay rendering implementation in native OpenGL/Vulkan applications using OpenGL/Vulkan<->DXGI interoperability. Currently RivaTuner Statistics Server enables such mode via application profile for NvRemixBridge.exe only to address native Vulkan renderer's incompatibility with NVIDIA's Vulkan Frame Generation implementation in Portal Prelude RTX
o Slightly optimized the process of ignoring interoperability DXGI flips in OpenGL/Vulkan presentation environment. Previously DXGI flips were ignored after rendering the first overlay frame on interop DXGI swapchain, now Direct3D overlay renderer is not initialized in such environment at all
o Added late initialization of bootstrapped objects aimed to improve Vulkan hooking reliability in the applications dynamically loading vulkan-1.dll (e.g. Ryujinx or Rage 2) on the systems with multiple installed third party Vulkan layers
- Improved OverlayEditor.dll plugin:
o Now you can use the layer's refresh period setting to slow down layer updates. Initially this setting was intended for speeding up layer updates only, when you were rendering timer driven sprite animations there
o Added "NVIDIA Reflex XXX timespan" and "NVIDIA Reflex XXX latency" groups of data sources, based on NVIDIA Reflex latency markers. Timespan sources contain packed ranges for independent stages of rendering pipeline, normalized relatively to the rest stages. Latency sources contain absolute times of each stage. All new sources are internal, which means that they are always available and you don't need to add them to data sources list prior to referencing them to your overlay layouts. Please take a note that timespan sources contain specifically packed ranges, which are designed to be used with new bar range graphs.
o Added Reflex.ovl overlay layout. This layout demonstrates the usage of "NVIDIA Reflex XXX timespan" and "NVIDIA Reflex XXX latency" groups of data sources and new bar range styled graphs to visualize NVIDIA Reflex latencies in debugger-styled color timebands form.
o Improved bundled PresentMonDataProvider.exe application. Now it supports streaming PresentMon's data from any foreground application instead of relying on RivaTuner Statistics Server's 3D application detection engine.
This mode can be used to get PresentMon's statistics for applications, which restrict third party hooks (e.g. BF 2042, FIFA 23, CS2 or Destiny 2) and cannot be detected by RivaTuner Statistics Server as a 3D process due to hooking restriction. You may add PM_ProcessId environment variable and set it to 1 in your overly layout to enable such foreground application based PresentMon data collection mode.
o Added FrameratePresented and FramerateDisplayed data source to PresentMon data provides. These data sources cam be used as PresentMon based alternative to native framerate counter, when it is not available.
o Added new presentmon_foreground.ovl overlay layout. This layout demonstates new foreground application based PresentMon data collection mode. You may use this layout to display PresentMon's framerate and
frametime in applications like BF 2042, FIFA 23, CS2 or Destiny 2, which do not support RivaTuner Statistics Server's native hook based framerate / frametime monitoring.
o Improved data source statistics access functionality. Previously you could access each data source's statistics via local xmin/xavg/xmax/xswa variables only and such variables couldn't be accessed from other data sources. Such local statistics variables are deprecated since this version, now you can use more robust functions for accessing each data source's statistics:
+ New statmin, statavg, statmax and statstd functions can be used to get global min/avg/max/std statistics for each data source and you can access it from other sources, e.g. you may use statavg("CPU power") + statavg("GPU1 power"))
to calculate average CPU+GPU power consumption. Global statistics is collected during whole OverlayEditor's runtime session for synchronically polled sources only, for frametime and PresentMon's data sources it reflects the last 1024 samples only
+ New swmin, swavg, swmax and swstd functions can be used to get sliding window based min/avg/max/std statistics for each data source, for example you may use swavg("CPU power", 8) to smooth CPU power consumption graph by calculating average CPU power with sliding window by 8 last sampled CPU power values. Maximum sliding window size is limited by each data source's ring buffer size, it is 512 samples for the most of OverlayEditor's data sources and 1024 for internal frametime and PresentMon's data sources. You may specify sliding window size as 0 to use whole ring buffer
+ New percentile and percentilei functions can be used to calculate classic (linear) and integral percentiles on ring buffer contents, so you can use it to calculate 1%/0.1% low framerates on PresentMon's data or add you own percentile based metrics. New presentmon_foreground.ovl demonstrates new functions usage to display 1%/0.1% low framerates
o Added new hardware VBlank counter based data sources to internal HAL. New data sources provide dynamic refresh rate monitoring functionality for displays connected to NVIDIA GPUs.
o Added new VRR.ovl overlay layout. This layout simulates pixelated look of display's native refresh rate counter and displays it next to application's framerate. You can use it to monitor GSync activity status, analyze LFC behavior specifics of your display etc.
o Fixed plugin crash on attempt to edit data sources referencing variables overridable via environment (cpuvendor, gpuvendor and cpucores).
o Fixed instances enumeration for some performance counters with no localized names in Windows performance counter data provider (e.g. GPU related Windows performance counters).
- Improved framerate limiter customization:
o Default passive waiting threshold has been decreased from 90% to 70%
o Minimum active waiting time limit is no longer hardcoded, it can be customized by power users via profile now
o Added alternate high resolution waitable timer implementation for Windows 10 1803 and later
o Added experimental interleaved passive waiting implementation. In this mode passive waiting can be performed on each N-th frame instead of every frame to tune balance between precision and power consumtion
o Now you may right click framerate limit edit field to display the context menu. The menu allows you to select precise refresh rates of each connected display (so ypu can use it to simplify the process of setting up hybrid scanline sync mode) or select VRR cap calculated as 95% of each connected display's refresh rate. Please take a note that the previous alternate way of setting framerate limiter to precise refresh rate of desired display is still supported too. You may hold <Alt> and click framerate limit edit field to set it to refresh rate of display showing RivaTuner Statistics Server's window
o Added experimental preemptive waiting implementation. Power users may use it in hybrid scanline sync mode in conjunction with front edge sync framerate limiting mode to shift balance between front edge sync (favors tearline stability) and back edge sync (favors latency) mode
- Improved scanline sync customization:
o Now specified framerate limit is automatically multiplied or divided by 2 if you select scanline sync 2x ot x/2 modes when hybrid mode is enabled. So it is no longer necessary to specify double or half refresh rate value as a framerate limit manually for such usage scenario
o Now you may right click scanline sync edit field to display the context menu. The menu allows you to select target display device for scanline synchronization in multimonitor environment. It is no longer necessary to specify it manually via SyncDisplay profile entry
- Fixed issue in RTSS desktop video capture module, which caused some cursor shapes to be captured improperly (e.g. ][ cursor displayed when hovering over edit boxes).
- Various GUI fixes and improvements:
o Height of application profile names in application profiles list is now scaled properly when you adjust skin scaling
o Now RivaTuner Statistics Server reinitializes skin scaling engine on DPI change events to prevent cases when GUI looks cut off in some cases (e.e. after switching between display resolutions with different DPI scaling settings)
- Added On-Screen Display profiles for OpenGL renderers of some console emulators to select framebuffer as On-Screen Display coordinate space
- Updated On-Screen Display profile for Prepar3D v5 to remove WPF runtime modules from injection ignore triggers for this application
- Updated built-in profiles list
Pay attention to the following item in changes list:
- Added NVIDIA Reflex latency markers monitoring for Direct3D11/Direct3D12 applications with native NVIDIA Reflex support. Reflex latency markers are embedded into the games as a part of NVIDIA Reflex technology integration process. The markers are allowing game developers and NVIDIA Reflex software infrastructure to track precise timings of different stages of rendering pipeline and estimate the effect of enabling Reflex low-laterncy mode. Now such markers can be also analyzed via RivaTuner Statistics Server. Furthermore, RivaTuner Statistics Server also exports raw NVIDIA Reflex latency markers as is via shared memory to third party client
applications (e.g. HwInfo, AIDA64 or CapFrameX), so such applications also get easy access to Reflex latency markers and can visualize them or calculate additional statistics based on raw markers.
With upcoming beta you can read raw Reflex latency markers (absolute timestamps of each stage of rendering pipeline tracked by Reflex, e.g. timestamps for start and end of simulation stage) directly from RTSS shared memory, which you already access. So something similar to OverlayEditor's NVIDIA Reflex latency analyzer timebands demonstrated in the following video can be also easily integrated in CapFrameX/HwInfo if you find it useful:
After releasing RTSS 7.3.5 beta 6 we'll also shortly update MSI AB beta, which will include updated RTSS distributive and add support for some new GPUs expected to be launched early in 2024.
Thank you for your hard work!
I forgot to document one more thing that was fixed in 7.3.5 beta 6, it is mentioned in this post:
- Fixed issue in RTSS desktop video capture module, which caused some cursor shapes to be captured improperly (e.g. ][ cursor displayed when hovering over edit boxes).