On Wednesday 16 March 2005 12:08, Daniel Phillips wrote: > On Tuesday 15 March 2005 18:43, Nicolai Haehnle wrote: > > 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.
Well, software rendering fallbacks need some way to read to and write from the framebuffer. All current DRI drivers do this via a mapping of the framebuffer. I have been pondering whether it would make sense to download/blit to system memory the necessary parts of the framebuffer before software fallbacks and uploading the results after software fallbacks. Pros of that approach: + Accessing system memory is a lot faster than going across PCI. + We no longer have to lock the hardware during software rendering. Cons: - There is an additional memory copy involved, and we might move a lot more memory than necessary if the fallback is very short (i.e. just a few small triangles). - Using prefetch instructions and cacheable mappings of the framebuffer, the difference between PCI and system memory might not be big enough to justify this. Anything else? I have zero actual benchmarking data to point either way. > > 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. I agree. Fortunately, this shouldn't affect hardware design too much. I believe an IRQ that is emitted when the ringbuffer read pointer passes a certain mark should be enough. cu, Nicolai
pgp9bDDxBsNeV.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)
