Windows 11 Compatibility - requesting a statement to show IT

Bugs & Features
,
1

Hey Mario!

We have been trying to request Windows 10 LTSC Edition from our Central IT as a back up for our upcoming fleet of Ubuntu machines - this will enable legacy paradigm to run without tweaking - and sidesteps the broken mess of Windows 11..For those of you who don’t know Windows 10 LTSC has support for 5 years or so, and so your central IT might allow it too - Windows 10 LTSC – the version that won't expire for years • The Register.

However, for Central IT to release Win10 LTSC to us, we have to prove that Windows 11 + PTB will not work.We know that changes to the DWM in Win11 mean that PTB as it currently stands can not work.

This involved us opening a case with MS Premier Support. We’ve concluded a Microsoft Premier Support case (#2601210050002502) regarding Windows 11 DWM timing issues with PTB. Microsoft’s escalation team has closed the case with their recommended solutions, and I need your official input on PTB’s development plans to present to IT.

Microsoft’s Position (Official Case Closure):

Microsoft states that sub-millisecond timing precision IS achievable on Windows 11, but requires application-level implementation of:

  1. DirectX Full Screen Exclusive (FSE) via IDXGISwapChain::SetFullscreenState

  2. Independent Flip optimization for DirectX swapchains

  3. DirectDisplay API (Windows.Devices.Display.Core) for compositor-free display control

Microsoft documentation: https://learn.microsoft.com/en-us/windows/win32/api/dxgi/nf-dxgi-idxgiswapchain-setfullscreenstate

Given PTB is OpenGL for cross OS compatibility I suspect it would be a massive/impossible undertaking to switch to DirectX.

Mario - Could you please provide an official statement on PTB’s development roadmap regarding these Microsoft-recommended DirectX implementations that I can show to MS and my IT department? Specifically:

Is PTB planning to implement DirectX FSE/Independent Flip to achieve precise timing on Windows 11?

Many thanks!

Regards

Dagmar Fraser

2

Hi Dagmar,

I am not aware of current Psychtoolbox being incompatible with Windows-11? My working assumption is that it works just “as well” with Windows 11 as with Windows 10, ie. ok for not too demanding use cases, if the system is set up according to our recommendations, with all the stated same limitations as on Windows 10, e.g., no Intel graphics, no mixing of HiDPI with standard DPI displays in multi-display setups, dual/multi display way more fragile than single display setup etc.

Right now, slightly more than 75% of all PTB 3.0.20 and later versions for MS-Windows are already running on Windows 11, so the lack of lots of trouble reports from users suggest it is working ok.

Now Psychtoolbox itself still reports Win 11 as “unsupported”, at least it did until yesterdays 3.0.22.2 update (which now says “somewhat supported and tested”, but that is only true in the sense that I don’t have access to a suitable Windows 11 machine atm., so I can’t extensively test it or support it if there were Windows 11 specific problems that don’t happen on Windows 10. I have one almost 10 years old MS Surface Pro 6 tablet running Windows 11, but it is so low on disc space that I can’t even install Matlab, only the less space consuming Octave 7.3 for testing. It only has one USB port, and it only has an Intel iGPU with known buggy graphics/display driver, which prevents any kind of presentation timing tests. To my knowledge all Intel gpu’s have broken drivers, but I couldn’t test if they get eventually fixed, as this Intel gpu hasn’t received any updated drivers in many years – considered end-of-life.

Do you have any different results from testing?

Wrt. to your support case, I think MS support answer is wrong, or at least incomplete, because they only talk about the specific DirectX/Direct3D capabilities, but not about the properties of the 3rd party AMD/Nvidia/Intel provided drivers wrt. OpenGL and Vulkan. These drivers do often use such DXGI optimisations under the hood, e.g., either item 1 or something equivalent to item 1.

(Btw. Last time i looked at it, proposal 3. was not usable by any standard software that doesn’t have a special contractual relationship ($$$ and including signing NDA’s and being considered a VIP enough customer/partner of Microsoft to be considered worthy of this mode) - and also usually reserved to some VR headsets or other special purpose displays.)

Psychtoolbox in its default OpenGL display mode uses an older “Fullscreen exclusive” implementation, which I think is still working fine, or at least was the last time i tested on Windows 10. Essentially when PTB’s timing tests said it is ok, it was usually ok, and if they fail it is broken. The optional Vulkan display backend uses a Vulkan fullscreen exclusive mode whenever possible, likely layered on top of 1.

One test I read to check if a fullscreen exclusive mode is active is to press the volume up/down buttons on your keyboard and see if the onscreen volume indicator shows. If it doesn’t, then it is likely in fullscreen exclusive mode. For yet another one, see the section of “Screen(‘Preference’, ‘VisualDebugLevel’, 6)” in help SyncTrouble.

So I wouldn’t make such a statement about Windows 11 incompatibilities without strong evidence that that’s true, evidence which I am not aware of.

3

Then I am really confused. 3.0.19 and later version we trialled under Windows 11 in September last, with AMD WX7100, all reported timing was impossible as the DWM was active, and you cannot disable the DWM in Windows 11. Is this now not an issue with more recent PTB versions?

I’ll spin then Win 11 machine back up, with yesterdays PTB update and report here what we were seeing… I have been acting under the delusion this DWM issue was common experience/knowledge.

Thanks for the reply!

Regards,

d

4

From PTB’s perspective, PTB has had almost no control over the DWM since Windows 8, and no control since Win 8.1. Since Windows 10, all we have is one hack to try to indirectly figure out if the DWM is on, but no way to know if it is actually doing anything or if it is on standby. The DWM decides by itself if it should stay out of the way (standby) or if it should interfere.

If the hack says the DWM is nominally “on,” PTB will print some text starting with “WINDOWS DWM DESKTOP COMPOSITOR IS ACTIVE. On this Windows-10 or later system, Psychtoolbox can no longer reliably detect…” on Windows 10 and later. It doesn’t say that timing is broken, though—only that we can’t reliably detect if the DWM is really doing something or if it is on standby. The message will be worded more strongly if PTB is sure that the DWM is actively compositing and interfering, containing phrases like “…ALL FLIP STIMULUS ONSET TIMESTAMPS WILL BE … INACCURATE / LIKELY WRONG …”

If you get the above message—something I also see on my Windows 10 system pretty much always—that doesn’t necessarily that mean things are broken, only that PTB can’t guarantee - or detect reliably if - things are fine, so independent verification is recommended.

Apart from the “is the DWM nominally on” hack, the best software-based indicator during startup / “OpenWindow” we have for true DWM interference is if the sync tests fail due to too much timing variability, with the thresholds for stddev chosen to be sensitive to DWM interference, but generally generous enough to rarely trigger on a “just a bit noisy” system. Ofc. this has a false positive and false negative rate, depending on the specific system and setup, hopefully a low rate of misdetection though. Additionally, during runtime, we run consistency checks on the timestamps and results of beamposition queries after each ‘Flip’ - If those report failure, then things are definitely broken from there on. It can be that the initial part of your session is working fine, until something in the middle of a session triggers true DWM activation and broken timing, e,g., a popup notification message, or a different window, e.g., the Matlab main window, getting active keyboard focus, because you clicked on it or interacted with it on a multi-display setup. These are described in our help texts, and the whole interacting with another window / Matlab window is a common hazard on MS-Windows multi-display, making multi-display on Windows extra fragile, even if only one connected display monitor is used by PTB for actual stimulation.

Apart from the software based trouble detectors, there are the “human in the loop” hacks, like those mentioned in help SyncTrouble, or playing with sound volume and checkinf if the sound volume indicator actually shows during a test run…

None of this is 100% reliable to always catch all brokenness, but it usually works pretty well and should work the same on Win 10 or Win 11. At least until proven otherwise. As stated before, my only Win 11 machine is with Intel graphics, and therefore broken by design, so I can’t really verify visual stimulation timing on Win 11 at the moment, only go by “theory and reasoning”, and the lack of user feedback that would suggest higher amounts of trouble on Win 11 compared to
Win 10.

1 Like