[prev in list]
[next in list]
[prev in thread]
[next in thread]
List:     ggi-develop
Subject:  Thoughts about LFB virtualisation
From:     "Kendall Bennett" <KendallB@scitechsoft.com>
Date:     1997-12-01 18:09:40
[Download message RAW]

Hi all,

I noticed a couple of threads on this list about 'virtualising' a 
linear framebuffer using the MMU page fault handling to do the bank 
switching. This is perfectly possible, and in fact is currently 
used in Windows 95 for banked framebuffer devices as well as in our 
SciTech MGL graphics library. Since I have already implemented 
exactly this type of code, I though I would share my experiences (and 
my code).

Firstly, there is one major 'gotcha' that needs to be understood in
order to be able to write LFB rendering code that is 'vitual buffer
compatible'. Basically you cannot write code that generates a memory 
reference that spans a 64Kb bank boundary. Hence if you are accessing 
the buffer a WORD or DWORD at a time, you need to ensure that those 
accesses as WORD or DWORD aligned respectively (BYTE accesses always 
work). For the most part this is easy to achieve, but there are times 
when it is convenient to use non-aligned accesses (like for 24-bpp 
packed rendering) so you have to be aware of this.

If you get this wrong, the system will lock up hard. The reason for 
this is that the first half of the memory access goes ahead just 
fine, but the second half generates a page fault and the page fault 
handler re-programs the SVGA hardware and unmaps the previous page 
for the MMU. The Intel CPU then restarts the *entire* intruction 
which goes back and accesses the original page again which has just 
been invalidated! Back to sqaure one and you get stuck in an infinite 
page fault loop ;-)

The second thing is that even though this seems like a great idea, 
the overhead of the code involved to perform the bank switch, MMU 
remapping and generic handling of the page fault is quite 
significantly more than just a dedicated bank switch function. It has 
been our experience with our libraries that a dedicated bank switched 
rendering function will outperform LFB rendering code when the buffer 
is virtualised. However generic LFB code is a lot simpler to write 
the bank switched code, so we tend to use it anyway ;-)

The third thing is that there are situations in higher resolutions 
and color depths where rendering primitives with classical algortihms 
can results in incredible performance hits. A classic example is 
rendering an ellipse or circle using a standard DDA algorithm. All 
algorithms generally use the symmetry of the ellipse to only do the 
complex calculations once and draw four sides of the ellipse 
simultenously. Now if you have an ellipse that happens to span one or 
more bank boundaries (and this happens a *lot* with high resolution 
and color depths) you can easily end up with the overhead of a page 
fault for *every* pixel drawn!! We don't bother to optimise for this, 
but a simple reorganisation of the ellipse functions in this case (to 
perhaps cache the pixel coordinates and draw them efficiently) when 
running on virtualised hardware would be beneficial.

Anyway, if you have not already gone ahead and implemented this code, 
you may want to take a look at the code we have for implementing this 
in our SciTech MGL graphics library. If you download the following 
ZIP file:

 ftp://ftp.scitechsoft.com/devel/mgls403.zip

you will find the files 

 \scitech\include\vflat.h
 \scitech\src\pmode\vflat.c 
 \scitech\src\pmode\_vflat.asm

that implement this virtual buffering mechanism for DOS4GW based 
applications. The page fault handler directly modifies the page 
tables so the code should be relatively simple to port to the Linux 
environment (and it saves you writing it all from scratch ;-).

BTW, I noticed people replying to my messages, but I don't see my 
original message get posted to the list. Does the list filter out 
my posts so I don't see them?

Regards,

+--------------------------------------------------------------------------+
|        SciTech Software - Building Truly Plug'n'Play Software!           |
+--------------------------------------------------------------------------+
| Kendall Bennett                     | Email: KendallB@scitechsoft.com    |
| Director of Engineering             | Phone: (530) 894 8400              |
| SciTech Software, Inc.              | Fax  : (530) 894 9069              |
| 505 Wall Street                     | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA                | www  : http://www.scitechsoft.com  |
+--------------------------------------------------------------------------+


[prev in list]
[next in list]
[prev in thread]
[next in thread]