NEMBENCH rework - test

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Scarlettkitten
Captain Atari
Captain Atari
Posts: 260
Joined: Thu Mar 19, 2009 11:42 am
Location: Northamptonshire, UK

Re: NEMBENCH rework - test

Postby Scarlettkitten » Fri Dec 21, 2012 3:03 pm

MegaSTE again 16MHz with cache on and -mste option.

Image
Music gear
Falcon 030 14MB, Cubase Audio, Soundpool FA8,FDI, MAudio 88 keystation, Roland S750, Yamaha A5000, Roland JV1080, Yamaha MG10, 1040STE, ZX Spectrum 128k.

https://soundcloud.com/softkitty123

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: NEMBENCH rework - test

Postby dml » Fri Dec 21, 2012 3:20 pm

Scarlettkitten wrote:MegaSTE again 16MHz with cache on and -mste option.


Thanks.

Looks like I haven't got this quite right yet - the figures for tests 'ICe' (instruction cache enabled) should be better, but they are the same. But it didn't crash as it did on all other machines so it's probably very close. Need to read the docs again.

doh.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: NEMBENCH rework - test

Postby dml » Fri Dec 21, 2012 4:54 pm

Tonight after a stiff drink I managed to swap the existing XC68040RC40M chip on my Afterburner board for the latest production mask revision, so it should run cooler and I might not need the *very* noisy fan that was stuck on the heatsink.

There are some ugly 'superglue' hacks around the mainboard I will clean up before I put it all back together and I should be in good shape for 68040 tests.

The PGA socket on that board isn't a real one apparently - it's a lot of small headers packed closely together and they aren't perfectly lined up. When I saw that after prizing off the chip I began to doubt if it would ever work again! The first boot didn't work but then I remembered it wont boot without the fastram installed. so it seems to be ok. :)

User avatar
Cyprian
Atari God
Atari God
Posts: 1507
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: NEMBENCH rework - test

Postby Cyprian » Mon Jul 15, 2013 2:25 pm

Hi Dml,
I'd like to request two additional features for Nembench. The first one is the test of Linear 16bit read/write/copy for ST-Ram (and maybe TT-Ram?). The second one is the test for Video-Ram, in both variants: Linear 16bit and also Linear 32bit read/write/copy.

Why 16bit for ST ram, due to that CPU more often operates on bytes and words than longwords (e.g. words data for TOS OS calls and bytes data for packers/depackers ). And also it would provide figures for performance comparison: 16bit (Falcon) bus vs 32bit (TT/A1200/A4000).

Regarding Video-ram, would be cool to know how really "fast" are e.g. VME cards for TT (they use 16 bit interface) and SuperVidel (32 bit interface)

What do you think about that?
thanks
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: NEMBENCH rework - test

Postby dml » Mon Jul 15, 2013 2:52 pm

Cyprian wrote:Hi Dml,
I'd like to request two additional features for Nembench. The first one is the test of Linear 16bit read/write/copy for ST-Ram (and maybe TT-Ram?). The second one is the test for Video-Ram, in both variants: Linear 16bit and also Linear 32bit read/write/copy.


Ok, no problem. I'm not very sure why 16bit was omitted previously but it's easily added. Perhaps byte-based transfers are also interesting, for some types of chunky operation?

Video ram - I don't know of a 'clean' way to request video ram at the moment. Until video cards (and SV) appeared on the scene, STram and video ram were the same thing.

The obvious way is just to see what the OS is using and write to that memory - but it is a bit untidy for a TOS app with TTY output (the written area could be backed up I suppose but will still show garbage while writing). Unless a cleaner method has appeared recently, this is probably how it would need to work?

User avatar
Cyprian
Atari God
Atari God
Posts: 1507
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: NEMBENCH rework - test

Postby Cyprian » Mon Jul 15, 2013 3:22 pm

dml wrote:Ok, no problem. I'm not very sure why 16bit was omitted previously but it's easily added. Perhaps byte-based transfers are also interesting, for some types of chunky operation?

yes, byte-based test would be cool also.

dml wrote:Video ram - I don't know of a 'clean' way to request video ram at the moment. Until video cards (and SV) appeared on the scene, STram and video ram were the same thing.

good question.
I have Mega STE and TT. I'll try to check how my VME video card is reported by TOS (Maybe Physbase is pointing out to Video ram?) on them
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

User avatar
Cyprian
Atari God
Atari God
Posts: 1507
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: NEMBENCH rework - test

Postby Cyprian » Mon Jul 15, 2013 8:53 pm

here is a sample code how to detect ATI Radeon card in CTPCI:

http://bus-error.nokturnal.pl/tiki-read ... =11&page=2

Code: Select all

//check graphics card availability
if((unsigned long)Physbase()<0x01000000UL){
  //graphics card not found, exit
  // not very sufficient test, can give problems
  // if another graphics card is connected
  logd("Graphics card not found! Exiting...\n");
  return 0;
}

looks easy, I will check if its works with TT's VME
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: NEMBENCH rework - test

Postby dml » Mon Jul 15, 2013 9:17 pm

Cyprian wrote:here is a sample code how to detect ATI Radeon card in CTPCI:
looks easy, I will check if its works with TT's VME


Yep just checking for physbase inside/outside the 16mb STRam window.

I suppose if that test passes, it's easy enough to do the rest - there is a risk it may not detect some kinds of card at all, but maybe not a big risk unless video is ported through some HW register area or cartridge port or something strange like that...

User avatar
shoggoth
Nature
Nature
Posts: 942
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: NEMBENCH rework - test

