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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
