Messages in this thread | | | From | (Pascal Haible) | Subject | Re: SVGA kernel chipset drivers. | Date | 3 Jun 1996 18:22:52 GMT |
| |
In article <Pine.LNX.3.91.960601111147.19921K-100000@linux.cs.Helsinki.FI>, Linus Torvalds <torvalds@cs.helsinki.fi> wrote: >On Fri, 31 May 1996, Albert Cahalan wrote: >> [attribution lost] >> > I/O port access is critical. The "frame buffer" of most cards >> > is actually a window of 64K onto a mapped space. >> >> That is good enough because the virtual memory hardware can be >> used to make it appear to be linear. The process does not need >> port IO to move the window. > >Wrong. You _can_ do it that way, but if you do that then you're shooting >yourself in the foot. Mainly because it's horrible for performance.
I did it, and I didn't shoot myself in the foot. The X server built on top of a 'magically bank switching framebuffer' ran at about the same speed as the banked one. Most of the x11perf tests were withing +/- 10%, with more on the faster side. Did anybody ever see the original X386 banking macros that tested for the end of the banking window for _each_ framebuffer access?
[about using the VM hardware for buffer window mapping]
> - most of the PC video cards that do windows do _separate_ windows for > read and write. However, there is no way we can support this with the > x86 MMU (it doesn't support write-only mappings), so copying from one > VGA window to another would be _horribly_ slow because we'd have to > switch every time (contrast this to doing it by hand, where we can > just set up a separate read and write window and copy directly). You can not _enforce_ write only, but you can set up two different VM area, one for the source (ro) and one for the destination (rw).
>In short, the VM approach is "interesting", but doing it in user space is >the right way anyway. It might require a bit more from the user program, >but that's ok. With mprotect() et al. this is true now. It has not always been. It should be worth a try.
Pascal -- Pascal Haible, haible@ITO.Uni-Stuttgart.DE
| |