lkml.org 
[lkml]   [1999]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread-private mappings and graphics (was Re: Per-Processor Data Page)
James Simmons wrote:
> [a lot of interesting arguments against user-space direct rendering]

IMO, a lot points very well made.

Worrying about an "ioctl 100 times a second" is a wasted thought.
You'll call gettimeofday() at least that often as well as a whole bunch
of syscalls for keyboard/mouse/joystick input and so on. User/kernel
and back transitions take <1 microsecond. At the rate of "per frame" or
even more often they are not significant.

An ioctl per rendering primitive is of course far too high a cost.

An interface based on the idea that user space fills a command buffer
and then flushes it to the kernel, with the kernel translating that to
rendering h/w commands, seems perfectly reasonable.

Having the kernel auto-flush the buffer as it is filled by using page
faults (not necessarily every page) is not a terrible idea. Not just to
improve latency: it would reduce data cache flushing too.

But it is probably better for the user-space buffer filling routines to
flush when /they/ decide to flush, and would surely give better
performance overall. (Page faults and mapping updates are not free, and
quite expensive on SMP). This gives user space more flexibility in
choosing the optimal flush points, which is good because the optimal
flush points are probably far from obvious and application dependent.

This suggests that maybe a user space driver would be enough, as a
separate process (like the X server) to multiplex and validate commands
from different apps. Context switches, especially when one process
sends control data over a pipe and bulk data through shared memory are
very fast in current kernels. This would work, but as James points out,
there are hardware facilities that only the kernel can use effectively.

A hard part is designing a good command buffer format, to minimise
memory bandwidth while keeping the hardware translation layer simple and
fast. For the sake of simplicity, the same format across different
hardware makes sense. Perhaps for older, slower hardware?

But for top of the range performance, a format optimised for the final
stage of verification and translation for the particular hardware is
perfectly acceptable. This doesn't compromise the security, it gives
top speed and the wonders of shared libraries mean the user space
portion can also reach top performance. For the best hardware, if it
will verify all commands itself and transfer command blocks using DMA,
this method is equivalent in speed to user space direct rendering
without the disadvantages and security impliciations.

btw, there are ways and means to overcome the OpenGL non-reentrant API
problem, transparently to the application, and it is a separate problem
to the direct rendering stuff discussed here.


Summary:

- no page faults

- no per-thread mappings

- "direct rendering" performance possible on high end hardware

- reasonable performance on lesser hardware (speculative :-)

- secure; user space cannot trash system

- overhead due to kernel negligable; benefits due to kernel driver available

have a nice day,
-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.292 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site