| This is a reply from Paul Jensen (decwse::jensen). Please followup directly to him.
This is not a bug, but a "feature". The PX, PXG, and PXG-turbo
options all accelerate graphics by having special rendering chips
connected in a highly parallel fashion to one of two special
memories: a 1280x1024 frame buffer mapped to the display monitor,
and 1 to 3 1280x1024 offscreen memory buffers. The PX has only
one offscreen buffer, where all drawing to pixmaps must occur.
Because the number of pixmaps supported by X can easily exceed
the capacity of offscreen memory, an offscreen memory allocator
is needed to manage this scarce resource. The problem you
are encountering is that by writing to several pixmaps, you are
inducing thrashing: pixmaps are continually being brought into
offscreen memory from system main memory, in the process
displacing other pixmaps which must be written back to main memory.
Unfortunately, this behavior is intrinsic to both the architecture
(rendering to dedicated, specially configured memory) and the
implementation (inadequate bandwidth between main memory and
the frame buffer). The only workaround is to either limit the
number of pixmaps to what will simultaneously fit in offscreen
memory; or to draw as much as possible to a pixmap before going
on to the next one. If you chose the former option, you will be
limited to two 512^2 pixmaps. Note that this is not guaranteed
however: two dimensional pixmap allocation is equivalent to the
(NP-complete) bin packing problem: the storage allocator trys
to be intellegent about placing pixmaps, but it doesn't always
succeed. You may be interested in reading a white paper I have
written describing the differences between the cfb & 2da. It
may be copied from basalt::/udir/jensen/pub/3max/2da.ps.
You make take some solace from knowing that the h/w designers of
the 2da/3da have been beaten up pretty savagely over this.
Regards,
/Paul Jensen
(2da gfx software developer)
|