RTSS 6.7.0 beta 1

Discussion in 'MSI AfterBurner Overclock Application Discussion' started by Unwinder, Feb 20, 2017.

  1. EeK

    EeK Member

    Messages:
    23
    Likes Received:
    6
    GPU:
    EVGA GeForce GTX 10
    Hi, Alex! I'm looking for confirmation about which sensors AB uses for CPU temps, when running a 3900X.

    My understanding is that "internal" as the data provider for "CPU temperature", in AB, corresponds to "CPU (Tctl/Tdie)" in HWiNFO64, yes?

    What about when using the HWiNFO plugin ("HwInfo.dll: 1")? I assumed that it was "CPU CCD1 (Tdie)", but temps don't seem to match (probably due to the polling intervals).
     
  2. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,548
    Likes Received:
    1,625
    Internal is CPU (Tctl/Tdie), and you can see implementation in open source MSI AB's CPU.dll plugin.
     
    EeK likes this.
  3. EeK

    EeK Member

    Messages:
    23
    Likes Received:
    6
    GPU:
    EVGA GeForce GTX 10
    Thanks for the confirmation regarding the "internal" reading, but I don't understand what you meant by seeing the implementation in the CPU.dll plugin, would you mind explaining that to me?

    My only options for data providers for CPU temps in AB are either "internal" or "HwInfo.dll: 1", and the latter doesn't seem to have temps that match any of the sensors in HWiNFO64.

    Am I missing something? Both AB and HWi64 are updated to their latest versions.
     
  4. Astyanax

    Astyanax Ancient Guru

    Messages:
    4,734
    Likes Received:
    1,403
    GPU:
    GTX 1080ti
    he is referring you to the sdk.
     

  5. EeK

    EeK Member

    Messages:
    23
    Likes Received:
    6
    GPU:
    EVGA GeForce GTX 10
    Oh, okay. I probably didn't have AB configured properly. As I said, I had the option of using "internal" or "HwInfo.dll: 1" as the data provider for the CPU temperature monitoring graph in AB.

    When using the HwInfo plugin, the temperature being shown didn't match any of the sensors in HWiNFO64, even when both that and AB were set to the same polling interval (1000ms). It looked like it was the same as the "CPU (Tctl/Tdie)", but with a slight delay.

    Now, I set up the plugin again, manually adding the appropriate data sources, and I can't change the data provider for the regular CPU temperature monitoring graph anymore, but new graphs were added to the bottom of the list, and they do correspond to the same sensors as in HWiNFO64.

    Not sure what I did wrong before. Are we supposed to be able to change the data provider for AB's CPU temperature graph?

    Edit: Also, while I'm here, I never bothered monitoring RAM with AB/RTSS, but decided to give it a go after customizing the OSD, and I'm not sure if the values presented are correct.

    I have 32GB of RAM (correctly displayed on task manager), but after a light gaming session, max RAM usage was 10259MB and max commit charge was 16763MB. I had already changed the graph limit to 32768. Is that normal?
     
    Last edited: Jan 19, 2020
  6. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,548
    Likes Received:
    1,625
    I mean that source code demonstrating implementation of MSI AB's internal CPU temperature monitoring, is available in SDK, in CPU.dll plugin. If you're not software developer (and you're obviously not, considering that "SDK" told you nothing), just ignore that.
     
  7. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,548
    Likes Received:
    1,625
    Some development news:

    The first beta of RTSS 7.3.0 (and the first beta in 2020 :)) is around the corner, I expect to publish it in the next couple of weeks. It contains the following key changes and improvements:

    - Various compatibility improvements in the hook engine:
    o Now any application may manifest itself as incompatible with RTSS overlay/hooks either via declaring special named exported variable (recommended and preferred way for EXE-level implementation) or via setting process environment variable (alternate way for DLL-level implementation). So the applications incompatible with RTSS may prevent its API hooking functionality with just a couple lines of code at compile time without need to add exclusion profile for it from RTSS side
    o Added user extendable profile mapper. The mapper is allowing RTSS to map multiple executable names matching with specified wildcard (e.g. vegas130.exe, vegas140.exe and so on for different versions of Sony Vegas) to a single profile file, so it is no longer necessary to create exclusion profiles for each version of such application independently
    o Added user extendable injection ignore triggers list. Similar to injection delay triggers list, injection ignore triggers list allows defining the set of DLL modules, which will prevent RTSS from injecting target process when any of such modules is detected in the process context. This feature is aimed to exclude applications using typical GPU accelerated GUI libraries from hooking. The list currently includes WPF framework libraries (PresentationFramework.dll and PresentationFramework.NI.dll), so all WPF applications are excluded from hooking now
    - Added new type of plugins, client plugins. RTSS is designed to act as a server process, which is running passively and providing different functionality (OSD rendering, screen and video capture, benchmarking etc) to multiple client applications connected to it (e.g. MSI Afterburner). GUI for such functionality (OSD visibility toggling, screen capture) is normally located at client application side. New client plugins allow integrating GUI for such functionality directly into RTSS, without the need to run additional client applications, so new type of plugins is intended for those who prefer to use RTSS as standalone solution without MSI Afterburner. SDK is now including hotkey handler client plugin with open source code, which is allowing processing hotkeys at RTSS side and toggle OSD visibility and framerate limiter without running any additional client processes.
    - Added alternate and user configurable CPU yielding implementation to busy wait loops used in both framerate limiter and scanline sync implementations. Alternate CPU yielding implementation is used by default now, it can improve previously existing and close to ideal framepacing accuracy even further under heavy CPU load conditions due to minimizing context switching related timing penalties.
    - Updated QSV video encoding plugin. The plugins was recompiled under newer version of Intel Media SDK in order to provide QuickSync video encoding compatibility with the latest Intel DCH drivers. As a side effect, RTSS distributive size has been decreased by a few megabytes due to more compact sizes of software QuickSync encoders in new SDK version
    - Scanline sync is no longer disabled in OpenGL applications when OSD support is disabled at application profile level
     
    eGGroLLiO, Headman, Andy_K and 9 others like this.
  8. RealNC

    RealNC Ancient Guru

    Messages:
    3,131
    Likes Received:
    1,355
    GPU:
    EVGA GTX 980 Ti FTW
    Ooooh.
     
  9. Dan Longman

    Dan Longman Member

    Messages:
    29
    Likes Received:
    7
    GPU:
    2080ti watercooled
    Wow sounds like a really great update, Looking forward to trying it out.
    Thanks @Unwinder!
     
  10. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,548
    Likes Received:
    1,625
    It's close. The first implementation of RTSS client plugin is ready and breathing, this tiny (and open source) 40kb plugin module allows using RTSS as standalone screencapture application and adds native OSD/framerate limiter related hotkeys control to it.

    [​IMG]
     
    LocoDiceGR, eGGroLLiO, disq and 11 others like this.

  11. VAlbomb

    VAlbomb Member Guru

    Messages:
    151
    Likes Received:
    4
    GPU:
    Nvidia G1 Gaming GTX 970
    Can't wait, I use RTSS solely for Framelimiting and MSI Afterburner for screenshots, this makes MSI Afterburner redundant for me.
     
  12. Undying

    Undying Ancient Guru

    Messages:
    12,488
    Likes Received:
    1,933
    GPU:
    Aorus RX580 XTR 8GB
    Using rtss standalone also for framelimiting so waiting patiently. Thanks for the free very much needed software.
     
  13. Andy_K

    Andy_K Master Guru

    Messages:
    466
    Likes Received:
    52
    GPU:
    MSI GTX 960 OC
    This hotkey handling will now transfer from MSIAB to RTSS or will both be possible alongside and what if so and the user enables both by accident?
    Will it collide?
    Will it produce 2 screenshots at one button press? Would it be possible to set one as PNG and one to JPG so we would be able to get two versions at once?
     
  14. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,548
    Likes Received:
    1,625
    It won't be transferred from MSIAB to RTSS and won't disappear from MSIAB. Similar hotkey handlers will coexist is both applications and may duplicate each other's functionality. Each handler "lives" in its own application context, so it won't allow you to map multiple actions to the same hotkey inside this application, but you'll still be able to define the same hotkey combination in different applications and yes, associated action will be performed twice in this case.


    Mapping the same hotkey to screen capture action in both applications _may_ produce 2 screenshots at one button press depending on running applications environment (i.e. depending on synchronous (desktop) or asynchronous (3D application) screen capture mode).
     
    Andy_K likes this.
  15. Andy_K

    Andy_K Master Guru

    Messages:
    466
    Likes Received:
    52
    GPU:
    MSI GTX 960 OC
    Thanks for clarification. I'm intrigued and looking forward to test it when it's released.
     

  16. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,548
    Likes Received:
    1,625
    Hehe, this story is not gonna stop. Some kewlhaxor's butt exploded during that exploit discussion that much so he decided to beat dead horse again. It was a fun read:

    https://swapcontext.blogspot.com/2020/01/unwinding-rtcore.html

    At least hfiref0x was smart enough to block me on his twitter to see no response.;)
     
    SpajdrEX and eGGroLLiO like this.
  17. Astyanax

    Astyanax Ancient Guru

    Messages:
    4,734
    Likes Received:
    1,403
    GPU:
    GTX 1080ti
    linking back to him is just giving him more airtime.
     
    gran172 likes this.
  18. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,548
    Likes Received:
    1,625
    Why not, hyping, airtime and collecting applause from malware creator kids was the primary target of posting that "research". If that's the only thing that makes that person happy, I can help with traffic with no problems. And share interesting read with MSIAB users at the same time.
     
    HARDRESET likes this.
  19. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,548
    Likes Received:
    1,625
    More development news:

    - Initially I planned to include just OSD visibility, framerate limiter toggle and screen capture hotkey control functionality in the first implementation of upcoming RTSS HotkeyHanlder client plugin sample. I excluded videocapture functionality from this list on purpose due to its rather complex configuration GUI, which I was too lazy to clone for a sample code, but I had some free time during weekends, so now the plugin got videocapture and benchmarking functionality too. So now the plugin is demonstrating full set of RTSS-powered functionality available in MSI AB GUI:

    [​IMG]

    - After some stress-testing on different platforms I decided to roll back Intel SDK version to the previous one (new SDK version was used to provide QuickSync support on Intel DCH drivers). The reason is a backward compatibility with old QuickSync capable Intel CPUS, unsupported by DCH drivers. QSV encoder compiled under new SDK seem to crash spontaneously on test Ivy Bridge platform with pre-DCH driver. I definitively won't like to drop QuickSync support support for such systems, so I rolled back to older Intel SDK for now. Good news is that actually the only thing that requires recompilation under new IntelSDK is their device manager component, which is auto-selecting wrong (discreete) GPU instead of Intel's one on multi GPU systems under DCH drivers. So to bypass compatibility issue it is enough to provide GUI for manual Intel GPU device selection in QSV plugin, while still compile it under pre-DCH SDK. So on pre-DCH drivers it will auto select device and on DCH drivers you'll simply need to manually select Intel GPU in plugin's properties.
    - Semi-development related offtopic and humor, related to exactly the same exploit, which we patched a few months ago: haxor's rage continues. Looks like I won't be able to continue development soon because hurt person demands MSI to fire me, heh :)

    [​IMG]
     
    toyo likes this.
  20. Im_Special

    Im_Special Active Member

    Messages:
    92
    Likes Received:
    17
    GPU:
    Nvidia GTX 1070 6GB

Share This Page