Re: [Pixman] [cairo] pixman: New ARM NEON optimizations
Siarhei Siamashka siarhei.siamas...@gmail.com writes: Regarding the (b) part, probably as a side effect of current implementation, right now it is possible to do some operations with images having non-premultiplied alpha: src_img = pixman_image_create_bits ( PIXMAN_x8b8g8r8, width, height, src, stride); msk_img = pixman_image_create_bits ( PIXMAN_a8b8g8r8, width, height, src, stride); dst_img = pixman_image_create_bits ( PIXMAN_a8r8g8b8, width, height, dst, stride); pixman_image_composite (PIXMAN_OP_SRC, src_img, msk_img, dst_img, 0, 0, 0, 0, 0, 0, width, height); We only need to wrap the same a8r8g8b8 buffer into x8r8g8b8 and a8r8g8b8 pixman image, and use the latter as a mask for pixman_image_composite() calls. Any operations which don't need mask themselves can use this trick. By also specifying negative stride, this is useful for example when dealing with the data returned by glReadPixels(). Yeah, this is useful, and it wouldn't directly be possible to do if the equation were changed to (s OP d) LERP_m d. However, a pretty simple way to fix it would be to just add an unpremultiplied format. Benjamin's video patches had this I believe. Using such a format as a destination can be slow because it requires divisions, but Joonas has a number of optimized implementations here: http://cgit.freedesktop.org/~joonas/unpremultiply/tree/ So I find it convenient that we are also allowed to work with masks which are basically interpreted as having a8x24 format. Right, having an a8x24 format would be another way to solve the problem. Soren ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [cairo] pixman: New ARM NEON optimizations
On Friday 11 February 2011 12:30:33 Soeren Sandmann wrote: If I had a time machine, I would go back and make - among others - these two changes to Render: [...] (2) The RGB channels of Alpha-only images would be considered to be the same as the alpha channel, and not 0 as they are now. For example, a 0xb9 pixel in an a8 image would be considered equivalent to 0xb9b9b9b9 and not to 0xb900. That is, they would be considered a translucent white rather than a translucent black. These two changes together would have the effect that (a) the equation would be much easier to understand visually (composite src and dst, then clip to the mask and write back), and (b) component alpha would become completely regular with no need for the component_alpha bit in pictures. Regarding the (b) part, probably as a side effect of current implementation, right now it is possible to do some operations with images having non-premultiplied alpha: src_img = pixman_image_create_bits ( PIXMAN_x8b8g8r8, width, height, src, stride); msk_img = pixman_image_create_bits ( PIXMAN_a8b8g8r8, width, height, src, stride); dst_img = pixman_image_create_bits ( PIXMAN_a8r8g8b8, width, height, dst, stride); pixman_image_composite (PIXMAN_OP_SRC, src_img, msk_img, dst_img, 0, 0, 0, 0, 0, 0, width, height); We only need to wrap the same a8r8g8b8 buffer into x8r8g8b8 and a8r8g8b8 pixman image, and use the latter as a mask for pixman_image_composite() calls. Any operations which don't need mask themselves can use this trick. By also specifying negative stride, this is useful for example when dealing with the data returned by glReadPixels(). So I find it convenient that we are also allowed to work with masks which are basically interpreted as having a8x24 format. -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [cairo] pixman: New ARM NEON optimizations
Siarhei Siamashka wrote: On Friday 11 February 2011 12:30:33 Soeren Sandmann wrote: If I had a time machine, I would go back and make - among others - these two changes to Render: [...] (2) The RGB channels of Alpha-only images would be considered to be the same as the alpha channel, and not 0 as they are now. For example, a 0xb9 pixel in an a8 image would be considered equivalent to 0xb9b9b9b9 and not to 0xb900. That is, they would be considered a translucent white rather than a translucent black. These two changes together would have the effect that (a) the equation would be much easier to understand visually (composite src and dst, then clip to the mask and write back), and (b) component alpha would become completely regular with no need for the component_alpha bit in pictures. Regarding the (b) part, probably as a side effect of current implementation, right now it is possible to do some operations with images having non-premultiplied alpha: src_img = pixman_image_create_bits ( PIXMAN_x8b8g8r8, width, height, src, stride); msk_img = pixman_image_create_bits ( PIXMAN_a8b8g8r8, width, height, src, stride); dst_img = pixman_image_create_bits ( PIXMAN_a8r8g8b8, width, height, dst, stride); pixman_image_composite (PIXMAN_OP_SRC, src_img, msk_img, dst_img, 0, 0, 0, 0, 0, 0, width, height); That certainly is useful and I thought it was officially supported by Cairo (using a 4-channel image as a mask is the same as using the alpha channel). However I don't see how changing the interpretation of the color of a one-channel image will make any difference to this. I agree with Soeren that treating one-channel images as though r==g==b==a (ie it is a white premultiplied image) is much more useful than as a black premultiplied image and should be done. ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [cairo] pixman: New ARM NEON optimizations
On Thursday 17 February 2011 20:41:28 Bill Spitzak wrote: Siarhei Siamashka wrote: On Friday 11 February 2011 12:30:33 Soeren Sandmann wrote: If I had a time machine, I would go back and make - among others - these two changes to Render: [...] (2) The RGB channels of Alpha-only images would be considered to be the same as the alpha channel, and not 0 as they are now. For example, a 0xb9 pixel in an a8 image would be considered equivalent to 0xb9b9b9b9 and not to 0xb900. That is, they would be considered a translucent white rather than a translucent black. These two changes together would have the effect that (a) the equation would be much easier to understand visually (composite src and dst, then clip to the mask and write back), and (b) component alpha would become completely regular with no need for the component_alpha bit in pictures. Regarding the (b) part, probably as a side effect of current implementation, right now it is possible to do some operations with images having non-premultiplied alpha: src_img = pixman_image_create_bits ( PIXMAN_x8b8g8r8, width, height, src, stride); msk_img = pixman_image_create_bits ( PIXMAN_a8b8g8r8, width, height, src, stride); dst_img = pixman_image_create_bits ( PIXMAN_a8r8g8b8, width, height, dst, stride); pixman_image_composite (PIXMAN_OP_SRC, src_img, msk_img, dst_img, 0, 0, 0, 0, 0, 0, width, height); That certainly is useful and I thought it was officially supported by Cairo (using a 4-channel image as a mask is the same as using the alpha channel). However I don't see how changing the interpretation of the color of a one-channel image will make any difference to this. I agree with Soeren that treating one-channel images as though r==g==b==a (ie it is a white premultiplied image) is much more useful than as a black premultiplied image and should be done. I was worried about the 'component alpha would become completely regular with no need for the component_alpha bit in pictures' part. It sounded like this case of 'using a 4-channel image as a mask is the same as using the alpha channel' was considered to be dropped. -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [cairo] pixman: New ARM NEON optimizations
Bill Spitzak spit...@gmail.com writes: Soeren Sandmann wrote: (1) The equation would be (src OP dst) LERP_mask dst and not (src IN mask) OP dst (2) The RGB channels of Alpha-only images would be considered to be the same as the alpha channel, and not 0 as they are now. For example, a 0xb9 pixel in an a8 image would be considered equivalent to 0xb9b9b9b9 and not to 0xb900. That is, they would be considered a translucent white rather than a translucent black. Why not just try making these changes directly to Render? This is pretty much what Cairo did and nobody complained. Panicking about back-compatibility when it is likely that nobody relies on the current behavior is silly. The only software I know of using Render for anything other than OVER is Cairo, and it must be avoiding all the cases where changing this would make a difference because it does not match it's rules anyway. Well, Qt exposes these operators to applications, and there is at least one place where it depends on the existing semantics for SRC (unless I'm misreading the code). There are also drivers, including the binary NVIDIA driver, who have implemented the existing semantics already. Soren ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [cairo] pixman: New ARM NEON optimizations
On Fri, Feb 11, 2011 at 11:30 AM, Soeren Sandmann sandm...@cs.au.dk wrote: Chris Wilson ch...@chris-wilson.co.uk writes: But at the moment, about the only thing I truly want to add to the API is a LERP operator. Cairo has a slightly different definition for [clip-] masked operators where the operation is defined as: ((src IN mask) OP dst) LERP_clip dst and for SOURCE and CLEAR: (src OP dst) LERP_(clip IN mask) dst Cairo currently implements LERP as: a LERP_t b := (a IN t) ADD (b OUT t) So for example, for the typical unbounded operation (such as IN) this translates to: result = (((src IN mask) OP dst) IN clip) ADD (dst OUT clip) which currently requires 3 composite operations: dst' = dst; /* may require a blt using SRC */ pixman_image_composite (OP, src, mask, dst'); pixman_image_composite (OUT_REVERSE, clip, NULL, dst); pixman_image_composite (ADD, dst', clip, dst); By introducing the LERP operator we can reduce this down to 2: dst' = dst; /* may require a blt using SRC */ pixman_image_composite (OP, src, mask, dst'); pixman_image_composite (LERP, dst', clip, dst); Obviously, we could introduce a quaternary operator and do this in a single pass - though the complexity would seem to outweigh this rarely used slow path. So, I realized I never actually responded to this, sorry about that. If I had a time machine, I would go back and make - among others - these two changes to Render: (1) The equation would be (src OP dst) LERP_mask dst and not (src IN mask) OP dst (2) The RGB channels of Alpha-only images would be considered to be the same as the alpha channel, and not 0 as they are now. For example, a 0xb9 pixel in an a8 image would be considered equivalent to 0xb9b9b9b9 and not to 0xb900. That is, they would be considered a translucent white rather than a translucent black. Isn't it possible for pixman to dynamically do that using a new iterator type (mask)? Pixman would then only need component-alpha operators, but I'm afraid it would still need to provide fastpaths for the old non-ca operators to avoid performance regressions. These two changes together would have the effect that (a) the equation would be much easier to understand visually (composite src and dst, then clip to the mask and write back), and (b) component alpha would become completely regular with no need for the component_alpha bit in pictures. Given the lack of a time machine, a possible direction might be to add a new set of operators CLEAR_LERP, SRC_LERP, DST_LERP, ..., that would follow the equation above, and also a new format type PIXMAN_FORMAT_TYPE_W where W stands for 'white', and the missing color channels would be defined to be copies of the W channel. Even better might be to add a new entry-point: pixman_image_composite_lerp (...): that would use the LERP equation and treat alpha-only formats as described above. With either, your LERP operator would simply be SRC_LERP, but the other other _LERP operators might be useful for cairo too. For example, the ((src IN mask) OP dst) LERP_clip dst equation could become composite (SRC, src, mask, tmp); composite (OP_LERP, tmp, clip, dst); instead of composite (SRC, dst, NULL, tmp); composite (OP, src, mask, tmp); composite (SRC_LERP, tmp, clip, dst); Adding all those operators is obviously a lot of work, so I can see why it would be tempting to just add the LERP operator. However, it would annoy me to have one single weird operator that would behave according to a totally different equation than all the other operators. If it were a huge speedup, then maybe, but it seems to be that it's only useful in relatively few cases. Or alternatively, if we have to bite the bullet and add special-cased support for this, then maybe it would be better to just add the full quaternary operator as a new entry point, and not pretend it's just another regular operator. Quaternary operators would avoid the temporary image, which might provide a very nice performance boost. An even better performance improvement might be possible if the clip was handled in pixman as spans (either emitted by cairo or by a pixman polygon image). Unfortunately I don't have any data to back there opinions, but IIRC Chris has been experimenting with spans in xcb-xrender, so he might be able to confirm or correct me. Andrea ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [cairo] pixman: New ARM NEON optimizations
Soeren Sandmann wrote: (1) The equation would be (src OP dst) LERP_mask dst and not (src IN mask) OP dst (2) The RGB channels of Alpha-only images would be considered to be the same as the alpha channel, and not 0 as they are now. For example, a 0xb9 pixel in an a8 image would be considered equivalent to 0xb9b9b9b9 and not to 0xb900. That is, they would be considered a translucent white rather than a translucent black. Why not just try making these changes directly to Render? This is pretty much what Cairo did and nobody complained. Panicking about back-compatibility when it is likely that nobody relies on the current behavior is silly. The only software I know of using Render for anything other than OVER is Cairo, and it must be avoiding all the cases where changing this would make a difference because it does not match it's rules anyway. Of course if there are real examples of existing and in-use clients (ie something actually distributed on Linux systems) that rely on the current behavior then you can't change it. ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
