Am Mittwoch, den 03.08.2016, 17:18 -0700 schrieb 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 contnue (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. I always wanted to have a look at the scroll feature, maybe SX can be used to start at odd pixels? regards Philipp _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
