Raspberry Pi 4

IIRC there was also more need to do cache control / memory barriers etc on the reads.

Correct – reading (to cacheable memory) requires cache maintenance at the start and the end of the operation, while writing only needs maintenance at the start.

Does RISC OS even support using DSI?

Yes (it’s basically all handled by the firmware, the only thing RISC OS is likely to need is a suitable MDF)

https://www.riscosopen.org/forum/forums/5/topics/3591

I suspect DSI might be a bit of a leftover from the Pi’s heritage? Or maybe it’s “a thing” in the mobile phone/embedded media player sectors?

Both. The DSI connector was present on the Pi 1, and they haven’t had a reason to remove it (especially since the official touchscreen makes use of it). And yes, small embedded devices generally use DSI (or similar) because it’s a simpler (smaller, cheaper) interface than HDMI.

@David: Those benchmark results of the Processor looped instructions are totally in line with the ones measured by Chris back in time on the linux Risc OS port on his Chromebook (also C-A72). He measured 5158932 at 2.2 Ghz, which would scale almost equally to 1.5 Ghz to your result of 3588423. Though that benchmark doesn’t show much of any real world conclusions anyway. But hey, at least it runs ;-)

So what’s the status ? Desktop running, also keyboard I guess. And mouse ? If so any link to a test image setup to download ?

Desktop running, also keyboard I guess. And mouse ?

No to all three I believe as there is as yet no USB on the Pi 4 under RISC OS, hence no keyboard and mouse (except possibly via a hack and the serial port) apart from command line input/output via serial terminal. Thus desktop would be unusable.

So what’s the status ? Desktop running, also keyboard I guess. And mouse ?

The status is much as outlined in the Pi rounded up to four news post. Work has been done to allow the ROM to start but there is no USB or Ethernet.

Here’s the full RISCOSmark benchmark.

First at the default clock speed (1.5GHz)

RISCOSmark 2.04 (30-Dec-2015) by Richard Spencer 2003
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800x600,256
(HD benchmarks are in kilobytes/sec)

MOS Utilities   5.27 (02 Jul 2019)
FileSwitch      2.87 (08 Jun 2018)
C Library       6.02 (08 Jul 2019)
USBDriver       1.29 (19 May 2018)
FileCore        3.75 (06 Jul 2017)
Shared Sound    1.20 (18 Jun 2016)
SCSIFS          1.35 (20 Jul 2018)
ShareFS         3.59 (11 Sep 2016) Access+
LanManFS        2.62 (04 Jun 2019)
SharedUnixLibrary       1.14 (05 Sep 2015) (C) UnixLib Developers, 2001-2015
HAL-based system (BCM2835 VDU device) tested at Sun,14 Jul 2019.08:43:47
Filing system: SDFS:RISCOSpi.$.Bench
Graphics Resoloution: 1920x1080, 16M colours

Test                                                   Benchmark
Processor - Looped instructions (cache)                  3721895    2092%
Memory - Multiple register transfer                        47852   29538%
Rectangle Copy - Graphics acceleration test                 1346     556%
Icon Plotting - 16 colour sprite with mask                 59174    2958%
Draw Path - Stroke narrow line                             15360     984%
Draw Fill - Plot filled shape                               2758     189%
Draw Render - Render draw file                              5522     609%
HD Read - Block load 8MB file                              23405     784%
HD Write - Block save 8MB file                             15264     501%
FS Read - Byte stream file in                               1367     660%
FS Write - Byte stream file out                              524     272%

Then running at 1.75GHz

Test                                                   Benchmark
Processor - Looped instructions (cache)                  4346081    2443%
Memory - Multiple register transfer                        55858   34480%
Rectangle Copy - Graphics acceleration test                 1346     556%
Icon Plotting - 16 colour sprite with mask                 60953    3047%
Draw Path - Stroke narrow line                             15946    1022%
Draw Fill - Plot filled shape                               2979     204%
Draw Render - Render draw file                              5994     661%
HD Read - Block load 8MB file                              23184     777%
HD Write - Block save 8MB file                             15456     508%
FS Read - Byte stream file in                               1450     700%
FS Write - Byte stream file out                              453     235%

And again at 2.0GHz

