Quoting Nicolai Haehnle <[EMAIL PROTECTED]>: > 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.
Do you have a link to the source code? I've had a lot of difficulty understanding the hooks between Mesa3D and the kernel source code. > 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 UseNix paper on the experimental Kdrive server goes into some depth on a design of copying the Pixmaps from System Memory to Graphics Memory and back. It also discusses the XOrg/XFree approach: http://www.usenix.org/events/usenix04/tech/freenix/anholt.html Interesting the White Paper on the design of the SGI Xserver/OpenGL interface also briefly discusses the 2D acceleration by the Xserver in section 5.3. Apparently not much is done. It could have changed by now. http://citeseer.ist.psu.edu/kilgard95system.html I suspect the SGI hardware is very snappy because of very fast memory copies from system ram to graphics ram and maybe double buffering all 2D windows and performing buffer swaps on the vsync interrupt. Searching the XOrg source code I have found no reference that the interrrupt is used in the server for 2D, users notice the window tearing that occurs when they are updated and think the server is slow. > > > 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. Ive just discovered an interesting ring buffer design (at least for a newbie). in the SGI visual workstation 320 sound driver. reference (line 343-347) http://joshua.raleigh.nc.us/docs/linux-2.4.10_html/473266.html Are you thinking of something like this? Tim. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
