Are there any grown-ups out there who can tell me if PCI Peer-To-Peer Support will provide a better foundation for projects like Looking Glass, or if it merely codifies a formal process for accomplishing what Looking Glass is already doing?
https://www.phoronix.com/scan.php?page=news_item&px=PCI-P2P-Memory-Support
I’ve pondered over exactly this idea for a while and the only hangups I could find were support and ACS security issues. It might actually be possible to make use of it and if so it would probably be a decent performance boost
Thank you for bringing “PCI Peer-To-Peer Support” to my attention, I have not followed that until now. However, reading this and skimming the surface with a google search descriptions are a bit vague.
“A kernel interface is provided so that other subsystems can find and allocate chunks of P2P memory as necessary to facilitate transfers between two PCI peers.”
Not exactly sure what to think of it. It certainly sounds like direct data transfer from framebuffer to framebuffer should be possible. I can’t tell how far along everything is, I will try and ask around.
Some links I came across:
Reading, some further it sounds like this “only” makes the BUS memory locations discoverable. Not sure how streight forward it is to use it directly? Sounds doable. Disclaimer: I don’t have the programming experience to do easily get a good understanding here. I’ll keep watching this thread.
looking at Capture::DXGI::GrabFrameRaw … maybe after you’ve set up and mapped the shared memory, maybe you can ask the API to deliver a copy directly.
Step1 would be to get rid of that memcpysse copy by setting up everything to allow dxgi to deliver a frame directly… And then cross your fingers that dxgi is efficient and does no frame manipulation internally
I’ve discussed this with another person interested in improving on the LG concept. One major issue he found is that high polling rate mice can cause a 1000hz update rate so you have to transport the main screen capture data and the mouse data as separate streams. likely we would want to keep memcpysse around just for mouse data transport to act as a buffer. since mouse data is much smaller memcpysse shouldn’t introduce much latency at all. with dxgi this is no problem. If NVFBC ever miraculously gets greenlit it would take a little extra work.
On a related topic. AMD at one time had a feature in their media SDK called Direct Encode Mode (DEM) which was functionally identical to NVFBC but they dropped support for it when they open sourced the SDK stating that it wasn’t worth maintaining at the time. I think we need to get together and petition them to bring it back.