For example, I’m going to work with dual gpu cuda cards later but I have only a single GTX750 for now and need to test “peer to peer” and similar features with same device but by different representations like a logical gpu representation.
no you wouldn’t be able to test Peer to Peer with only a single GPU.
What if I launch 2 processes with their own cuda implementations and get pointers from each other for p2p commands? Is this “multiGPU-only” limitation a hardware related or a software related thing?
I would say it is a hardware limitation in that GPUs lack sufficient hardware support for the required level of virtualization.
Even though modern x86 CPUs offer full virtualization support, you’d be hard pressed to meaningfully exercise things like QPI links in a dual socket machine on a single-socket system that way (which is the closest analogue to P2P communication between GPUs that I can think of)
By P2P, I have meant pci-e to pci-e communication without passing through CPU. If thats what you meant, then I guess I will implement a strategy to use in place of P2P API commands with some sort of dependency injection or similar, so in times of real production, simply disabling the (device-to-host-to-device)injection or renaming would work.
I think we are all in agreement what P2P means, and that it cannot be exercised when using a single GPU.
You stated that you will “work with dual gpu cuda cards later”. As a practical consideration, you may want to check whether it is possible to get earlier access to the hardware that you will use eventually. Maybe in the form of a loaner system from a different department or institute. Trying to come up with a one-off adhoc emulation seems fraught with potential errors and wasteful in terms of opportunity cost.
This may sound weird but what if I loan another GTX 750 :D could it act fit for a dual-gpu single card implementation, just to make it work same, let alone performance optimizations? Provided that cuda compute capability of it will be 3.7 and GTX750 is already 5.0.