Messages in this thread | | | Date | Fri, 24 Dec 1999 10:11:17 -0500 (EST) | From | James Simmons <> | Subject | Accel Hnadling (was Re: Thread-private mappings and graphics) |
| |
Soory I didn't write earlier. I have busy with the holidays. Also I will not be around until Sunday. Also you sound very knowledge. How about joining my list (http://lists.sourceforge.net/mailman/listinfo/linuxgfx-dev), I could always need helpful input. We can move this thread to their :)
> Why? I think it would be much better to have user space check the > watermarks
Userspace cannot overflow a hardware FIFO. Only the kernel code can do that, and you may or may not want the userspace -> kernel FIFO behavior to match that of the kernel -> hardware behavior. Userspace should wait on a semaphore or something.
> and flush the buffer as it reaches each water mark.
Userspace should not be telling the kernel when to flush the kernel's buffers, only its own. Even if the hardware watermarks must be polled (no IRQs), those belong to the kernel.
> Or at > its option, some other policy. (Timer signals, optimal icache points > between major rendering units, that sort of thing).
Sure, through a generic explicit-flush mechanism.
> I recall experiments with functional language memory allocators. They > allocated memory from a large region by simply incrementing the > address. Something they had to test was when the allocation reached the > end of the region, to trigger a garbage collection. > > Two approaches were tried. One using a pages fault at the end and > trapping the SIGSEGV, the other explicitly comparing the address on each > allocation. The explicit compare won. > > That was just one fault every <insert large block of memory>. You are > proposing faults much more often.
Not really, and especially not when the load is high. When you are doing something like moving windows in X and the accel load is really low, you can afford to fault quite often (relatively speaking) without the resultant system overhead being too bad. In some cases the 4K intel pagesize minimum buffer size may turn out to be too large, and most flushes will be explicit from userspace or automated via the VSYNC IRQ handler to keep things running smoothly.
With Quake3, although you have a huge stream of primitives to pass to the kernel, you are going to be producing so many of them per frame at such a steady rate that you can drop the number of pagefaults quite dramatically and still be able to get a frame's worth of data to the kernel. The technique scales very well because of this factor, even on SMP.
> One obvious complaint about using page faults is the overhead of > updating mappings. Inter-CPU TLB flushes are particularly expensive.
See above. You don't end up having to do them often enough that it becomes a problem. Overhead from the Linux fault handling code is an issue, but rawio and friends in 2.3 may be able to obviate some of the problem.
Also another note about using page faults to handle accel access. Everyone is worried about Inter-CPU TLB flushes. Their was a discussion about this as well as fork threads and exec effects on the accel engine. Remember OpenGL is designed around a graphics pipeline and each part of the pipeline could have different grpahics context state. As you go down the pipeline you switch the context state. Whats does this have to do with the kernel handling. Well each process, which will be in each part of the pipeline, must have a private grapohics context to self and a private mapping. This means if a process mmaps a accel resource only that process can only have access to it at the time its scheduled to run. If the process forks and wants to use the accel resource then it must mmap it as well. This way it will also have its own private graphics context and private mapping. If a child tries to use the parents accel resource then it segfault. Also when you context switch the process this way you only have to flush only the local TBL.
James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net
- 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/
| |