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-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
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.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
