On Tuesday 15 March 2005 10:40, Lourens Veen wrote:
> On Tuesday 15 March 2005 15:26, Roland Nagtegaal wrote:
> > I have included a weppage by Linas Vepstas about designing graphics
> > hardware in such a way that it is easier for the OS to make
> > graphics access crash-proof, secure, but still fast.
Hi Lourens,
> Yes, this has been discussed before. This document is very useful
> however, since it puts everything into one place, and I bet Timothy
> has it marked for future reference already. The current consensus is
> that it would be very nice to have (but not absolutely essential,
> since other PC hardware doesn't have it either), but as with every
> part of this design, it depends on the amount of available gates
> and/or chip surface whether it can be implemented. We will have to
> see how it goes.
The Vepstas proposal is overkill, which is proved by example as you say.
There is certain functionality that is essential though. I'm working
myself up to submit what I hope is a comprehensive proposal on security
and the DMA/interrupt model. Security and DMA are inseparable if we
want unprivileged tasks to be able to submit command lists.
The problem is easy if we: a) require unprivileged tasks to submit
commands via a software interface that translates them to hardware
commands, or b) parse each command list before submitting it. But in
the interest of efficiency, I think we should at least try to come up
with a model that avoids these bottlenecks.
I think the following rules cover what we really need:
* Only privileged tasks (or kernel) can directly initiate DMA, an
unprivileged task must go through DRI. This is enforced by
only allowing an unprivileged task to submit indirect DMA. (DMA
obviously can't be initiated from an indirect DMA command list.)
Direct DMA, i.e., the command ringbuffer, may only be submitted
by DRM/DRI.
* Only privileged tasks can directly define or position the hardware
cursor.
* An unprivileged task cannot draw outside its own window, which is
enforced by the ownership test in cooperation with the X server
* All drawing commands are submitted as DMA commands, PIO is used
only for DMA setup, soft reset, interrupt control and similar. PIO
is only available to privileged tasks. (Timothy stated earlier that
defining the hardware cursor should be done by PIO, though I don't
really understand why that is better than submitting it through the
ring buffer)
Did I leave any holes?
In the "future" category, I think we need to plan now how asynchronous
background DMA will work, even if it isn't implemented in the initial
release. This capability really isn't optional. We just can't afford
to have all drawing grind to a halt every time a texture loads.
I'd have already posted a full proposal, except that I don't yet have a
clear picture of how buffer low/empty events will be fielded by normal
tasks. This requires delving into the innards of DRM and other things,
deeper than I've had time for so far. If anybody has already looked at
this, please shout.
Regards,
Daniel
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
