Hi Andre', >> Ideally, for compatibility with existing older drivers I think the >> StretchBlit behavior should be the same as before. Thus, if >the rects >> were 1:1 and if a driver obtains better performance from an >actual 1:1 >> blit being performed by the driver rather than a scaled blit that >> behavior could still occur. > >The patch doesn't change behaviour of that.
I know, I was try to suggest that only StretchBlit would use the standard graphics driver blit for 1:1 rects, AND the BatchStretchBlit would use the new logic WITHOUT the special 1:1 rect handling (yes, two real implementations the old dfb_gfxcard_stretchblit and a new dfb_gfxcard_batchstretchblit). >> I know it will complicate the implementation, but I think the >> implementation of the dfb_gfxcard_batchstretchblit function should >> allow fully disjointed GPU/CPU scaled blit operations [...] >It appears >> that your implementation will allow the fallback to CPU, but >then does >> not return to GPU operations. > >BatchStretchBlit() operates similar to BatchBlit(), which has >the same limitation. Such an optimisation could be done as a >separate step. Okay, I didn't review the existing BatchBlit implementation and didn't realize it was implemented in the same manner. I think the same recommendation should be applied to BatchBlit also. :) >Unless a rectangle is too large to fit into a hardware's >limitations, why do you think switching between CPU/GPU would >be something that happens regularly? Well fallbacks have been a viable way to handle odd cases like the one you mentioned, or if there's a precision issue when a dest rect is not fully inside a dest surface's area. The frequency of specifying a configuration a graphic driver might not handle well is highly dependent on end user content and scenario driven, not too mention how skilled a developers is, or how much time a developer has to perform performance optimizations, or even have good knowledge of DFB or the DFB app that is being ported. These considerations lead me to think it ideal to make the best performance as automated as possible. >> Another thing to consider is to add a DFXL_BATCHSTRETCHBLIT >> flag for the driver to report support for it. If not >> supported, the DFB core software should emulate by just >> calling standard stretch sblit iteratively. > >This is how both, BatchStretchBlit() and BatchBlit() work. Why >is an extra flag needed for BatchStretchBlit()? The reason I mentioned an extra flag for BatchStretchBlit was related to my earlier idea of only having the previous 1:1 rect behavior handling present in the non-batch implementation/code path of StretchBlit. It would simply allow a graphics driver to indicate if it needs the 1:1 rects specified in a BatchStretchBlit to be handled by the standard 1:1 Blit code path. Best Regards, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
