forums.ps2dev.org

Hop,

All is in the subject :D

I wrote a simple tool to compare the different PS2 gfx libs available :
- GfxPipe by Vrrzrrn/Sjeep
- Libito by Jules
- GsKit by NeoVangelist (based on PbDemoLib)
- PbDemoLib by emoon
- LibPlanar/LaLib by Neofar/DJ Huevo
- GsLib by Hiryu (based on GfxPipe)
- GSULib by Oopo
- DreamGL by Dreamtime
- PS2Linux

This tool is basically a plasma screen rendered on a grid and the tool increase the grid size in order to reach the maximum number of gouraud triangles the lib can support.

So it's not an absolute performance test as the plasma UV generation is far from optimized and I'm nearly sure that all Gouraud Triangle lib primitives don't use the VU1. So do not take this tool as a performance tool but as a comparison tool on one criteria: gouraud triangles.

The tool is not finished as I did not implement all the libs yet (DreamGL is still buggy, and GsLib and GSULib are not done) and some are still fuzzy.

So feel free to modify it :D

look at the readme for usage

Link : wait for monday...

Current results :
[edited...]

Let the wars begin. :)

Hrmm something seems to be amiss here.

I just compiled and tested it with gsKit, and only made the following modifications:

gsGlobal = gsKit_init_global(GS_MODE_PAL); // Set 640x480 non interlaced mode
gsGlobal->ZBuffering = GS_SETTING_OFF;
// gsGlobal->Width = 640;
// gsGlobal->Height = 480;
// gsGlobal->StartX = 632;
// gsGlobal->StartY = 40;
// gsGlobal->MagX = 3;
// gsGlobal->MagY = 0;


The above lines were commented out, because they were incorrect. PAL is not 640x480, it is 640x576 (In gsKit).

As for StartX/StartY, they are inconsequential.

Also:

if( (fps < GS_REGION_MODE) & (mycounter == 0) ){
printf("[%2d fps] with %d*%d*2=%d triangles\n", fps, grid_step_W, grid_s
// decreaseLOD();
increaseLOD();
}


increaseLOD was put there so that I could have it continually add more triangles until the lib broke.

gsKit reached the following:

[ 7 fps] with 16*480*2=15360 triangles

At this point, the screen went black just like libito and gfxpipe.

My guess, is that is a hardware contraint with the GS itself, or a bug in your test suite that causes it at this point. It seems odd to me that three different libraries would all crash at once on this number.

However, I am curious as to how to got the result you did with gsKit. I made almost zero modifications to your library, and my gsKit is stock from CVS save a couple of small bugfixes.

Thanks a lot for your feeback Neovangelist !!!!

Yep I agree, the tool is far from being finished and the results are not consistent yet.

The first tricky thing is to find for all libs a relevant and unique screen setting, probably PAL/640*480/Non Interlaced is not a good choice...

Until somebody propose me a nice setting, I'll think I'm going to set it to PAL/non interlaced/320x240 which is not that nice but supported by all.

Concerning the poor results I've got with gskit... dunno why, my version is from 2 weeks ago from the CVS, I'll update it (if you're interested I can send you my current... but... maybe useless)

Concerning the my goal was to increase the nb of triangles until the framerate fall (so basically how many triangles can you draw at fullframe=50Hz) and I decrease the LOD else.
So I can see you're able to reach the strange limit by at 7fps and not at fullframe as gfxpipe, pbdemolib or libito can. So how many triangles can gskit render at 50 fps ?

Then I agree the 15360 is strange, maybe a bug in the plasma generation, I'll try a simplier effect like drawing random x,y triangles.

So thanks again for your update !!
The goal is not to make wars, simply to see what is available and maybe to help the developpers to fix bugs...because the performance is one aspect but not the only one.... grawing gouraud triangles is straight forward for any lib but for example gskit is far from more "configurable" and powerful in terms of features than gfxpipe for example... so this is not the Gfx Oscars :D, only a limited testsuite :D

Okay, I found what this limit is while taking my shower.. SHAME ON ME !!!
Even the trollest Ps2dev troll would have found it...

I won't explain it as it really too stupid... and I feel ashamed...

So I wrote another drawing routine displaying random triangles... I'd like to test it before releasing it tomorrow...

I'll keep my funny plasma screen for a demo ;-D

NeoV, can you give me the gsGlobal attributes I need to set for PAL/320x240 ?
Currently I set : Is it right ?

Hey there, thanks for the follow up!

Alrighty, couple things here.

NeoV, can you give me the gsGlobal attributes I need to set for PAL/320x240 ?

What you are trying to do here is called "Half Buffers". As of right now gsKit does not support half buffers. I spent quite some time before on them, but they are still not working. However, all the framework and such is there and ready, it just needs to be completed and tested.

Also, in regards to the performance issues, those I am aware of.

The issue here is that gsKit does not currently have a render queue to form proper display lists to send on bufferflip/vsync.

Right now, when you do gsKit_prim_* or any other routine that has to send a packet to DMAC, it sends it right that instant. As a result of this, we have much uneeded DMAC overhead, and lost efficiency. I am working on an implimentation which puts these into a queue and sends them as a DMA chain on vsync, but this was going to wait until gsKit 0.3. However, I think that after I fix this nasty texture bug I may take a shot at it.

overflowing? ;)

Here is a new version of my tool including a simplier but more reliable bench

http://tmpstore.free.fr/ps2dev/GfxLibTests11.zip

This bench simply dispaly randomly 32x32 gouraud triangles and catch how many the lib can draw using its gouraud primitive (not VU) at full PAL framerate, in 320x240 (not supported by all libs):
So, as some libs, as NeoV said, don't support 320x240, reqsults are still not totally relevant.
By the way, I'm quite hurry to have GsKit 0.3 and the DMAC usage optimization (GfxPipe is simply the better example...)

So taking profit of Scratchpad and DMAC pipes can be a solution no ;-D

have you tried lalib? also from ps2dev.ofcode

Mr Bob,

As libplanar is using lalib to provide GS access, I would say yes.... even adding a layer can add bottlenecks too :D

I have to finish the code for GSLib and GSULib to be exhaustive...

overflowing? ;)

