OpenXR is the new generation of developer interfaces (API) for VR. What this means is that none of the OS/VR environments where originally developed for it (they predate the OpenXR standard by several years). So for now, OpenXR is mostly implemented as a compatibility layer with the “older” API. It translates what developers do into the older calls.
So instead of having something under the hood that looks like:
Game → OpenXR → OS
You in fact for WMR have:
Game → OpenXR → Mirage → OS
Mirage is the name of the original API for WMR support on Windows (this is why sometimes you will see reference to Windows.Mirage.Dll in logs or crash dumps etc).
Now when you use SteamVR, there is another layer I believe (I am not familiar with SteamVR but here is my guess):
Game → OpenXR → OpenVR → OS
OpenVR is the name of the original SteamVR API.
Now this gets even messier in reality because SteamVR does not talk to the OS directly for the majority of headsets…there is an additional driver. So for WMR:
Game → OpenXR → OpenVR → Mirage → OS
This should explain why using the SteamVR OpenXR runtime will likely give you lower performance than the WMR OpenXR runtime. You have this extra “hop” into SteamVR (OpenVR) world, only to go back to WMR world (Mirage).
Just to make things more complicated, some features of OpenXR are not directly supported by the legacy API like OpenVR or Mirage. So in this case, the OpenXR runtime has to do extra work to implement these features, and will do it in a way that is designed to be efficient only on the target VR headset. So using the OpenXR runtime that is not targeting specifically your hardware could be less efficient.
I hope this helps.