3 ms·

Maybe? Alternatively by bringing the distributed nature up front-and-center you can have more flexible designs. If I could timeout my drawing routine when the s

Maybe? Alternatively by bringing the distributed nature up front-and-center you can have more flexible designs. If I could timeout my drawing routine when the screen has already refreshed (or context has been stolen from the OS) then I have a lot more flexibility in how to recover instead of pretending to do my best and ending up with a lot of screen tearing when I miss my frame budget.

jayd16 5y ago
I'm trying to wrap my head around where this would happen in a way that made sense. Derailing the GPU pipeline from the OS probably doesn't make much sense. If we're talking about the OS halting the CPU side of the render I guess that would maybe be useful? Even on a single core machine it would be equally useful so I don't know if its a case of distribution per se... But in the abstract, sure. It's a give and take. It's useful to know things and use that knowledge. It's also useful to know a detail is hidden and changeable without consequence.
- Karrot_Kream 5y ago
  Yeah I'm thinking the OS halts the CPU side of the render and, say, stuffs an errno into a register after the routine so the CPU can see what happened and recover. If I were writing a program that required a minimum frame rate and I missed multiple frames, it would probably be nicer for the user if I displayed a message that I was just unable to write a frame at the required speed and quit rather than screen tear and frustrate the user. A similar situation happens if my NIC/kernel buffers are to overloaded to send the packets I need out. Instead I can try in vain to push packets out and have almost no understanding how many packets the OS is dropping just to keep up. Media standards like RTCP were designed around scenarios like these, but that itself is complexity we wouldn't need if the OS could notify the application when their packet writes failed. This kind of flexibility right now is really difficult because most OSs try to pretend as hard as possible that everything happens sequentially. This is just about opening up more complete abstractions to the programmer.

jayd16 5y ago

I'm trying to wrap my head around where this would happen in a way that made sense. Derailing the GPU pipeline from the OS probably doesn't make much sense. If we're talking about the OS halting the CPU side of the render I guess that would maybe be useful? Even on a single core machine it would be equally useful so I don't know if its a case of distribution per se... But in the abstract, sure. It's a give and take. It's useful to know things and use that knowledge. It's also useful to know a detail is hidden and changeable without consequence.

Karrot_Kream 5y ago
Yeah I'm thinking the OS halts the CPU side of the render and, say, stuffs an errno into a register after the routine so the CPU can see what happened and recover. If I were writing a program that required a minimum frame rate and I missed multiple frames, it would probably be nicer for the user if I displayed a message that I was just unable to write a frame at the required speed and quit rather than screen tear and frustrate the user. A similar situation happens if my NIC/kernel buffers are to overloaded to send the packets I need out. Instead I can try in vain to push packets out and have almost no understanding how many packets the OS is dropping just to keep up. Media standards like RTCP were designed around scenarios like these, but that itself is complexity we wouldn't need if the OS could notify the application when their packet writes failed. This kind of flexibility right now is really difficult because most OSs try to pretend as hard as possible that everything happens sequentially. This is just about opening up more complete abstractions to the programmer.