Rogue GPU and the numbers 14, 25 and 51?

I’ve got a very curious issue here. I’m doing image processing on a rogue GPU (iPhone 5S). I’m using a 16bit render target, and rendering in an image, then using a feedback loop and mixing the result back in.

That’s all fine, but there’s a really odd issue when this is left running for quite a while (hundreds of frames). I start seeing “blockiness” in the image - similar to very heavy JPEG compression (the image shows clear blocks of different colours, often with a gradient across the block. Low-contrast parts of the image look perfectly normal, but it might just show up the effect more in higher contrast regions.

The blocks seem to have variable sizes, but the sizes follow a pattern - the smallest is 14 pixels, then 25 pixels, then 51. Larger blocks seem to be multiples of 51.

I thought at first it could be related to the tiler, but I doubt it’s using these strange block sizes! Is there anything else on the GPU that might cause this under extreme circumstances?

Stuff I’ve ruled out so far:

  • The source data (scaling the image should show bigger blocks in this case, instead I see a zoomed in image with the same small blocks)
  • The rendering setup (at least nothing in there is block based, I can’t imagine anything that would cause it)
  • Bad output (the blocking is also seen with uncompressed PNG output).

Oh yes, forgot to mention: this is visible on screen too, so bad file output is definitely ruled out.

Here’s a sample:

Aaaand solved! The issue is low precision interpolation - normally not an issue, but my setup amplifies tiny errors causing the pixels to drift over time.

If anyone else has this, the solution is to disable linear interpolation on the render target (this eliminates the drift), or another suggestion (should work but not tested) is to use a pow2 texture size.

Oh, and the relevance of those numbers? My RT is 3264 pixels wide. 3264/51 = 64. I’m guessing that’s related to the interpolation accuracy in the GPU :slight_smile:

Hi Chris,

I was going to chip in and suggest that it looks like an accummulative precision error. Glad to hear its working now Thanks for sharing the solution :slight_smile: