3 ms·

Yeah if you want to hit 60 fps, 2/3rds of your processing time just evaporated.

by fleitz 12y ago

waps 12y ago
60fps won't matter one bit if it's 120fps for one second followed by 0fps for another second. That's why people are asking for pauseless.
- fleitz 12y ago
  Fully agree. I thought the GC only paused for 10 ms, which would be bad enough, if it's a full second... that's insane.
jblow 12y ago
And it's worse, because... "only 60fps?" 60fps was fine pre-VR, but now you want to do 90fps times 2 eyes. That's a lot of rendering.
- reality_czech 12y ago
  If only someone would invent a co-processor that we could offload our rendering to. A "graphics processing unit," so to speak. Oh well. One day! If you want to update some physics model at 60 FPS, you will be updating every 16 ms. An occassional 10 ms pause is not going to prevent that. Anyway, any reasonable game design needs to deal with pauses that are caused by network congestion intelligently, which can often be longer than 16 ms anyway.
  - cma 12y ago
    A pause due to network congestion isn't nearly on the same level as a pause in updating your head orientation in VR.
  - jblow 12y ago
    Dude you have NO idea what you are talking about. An occasional 10ms pause absolutely will "prevent that". Those of us who work on software that does a lot of rendering using these fabled GPUs you mention know that feeding the GPU properly is a big problem and requires a lot of code to be running on the, err, CPU. I don't even know what you are talking about wrt network congestion. What are you talking about??
    - reality_czech 12y ago
      If you're playing a multi-player game, you could easily lose touch with the servers or other players for more than 10 ms. So the game engine needs to be able to handle these pauses and extrapolate what happened with physics during the time you lost touch. It's the same thing here. I developed games for Android at one point. GC pauses were common there. In the 1.0 version of Android, the pauses could be up to 200 ms. Now, it's more like 5 or 6 ms on average, as they improved the Dalvik VM. The GC hasn't stopped a lot of good games from being written for Android. People need to be aware of the realities of scheduling on commodity computer hardware. A 10 ms guarantee is actually very good. You can't get much better than 10 ms timing on commodity PC hardware anyway. Even a single hard disk seek or SSD garbage collection event will probably block your thread for more than 10 ms. Whether this guarantee is good enough for you depends on what you're doing. But I guarantee you that 99% of the crowd here doesn't know what you need to do to get better guarantees than 10 ms anyway (hint: it involves a custom kernel, not doing any disk I/O, and realtime scheduling).
      - jblow 12y ago
        Extrapolation is not at all the same thing. When you aren't getting network packets, yes, you run locally to do some kind of approximation to what is happening (in fact for a good game, your frame rate is never contingent upon what is coming in over the network, you just always do your best to display whatever info you have right now). But that is totally different than the GC situation. With a STW GC you cannot even run, how do you expect to be able to display anything on the screen? Even with a non-STW GC, the reason the GC has to collect is because you are running out of memory (unless you are massively over-provisioned), and if you are out of memory for the moment how are you going to compute things in order to put stuff on the screen? Accessing disk/network/etc induces latency, yes, but that is why you write your program to be asynchronous to those operations! But this is a totally different case than with GC. To be totally asynchronous to GC, you would need to be asynchronous to your own memory accesses, which is a logical impossibility. I do not see how you even remotely think you can get away with drawing an analogy between these two situations.
        12y ago

Yeah if you want to hit 60 fps, 2/3rds of your processing time just evaporated.

by fleitz 12y ago

Yeah if you want to hit 60 fps, 2/3rds of your processing time just evaporated.

waps 12y ago

60fps won't matter one bit if it's 120fps for one second followed by 0fps for another second. That's why people are asking for pauseless.

fleitz 12y ago
Fully agree. I thought the GC only paused for 10 ms, which would be bad enough, if it's a full second... that's insane.

jblow 12y ago

And it's worse, because... "only 60fps?" 60fps was fine pre-VR, but now you want to do 90fps times 2 eyes. That's a lot of rendering.

reality_czech 12y ago
If only someone would invent a co-processor that we could offload our rendering to. A "graphics processing unit," so to speak. Oh well. One day! If you want to update some physics model at 60 FPS, you will be updating every 16 ms. An occassional 10 ms pause is not going to prevent that. Anyway, any reasonable game design needs to deal with pauses that are caused by network congestion intelligently, which can often be longer than 16 ms anyway.
- cma 12y ago
  A pause due to network congestion isn't nearly on the same level as a pause in updating your head orientation in VR.
- jblow 12y ago
  Dude you have NO idea what you are talking about. An occasional 10ms pause absolutely will "prevent that". Those of us who work on software that does a lot of rendering using these fabled GPUs you mention know that feeding the GPU properly is a big problem and requires a lot of code to be running on the, err, CPU. I don't even know what you are talking about wrt network congestion. What are you talking about??
  - reality_czech 12y ago
    If you're playing a multi-player game, you could easily lose touch with the servers or other players for more than 10 ms. So the game engine needs to be able to handle these pauses and extrapolate what happened with physics during the time you lost touch. It's the same thing here. I developed games for Android at one point. GC pauses were common there. In the 1.0 version of Android, the pauses could be up to 200 ms. Now, it's more like 5 or 6 ms on average, as they improved the Dalvik VM. The GC hasn't stopped a lot of good games from being written for Android. People need to be aware of the realities of scheduling on commodity computer hardware. A 10 ms guarantee is actually very good. You can't get much better than 10 ms timing on commodity PC hardware anyway. Even a single hard disk seek or SSD garbage collection event will probably block your thread for more than 10 ms. Whether this guarantee is good enough for you depends on what you're doing. But I guarantee you that 99% of the crowd here doesn't know what you need to do to get better guarantees than 10 ms anyway (hint: it involves a custom kernel, not doing any disk I/O, and realtime scheduling).
    - jblow 12y ago
      Extrapolation is not at all the same thing. When you aren't getting network packets, yes, you run locally to do some kind of approximation to what is happening (in fact for a good game, your frame rate is never contingent upon what is coming in over the network, you just always do your best to display whatever info you have right now). But that is totally different than the GC situation. With a STW GC you cannot even run, how do you expect to be able to display anything on the screen? Even with a non-STW GC, the reason the GC has to collect is because you are running out of memory (unless you are massively over-provisioned), and if you are out of memory for the moment how are you going to compute things in order to put stuff on the screen? Accessing disk/network/etc induces latency, yes, but that is why you write your program to be asynchronous to those operations! But this is a totally different case than with GC. To be totally asynchronous to GC, you would need to be asynchronous to your own memory accesses, which is a logical impossibility. I do not see how you even remotely think you can get away with drawing an analogy between these two situations.
      - 12y ago