Hello, On R, 2012-02-24 at 15:48 +0100, Christian Gmeiner wrote: > Hi all > > I have compiled a version of the driver with GEODE_TRACE_FAIL enabled > and got this messages: > > lx_check_composite: Masks can be only done with a 8bpp or 4bpp depth > lx_check_composite: Transform operation is non-trivial > lx_check_composite: pSrc should be 1x1 pixel if pMsk is not zero > > Is there some potential for improvements?
Does these happen often in the middle of other operations that are hardware accelerated, as such causing heavy pixmap migration ping-pong and huge perfomance slowdown due to that? >From the driver level, there may be some potential improvement possible depending what the actual details of the operation are. "Masks can be only done with a 8bpp or 4bpp depth" happens if the given alpha mask is, well, not 4 or 8 bits per pixel depth. I can imagine some optimization possibilities here if all the alpha pixel values could be transformed without loss of detail to a temporary 4bpp or 8bpp alpha mask instead, e.g if the mask is actually 1bpp, 2bpp, or if it's 16bpp or 24bpp with the least significant bits somehow not mattering (not sure what the depth conversion logic here is offhand for them to not matter if converting depth down). Perhaps you could try printing out the actual value of pMsk->format there and see what the depth and other details are when it fallbacks most often. It seems you can get details of the format with the following macros: PICT_FORMAT_BPP(pMsk->format) PICT_FORMAT_TYPE(pMsk->format) PICT_FORMAT_A(pMsk->format) PICT_FORMAT_R(pMsk->format) PICT_FORMAT_G(pMsk->format) PICT_FORMAT_B(pMsk->format) For comparison, PICT_a8 would be 8bpp, type PICT_TYPE_A, and values of 8, 0, 0, 0 for A, R, G, B - those tell how many bits per pixel for alpha, red, green and blue channels are used. "Transform operation is non-trivial" should happen basically if the transform isn't just a full degree rotation, as the Geode hardware can do only 90, 180, 270 degree rotations basically; which is important to have for rotated screens. Depending on the actual transformation, perhaps something tricky can be figured out to do it, as it isn't necessarily some kind of rotation, but could be a different kind of transformation in there - so according to the exact details of nature of it, perhaps something could be done to hardware accelerate it. "pSrc should be 1x1 pixel if pMsk is not zero" happens when it tells it happens. I'm not sure if we could do something with more complex sources with masks than just a pixel. Needs some thinking there. All these fallbacks would also be less costly, if we didn't end up migrating the pixmaps out temporarily from video memory to system memory. I believe that theoretically pixman based software fallbacks could be done inside video memory, but I didn't get EXA classic mode convinced of that yet to try it out. As in, video memory is really just CPU memory too, just framebuffer memory set aside into which hardware accelerated operations can put their result in; so if we were doing software operations in there as well if there's enough room, without migrating out of there, we could avoid the costly part of copying memory around too much and fix it for all cases to not be SO big of a performance hit, while it'd be still nice to do in hardware what is possible. If you have a custom drawing code you need to have fast, then an alternative could be to change the drawing operation at the application level as well. But that's not really feasible for a generic desktop system or so. Best Regards, Mart Raudsepp _______________________________________________ Xorg-driver-geode mailing list Xorg-driver-geode@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-geode