Possible ideas for improved netplay

[dustbin]

There was a thread a while ago which asked if rollback netcode was possible, met with mostly "no" because the price of saving state every frame is simply too high. I think rollback might actually still be feasible as there is a way to remove most of the serialization cost. Because rollback only needs to roll back to the confirmed frame between both clients, you can only serialize the data that was changed each frame from the confirms frame, taking the delta between the frame before the current frame and the current frame eliminates the vast majority of the serialization cost and makes rolling back low-cost since you just need to patch specific areas of memory, not load the entire state again.

This would make the main bottleneck running the game fast enough to resimulate the frames with updated input, you could have a fixed maximum amount of rollback frames recommended by CPU speed to ensure that this is possible in most cases, and possibly fall back to delay if required.

I think this might be the best way to improve dolphins netcode for users with computers that are able to handle it, in cases where the system cant resimulate fast enough it would probably be best to give users the option to switch to pure delay.

This is purely an idea at the moment, I haven't actually tried to implement a proof of concept for this. I'm inexperienced with dolphins codebase and would love if some developers were able to give me feedback on this, e.g. things I'm missing which would make it infeasible, more possible optimizations, etc.

[JosJuice]

(09-04-2021, 09:43 AM)dustbin Wrote: Because rollback only needs to roll back to the confirmed frame between both clients, you can only serialize the data that was changed each frame from the confirms frame, taking the delta between the frame before the current frame eliminates the vast majority of the serialization cost and makes rolling back low-cost since you just need to patch specific areas of memory, not load the entire state again.

How do you propose that we create a delta without first serializing the entire state?

[dustbin]

(09-04-2021, 07:03 PM)JosJuice Wrote: How do you propose that we create a delta without first serializing the entire state?

This is a naive assumption from seeing it applied in other emulators, but since it's an emulator, you could track all the writes to memory to see what changes each frame, and then only reverse that. I obviously don't know how that would fit into Dolphin, but it has been done in other emulators where serializing the entire state requires far too much throughput.

[JosJuice]

That sounds like it would be slow. Emitting this tracking in the JIT would add overhead to almost every load and store instruction that gets emulated, and the alternative of doing it by locking memory pages means you pay a much larger performance penalty but fewer times (once for each accessed page). I'm not sure which one of the two is the slower one.

Also, this is just for the memory. How would you create a delta of the rest of the machine state?

[dustbin]

(09-05-2021, 06:51 AM)JosJuice Wrote: That sounds like it would be slow. Emitting this tracking in the JIT would add overhead to almost every load and store instruction that gets emulated, and the alternative of doing it by locking memory pages means you pay a much larger performance penalty but fewer times (once for each accessed page). I'm not sure which one of the two is the slower one.

Also, this is just for the memory. How would you create a delta of the rest of the machine state?

Is the rest of the machine state large enough to significantly slow down the state save/loads? The memory seemed to be the vast majority of the throughput needed for save states, if so then you could probably forego the delta entirely and just save/load it all.

[JosJuice]

(09-05-2021, 07:48 AM)dustbin Wrote: Is the rest of the machine state large enough to significantly slow down the state save/loads?

It's not really a matter of it being prohibitively large, it's more a matter of having to go through all the custom logic. Synchronizing with the GPU, for instance.

[LittleCoaks]

(09-04-2021, 09:43 AM)dustbin Wrote: There was a thread a while ago which asked if rollback netcode was possible, met with mostly "no" because the price of saving state every frame is simply too high. I think rollback might actually still be feasible as there is a way to remove most of the serialization cost. Because rollback only needs to roll back to the confirmed frame between both clients, you can only serialize the data that was changed each frame from the confirms frame, taking the delta between the frame before the current frame and the current frame eliminates the vast majority of the serialization cost and makes rolling back low-cost since you just need to patch specific areas of memory, not load the entire state again.

This would make the main bottleneck running the game fast enough to resimulate the frames with updated input, you could have a fixed maximum amount of rollback frames recommended by CPU speed to ensure that this is possible in most cases, and possibly fall back to delay if required.

I think this might be the best way to improve dolphins netcode for users with computers that are able to handle it, in cases where the system cant resimulate fast enough it would probably be best to give users the option to switch to pure delay.

This is purely an idea at the moment, I haven't actually tried to implement a proof of concept for this. I'm inexperienced with dolphins codebase and would love if some developers were able to give me feedback on this, e.g. things I'm missing which would make it infeasible, more possible optimizations, etc.

i won't pretend to be an expert on this at all, but in my opinion the most realistic way for this to be done would be that dolphin would have a general infrastructure for rollback netcode, and if a game wanted to utilize it then that game's community would need to somehow provide the important memory for that game that would be needed for rollback to function. That way the save state wouldn't need to contain the entire state, but only the necessary information for rollback.

Tho i must admit my knowledge on rollback ends about there. again i really don't know all the intricacies of dolphin or how rollback net code works, but that's my idea based on what i do know. if a dev is reading this then feel free to correct me lol