search

uli / basicengine-firmware

BASIC Engine Firmware
78 stars 16 forks source link

Overall graphics performance decrease since firmware ver. 382 when the circle fill routine was fixed #22

Open bitartrate opened 4 years ago

bitartrate commented 4 years ago

There seems to be a bug surrounding the circle fill routine and maybe the line drawing routine.

Using the below program as a benchmark we see these data points: v.354 fixed circle color and psx freeze (3142 lines per second lps) v.358 fixed psx (2846 lps) v.366 (3286 lps) this is the high tide and is reproducible v.372 (2901 lps) v.382 fixed circle fill (1219 lps) v.384 fixed line command (346 lps) strange anomalous dip that is reproducible every time v.386 fixed edit command (1095 lps)

900 SCREEN 4 1000 z=TICK() 1010 FOR I=1 TO 10000 1020 x1=RND(320) 1030 x2=RND(320) 1040 y1=RND(200) 1050 y2=RND(200) 1060 c=RND(256) 1070 LINE x1,y1,x2,y2,c 1080 NEXT 1090 t=TICK()-z 1100 PRINT INT(10000000/t);" lines per second."

uli commented 4 years ago

This is the direct-mapped cache rearing its ugly head. It is likely that two or more of the methods called to draw a line (from the BASIC command implementation down to setPixel()) occupy the same space (modulo 32k).

I have committed patches that group all pixel-graphic related methods into one group (basic_video); that may fix the problem. For now. Please check if it does.

It would also be nice if you could turn the above program into a test case that checks that the performance doesn't drop below, say, 2000 lines per second. (Put it in tests/eb, along with a .run file with the expected output.)

bitartrate commented 4 years ago

I do remember you writing about the direct-mapped cache and it's potential for problems. I will turn it into a test case and send it to you. For now the patch (pre firmware ver.398) is averaging 520 lines per second per the above program. I will continue to think on this one too and see if I come up with any ideas.

bitartrate commented 4 years ago

I just wanted to get some quick data. I will make a more user friendly and enlarged time window test program.I have made an interim test program that only starts the draw routine at a whole tick(1) second to satisfy my control issues. ;) Upon taking much smaller sample size of 1 second per cold run; in that time window each run is between 510-530 lines per second. So ver.398 is averaging 520 lps.
In contrast ver.366 is averaging 2590 lps. So I think I will set a threshold for more like 500 lps for the test case for now.

uli commented 4 years ago

The other day, this bug had a comment from Kevin saying

With ver.398 I see a bump in performance back up to 3250 lines per second over the span of 10,000 lines

I have no idea why that isn't here anymore. Did it not work?

bitartrate commented 4 years ago

Hi Uli, I'm sorry I had bad data that day so I deleted the report. I am actually getting 1100 lines per second on the current nightly build.