On Tue, Dec 1, 2009 at 7:54 AM, Lindo Lonappan <li...@tataelxsi.co.in> wrote: > Dear Lionel, > > Thanks for your reply. Please see my reply inline. > > Thanks & Regards, > Lindo Lonappan. > > Lionel Landwerlin wrote: > > On Mon, Nov 30, 2009 at 11:40 AM, Lindo Lonappan <li...@tataelxsi.co.in> > wrote: > > > Dear all, > > We are using IDirectFBSurface::Blit() call for surface rotation. > Our hardware doesn't support surface rotation. We are using the software > fall back provided by DFB-1.4.2 for this. > > We observe that surface rotation is faster if we create surface in the > system memory. There is an extra time of 200ms for rotation if we create > surface in video memory. > But since we have hardware fall back for other operations we need to use the > video memory. They will have better performance in video memory. > > 1. why the rotation in system memory faster than video memory? > > > Probably because video memory is mapped uncached (that's usely the case > with frame buffers). > > > > I don't get this reply exactly. I am not very good in device driver part. > Can you please explain this?
On most system on chip dealing with audio/video, there is usually no difference between video memory and system memory. The difference is the way you're using it. When you're using an hardware accelerator, you have to take care that memory area used by the accelerator is not used at the same time by the CPU (because of the CPU cache). Otherwise, you will get cache coherency problem (garbage in your graphic/video buffers, etc...) So the easiest way to deal with that coherency problem is to not use the cpu cache for video buffers, by mapping them uncached (this is normaly done in your framebuffer driver, have a look at the mmap handler of the driver). > > 2. We guess in the case of video memory there is some overhead of switching > between kernel and user space since we are using a software fall back for > rotation. Is this is correct? > > > There is no switch kernel/user when using the software fallback. > > > > Thanks for correcting me. > > 3. Is there any way of creating surface which will not have any performance > difference in both hardware and software fall back? > (ie We need to create a surface which will give a performance of system > memory for surface rotation and a performance of video memory for operations > supported by our hardware.) > > > You will have to use cached mapping for your buffers and correctly manage > cache > synchronization in your gfxdriver. > > > > Thanks for the reply. One more question is the pointer returned by Lock() is > memory mapped ? Question is because even if i tried to rotate( or mirror > image) the surface with some algorithm(which requires memory copy) there is > also a performance difference for system memory surface and video memory > surface. In that case also system memory have the better performance. The Lock method return a virtual address inside the mapped buffers area, so if the memory is mapped uncached you will get slower performances. > > Thanks a lot in advance!!! > > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
