I'll take a shot at qualifying what is is that KGI wants:
Yes, we definitely want page-fault handlers if we can possibly
get them:
1) For fossil cards where the aperture is smaller than the VRAM,
with impossible-or-dangerous-to-expose-to-userpace aperture
control. Also this provides naive applications with often desired
contiguous direct buffer access.
2) For fossil planar mode cards with dangerous-to-expose-to-userspace
plane-mask controls, to allow for direct access to different
planes/plane-masks such that naive applications need not
explicitly use an IOCTL to set the plane masks. *
3) For resources of lower access privilage which are move around
inside an aperture of higher privilage (e.g. if an area of VRAM
controlled by a normal application must be relocated in VRAM
by a session leader.)
4) For policing access to RAM, usually DMA-capable RAM, such
that the application can write accelerator commands to a
page and submit the page to the kernel, which then revokes
write privilages until the page has been proofread and
swapped for a clean page such that it can be executed asyncronously,
while the application obliviously continues to write commands.
Page faults and blocking behavior are needed in this case in
order to provide a ring-buffer-like feel to applications that use
the ring-buffer paradigm for command FIFOs, and doubtless they
will become useful in implementing a display-list paradigm as well.
In a perfect world, a user application would be able to explicitly say
where it wants pages mapped (and which command-queue pages are ready
for execution) by altering some shared memory that serves as a control
interface to the VM, and as long as the application's request is sane,
the requested mapping would occur on the next page fault on the existing
mapping, explicitly through IOCTL, or asyncronously as desired (obviously
we need to work on advisory locking for the VM control/status interface.)
The items listed above could all use such a mechanism to acheive secure
access, but in addition to that, the sugar of emulated ring buffers and
emulated contiguous apertures using page faults are minor technical
enhancements that are major API improvements, as they ease porting
applications that were coded to graphics systems that had those features.
Under Linux a few mods to speed up the VM are needed, as we can
demand that the userpace application not attempt anything esoteric
under penality of death by the kernel and thus remove some cruft, but
basically other than that we can define our own VM fault handler
that remaps things as we please... what's the story under FreeBSD?
* Why support such cretinous hardware? Laptops. Especially of the
non-x86 variety.
--
Brian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