well, in the case of LlibPlanar the freeze is caused by an buffer overflow, the code don't do any kind of bound checking.

in the last test libplanar has 2500 poligons per frame that are:
6 qwords per triangle * 2500 = 0x3A98 (near 0x4000)

inside libgs.c says: you can change it to: and you will get about 10900 points in last Shazz test.


anyway be aware that:
in (busclock/16) ticks
153600 ticks is a NTSC frame
184320 ticks is a PAL frame

the little nice goraud triangle took about 4 ticks to be full drawed, but more complex draws (ie textured ones, larger ones, etc) this number increment a lot, then with superultralooperfast code like gfxpipe you can send a lot of poligons data but at the media value of 6,6 ticks each one in NTSC.

another thing is send texture data, that also can be transfer to local memory through the VIF.

Shazz: what means "bad magx"?

djhuevo wrote: well, in the case of LlibPlanar the freeze is caused by an buffer overflow, the code don't do any kind of bound checking.

in the last test libplanar has 2500 poligons per frame that are:
6 qwords per triangle * 2500 = 0x3A98 (near 0x4000)

inside libgs.c says:

Code: Select all

qUnion gsPacket[0x4000];

you can change it to:

Code: Select all

qUnion gsPacket[0xFFFF];

and you will get about 10900 points in last Shazz test.

Welcome here DJ Huevo ! Nice to meet you :D
Thanks for the fix, I'll will update my LaLib.

djhuevo wrote: anyway be aware that in (busclock/16) ticks
153600 ticks is a NTSC frame
184320 ticks is a PAL frame

Eh eh in the sqme time I'm writing a timer lib using all the possible precision offered, I will use it to, as you did, provide detailed stats for each triangle... (If you already code something with the timers, we have to keep in touch ;-) )

djhuevo wrote: the little nice goraud triangle took about 4 ticks to be full drawed, but more complex draws (ie textured ones, larger ones, etc) this number increment a lot, then with superultralooperfast code like gfxpipe you can send a lot of poligons data but at the media value of 6,6 ticks each one in NTSC.

Yep, that's why I've got a define called TRIANGLESIZE I set to 32 which is I think an average triangle side size for complex 3D objects... but yep, if you're curious, increase this value and you'll see how the perfs fall !! Amazing ! Try to fill the screen with one triangle of 320x240 and you'll reach nothing more than 4000 triangles per frame (so better to have plenty of small than huge ones if you can :D)

djhuevo wrote: another thing is send texture data, that also can be transfer to local memory through the VIF.

For sure using the VIF is a first state for higher priority primitives and at the end using the VU1 is the only way to achieve performance (easy double your poly rate) but not everybody is aware/ready to use the VU1 and so the libs are here for them :D

I'm thinking of a lib which can generate at run time VU1 microcode to perform standard primitive drawing... maybe could be an idea, dunno...

djhuevo wrote: Shazz: what means "bad magx"?

One of the parameters, magnifier in x and y, needed by the GS to handle lower resolutions like 320x240, if I'm not wrong

Why Havnt anyone add SuperLib to the lits yet ?

Because you did not ask anything to the marketing guy... :-)

Then send me 100 euros if you want some good results else I can't promise anything... :D

Just a note, with latest gsKit in svn (with the renderqueue) my current score is 6080. (A big improvement from 2220!)

It's still all path3, but has a proper renderqueue and dma to/from the scratchpad.

However, it will not be faster out of box, you will need to modify whatever app/lib is using gsKit a bit to take advantage of the new system.

It's fairly easy, and I've updated the examples to illustrate how.

UPDATE:

Current SVN now scores 8864 in PAL :)

Next boost will come from going via VU1... hoping to narrow the gap between my lib and gfxpipe considerably.

Enjoy!