    [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]

Log in / Log out | Configure Your Environment | About MARC | We're Hiring! | Want to add a list? Tell us about it. | 10East