p96 is unbelievably Slow!

[ChaosLord]

MattHey FTW!

[wawrzon]

If you look at the speed results at http://www.amigaspeed.de.vu/, you will see that the Voodoo 3 is almost 10 times faster at 2D line drawing than the Picasso 4 with CGFX 4. It also looks like P96 is a little faster than CGFX for line drawing with the Voodoo 3+ at least. I would expect the Picasso 4 driver to be good with P96 as well. The Picasso 4 is slow compared to Voodoo 3+ except where the gfx bus speed matters (bitmaps).

im using picasso4 with p96 system and respectively cv64 with cgx (4)?. so this should be the optimal setup. though since i got to get rid of sfs im going to install mirror partitions with the alternative gfx system on each of the machines for the sake of testing.

No. I don't think so. Sorry if I mislead you. The Avenger libraries do call the appropriate CGFX or P96 Warp3D libraries which call the appropriate CGFX or P96 functions but these shouldn't be used for 3D lines. 3D lines need the Z value and are affected by the Z buffer. They are actually drawn as triangles as the Avenger has no support for 3D lines (or points). The Avenger does have support for 2D line drawing that is very fast in comparison. It would be very inefficient to use W3D_DrawLine() or similar to draw 2D lines.

i stay corrected. i  have still the impression though that the line drawing in w3d is generally not as fast as it should be. see 4dtris and snake3d. btw have you corrected that issue in your w3d libs where the color texturing loses saturation (foobillard,brass parts)? i can look at what function is actually used there if you dont know what im talking about.

I doubt it is the filesystem. It looks like a NULL pointer that is not tested. Let me translate it to something you might be able to read...

...
OpenLibrary (libName="expansion.library", version=0)
configDev = FindConfigDev (oldConfigDev=0, manufacturer=-1, product=$60)
tmp = configDev->cd_BoardAddr
globalvar1 = tmp
globalvar2 = tmp
...

See, configDev was never tested for NULL before it was used (neither was the OpenLibrary return). cd_BoardAddr offset is $20 from 0 which explains the read from address $20. I would say that this code is a patch that was added in by an assembler programmer at a later date than when it was compiled. The biggest hint is that the patch does some self modifying code and then calls exec/CacheClearU(). This is not normally done in C. I would suggest reverting back to the original rtg.library 40.3994 (08/22/04) 217988 bytes. Actually, this is the version that I have been using all along without problems. It does not contain this hackish patch.

sounds you are right. since i did it by hand on voodoo system i didnt install gullivers 40.3994 because iv already had a lib with this version number. in this case gulliver should also revert his package to this version of rtg.library.

[wawrzon]

I would suggest reverting back to the original rtg.library 40.3994 (08/22/04) 217988 bytes. Actually, this is the version that I have been using all along without problems. It does not contain this hackish patch.

i can confirm now the hits due to the gillivers rtg.library have vanished when reverted ot the amithlon 40.3994 (08/22/04) 217988 bytes version.
@gulliver: either roll back your boing bag to this version or (better yet) let the new library edit again, whoever did the patching. it seems, it was working well apart of this one initial read hit. read hit is not critical but may be annoying.

[wawrzon]

ive found the reason why p4/p96 on one of my machines was so slow. i removed the cyberstorm ram module and forgot it lying disassembled on my desk just in front of my eyes. how dumb is that!!!! :facepalm: the machine was running from z3 and mobo memory all the time!!

[adz]

ive found the reason why p4/p96 on one of my machines was so slow. i removed the cyberstorm ram module and forgot it lying disassembled on my desk just in front of my eyes. how dumb is that!!!! :facepalm: the machine was running from z3 and mobo memory all the time!!

[Karlos]

ive found the reason why p4/p96 on one of my machines was so slow. i removed the cyberstorm ram module and forgot it lying disassembled on my desk just in front of my eyes. how dumb is that!!!! :facepalm: the machine was running from z3 and mobo memory all the time!!

We've all had days like that...

[wawrzon]

now, is that for real??:
Mode = 320x240, software
Pitch = 640
Hardware surfaces avail = 1
Window manager avail = 1
Blitter hardware = 1
Colorkey blit hardware = 0
Alpha blit hardware = 0
Software->Hardware accel = 1
Video memory = 8000

Slow points test
Fast points test
Rect fill test
32x32 Blitter test
Mode = 320x240, hardware
Slow points test
Fast points test
Rect fill test
32x32 Blitter test
Mode = 640x480, software
Slow points test
Fast points test
Rect fill test
32x32 Blitter test
Mode = 640x480, hardware
Slow points test
Fast points test
Rect fill test
32x32 Blitter test
320x240 320x240 640x480 640x480
software hardware software hardware
Slow points (frames/sec): 1.386 1.38961 0.181905 0.181934
Fast points (frames/sec): 14.6027 14.6127 3.67341 3.67415
Rect fill (rects/sec): 2377.25 2380.01 790.581 790.886
32x32 blits (blits/sec): 5403.69 5375.33 5354.25 5340.29