On 10/10/05, Johannes Berg <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-10-07 at 17:41 -0400, Timothy Miller wrote:
>
> > The second source of commands is the indirect buffer.  Indirect
> > buffers are linear stretches of commands.  They can be privileged or
> > not, as specified by a flag in the ring buffer packet that initiated
> > the indirect transaction.
>
> I take it that an unprivileged indirect buffer cannot upload/download
> things since that would allow it to read arbitrary memory. I thought
> that maybe it would be advantageous to allow an unprivileged indirect
> buffer memory uploads as well, from within the buffer area.

Yeah.  The inline one is unprivileged.

>
> For this, you'd need a second permission bit of course (if this kind of
> access is allowed) and a kind of jump command that would allow jumping
> within an indirect buffer. Then, the (kernel) driver could allow some
> process to use some kind of larger buffer it owns for commands including
> uploads, and that stretch of commands could use a jump to skip over a
> data area. The card would have to validate all memory uploads that
> originate from within this area to only use addresses within this, of
> course.

If the driver overhead isn't much, it won't matter.  If you want to do
an arbitrary copy, just use the driver API and request it.  The driver
will check your pointers, validate them, possibly split things up for
scatter/gather, and then submit it if it passes.

I don't feel the desire to add extra hardware to indicate
pre-validated host memory buffers.  Anything involving arbitrary host
addresses has to go through the driver.  And the only commands that
don't need to be validated are ones that could only mess up the GPU.

If you requested a 65536x65536 bitblt, that would be bad, causing the
GPU to appear to hang for a very long time.  For that, the driver
would have to use a watchdog timer and reset the GPU (and probably
kill the offending process, if it knows who did it).


>
> I'm not sure if this is worthwhile from a programming perspective at
> all, or doable in the hardware; it was just some random idea...

Doable is not necessarily practical, at least not now.  Some of the
security may be inconvenient and created more overhead, but this is
one of the reason for the "almost empty" sorts of interrupts that let
you submit more commands before the GPU is even finished.

This design does require a significant CPU load.  I mean, all of the
vertex stuff is done by the host CPU.  Some extra driver overhead
won't kill us.

_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to