Postby shoggoth » Tue Jul 16, 2013 4:31 pm

Cyprian wrote:here is a sample code how to detect ATI Radeon card in CTPCI:

http://bus-error.nokturnal.pl/tiki-read ... =11&page=2

Code: Select all

//check graphics card availability
if((unsigned long)Physbase()<0x01000000UL){
  //graphics card not found, exit
  // not very sufficient test, can give problems
  // if another graphics card is connected
  logd("Graphics card not found! Exiting...\n");
  return 0;
}

looks easy, I will check if its works with TT's VME


Honestly, this is a horrible test imo. Doesn't Didier provide some cookie for this? That test can give false positives for other graphics cards, and philosophically it just feels plain horrible. CT60 TOS v1.04 and higher does a similar test and decides pixel format based on the location of the frame buffer, and that's just... not right.

Please just do it some proper way instead, no offense.
Ain't no space like PeP-space.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: NEMBENCH rework - test

Postby dml » Tue Jul 16, 2013 5:57 pm

I haven't done anything about it yet - just waiting to see what advice pops up here on the subject.

Clearly a cookie is preferred for the devices that provide one. It doesn't look like there is a 'general' solution though for other kinds of card (except via more cookies where available or nasty speculating with addresses).

I probably won't look at this until the weekend but will use the 'clean' way for SV since that's the primary interest at the moment I think.

note: Nembench already uses the CPU cookie and a clean method of detecting TT ram. I'm willing to entertain some special case detections if they are already in use and known to work - but don't aim to create any new ones.

User avatar
shoggoth
Nature
Nature
Posts: 942
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: NEMBENCH rework - test

Postby shoggoth » Tue Jul 16, 2013 9:23 pm

The SV reacts very differently to move16 compared to move.l and movem (move16 gives 4x performance or something like that). IIRC move16 is write-through and doesn't pollute the cache, and the SV bus logic has a much easier time collecting the data compared to move.l etc. Perhaps this could be taken into account by the benchmark, or you could have a separate move16 bench.

Personally I'd rather add a 3rd class of memory to Mxalloc(). It's not difficult, but so far I haven't gained any support for it. Instead, there's ct60_vmalloc(), which is the same on the CTPCI and the SuperVidel.
Ain't no space like PeP-space.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: NEMBENCH rework - test

Postby dml » Tue Jul 16, 2013 10:05 pm

shoggoth wrote:The SV reacts very differently to move16 compared to move.l and movem (move16 gives 4x performance or something like that). IIRC move16 is write-through and doesn't pollute the cache, and the SV bus logic has a much easier time collecting the data compared to move.l etc. Perhaps this could be taken into account by the benchmark, or you could have a separate move16 bench.


Yes move16 works behind the cache / nonpolluting but still uses burst signals IIRC.

I'll make a second instance of the move16 test for video ram (in fact, probably worth repeating most tests on all kinds of ram available).

shoggoth wrote:Personally I'd rather add a 3rd class of memory to Mxalloc(). It's not difficult, but so far I haven't gained any support for it. Instead, there's ct60_vmalloc(), which is the same on the CTPCI and the SuperVidel.


Either is good news but yes extending Mxalloc() seems more natural.

User avatar
shoggoth
Nature
Nature
Posts: 942
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: NEMBENCH rework - test

Postby shoggoth » Wed Jul 17, 2013 2:27 pm

dml wrote:Either is good news but yes extending Mxalloc() seems more natural.


Yep. It would also have the benefit of freeing unfreed memory on process termination, which isn't the case right now (ct60_vmalloc() is an XBIOS call, and GEMDOS has no clue about it).

Just a suggestion - if you add the possibility to override the memory locations for the different tests through a configuration file, people could use the app on (unlikely) future hardware as well.
Ain't no space like PeP-space.

RA_pdx
Captain Atari
Captain Atari
Posts: 215
Joined: Sun Feb 02, 2003 12:01 pm
Location: Nuernberg/GERMANY

Re: NEMBENCH rework - test

Postby RA_pdx » Wed Aug 14, 2013 7:10 pm

Until today i never recognized this thread - so i am a little bit late. ;-)

IMG_RA.jpg

For the machine look at my signature below.
You do not have the required permissions to view the files attached to this post.
>> > raZen/Paradox < <<

Atari 1040STE, TOS 2.06, 4MB, MC68010, IDE 8GB SSD, Gigafile

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: NEMBENCH rework - test

Postby dml » Wed Aug 14, 2013 7:14 pm

A 68010... cool :)

Well I had to shelve this for a while anyway, to get other stuff done. But I'll return to it before long. I wanted to use it to figure out a few mysteries (to me, anyway).

Dal
Administrator
Administrator
Posts: 4161
Joined: Tue Jan 18, 2011 12:31 am
Location: Cheltenham, UK
Contact:

Re: NEMBENCH rework - test

Postby Dal » Wed Dec 11, 2013 11:59 am

Here's my results on a Mega ST4 with the Gadgets By Small SST accelerator fitted.

Specs are:
68030 and 68882 both running at 33Mhz
8MB SST (Fast) RAM 60ns
Normal Wait States: 1
BURST Mode Wait States: 1

First, here is the benchmark with FastRAM disabled:
SST - FastRAM Off.jpg


Now here's what happens when FastRAM is enabled:
SST - FastRAM On.jpg
You do not have the required permissions to view the files attached to this post.
Mega"SST" 12, MegaSTE, STE: Desktopper case, IDE interface, UltraSatan (8GB + 512Mb) + HXC floppy emulator. Plus some STE's/STFM's


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 3 guests