5 ms·

> I'm not very interested in the worst case, I think a HAM image with width * height modify ops is very unlikely. Sure, but maybe not as far off in some real w

> I'm not very interested in the worst case, I think a HAM image with width * height modify ops is very unlikely. Sure, but maybe not as far off in some real world cases. Say, black-but-not-perfectly black letter box bars where the nuances could result in long sequences of small alterations to the base black color. This becomes less likely with an optimized palette, and of course you could set a hard limit to length of modify sequences in conversion, though that would have to compromise the quality of conversion. > The average case for a direct HAM implementation would probably be more like hundreds of frames, or a couple of seconds, not tens of thousands. Then the problem, with respect to the original question, is the definition of real-time. For the purpose of a game like No Man's Sky for example I'd think hundreds or even tens of frames would be unacceptable. Don't get me wrong, I love technology applied to the "wrong problem" and see that as an end in itself sometimes :). I'm just considering the feasibility of accurate HAM in realtime using shaders, and am really enjoying the discussion on what compromises have to be made for it to perform adequately in a shader. But with respect to the original question I can't quite bring myself to say "yes"

dahart 9y ago
> Then the problem, with respect to the original question, is the definition of real-time. Yeah, true. But there are two factors here that still meet a reasonable definition of real-time, which is >= 30fps in my book. First, a predictable number of frames of latency still allows 30fps throughput. Second, this encoding can be done in multi-pass batches in a single frame. The dependency of one sweep of modify ops doesn't need to wait for a full frame to do the next sweep. This is very common on ShaderToy where people build dependent buffer chains. It's perfectly reasonable (outside ShaderToy) to do 10 sweeps in a one frame cycle. I don't know what the limit would be on a standard GPU these days, it might be much higher. Consider that shaders on ShaderToy are routinely doing several hundred tap texture samples per pixel, and/or several hundred Ray marching iterations per pixel. The amount of work the GPU can do now in real time is incredible. You can combine the inter-frame sweeps with cross-frame passes, and you only lose latency but not throughput. There's a likely chance you can also unroll once or twice for a single pass. If you unrolled once, and had 10 passes inter-frame, and had a 10 frame latency, you could in theory get a modify radius of 200 pixels, while maintaining 30fps throughput with 10 frames of latency, assuming I haven't taxed out the GPU at this point. So, you're right, it would be silly & hard to do this, but I still think HAM encoding could probably be done in real time, with perhaps some compromises or quality limitations to keep the encoding predictable, or at least have a known reasonable upper bound.

dahart 9y ago

> Then the problem, with respect to the original question, is the definition of real-time. Yeah, true. But there are two factors here that still meet a reasonable definition of real-time, which is >= 30fps in my book. First, a predictable number of frames of latency still allows 30fps throughput. Second, this encoding can be done in multi-pass batches in a single frame. The dependency of one sweep of modify ops doesn't need to wait for a full frame to do the next sweep. This is very common on ShaderToy where people build dependent buffer chains. It's perfectly reasonable (outside ShaderToy) to do 10 sweeps in a one frame cycle. I don't know what the limit would be on a standard GPU these days, it might be much higher. Consider that shaders on ShaderToy are routinely doing several hundred tap texture samples per pixel, and/or several hundred Ray marching iterations per pixel. The amount of work the GPU can do now in real time is incredible. You can combine the inter-frame sweeps with cross-frame passes, and you only lose latency but not throughput. There's a likely chance you can also unroll once or twice for a single pass. If you unrolled once, and had 10 passes inter-frame, and had a 10 frame latency, you could in theory get a modify radius of 200 pixels, while maintaining 30fps throughput with 10 frames of latency, assuming I haven't taxed out the GPU at this point. So, you're right, it would be silly & hard to do this, but I still think HAM encoding could probably be done in real time, with perhaps some compromises or quality limitations to keep the encoding predictable, or at least have a known reasonable upper bound.