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. > > Hardware Cursor > > I do believe we have this. I don't think any specifics have been discussed. It would be nice to not have to bother the memory controller about this, it already has enough to worry about. So how about using block ram for the cursor? RGB cursors should be supported, even if hardly anybody uses them. The color doesn't have to be full 24 bit though. Alpha blended cursors would be nice, but messy hardware-wise. One bit alpha is probably the right choice. Limiting the cursor to 32x32 is probably ok, since other hardware has similar limitations. A 32x32 cursor with 6:6:5:1 rgba will fit in a single 1024x18 block ram. There could be a dedicated "load cursor" command with cursor data inline, or a cursor could be loaded as a normal rgba texture and have an "activate cursor" command, giving the texture address and dimensions (always 32x32) which loads the cursor into block ram. X actually defines a cursor in terms of two bitmaps and doesn't know anything about RGB cursors, as far as I can tell, but Windows does. I didn't dig far enough to find out what limits X has for cursor size, if any, or how the fallback from hardware cursor to software cursor works. 32x32 is a typical limitation for display hardware. Anyway, the required format conversion can be handled in the driver. X supports specifying colors for cursor foreground and background. so this has to be handled in some way, even though I've never seen any actually use this feature. There is no point in supporting cursor control through the command buffer, as far as I can see. Timothy has mentioned providing a command to set/get any register through the command buffer, but what I'd rather see is all functions divided up strictly into register-controlled vs command-controlled. I doubt there is any overlap. Cursor position and enable/disable is one of the few functions that needs dedicated registers, because cursor positioning has to be immediate, not delayed by the geometry backlog. Just a few notes, hopefully to start some discussion on cursor specifics. > > Window Clipping Planes > > I agree this is a good thing. The current software model does have a > scissor test. By protecting the scissor control registers (in the > sense of Protected Mode), Window Clipping Planes are trivial to > implement. The only "protected mode" I recall being seriously considered is separating registers into banks so that mapping certain register sets can be disabled according to process privilege. This doesn't strike me as a feature worth expending any hardware over. The X server has root privilege and no other userspace process will touch the hardware directly. > > 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. > > 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. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