Test                                                   Benchmark
Processor - Looped instructions (cache)                  4970115    2794%
Memory - Multiple register transfer                        63908   39449%
Rectangle Copy - Graphics acceleration test                 1348     557%
Icon Plotting - 16 colour sprite with mask                 59343    2967%
Draw Path - Stroke narrow line                             13664     875%
Draw Fill - Plot filled shape                              10732     735%
Draw Render - Render draw file                             15606    1722%
HD Read - Block load 8MB file                              23405     784%
HD Write - Block save 8MB file                             14804     486%
FS Read - Byte stream file in                               1549     748%
FS Write - Byte stream file out                              547     284%

39449%

Never mind – just noticed this: Comparison with RiscPC SA 202MHz.

Damn. A StrongARM, not a lowly 310. That’s all the reason anybody ought to need to understand why keeping old machines running is…. What’s the word? Futile?

PS: Has somebody been fiddling with the forum this weekend? I have to clear cookies/log in multiple times before it “sticks”. Grrrrrrrrrr…!

That’s all the reason anybody ought to need to understand why keeping old machines running is…. What’s the word? Futile? => Site admins can this person be removed from the forum ?. ;-) . Well keeping old machines is for fun. And it easier to measure in DIL components …

Well keeping old machines is for fun.

I wasn’t referring to “collectibles” (I still have my original Model B). I was referring to those who stick with the old slow power hungry chunderbugs in preference to new things.
It’s like favouring an 8088 box (look, it has a Turbo button!) over a little modern netbook type machine that can near infinitely outclass it in every way. That’s the Ti/MX6/π4 compared to the old boxen of Acorn era. Fun as a vintage piece, left behind as a serious machine…

PS: Has somebody been fiddling with the forum this weekend? I have to clear cookies/log in multiple times before it “sticks”. Grrrrrrrrrr…!

Must be the way you do it?

Draw Path - Stroke narrow line    15360     984%
Draw Fill - Plot filled shape      2758     189%

Weirdness.

I have to clear cookies/log in multiple times before it “sticks”

Don’t start at riscosopen.org/forum – start at the root, click ‘log in’, delete cookies and log in, then go to Forum.

Draw Path - Stroke narrow line    15360     984%
Draw Fill - Plot filled shape      2758     189%

Weirdness.

I expect the performance of those tests will have been impacted by the serial terminal – it just redirects OS_ReadC / OS_WriteC over the serial port (including the VDU sequences), so anything which uses lots of VDU sequences will be slow.

Sounds to me like we need some real life tests too, like:

• Load NetSurf, fetch and render ROOL forum recent posts page.
• Ditto Otter.
• Load Ovation, with a reasonably complicated file (any of the old Frobs?), print to PDF (via PostScript).
• And?

I wonder if such a thing could be made with a program to create fake mouse position and fake keypresses to act as “the user”, and hook into FileV and/or OS_ChangedBox or something to detect when the screen is no longer changing (hence job done?)? Maybe also monitor how fast the Wimp polls prior to starting the test, and see how long it takes to return to a similar state?

Something like that might provide a more real-world test than “it can shift memory around four hundred times faster than this arbitrary RiscPC”.

I expect the performance of those tests will have been impacted by the serial terminal – it just redirects OS_ReadC / OS_WriteC over the serial port (including the VDU sequences), so anything which uses lots of VDU sequences will be slow.

It was caused by the SpecialFX module. I’ve updated the 2.0GHz results without it loaded.

A few more benchmarks.

povray -w1024 -h768 +a0.3 teapot.pov

Tianium @1.5GHz 9s
RPi4 @2.0GHz 5s
RPi3b+ @1.4GHz 14s

RPCEmu on RISC OS running RISC OS 5 idling at the desktop

Titanium 20mips
RPi4 @2.0GHz 42Mips
RPi3b+ @1.4GHz 15mips

SQLQuake timdemo demo1 1280×1024 in windowed mode.

Titanium 33fps
RPi4 @2.0Ghz 53fps
RPi3b+ @1.4GHz 22fps

Impressive!

@Chris: Nice results! A comparison to RPI 3 would be even more interesting, if you got some time to do that. To run the RPI 4 at 2.0 Ghz permanently, I guess you use some active cooling ? Any picture of your setup ?

