Maybe it would help if you explain how you think data is read off a SSD and gets to RAM on the video card.
Heck that's easy.
I. Load from disk
File I/O requests typically use
CreateFile /
ReadFile / ReadFileScatter and these must provide a pre-allocated user-mode buffer (or a scatter page list to multiple buffers).
The I/O manager checks whether file cache contains the required data - if yes,
filesystem driver Fast I/O path calls into the Cache Manager (and Memory Manager).
Otherwise the
I/O Manager locks the physical pages in the user buffer and maps them into kernel address space using the
memory descriptor list (MDL) structures, then creates I/O request packet
IRP_MJ_READ.
The IRP passes
through the filesystem stack down to the StorPort/StorNVMe driver pair, which set up the NVMe controller to perfrom
Direct I/O DMA to the user-mode buffer mapped by MDLs.
When complete, the driver reports success (or failure) to the I/O Manager, which unmaps the user-mode buffer from kernel address space, then returns the number of read bytes to the user-mode process.
II. Move/map into video memory
Once your data is loaded into system memory, you call the graphics API runtime to submit your resources to the video memory.
The runtime uses
WDDM kernel-mode driver (DXGK) callbacks to manage local video memory; I/O requests are served by the video port driver using
DMA paging buffers and
MDLs.
WDDM 1.x uses
linear video memory model where
DXGK video memory manager maps a part of GPU video memory to an
aperture 'segment' in CPU memory space. The Direct3D 9/10/11 runtimes automatically manage
local video or shared (system) memory pools to allocate
created resources.
In Direct3D 12 and WDDM 2.x DDIs, there is no automatic resource management. The video memory manager allocates
GPU virtual address space for each user process. The
resource binding model requires the programmer to organize GPU resources into
descriptor heaps/tables; the runtime processes the descriptors to
assign them a virtual video memory address. The application then has to
allocate physical memory for the resources from available shared (system) memory or local video memory.
For
discrete GPUs (GpuMmu model), the driver takes an
abstracted page table format from the video memory manager and maps internal GPU page tables to point into physical video or physical system memory. The video memory manager
pages physical memory from
system memory to local video memory by requesting DMA transfers. Additionally the system memory
aperture 'segment' contains the entire local video memory for the CPU to access.
This is the memory model used for AMD GCN and
NVidia Kepler ('Unified Memory'), or later.
For
integrated graphics (IoMmu), you actually don't have local video memory, only system memory; GPU MMU uses the same virtual address space as the CPU, and the Memory Manager handles page faults as usual.
This is the memory model for Intel UHD.
What has memory-mapped I/O got to do with this?
'CPU I/O', which I take is your term for either programmed or memory-mapped (port-mapped) I/O, is not used by StorAHCI or StorNVMe miniport drivers; StorPort only supports Direct I/O DMA mode - specifically bus-master DMA and interrupt signalling. The reason is, UDMA HDDs and PCI bus-mastering controllers like Intel PIIX for i430/440 series and ICH for i810/820/840/865 series were commonplace by 2003 when development of Longhorn (Windows Vista) started. 
The more I/O, the more CPU work is required. Again, I can only keep linking 
