p96 is unbelievably Slow!

[wawrzon]

okay ive updated my voodoo3 setup as well. by hand this time. was not much to do, most libs were up to date. also my picture.datatype is newer than the contained in the archive. i dont recall where it is from. maybe it is some wos version, will have to take look at version number. all is working well, no hits, not much difference to before, excep a slight speedup in "pig" on little endian mode. in kuklomenos im getting 10fps in big endian and 7 in little.

on p4 things are quite different. there is quite a boost, but not in kuklomenos. i wonder why is this so slow. i suspect p96 is quite slow drawing the lines. if i inderstood you correctly, matt, also to draw lines in 3d cgx or p96 is used. is this correct? and this too is explicitely slow in w3d.

apart of that i now get with picassoIV system also a hit on startup. but that might be due to corrupted filesystem. i have to bring that in order first. here is a log, i dont think it will indicate anything without the sources though.
--------------------------------------
30-Sep-08  22:29:33
LONG READ from 00000020                        PC: 07373FE8
USP : 070B0FAC SR: 0010  (U0)(-)(-)  TCB: 070B0728
Data: 00000000 00000060 00000044 00000084 073579EC 07357ABA 07357ADE 00000000
----> 073579EC - "Work:Libs/Picasso96/rtg.library"  Hunk 0000 Offset 0000016C
----> 07357ABA - "Work:Libs/Picasso96/rtg.library"  Hunk 0000 Offset 0000023A
----> 07357ADE - "Work:Libs/Picasso96/rtg.library"  Hunk 0000 Offset 0000025E
Addr: 00000000 FFFFFFFF 0738D354 0738D354 0735766E 0738D354 000046CC 07002340
Stck: 070008D4 0738A18C 00F81CBA 00000400 00000000 00000000 00000000 00000000
Stck: 00000000 07357ADE 0735766E 073586A6 00000000 073581BB 070B06B0 00F81100
Stck: 07357884 0738A18C 00FD56BE 070B0728 070008D4 00FD560E 00F8A06E 00000800
Stck: 72616D6C 69620000 00000000 070B0710 070B0772 00000000 00000001 070B1030
Stck: 00000014 00000002 003E26A2 003E3AFA 003F5571 00000000 00000000 00000038
Stck: 00000001 FFFFFFFF 070B11CC 01C50F87 00000001 00000001 00F8F5DE 00F8F6C2
Stck: 00F8F6B6 070B104C 00000000 000000C4 FEDCBA98 00000000 00000000 070113D8
Stck: 0000A4A4 10100000 00010005 00000000 00000000 0000A4A4 00101008 4DEF0000
----> 07373FE8 - "Work:Libs/Picasso96/rtg.library"  Hunk 0002 Offset 00017D58
----> 00F81CBA - "ROM - exec 45.20 (6.1.2002)"  Hunk 0000 Offset 00001C0C
----> 07357ADE - "Work:Libs/Picasso96/rtg.library"  Hunk 0000 Offset 0000025E
----> 073586A6 - "Work:Libs/Picasso96/rtg.library"  Hunk 0000 Offset 00000E26
----> 073581BB - "Work:Libs/Picasso96/rtg.library"  Hunk 0000 Offset 0000093B
----> 00F81100 - "ROM - exec 45.20 (6.1.2002)"  Hunk 0000 Offset 00001052
----> 07357884 - "Work:Libs/Picasso96/rtg.library"  Hunk 0000 Offset 00000004
----> 00FD56BE - "ROM - ramlib 40.2 (5.3.93)"  Hunk 0000 Offset 000003E6
----> 00FD560E - "ROM - ramlib 40.2 (5.3.93)"  Hunk 0000 Offset 00000336
----> 00F8A06E - "ROM - dos 40.3 (1.4.93)"  Hunk 0000 Offset 000005B2
----> 00F8F5DE - "ROM - dos 40.3 (1.4.93)"  Hunk 0000 Offset 00005B22
----> 00F8F6C2 - "ROM - dos 40.3 (1.4.93)"  Hunk 0000 Offset 00005C06
----> 00F8F6B6 - "ROM - dos 40.3 (1.4.93)"  Hunk 0000 Offset 00005BFA
PC-8: FF0C60BE 2F0E6068 700043FA 00424EAE FDD82C40 70FF91C8 72604EAE FFB82040
PC *: 20280020 41FAFFD2 208041FA FF7C2080 41FAFF60 208041FA FF0A2080 41FAF7B8
07373fc4 :  6dff fffe ff0c             blt.l $7363ed2 ;extended opcode
07373fca :  60be                       bra.s $7373f8a
07373fcc :  2f0e                       move.l a6,-(a7)
07373fce :  6068                       bra.s $7374038
07373fd0 :  7000                       moveq.l #$0,d0
07373fd2 :  43fa 0042                  lea.l $7374016(pc),a1
07373fd6 :  4eae fdd8                  jsr -$228(a6)
07373fda :  2c40                       movea.l d0,a6
07373fdc :  70ff                       moveq.l #-$1,d0
07373fde :  91c8                       suba.l a0,a0
07373fe0 :  7260                       moveq.l #$60,d1
07373fe2 :  4eae ffb8                  jsr -$48(a6)
07373fe6 :  2040                       movea.l d0,a0
07373fe8 : *2028 0020                  move.l $20(a0),d0
07373fec :  41fa ffd2                  lea.l $7373fc0(pc),a0
07373ff0 :  2080                       move.l d0,(a0)
07373ff2 :  41fa ff7c                  lea.l $7373f70(pc),a0
07373ff6 :  2080                       move.l d0,(a0)
07373ff8 :  41fa ff60                  lea.l $7373f5a(pc),a0
07373ffc :  2080                       move.l d0,(a0)
07373ffe :  41fa ff0a                  lea.l $7373f0a(pc),a0
07374002 :  2080                       move.l d0,(a0)
07374004 :  41fa f7b8                  lea.l $73737be(pc),a0
Name: "ramlib"

[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!!

[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