#GVP '040 Slooowww!
22 messages in this thread
Beware of a trap I just fell into:
I had (have) an animation running that will take 22 days to render to
get 22 seconds of animation. I have a GVP 33 Mhz 68030 Combo card.
As I began thnking about ways to speed up the rendering I n otice
some very low prices on GVP 33 Mhz G_Force '040 boards for the
A2000. So I got one thinking that the rendering time would improve
significantly. I didn't really believe the peolple who told me that
I would get a 10 fold increase in the rendering speed. But I thought
3 to 4 times might be about right.
Well, after I installed the card and did the "boot from WB floppy" to
insure that the card was installed correctly, I then rebooted from my
HD before I installed thier '040 unique software. SO I figured I'd
render a frame while I was at it. SURPRISE!!! No differnce in time
over the '030.
At this point I figure I have to set up the '040 unique software. I
do the standard install from the included floppy. It includes a
library that allows the '040 to emulate the functions of the '882.
Then I do a power down, wait 10, power-up. Start a fram rendering –
nothig is happening, or so it appeared. On investigating further I
found that it had just SLOWED DOWN so much that it appeared to be
nothing happening. In fact is slowed down by about a factor of 4. In
addition, I could n o longer get decent mouse movement on the screen
(I bounce out of LW while it renders to do some otherwork
occasionally). It seems that when the routines of 68040.library are
invoked, that even the mouse pointer is locked out of updating for
positional changes.
Bottom line: the GVP G-Force '040 with Software emulation opf an'882
does not speed up rendering or anything else. I REALLY slowas it
down. In addition the serial port wouldn't wok with AutoPilot
(didn't try anythin else.).
Save yer pennies for a better '040 implementation – like the 4000T.
wmc – via Autopilot!
Goes to show what I've felt for a long time about that company…
GVP=GiVe uP or
GVP=Guru Very Probable
🙂
—Flying BLIND with AutoPilot
Do you have any experience with other accelerators? This one goes
back tomorrow unless GVP tech support comes up with a flash of
brilliance that fixes the speed problem. But I do need something
that works a little faster.
Oh yeah! Did you know that there are TWO versions of Lightwave on your
Toaster system? One is for 68000 and the other is optimized for
68030/8882. Unfortunatly, the program that loads Lightwave looks for an
EXTERNAL math unit and if it doesn't find one (as is the case with the
68040 due to the math co-processor being INTERNAL) it defaults to the
slower 68000 version. To remedy this situation, simply rename the
Lightwave file in your Toaster directory to lightwave.000 and then rename
the lightwave.fp to lightwave. Now when the Toaster goes to load Lightwave
and it can't find the EXTERNAL floating point unit, it loads the RIGHT
version for a math co-processor anyway! Tricky Eh?
—Flying BLIND with AutoPilot
But that's not the problem. Acording to the "about" (and experiments
renaming Lihtwave_FP) the Toaster loads the FP version. It jus turns out
that the '040 renders faster in integer than in FP at this time. SO you
WANT the integer version for rendering. Problem is, you have to relad teh
FP version before you try any modelling…
wmc – via Autopilot!
Well (ptoey, ptoey [feathers drifty to floor]) I have the double
dipleasure of crow all over my face – I'm a vegetarian, you see.
It seems the 68040.library is a CBM supplied module, not a GVP
module. GVP's tech support is of the opinion that the problem is
really with lightwave. They say that since the CPU has to "throttle
back" (my term) to 68030 and '882 emulation, the resultant demands on
the '040 are such that the slowdown I am witnessing in muli-taksing
with LW rendering (which works nicely with an '030 but not with the
'040) occurs.
I asked them about the claims I've seen in print of like the PPS and
RCS '040s speeding up LW by 4 to 10 fold over a similar clock speed
'030. They maintain it is because the other manufactures MAY NOT
(emphasis mine) be using the CBM 68040.library. (This is reasonable
as I noticed a 25% speed increase if I removed that library. The
problem is that you can't get the '040 into burst mode without that
library, or apparently some other home-grown library). Is this a
subtle hint that CBM has a lot of optimization left to do in that
library? Does anyone know, short of having a beta copy of LW 3.0,
how these people that have written to/for various magazines have been
able to get such radical speed improvements of LW with a 68040?
Some other information I gathered that is helpful but not in the
document for the '040 combo board: The J22 jumper should be as in
the table on p7 not as in the text on p13 (this enables/disables
burst mode). The "GVPCPUCtrl MoveSSP FastROM" needs to be bracketted
by "cpu nocache nocopyback" and "cpu cache copyback" statements. This
sequence should go at the beginning of s:User-Startup. Note that I
found that without the MoveSSP option of the GVPCPUCtrl command, the
FastROM option will slow the machine down remarkably.
The correct GVPScsiCtrl command sequence if you have a tape drive and
a removable on the SCSI bus is -r , -s, DCOFF rather than the -r,
DCOFF, -s sequence in the document. This sequence should appear at
the end of the s:User-Startup sequence.
On the serial port, they claim that it works just fine with at least
JRComm, latest rev. It is possible that my problems really lie with
AutoPilot and the older MSS terminal programs, but until I can get
the latest JRComm to test it I won't know. I've been told that
anyone following BM standards will allwo Autopilot to run using
alternate serial device drivers. The 2.4 MFC rev works with
Autopilot, so I know it is not impossible.
Am I a happy camper now? Not yet. Aside from the crow eating
exerise, I am still trying to figure out (short of waiting for LW 3)
how to get better performance in rendering and how to dump the
multi-face card by getting the GVP serial port working.
I installed a GVP G-Force 030 25 MHZ board with 1 Meg (later
bought an additional 4 Meg), 68030 (w/MMU), and 68882 in our Amiga
2000HD. It seems to run faster for me. Of course, my 68882 is h/w,
not s/w. Apparently, software emulation will, in general, run slower
than a hardware configuration. However, I don't do any heavy video
work either.
Somethings wrong, it shouldn't have slowed down, or even stayed at
the same speed.
I fiures out what is wrong – nonstandard interface to the CPU
requiring a GVP supplied routine (68040.library) which is essentially
incompatible with an A2000 runnign ADos 2.1.
Wayne I had a similar problem with my GVP 040. It didn't slow down
though but it rendered at the same speed as my 030-28 I also have
ADOS 2.1. Did you check if your kickstart is mapped right. go to the
SHELL and type "GVPCPUCTRL". I solved the problem by giving the
command "gvpcpuctrl movessp". Its somewhere in the manual. With that
command my rendering speed doubles, otherwise it stays the same as an
030. I expected more than double speed but I gues the problem is that
I use alot of image mappings. They say that the 040 does slow down
when rendering image mapped objects. Good luck. P.S. If you find out
anything about the 2.1 incompatibility let me know.
Edward, Which package are you rendering with?
By using "MoveSSP" option I only get equal speed with the '030 and
lightwave. The only way to get faster is to either remove the
68040.library (which is actually CBM's, I found out) for a 22%
decrease in rendering time or remove the floating point version of
Lightwave which gives a 30% decrease in rendering time.
Disk access is generally a little faster, but other than that I notice
no speed-up in general applications other than rendering animations
either. Pagestream, excellence!, PSFC all seem about the same. I
think the board is going back.
I use lightwave also. I didn't have to remove or rename the lightwave version
to get it to work with the 68040 it did that automatically. I have only 8 megs
of RAM so I don't just burst mode either. I am happy with my board but I hope
that LW3.0 will give me much better performance.
Edward,
It works with the FPU version as a renderer but is mighty slow. Switching
to the integer version for rendering gives you almost 30% speed-up.
wmc – via Autopilot!
THIS IS VERY STRANGE. let me give you my setup; A2000, 2Mb chip Ram, GVP
040-2000 with 8 Mb RAM, lightwave 2.0, ADOS 2.1. I received my board at the
same time as my DOS upgrade so I decided to reinstall everything. before I
started. So all my parameters are default. I installed the accelerator, then
ADOS, then aplied GVP upgrade, then TOASTER. what message do you get when you
just type gvpcpuctrl? I get 2 lines; kickstart mapped …..
system stack moved …….." My toaster software automatically
recognized my 040 as a FP processor so I didn't change or rename anything in my
toaster directories.
Edward,
You mis read my message. Yes, the Toaster will automatically use the FP
LW with the GVP 040 BUT IT WILL RENDER SLOWER THAN EITHER THE GVP '030/882
OR THE '040 USING THE INTEGER LW!!
Don't believe me? Render a scene with one or two images or procedural
textrures in it. Note the time. Now rename LW FP to something else,
enter LW (you'll get the can't find FP version, loading default version
message) then Render the scene. You'll find that there is at least a 30%
decrease in rendering time.
I just wanted to figure out how, after setting up to use integer LW, to
get a modeller that would work with it. I've done that and will continue
to use this klude set-up until I get the '040 optimized LW (which, I'm
told, will be only marginally faster than using the current integer
version now).
basically I've concluded that the 2x – 10x faster claims were overreaction
to benchmarks like seive etc. That's why I always say that benchmarks
mean very little. The only valid comparison is on the real life jobs you
do everyday. Based on that, the '040 is less of a blessing then dealers
would like you to believe.
But it is better than a 68000 :^}
wmc – via Autopilot!
Are you sure that you have a full 040 and not an EC040 installed on your board?
The slower floating point execution vs. integer execution would indicate that
there is no FPU and so the math libraries are being used instead (for a loss in
speed).
Hi Dave,
this problem also manifests itself with the progressive 040 boards. The problem
is not that he has an EC040 but rather that the floating point version of
lightwave was compiled with 882/881 fpu chips in mind. The 040 chip has many of
the math instructions of the 882 on the chip but those that are not are
emulated in software and thus will runn slower than a true 882 chip. The non
fpu version of lightwave will run faster since it is optimized for an amiga
without the fpu thus the 040 does not have to emulate anything.
I think I explained that right…
Well it is advertised as the 040. I can't tell what it is since the thing
is covered with a fan and a metal heatsink housing on top of that. Also,
I believe (if I am reading the Motorla Programmers Reference manual I have
in fornt of me correctly) there is no difference between the EC040 and the
040 as far as FPU. I believe what may be confusing is that when I look
through the floating point instruction section, there is a table of
directly supported instructions for the 040 family and those indirectly
supported by the 040 (i.e. implemented in software). The on-board FPU
supportdinstructions are badically add, sub mult and div, sqrt, negate
(mul by -1) and some block move and test instructions. The larger
"indirectly supported" instruction table lista all the exponential ops in
base 2, 10 and e, logarithmic ops in same bases, all the circular and
hyperbolic trig functions, and inverse trig functions – basically all the
ops that get used for procedural textures and image map projections.
After looking over this documnet I am of the opinion that the '040 is not
the best chip for graphics oriented work. An 030/882 is almost as fast on
these since the FPU can actually be working two FLOPS while the CPU is
doing something else. So there is a paralellism that the '040 gave up
that directly hurts math intensive operations like rendering.
wmc – via Autopilot!
that is truly odd. FractalPro runs 7X faster on a 25mhz 040 than a 25mhz 882!
So does NeuroPro 2.0! Sounds like the programs are BADLY written (probably in
C instead of assembler!) if they don't speed up on an 040!
LW 3.0 is DEFINITELY speedier than LightWave 2.0. (By a factor of 3-6
times!)
LightWave 2.0 was optimized for the 030/882 combo, and thus is somewhat
piggish on the 040.
Keep On Toastin'
Erik Flom
Hi dan,
hows the BIG drive business? Gotta call you about them sometime. I'm
getting HD claustrophobia!!
I went from 33 mhz 030/882 to 33 mhz 040. Most of the slowness appears to
be due to the 68040.library that, among other things, seems to provide
that protion of 882 emulation not resident on the '040 HW. I'm not
positive that is what is in there, jsut seems to be. The only other
possibility is that it doesn't like the 16 bit memory on the HC/8
controller. I've heard there are some programs that don't like that but
GVP literature says it is no problemo…
wmc – via Autopilot!
Bummer…
Bob Comer — Cruising the nets on AutoPilot from Cheyenne, Wyoming