Re: [PATCH v2 11/13] gpu: ipu-ic: Add complete image conversion support with tiling

[Steve Longerbeam]

On 08/01/2016 02:29 AM, Philipp Zabel wrote:
> Am Donnerstag, den 28.07.2016, 16:09 -0700 schrieb Steve Longerbeam:
>>> Now split the frame in half and suddenly pixel x' = 640 is the start of
>>> a new tile, so it is sampled at x = 160, and pixel x' = 1279 will be
>>> sampled at x = 160 + (1279 - 640) * 8192/32846. = 319.37, reading over
>>> the edge of the source image.
>> Here's where we part.
>>
>> The 320x200 --> 1280x800 conversion is split into two 160x200 -->
>> 640x800 conversions. The DMA controller and ipu_ic_task_init() are given
>> those width/height dimensions, not the dimensions of the original images.
>> So this is simply two separate 160x200 --> 640x800 conversions. The only
>> difference from a true 160x200 --> 640x800 image conversion is that the DMA
>> controller must be given the stride lengths of the original 320x200 and 
>> 1280x800
>> images.
>>
>> The rsc for the 160x200 --> 640x800 conversions is
>>
>> x = x' * (160-1)/(640-1) = x' * 8192/rsc, so rsc = 32923
>>
>>
>> So original horizontal position 640 is really x' = 0 of the second 
>> conversion,
>> which is sampled at x = 0 of the second conversion. And the pixel at x' 
>> = 1279
>> is really x' = 639 of the second conversion, which is sampled at x = 639 
>> * 8192/32923
>> = 158.98, which does not read over the edge of the source tile.
> My bad, I somehow thought that the scaling factor is calculated per
> image (as it IMHO should be), not just per tile.
>
> Of course in that case you won't ever read over the edge, but on the
> other hand the visual problems are worse because you underestimate the
> scaling factor and introduce a sharp edge at the center: even if the
> source pixel step per target pixel step is a fraction, between pixels
> width/2-1 and width/2 there's always a whole source pixel step.
>
> Take the extreme example of scaling 32x32 to 1080x1080 pixels. The ideal
> source pixels for x' = 519 and 520 should be x = 14.911 and 14.939,
> respectively. Due to tiling they will be x = 15 and 16, introducing a
> sharp seam in the otherwise blurry mess.

I think you mean at x' = 539 and x' = 540.

But yes I agree. Due to tiling, at x' = 539, the input pixel is sampled at x = 15.
If the interpolation were to continue (no tiling), at x' = 540, the input pixel
would be sampled at (31/1079)*540 = 15.514. Instead, because of tiling,
there is a discontinuity in the interpolation (it is reset), beginning again at
x' = 0 (540), which is sampled at x = 0 (16).

The only way I can think of to resolve this problem is to add some width
to the output tiles such that the interpolation completes a full span between
input position w - 2 and w - 1. That is, add to w' until floor(F*w') increments
to the next whole integer, where F = (w-1)/(w'-1) is the scaling factor.

But that will likely cause the next tile DMA addrs to fail to fall on the IDMAC
8 byte alignment.


>
>
>> That said, I _have_ noticed seams, but I have always attributed them to the
>> fact that we have a discontinuity in color-space conversion and/or resize
>> interpolation at the boundary between tiles.
>>
>> I've also found that the seams are quite noticeable when rendered to a
>> display overlay, but become significantly less pronounced if the images are
>> converted to a back buffer, and then page-flipped to front buffer when the
>> conversion (all tiles) completes.
> I don't know what to make of this. Maybe it is a timing issue and what
> you are actually seeing is tearing between tiles of different frames?

Yes, that's always been my assumption, a scan-out contains a mix
of tiles from different frames, when page-flip is not used.

Steve