On Tuesday 15 March 2005 18:43, Nicolai Haehnle wrote: > On Tuesday 15 March 2005 20:15, Daniel Phillips wrote: > > * All drawing commands are submitted as DMA commands, PIO is used > > only for DMA setup, soft reset, interrupt control and similar. > > PIO is only available to privileged tasks. (Timothy stated earlier > > that defining the hardware cursor should be done by PIO, though I > > don't really understand why that is better than submitting it > > through the ring buffer) > > I agree. I don't know Timothy's precise reasoning, but I could > imagine that using PIO for the cursor is better for latency.
I agree completely, for position. Cursor position and cursor enable should be r/w PIO registers. But cursor definition... that's not as obvious. Well, I guess Timothy is right, the simplest way to program the cursor is to control every aspect through PIO. > > Did I leave any holes? > > If we enforce window boundaries (which is btw not enforced by any > graphics driver on Linux that I know of), we would also have to think > about how mmap()'ing the framebuffer could (or couldn't) work. Can you do that? If a normal task can do that, then forget about per-window security, it's impossible. But I have a feeling it's not allowed. > > In the "future" category, I think we need to plan now how > > asynchronous background DMA will work, even if it isn't implemented > > in the initial release. This capability really isn't optional. We > > just can't afford to have all drawing grind to a halt every time a > > texture loads. > > Basically, I agree. On the other hand, there may be limitations on > the memory controller (especially in the first release) that make > background uploads unfeasible. Considering that this card will have a > *huge* amount of RAM compared to its rendering performance, my > educated guess is that texture uploads won't be a limiting factor for > 3D. Things may be different for video playback, though... In the light of day, I'm not so sure that background texture loading buys anything on a slow bus, this needs more pondering. But it is a theoretical issue anyway. The simple, synchronous way of loading textures is clearly the right way to go for a first cut. > > I'd have already posted a full proposal, except that I don't yet > > have a clear picture of how buffer low/empty events will be fielded > > by normal tasks. This requires delving into the innards of DRM and > > other things, deeper than I've had time for so far. If anybody has > > already looked at this, please shout. > > The current DRMs actually seem dumb. The DRM only enters commands > into the ring buffer as a response to ioctls from userspace, and if > the buffer is full, it will busy-wait for space to become available. > I haven't checked all drivers out there, but all that I've looked at > so far work like this. I feel it's worth taking a run at doing that better. The worst we can do is fail and have to fall back to sucking as much as everybody else. 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)
