Re: [Pixman] On sampling (Re: Add a new benchmarker targeting affine operations)
On 04/24/2015 07:31 AM, Pekka Paalanen wrote: Would it be good to set a rule of thumb, that when you are scaling images, first compute the final size, and then compute the transformation paramaters for Pixman, regardless from which one you start with? If I understand what you are asking for, the answer is no. When scaling images do not be confused by the pixel size or pixel centers. The correct transform is the one that places the outer corners of the source image (ie integers 0,0 and w,h for the entire contents of a w,h sized image) at the outer corners of the desired destination quadrilateral. This will produce the correct filtering and the correct position for the image. If you gradually change the destination rectangle, the image will scale smoothly with it. Another way to look at is that this rule is the one so that if you transformed to an intermediate image and then did a further transform to the final, the result will not be shifted or scaled differently (it may be blurrier but that blur will be centered with no visible shift). The confusion is that filtering will sample outside the source rectangle, and the filtering can produce non-zero outside the destination rectangle. This effects the calculation of bounding boxes, and yes it gets complicated if you want an accurate bounding box. But you should *not* use this to determine the desired transformation. ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
[Pixman] pixman fails to build on mips32r2
Hi, Pixman has been failing to build on mips32r2 since 0.32.6. Can the patch posted in this bug report be applied to fix it? https://bugs.freedesktop.org/show_bug.cgi?id=83358#c1 Thanks, James signature.asc Description: This is a digitally signed message part ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
Ben Avison wrote: > > Unless someone has forked Pixman somewhere else, then no, there is no > special support for AArch64. The existing ARMv6 and ARMv7 optimisations > are all hand-coded assembly, so can only be built for the AArch32 > instruction set. If you run an ARMv8 in AArch32 state, then I would > expect the ARMv6 and ARMv7 optimisations to still work - in AArch32 > state, ARMv8 is only incrementally different from ARMv7 - but I have a > feeling that Apple only run their ARMv8 chips in AArch64 state (BICBW). You are correct, Apple specifically runs these chips in 64 bit mode. Pixman rendering without optimization is pretty slow even on those processors. > > There is still code in Pixman, first added at 0.24, to determine which > ARM features are available when building for iOS - it's just in > pixman-arm.c now rather than pixman-cpu.c. However it makes no attempt to > factor in the AArch32/AArch64 state before enabling the ARMv6 and ARMv7 > optimisations. You'd also need some magic in the build system so that it > doesn't even attempt to assemble any of the AArch32 assembly source files > in an AArch64 build. 0.24 is the version I am using, and it never built "natively" (i.e. using configure script) for iOS. There was, as I recall, an issue with iOS assembly being incompatible with gnu/Linux toolchain for which pixman assembly code was written. Someone instead posted manually created (I think through assembly/disassembly on a Linux box) file that was manually added to the pixman build. At least that's what I still have in 0.24. I tried current version and encountered the same issue - essentially optimization assembly is not compatible with current Apple compiler. > > If you're having trouble even building the ARM optimisations for AArch32, > you might want to try building intermediate versions of Pixman until you > can narrow down where it stopped working. It sounds as though, unless something changed dramatically, iOS tools are still not compatible with assembler used in pixman so they are unlikely to work. If anyone wants to take a look at it, I am glad to help build anything - but my own knowledge of assembly code is pretty rudimentary. ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
[Pixman] On sampling (Re: Add a new benchmarker targeting affine operations)
On Thu, 23 Apr 2015 17:12:59 +0100 "Ben Avison" wrote: > On Thu, 23 Apr 2015 12:46:56 +0100, > Pekka Paalanen wrote: > > > I'm guessing yes, because you do that in affine-bench, reversed... am I > > on the right track here? > > Affine-bench only uses integer translation offsets, and it only uses any > at all to ensure it's only testing the COVER_CLIP case. This means it's > effectively testing the scale-from-pixel-edges model, and if you aren't > testing reflection, rotation or anything else that involve negative > transform coefficients, and you weren't testing bilinear scaling, then > you could get away with passing src_x and src_y = 0 to bench(). > > You may be getting a bit confused by the fact that when calculating xmin > etc in main() that I unconditionally half a pixel extra space. Normally > this is only relevant for bilinear scaling, but a source image that > satisfies COVER_CLIP for bilinear scaling will always satisfy COVER_CLIP > for nearest scaling too, and I wasn't too concerned with allocating one > pixel too many here and there. Ah, didn't realize that indeed. > > Ok, yeah. Since Weston is working with geometry rather than pixels, I > > think that works just fine... except for the left or top edge, which > > like you said for the pixel occupancy rules, would be accounted to an > > outside pixel. Sounds like should be removing pixman_fixed_e in Weston > > from the source area left and top or something to hit COVER_CLIP. > > Remember, affine-bench is doing things kind of backwards compared to what > most use cases would be. It has a fixed size destination buffer and has > been told to use a particular affine transform, and it's trying to work > backwards to find out how large a source image it needs to start from to > be able to achieve this without having to invoke source image repeat. Yes, that is what I mean by "reversed". > I imagine most of the time, you'll have a source image of fixed size, and > you'll either have a target destination size (in which case your task is > to calculate the transform matrix coefficients) or you'll have a target > scaling factor (in which case your task is to work out the destination > size that can be achieved without running off the sides of the source > image). Right. On Thu, 23 Apr 2015 18:13:56 +0100 "Ben Avison" wrote: > On Thu, 23 Apr 2015 17:12:59 +0100, I wrote: > > I imagine most of the time, you'll have a source image of fixed size, and > > you'll either have a target destination size (in which case your task is > > to calculate the transform matrix coefficients) or you'll have a target > > scaling factor (in which case your task is to work out the destination > > size that can be achieved without running off the sides of the source > > image). > > Just to add to this, an example has come to mind that demonstrates why > higher level software should really know about the pixman_fixed_e offset > for nearest-neighbour scaling in order to make best use of Pixman. > > Assume we have a source image that's 101 pixels wide, and we know it has > to be plotted at a scale factor of 50%. How many destination pixels do we > tell Pixman to plot? > > In reality, given a transform matrix whose diagonal is (0.5, 0.5, 1), > Pixman is capable out picking out source pixels with index 0, 2, 4, 6 ... > 100 - that's 51 pixels - whilst still using a COVER_CLIP fast path. If it > weren't for the pixman_fixed_e offset, it would pick out source pixels 1, > 3, 5, 7 ... 99 instead - that's 50 pixels. > > Now, if the caller asks for 50 pixels and Pixman uses the offset, then we > get to use the COVER_CLIP fast path, but we've trimmed two pixels off the > right and none off the left. > > But if the caller asks for 51 pixels and Pixman doesn't use the offset, > then Pixman realises it needs a value for out-of-bounds pixel index 101 > so won't use the COVER_CLIP fast path. > > So, for the best combination of image quality and speed, the details of > Pixman's rounding algorithm *can* be significant. Yes, that is a nice example, I would have never thought it like that. You are starting with the assumption that the user demands scale 0.5, and then computes the resulting width. The scale is fed directly into the matrix. Would it be good to set a rule of thumb, that when you are scaling images, first compute the final size, and then compute the transformation paramaters for Pixman, regardless from which one you start with? I'm going to bookmark your email, your explanations are so thorough and with excellent figures that it can be used as a reference. :-) Thanks, pq ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [PATCH v3] test: Add a new benchmarker targeting affine operations
On Thu, 23 Apr 2015 20:28:58 +0100 "Ben Avison" wrote: > On Thu, 23 Apr 2015 13:10:10 +0100, Pekka Paalanen > wrote: > > > Affine-bench differs from lowlevel-blt-bench in the following: > > - does not test different sized operations fitting to specific caches, > > destination is always 1920x1080 > > - allows defining the affine transformation parameters > > - carefully computes operation extents to hit the COVER_CLIP fast paths > [...] > > did I capture all the special features affine-bench has over > > lowlevel-blt-bench? I see llbb could use a transform too, and > > was looking at why extending that would be unwanted. > > Yes, there's some support in lowlevel-blt-bench for scaled plots, but > it's limited to a single scale factor - it's the smallest expressable > increment larger than unity, corresponding to an oh-so-slight size > reduction, and is applied only in the X axis. The fact that lowlevel-blt > bench doesn't attempt anything more than that means it can make some > simplifications: > > * the source and destination buffers can be the same size as for the >unscaled case > * automatically satisfies COVER_CLIP_NEAREST (although when I was >analysing the flags yesterday, I was reminded that before I removed the >8*pixman_fixed_e fudge factor, lowlevel-blt-bench's bilinear operations >were incorrectly calculated to *not* satisfy COVER_CLIP_BILINEAR) > * no need to add translation offsets into the transform matrix > * one pixel row in = one pixel row out greatly simplifies the >calculations about what can fit in L1 and L2 caches - this is why I >deliberately only tested the memory-constrained case in affine-bench. >For example, in a 90-degree rotation, each new output pixel in a row >will require reading from a different source cacheline. > > When I was writing the ARMv6 scaled fetchers, I became aware that they > were going to take quite different code paths in the enlargement vs > reduction cases, as well as when a vertical scaling factor was involved. > I needed to be able to benchmark all these combinations in order to > select the best prefetch distances, if nothing else. I also realised > there was currently no way to benchmark other common affine transforms > that I might want to address in future such as reflections (including > those used by the reflect repeat type) or even simple rotations, so with > the difficulties of ensuring COVER_CLIP_BILINEAR too I just decided it > would be easier to write a new benchmarker. Yes, very good. Also forgot to say, that I didn't bother changing the CLI for affine-bench to use llbb's pattern parser. I figured it wouldn't be that important. We already use the same operator and format name lookup tables anyway. > I've reviewed your version, looks fine to me. A very minor point: I'm not > sure it's worth making a copy of the transform struct at the start of > bench() because we mostly only use a pointer to the struct thereafter, so > you might as well have kept using bi->transform. Thank you, I'll take that as R-b. I make the copy for the sake of the API. I wanted to use const arguments as much as possible to avoid confusion later on about what values were actually changed or not. I assumed it wouldn't make any difference to the benchmark results. Thanks, pq ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
