FIXED: possible sharedmemory issue related to screen resolution in 4.35 U1
-
Hello devs and BMS fans, I’ve just recently upgraded to 4.35 U1 and afterwards I noticed my Helios MFD extractions and general gauges were updating much slower than in 4.35.0 or 4.34.4 for that matter.
The Problem: My desktop resolution is 3440 x 2160 @60hz so I run BMS borderless at the same resolution. When I run 4.35.1 shared memory updates seem to have some kind of odd delay (see the video link for a visual) noticed by running my Helios profile. All the gauge updates are very choppy as well as the MFD extractions. Everything is delayed.
If I set my BMS resolution to 2560 x 1440@60hz the shared memory updates seem to smoothen out (see the video link for a visual)
Might this be an issue with DX11 update or recent updates for RTT?
Video link demonstrating the issue
https://imgur.com/a/AnorDP8LATEST UPDATE: Apparently setting VSync on in BMS has fixed this issue. See the video for details
-
have u seen this:
RTTRemote: updated to v3.3.0.3
- Check the RTTServer.ini for the new config option “LIMIT_MBPS”
And the readme in rtt tools folder?
RTT Client/Server v3.3
by Dunc, 2021/01
Changelog
v3.3:
- RTTServer can now be configured to limit its maximum bandwidth usage per
client. Check the RTTServer.ini for the new config option “LIMIT_MBPS”.
NOTE: If you’re experiencing “slide show” behavior (choppy images), you’re
exceeding network capabilities (w/ or w/o LIMIT_MBPS set). Try using JPG
compression and lower FPS and JPG quality settings in RTTServer.ini! - Optimized message handling for networked RTTClients.
- Added possibility to send out shared mem data (not RTT) via UDP multicast in
addition to the regular RTTServer/RTTClient network protocol. This is NOT at
all related to the normal RTTServer/RTTClient functionality and NOT a feature
for regular end-users, but can be helpful for 3rd party custom clients. See
MULTICAST.txt for details.
-
So is that something that needs to be set even if you’re not using RTTServer?
I tested your idea which has no effect with this issue. Helios accesses SharedMemory directly and not through RTT.
-
What is the setting for the config option to extract every x frames? Think by default it is 2, I change it to 1 and its glass. Admittedly I am only 3440x1440 but may be worth checking? Its the line directly after enable RTT extraction usually. Sorry, not at PC right now for exact names, etc.
-
You are referring to the batch setting. I had it set at 2 and changed it to 1 but the problem remains. The only thing so far that helps is to reduce BMS resolution.
Sent from my iPhone using Tapatalk
-
You are referring to the batch setting. I had it set at 2 and changed it to 1 but the problem remains. The only thing so far that helps is to reduce BMS resolution.
Sent from my iPhone using Tapatalk
The slow extraction you get is sure not caused by g_nRTTExportBatchSize because changing from 1 to 2 would reduce the texture export to half the ingame frame rate but that not as drastic as in you video.
Next is that that would/should only affect Texture extraction MFD, DED but as in your video all Helios gauges so those that are using the non textured sharedmemory are affected as well. My best guess it’s a rendering issue with in the Helios screen rendering.
I’m running multiscreen setup but at 1080p and can not see any noticable difference with Helios extraction.Have you tried RTT or MFDE at 3440 x 2160 as well. Just to see if it’s really a combination of screen resolution and Textured shared memory access
-
The slow extraction you get is sure not caused by g_nRTTExportBatchSize because changing from 1 to 2 would reduce the texture export to half the ingame frame rate but that not as drastic as in you video.
Next is that that would/should only affect Texture extraction MFD, DED but as in your video all Helios gauges so those that are using the non textured sharedmemory are affected as well. My best guess it’s a rendering issue with in the Helios screen rendering.
I’m running multiscreen setup but at 1080p and can not see any noticable difference with Helios extraction.Have you tried RTT or MFDE at 3440 x 2160 as well. Just to see if it’s really a combination of screen resolution and Textured shared memory access
All good points. I did of course run an RTT test with two MFDs and there was no extraction delay running at resolution 3440 x 2160. I also did a test of running just two MFDs within a Helios profile and it also seems to run ok with the same resolution. So I’m not sure what the deal is with running a full pit profile like the Ice profile against 4.35.1. if I run the same Ice profile against BMS 4.34 at the same 3440 x 2160 resolution the gauges and MFDs are all smooth. So if it were a Helios issue I’d expect it to also occur with BMS 4.34. So if no one else has this issue then great, its just local to my setup but if others also have this issue at same or higher resolutions then it must be a problem somewhere. The Helios code that accesses BMS sharedmemory hasn’t been touched in a very long time as there has been no need to do that it has just worked.
-
What GPU do you have and what is the resolution of the screen you are exporting the displays to? Anyway I think using the built-in RTT exporter will be more efficient than any 3rd party SW. If you are getting smooth with RTT on 4K then I strongly suggest to use just that.
Now, regarding g_nRTTExportBatchSize - Guys please know this:
A setting of 1 to this value isn’t effective anymore as there is no efficient way with the DX11 pipeline (pipeline means also the GFX engine, in general) to really use a 1 setting. 1 means that we update the displays every frame and that can’t happen with new engine since it stalls the engine and will cause performance issues. So even if you set to 1, you get minimum 2, simply because the code don’t take 1 anymore. -
Anyway I think using the built-in RTT exporter will be more efficient than any 3rd party SW.
Any of the 3rd party tools all use the same kernel32.dll function to MapViewOfFile to access sharedmemory which I assume RTT is using as well. So RTT wont gain anything in terms of reading from sharedmemory. Different story for processing the data.
-
So here is my latest update. Setting VSync on in BMS corrects the choppy gauge updates and MFD rendering.
Watch the video!
-
Can confirm, I have VSync on anyway as my 4K main screen is 60Hz, and do not experience choppy Helios MFD extraction.
However, my first test flight with U1 (training mission 1) CTDd. 2nd time around no CTD. I hope this is not RTT extraction related, but if I have more CTDs…. well… -
Can confirm, I have VSync on anyway as my 4K main screen is 60Hz, and do not experience choppy Helios MFD extraction.
However, my first test flight with U1 (training mission 1) CTDd. 2nd time around no CTD. I hope this is not RTT extraction related, but if I have more CTDs…. well…I took the Harm Training TE as that was my repro TE for RTT freezes. Freeze or crash within 2 minutes. Flew it several times without freeze or crash. So consider the RTT bug as fixed as stated in changelog
Gesendet von meinem SM-G930F mit Tapatalk
-
I took the Harm Training TE as that was my repro TE for RTT freezes. Freeze or crash within 2 minutes. Flew it several times without freeze or crash. So consider the RTT bug as fixed as stated in changelog
Yes this makes sense, the actual bug that caused the mess with BMS EXE itself (freezes and/or crashes, not on all systems BTW, e.g I couldn’t repro it locally while other could like you in 2 minutes) was that by mistake the RTT code was accessing the D3D11 device context from the main thread while the engine itself is using it to render from the rendering thread. Unfortunately the D3D11 context isn’t thread safe as D3D11 doesn’t support concurrent rendering and so the access was illegal and the bug was obvious. The fix of course was to ensure protected access to the D3D11 device context object.
-
Well, I’m not savvy in all that foreign language you speak but I can confirm testing the harm training TE did not crash in two minutes or far beyond that in fact. Been testing tonite without a single CTD, so let’s hope all is well. In any case, my humblest thx to the dev team, from an olde F3-F4-AF and now BMS believer!