well back to our cows... I get frames from bt848 at 25 fps - F_CIF (710x576 YUV420 i.e. 12 bits) -0% cpu usage if I just discard them.
since I get them in mmap'ed driver area and not shared memory, I use single memcpy to copy them to one previously allocated shared memory - 25% CPU time. Now XvShmPutImage - 50% CPU - pretty predictable since it also does memcpy's for the same buffer no compression goes in a middle. BTW it goes very well with observation that 250 loops of memcpy(...); usleep(30000) take exactly 10 seconds meaning that memcpy takes 10 milliseconds. multiplying by 25 = 250ms -> 25% putting DMA might save about 25%... another 2 questions: 1) may be I should just use some optimized version of memcpy? someone knows of MMX or SSI uses in glibc? I have very defined hardware to run on... 2) offtopic: does somebody know how to access shared memory from kernel space ( may be I will fix bttv driver to write directly to shared memory, this will save me another 25%...)? any help? ----- Original Message ----- From: Sottek, Matthew J <[EMAIL PROTECTED]> To: 'Michael Zayats' <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, October 09, 2001 5:39 PM Subject: RE: [Xpert]XVideo consuiming to much CPU > Michael, > If you are only able to get 25fps then there is something wrong > in your application. I know of Xv based mpeg decoders that can > do full DVD sized frames at 30fps without issue, and the vast > majority of the cpu is taken up with the mpeg decode not the > transfer. I myself have done Xv tests that can peg the framerate > at 99fps when the vertical retrace is 100 (this was with a smaller > 320x200 mpeg1 stream) This was with a modest PIII cpu. > The bottom line is this, doing a blit from system memory to the > framebuffer or some other DMA transfer could offload a little bit > of cpu usage, but it isn't going to make anything "faster" the > overlay can only flip buffers on vertical retrace and even a > slow cpu should be able to keep up. Using the blit/DMA you will > then either have to wait for the transfer to complete or have > something else poll to find out when the transfer completes and > then flips the overlay. That makes a mess of a pretty simple > problem, all to save a little cpu. > Keep in mind that the memcpy isn't really that bad on i810 > since it is sharing memory bandwidth with the system instead > of actually being behind a pci bus. > > -Matt > > -----Original Message----- > From: Michael Zayats [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 09, 2001 3:05 AM > To: Mark Vojkovich > Cc: [EMAIL PROTECTED] > Subject: Re: [Xpert]XVideo consuiming to much CPU > > > > > > The i810 driver will not display video faster than the vertical > > retrace. If you send frames faster than that, it will busy wait > > until the next retrace. What you are seeing is the expected behavior > > on i810. > > I send 25fps and as Peter already mentioned (and I checked it) it's > because of memcpy use instead of DMA in XVideo i810 driver > > > > > > > Mark. > > > > _______________________________________________ > > Xpert mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/xpert > > > > _______________________________________________ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
