On Monday 28 February 2005 06:24, Daniel Phillips wrote: > On Sunday 27 February 2005 09:37, Nicolai Haehnle wrote: > > > Protected Mode > > > > Definitely an important requirement, and this translates nicely to a > > command buffer based programming mode. This has been brought up on > > this list before. I'm not sure what the final word is (or if there is > > a final word). > > I do not recall that there was any compelling argument raised to prove > that more than one process (the X server) needs to issue commands > directly to the card. There is no need to burn precious real estate > blazing a trail here.
Actually, all 3D clients need to issue commands (kind of) directly (that's why it's called the Direct Rendering Infrastructure, after all). We have to push the rasterizer setup data across the PCI bus. The kernel DRM must be able to garantuee that the data supplied by userspace cannot do anything nasty to the system as a whole. This can be done the hard way, by manually parsing the entire rasterizer setup data in kernel and copying it to an in-kernel data buffer in the process. Or we could rely on some kind of protection in the hardware itself. *That* is what is meant with "Protected Mode". There are any number of schemes for this kind of protection. For example, there could be a separate buffer format for rasterizer setup data (different from the normal command ring buffer, that is). Alternatively, all privileged command codes could have the least (or most) significant bit set to 1, while unprivleged commands have that bit set to 0. Since command codes are pretty much arbitrary numbers, this shouldn't be too difficult to do. Protection is then just a matter of failing to process commands that have the "protected" bit set. This is the same idea as the idea behind "separate registers into different banks". And of course, I'm sure you can think of a number of variations of these schemes. So I believe doing this in hardware is *a lot* easier and faster than doing it in software. [snip] > > > Per-Window Double Buffering > > > > Just blit from a per window back buffer to the screen. This also > > interacts with compositing etc. In any case, I don't think it's a > > problem for the hardware. > > I don't think so either, but I'm not quite prepared to prove it. X does > manage to animate multiple windows of hardware accelerated GL on my > machine here, and I seriously doubt the i845 supports any fancy > per-window logic. As far as I know, all DRI drivers use a simple blit for the swap buffers call by default, and page flips as an optimization when possible and enabled. > > > FIFO's > > > > Yes. > > One fifo should do, the command ring buffer. Per-process command lists > sound nice, but I don't see what they would be used for. Some means of indirect buffers are necessary for performance: User space writes all non-protection-critical stuff into a DMAable memory area that is supplied by the kernel. User space then instructs the kernel to issue an "indirect buffer" command using this memory area, and the graphics card will simply read the commands via DMA. This way, we can transfer all the rasterizer setup data in the most efficient way possible: User space can write directly into a DMA buffer that will then be read directly by the graphics card. We don't have to do intermediate copies or validation passes in the kernel. And no, I don't think the hardware needs explicit support for per-process command lists. cu, Nicolai > Regards, > > Daniel
pgpKtxiRTMrQO.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
