> my experience is that it's flawless and indistinguishable from native in twitch games like fortnite and counterstrike
This is just your opinion and it's wrong for at least 50% of humans. Nobody with a mouse will find fortnite or cs playable with 40ms added lag. 40ms lag is higher than the mere 16.66ms you get from going from 60 FPS to 60 Hz vsync (that is, running the monitor at 60Hz and enabling vsync. it will be the same framerate but much laggier). In the 60 FPS days, EVERYONE complained about this mere 16.66ms added difference. This included people who just started playing their very first video game one day ago. On Twitch, still everyone notices vsync and turns it off once they figure out that it is the cause of the shitty sluggy mouse feel.
Your next idea
> The "trick" here is that native devices already have some amount of latency, just they are in an acceptable range for most people. However nvidia can optimize PC hardware to reduce the device's latency such that even with the network latency added it's still faster than the average person's native device. Hope that makes sense.
Is also utterly wrong. You don't need "le graphics pipeline" to make input lag noticeable. Just plug in a monitor with 16ms input lag to your computer and you will notice that the mouse is annoyingly difficult to position over anything in the Windows or Linux desktop.
OR another explanation: Make a program to move a small shape around the screen using the mouse position. It waits until the monitor is about to start scanning out a frame from the framebuffer and only then draws the shapes new position in the framebuffer where the mouse is at that time (since it's just a blank image with a small shape it's near instant to do this in the CPU, a few microseconds). If you use a monitor without lag (like a CRT) and it's running at 60Hz, that means there is now a total input lag of up to 16.66ms (accounting for the time between frames), and perhaps 1ms if you run the mouse at 1000Hz like you should be doing, then maybe some small delay from the OS. Now if you make this program render the slow vsync way, i.e, rendering the frame to temporary memory and doing nothing for the next 16.66ms then swapping it to the framebuffer once the monitor is about to scan out the next frame, this adds another 16.66ms of input lag. And it will feel terrible.
Ergo, getting far greater than 16.66ms lag caused by some network streaming service will NOT magically feel less laggy than native hardware. Also the idea that optimizing small isolated components randomly will fix input lag is laughable, it's all about timing. Almost no lag is caused by CPU (or GPU core) bottlenecks, aside from the straight up most basic problem of low framerate.