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 **** 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. 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 in a machine with at least 4 Megs of RAM. I've done a couple timing tests and found that trace time can be reduced by as much as 30% with a 500K or larger buffer. > What is the minimum amount of conventional DOS memory needed to run POV? Does freeing up conventional memory above this minimum improve performance? No minimums are given in the ICB docs, I imagine all that is required is enough for the loader program to execute since it is (basically) a real mode program. Be aware however that machines with large amounts of memory taken up by drivers, TSR's etc. are MORE LIKELY to have some kind of problem with conflicts between POV-Ray and those drivers. (Simply because they *are* loaded and the vast differences in the way the CPU it's self is used between real mode and the 32bit protected mode.) Performance is not effected by how much real mode memory is available, POV-Ray runs almost completely in the area BEYOND the real mode 1meg boundary. > I assume that if POV-Ray is a protected mode application, you should give it as much *extended* memory as possible. How much can it use? Yep, defiantly. The more the better since, as far as POV-Ray is concerned, this IS the memory. That is where the program actually runs. See IBMPCEXE.DOC for info on what switches to use with various memory managers to insure that extended memory is available for POV-Ray. As previously described, POV-Ray (ICB's limits) can use 64 megabytes of physical RAM (the IC's installed in the machine) and additional hard disk space to total 3.75 Gigabytes of paged virtual memory. NOTE however that "shortcuts" taken by some *hardware* manufacturers may limit what is "really" available to the program, even if more is actually installed in the machine. Generally you are pretty safe in assuming that 16 megabytes of RAM and 32 megabytes of disk space will be usable/available in *ANY* IBM compatible 386/486 PC with an ISA buss. 48 megabytes of VM should be plenty for any rendering that will be completed in under a century.... Also note that I have gotten some messages (2 to be exact) from people that have been unable to get the program to run in a machine with only 2 megs of RAM installed. Since the first meg is "reserved" for real mode use this leaves 1 meg for POV to knock around in. POV is actually a pretty big program it's self these days, and getting bigger. 4 megs gives it some "breathing space". > What options will allow the program to run as fast as it can? Generally the command line options that have the most effect are the image buffering (+bxxx) and the keyboard abort (+x). The image buffering can dramatically reduce rendering times. A setting of +b512 on a machine with 4+ megs of RAM is a good compromise between the buffer & how much RAM is "sacrificed" to the buffer. For instance a 512K buffer will limit an 800x600 image to just 3 disk writes during the image generation instead of ** 600 **. Depending on the environment, the keyboard abort option (+x) can slow things quite a bit too. It's most noticeable in multitasking environments since the keyboard is constantly polled to check for the occurrence of any keypress. Disabling the display option can give a slight improvement in rendering speed, but it is generally not a very significant improvement. A note about benchmarking POV-Ray: Unfortunatly for benchmarking purposes the images that run the fastest also tend to have the very widest variations from compiler to compiler. That results in essentially meaningless comparisons since it doesn't represent the average performance difference you will see in day to day use of the program. The ways that various compiler designers implement solutions to functions can cause -really- wide variations between EXE's, completely dependant on what image is being rendered. For instance BLOB.POV will render about 20% or so faster with a Watcom 9.5 compile than the ICB 1.0 compile of version 1.0, but something like ARCHES.POV is only about 7%-8% faster. A 12% variation between just 2 images. About a year ago I did a whole bunch of comparisons using a couple dozen images that used various features of the raytracer. SKYVASE.POV *generally* seems to result in about the same speed differences between compilers as what the average results of all those images turned out to be. If you turn on anti-aliasing things tend to tighten to closer render times too. Different methods of handling disk access can also skew things, you end up measuring the I/O efficiency of the compiler rather than the floating point math capability. You can use the -bxxx image buffering to eliminate, or at least significantly reduce, that.