Messages in this thread | | | Date | Mon, 20 Dec 1999 17:54:03 +0100 | From | Jamie Lokier <> | Subject | Re: 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/
| |