It was caused by the SpecialFX module.

Sorry for being naïve, but can someone explain better? Is SpecialFX causing slowness only on this special case, or every RPi is ‘affected’? If this is the case, can SpecialFX be corrected to better perform?

I expect the performance of those tests will have been impacted by the serial terminal – it just redirects OS_ReadC / OS_WriteC over the serial port (including the VDU sequences), so anything which uses lots of VDU sequences will be slow.

Draw calls HLineAddr directly.

Is SpecialFX causing slowness only on this special case

SpecialFX IIRC is a module that redirects Draw SWIs to CC’s GDraw module, which does anti-aliasing. This requires blending pixels to the background, which involves a read, multiplies (usually 3, but 2 if you know what you’re doing), in addition to the pixel write (and further table lookups and bit-twiddling for <24bpp) for every pixel, so AA is necessarily slower than blitting.

Draw, like the rest of the VDU code, draws complete scanlines. So apart from line starts and ends in paletted modes, this becomes trivial multi-word blits, and is very fast. So large rectangles in 24bpp are the fastest per pixel one could expect (in software only).

When “narrow” is mentioned, and goes significantly slower, there is clearly an issue with edges (as there’s be almost no “inside”). Since this isn’t likely to be a low-colour mode these days, the only other explanation is that something is going very slowly when dealing with edges – hence anti-aliasing.

My surprise was that no one had noticed from the numbers that there was something amiss.

Sorry for being naïve, but can someone explain better? Is SpecialFX causing slowness only on this special case, or every RPi is ‘affected’? If this is the case, can SpecialFX be corrected to better perform?

My solution was always “remove SpecialFX from everywhere”. It has produced countless hard-to-debug problems and therefore cannot be worth using it. If any bug or weirdness shows up, you should always first ask “is SpecialFX active”. Saves a lot of time.

Nice results! A comparison to RPI 3 would be even more interesting, if you got some time to do that. To run the RPI 4 at 2.0 Ghz permanently, I guess you use some active cooling ? Any picture of your setup ?

I’ve updated the ‘A few more benchmarks’ post to include the comparison to RPi3b+.

Definitely needs a fan. Just a USB fan blowing air from underneath. About 60 C under load with fan.

Definitely needs a fan. Just a USB fan blowing air from underneath.

The Fan Shim by Pimoroni sounds ideal for the job.

Regarding SpecialFX/GDraw module and its slowness, can’t the anti-aliasing process be offloaded to the GPU, maybe with a ‘fake’ GDraw module? The GPU in RISC OS is largely underused (for technical reasons, I know).

The alpha-blending part is just the end of a very long process of number-crunching and data-processing to take a Draw path and stroke/fill, dash-pattern, join/cap and linewidth specification and produce actual pixels.

Part of the design of the Cerilica Nucleus was that the alpha-blending stage of the Vantage graphics engine pipeline was to be implemented in the FPGAs. This was easy because the engine produced complete 32b RGBA scanlines. Whereas, IIRC, GDraw antialiases edge-crossings and blits interiors separately… but maybe Martin has changed that.

What would be crucial is the API to the hardware and its overheads. Either way, you won’t be implementing the whole of the Draw module’s rasterisation in the GPU.

Either way, you won’t be implementing the whole of the Draw module’s rasterisation in the GPU.

I only have superficial knowledge of todays’s GPUs, but…why not?

I mean of all the things that the few RO developers left might spend their time doing, duplicating Draw’s scaling, flattening, dashing, thickening, joining, capping, re-flattening and rasterisation in OpenCL (say), rather than merely making use of alpha blending, seems too unlikely to consider.

Relevant link

I mean of all the things that the few RO developers left might spend their time doing, duplicating Draw’s scaling, flattening, dashing, thickening, joining, capping, re-flattening and rasterisation in OpenCL (say), rather than merely making use of alpha blending, seems too unlikely to consider.

OK, that clears it up.

We have a saying where I work, when someone comes up with a rather complex task, at the end of discussing it, someone asks “Was spricht dagegen außer dem Aufwand”, which roughly translates into “What – apart from time and effort – prohibits us from doing it?”