home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Computerspiele Selbermachen
/
computerspieleselbermachen.iso
/
pov
/
ibmdocs
/
q&a.doc
< prev
Wrap
Text File
|
1993-09-30
|
13KB
|
211 lines
POV-Ray Questions & Answers. B.Pulver 5/9/93
-----------------------------------------------------------------------------
This document addresses some of the most commonly asked questions about
POV-Ray and the way it works. It applies only to compiles of POV-Ray done
with Intels "Code Builder Kit" (ICB) 32bit extended DOS compiler. It also
includes some hints on maximizing rendering speed toward the end of the
file.
This document gives a (real) quick overview of the POV-Ray operating
environment. It does not fully describe the options & capabilities of
the 80386+ processors as that would take volumes. It is instead meant
to be a simple FYI type overview for those that may be interested.:
Intel's "Code Builder Kit" creates 32 bit protected mode programs that take
advantage of the enhanced memory management of the 80386+ processors. These
processors have 3 main modes of operation generally known as the "real",
"virtual 86" and "386 protected" modes.
The "real" mode of operation is what most people are familiar with. In
this mode the CPU "emulates" an 8086/8088 based machine. The 8086 is
capable of addressing 1 meg of memory, to maintain compatibility this
limit is also imposed on the '386/'486 processors when running in this
mode. This is the mode that MS-DOS, and the overwhelming majority of IBM PC
based applications, operate in. The area generally known as "conventional
memory" is the first 640K of this memory block with the second 384K being
used for the built in BIOS ROMS, I/O buffers (such as video) and things
like EMS page frame addresses. That is all the memory the 8086/8088
processors are capable of directly manipulating. Basically a 386/486 running
in real mode is nothing more than a fast 8086 based machine. In actual
operation the 386/486 CPU's *are* capable of using an additional 64K of
memory beyond what the 8086 is capable of. This is what 386/486 memory
managers are referring to at boot time with messages such as "64K high
memory area available". All the memory in the machine must be dealt with in
"chunks" (called segments) no larger than 64K in this mode.
The "virtual 86" mode is what programs such as Windows run MS-DOS programs
in. Basically the CPU sets up "virtual" machines that all run independently
but retain the limits imposed by running in real mode. In this mode several
programs can be run "at the same time" with all of them thinking they are
running, by them selves, on an 8086 based machine. The advantage of this
mode is that each of the virtual machines may be separated, to some extent,
in hardware (thru the 386+ processors memory management) and is thus less
subject to problems between applications.
The "386 protected mode" is quite different from both of these modes,
bearing more similarity to CPU's like the Motorola 680x0 series used in the
Macintosh. This is the mode that POV-Ray spends most of it's time running
in. The mode offers the ability to load applications in separate areas of
memory and logically remap that memory to any address in the machine.
Memory available in this mode can be configured as a linear address space
of 4 GigaBytes. (From 0 to 2^32-1 addresses, also called the "flat memory
model".) This memory may be allocated and dealt with at any size, the DOS
64K segment is gone as is the DOS "640K limit". 4,294,967,294 bytes of RAM
are theoretically available to POV-Ray in this mode, of course machine and
compiler limitations dictate what is "really" available. Given a machine
with sufficient resources POV-Ray can directly use 64 megabytes of physical
RAM and (thru the Virtual Memory Manager) additional disk space to total
3.75 Gigabytes of virtual memory. I.E. POV-Ray has the ability to use 3.75
GIGABYTES of memory. Intels Code Builder (ICB) reserves the first megabyte
of "real mode" memory in the machine for a "scratch pad" area and for
communication with the machines built in BIOS and DOS since THEY are 16 bit
"programs". "Freeing up conventional RAM" has no meaning in this context,
POV-Ray does not use the area for much. The POVRAY.EXE file actually
contains 5 "programs". A Loader/DOS extender (used to add 32 bit
functions to MS-DOS since MS-DOS is a 16 bit operating system), a Virtual
Memory Manager, a protected mode 80387 emulator to provide floating point
math operations in a machine with no CoProcessor installed, and the POV-Ray
program it's self. When POVRAY.EXE is invoked the "loader" is loaded by DOS
& executed, it in turn loads the DOS extender which checks for the presence
of a DPMI *HOST* memory manager. (Common DPMI hosts are Windows, OS/2 2.x in
a DOS VDM, and Quarterdecks QEMM with their QDPMI add on installed. 386MAX is
also supposed to provide it but I have not verified it's operation. I
have tried all the others & they work fine.)
**** This is where it gets complicated <g> **** IF an *existing* DPMI
host/memory manager (say Windows) is found to be *already* running the DOS
extender USES IT for ALL memory requests **AND** virtual memory management.
I.E. Windows IT'S SELF provides POV-Ray with all it's memory management and
the configuration of *WINDOWS* imposes the limits on what the program can
use. (How much extended memory is allocated to the application, the size
that the Windows swap file is, and can go to.... etc.) If a DPMI host is found
to be in operation POV-Ray (ICB) will "gut" it's own virtual memory manager
(since it's not used in this case) to conserve RAM.
If NO DPMI host is found then the DOS Extender in POV-Ray will provide the
memory management for the program. (It is NOT, however, a DPMI host) The
parameters the program will *expect* to be able to use are set with the
POVMOD program. (Windows, OS/2 and QEMM/QDPMI *must* be configured to
provide *at least* these parameters for POV-Ray to run.
It's *very important* that the program providing the DPMI host services be
configured to provide what POV-Ray *ASKS* for (which is in turn what is set
with POVMOD) or the program will error with an insufficient memory message.)
The loader/extender then checks to see if a CoProcessor is installed in
the machine. IF NONE IS FOUND the 80387 emulator is loaded. If a
CoProcessor *is* detected the emulator is NOT loaded to conserve RAM. (Note
that the emulator *will not work* correctly in a DOS VDM under OS/2 2.x,
the machine MUST have a CoProcessor installed for the program to function
well. Under Windows 3.x the VEMD.386 driver MUST be installed to run the
program on a machine with no CoProcessor. See the IBMPCEXE.DOC file for
more information.)
At this point the actual execution of POV-Ray begins.
This is a (very) quick & basic overview of the programs operation and the
environment it executes in.
In answer to some specific questions:
> Does the "virtual memory manager" in POV run only if no existing hard
disk cache (like SMARTDRIVE) is detected?
No, the virtual memory manager is NOT a disk cache. It provides paged
memory services to POV-Ray in much the same way that a Mainframe or
MiniComputer may use their hard disk drives as "memory". This "memory" appears
to the program to be actual RAM available for it's use. It is NOT a "swap
file" in the conventional sense. (For this reason it's best that the file
used should be located on a drive that *DOES NOT USE DISK COMPRESSION
PROGRAMS* such as STACKER or SUPERSTOR!) ICB allows this (plus physical
RAM) to go to a total of 3.75 Gigabytes.... if you have a big enough hard
drive.<g>
Disk caching will have little effect on the performance of POV-Ray.
POV-Ray will "tolerate" it's being present, if new enough versions of the
programs are used. (See IBMPCEXE.DOC) A MUCH better way to boost
performance is to use the image buffering built into POV-Ray with the +bxxx
commandline switch. Since POV-Ray must switch out of protected mode to use
the BIOS disk service routines, it takes a performance hit for *every line*
as it is written to disk. Also, since POV-Ray cares little about memory
usage a buffer of 500K is not unreasonable