From: <bug...@fr...> - 2005-07-15 18:33:00
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3791 Summary: PCI DMA bitblt support for unichrome Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: DRM modules AssignedTo: dri...@li... ReportedBy: uni...@sh... Before going on vacation I'd like to post this patch for review. It adds PCI DMA bitblt support for unichrome and unichrome pro chips using the via drm. It's not totally finished but almost so. There are some security concerns that I have: The mechanism works as follows: 1) The userspace app submits a blit request and gets a sync handle. 2) The kernel locks relevant pages in memory. 3) The kernel performs a DMA mapping. 4) The request is queued pending blit engine idle. Up to 8 queue slots per engine. If the slots are all busy, the initial submission will block. 5) The blit is scheduled by the interrupt handler. 6) The kernel unmaps the DMA mapping using a workqueue task 7) The kernel unlocks the pages, and awakes any sync request from the user app, also in the workqueue task. Security concerns are 1) What happens if the application dies or frees up the memory while the blit is in the queue? If the kernel refcounts the number of times the page is locked than this shouldn't be a problem and the page is released when it is unlocked by the blit code. 2) As above, but a second blit referencing the same user pages is queued behind the first one. What happens when the pages for the first blit is unlocked. Again, if the kernel refcounts page locks then this is not a problem. 3) Same situation as 2. What happens when the DMA mapping for the first blit is released? Will this affect the DMA mapping for the second blit. Apparently unmapping a DMA mapping on x86 is a Noop, but not for all x86_64 configurations. Are DMA mappings refcounted? If not, this is not neat. If any of this is a concern, one might be better of using a big bounce buffer in the kernel, also considering the alignment constraints. Copying to and from a bounce buffer should be fairly fast also compared with PCI DMA. Judging from performance test PCI DMA BitBlt is fairly slow for copying data to the frame-buffer. About 75MB /s, and the same from the frame buffer. But in the latter direction it is a big improvement. Also it uses very little CPU for settimg up the mappings. On architectures with fast CPU and slow system-to-framebuffer bandwidth even copying to the frame-buffer should be a big gain in CPU usage. For example on a K8M800 Athlon 3400+, Xv playback of a DVD requires above 20% CPU for X just for copying data to the frame buffer. Using this PCI DMA code, I'm down to around 1%, but the theoretical maximum frame-rate should be less. Some Unichromes have broken IRQs. They generate about 300000 spurious IRQs per second and the IRQs are disabled by the kernel, since nobody recognizes them. There's a low frequency polling scheme implemented for those, which is based on the looping frequency in the DRM_WAIT_ON() macro. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |