lkml.org 
[lkml]   [1996]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: SVGA kernel chipset drivers.
Date
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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:3.507 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site