Hardware graphics acceleration now available for ARMX6 and mini.m

R-Comp Interactive is pleased to announce that we have released a major new upgrade for ARMX6 and mini.m computer owners. This upgrade enables hardware graphics acceleration on the computers, unlocking extra capabilities of the i.MX6 CPU/GPU.

The new module makes desktop and command line operation up to (approx) 10x faster, although how tangible this is will vary depending on what you‘re doing, and the resolution you‘re running in.

Of particular note, scrolling through documents is much faster, as well as moving large windows around. Also, at the command prompt, screen scrolling is hugely faster.

The new upgrade allows ARMX6 and mini.m to deliver some of the fastest, smoothest desktop experiences around, at resolutions up to 4k (3840 × 2160).

Commenting on the benefits, Andrew Rawnsley said, ”As screen resolutions rise, and the average user runs at 1920×1080 or higher, hardware acceleration makes a huge difference to the desktop experience”.

This software acts as an add-on, loaded during startup. It does not affect your ability to install any future operating system updates, and will work in parallel with them.

The software is available now, and at the London Show on Saturday.

Hey, wow – that means at long last we have a RISC OS platform that can smoothly run a 4K display at an equivalent of 1920×1080 screen area using EX0/EY0 for very high display clarity (c.f. “retina” modes on OS X). I remember talking about that with a colleague back at Acorn in 1996 when 1600×1200 monitors were starting to become more common and we figured the resolutions would keep increasing. It was the driver behind the creation of the high density sprite filename conventions for application sprites and window tools. We didn’t foresee the industry cost-reducing down to 1080p as a common denominator and stalling the updates for a decade or so!

Well, it took 22 years but we got there in the end! Great work R-Comp.

The Pi3 works fine with 4K displays and has supported graphics acceleration for a long time. Time to update your hardware, Mr. Hodgkinson :-)

Andrew® was a bit light on the details, but what I gathered from the ARMini mailing list, it is “just” rectangle fill/rectangle copy acceleration. I have not seen benchmarks of the accelerated i.MX6 platforms, the unaccelerated i.MX6 was – for ROMark’s rectangle copy benchmark – a lot slower than RPi, PandaBoard, Titanium or even the IYONIX. And probably even as a ViewFinder-equipped RPC, which did a lot of accelerator magic.

Andrew®

I gather that this is an amusing Textilism rather than something deliberate :)

Oh yes, an R in round brackets gets converted to the “registered trademark” character. Funny. It was a last minute addition when I realised that I was answering two different Andrews.

Oh yes, an R in round brackets gets converted to the “registered trademark” character.

I think it does something similar with a C like this: ©

The Pi3 works fine with 4K displays and has supported graphics acceleration for a long time. Time to update your hardware, Mr. Hodgkinson :-)

Andrew’s point, quite rightly, is that the limitation is the displays. When the HDMI forum and content producers got to dictate what display aspect ratios and resolutions we were permitted to use on our computers they did us a grave disservice IMHO. Displays of 2048×1536 were not uncommon in the late 90s and yet it’s still comparatively rare to see a computer display that’s above 1920×1080 and now really hard to find a display that has an aspect ratio better-suited to computer use (eg. 2560×1600 has all but disappeared). I have even met some people who believe that analogue VGA cables and monitors could not support ‘full HD.’

Steffen: I cannot hook up my RPi3 to my UHD monitor at the moment, but my understanding was that all Pi chips still use the same HDMI hardware and it’s thus limited to 15fps? It was designed only for 1080p operation in ~2008, if so, and I must say that using a mouse pointer/GUI at 15Hz would frustrate me. The i.MX6 can drive UHD at 30Hz but even then – for me – it’s usable only because my UHD Dell is a monitor. On a UHD TV I have to disable processing and switch to a low-latency gaming mode otherwise the lag is objectionable.

Re benchmarks, I’ll perhaps try to run them side-by-side at some point; it’s the rectangle copy that’s nearly 10 times faster than the OS code when using acceleration and ought to be about the same as Titanium clock-for-clock, being the same hardware IP block, but it benefits more than Ti does on account of having ARM cores that are slower/Hz but the potentially-higher screen resolutions.

Steffen: I cannot hook up my RPi3 to my UHD monitor at the moment, but my understanding was that all Pi chips still use the same HDMI hardware and it’s thus limited to 15fps?

It depends on the Pi, but I was successful in driving my 4K monitor with 24Hz. This was good enough for me, so I stopped there. If it is helpful for you, I can have a go at 30 Hz. There will be a point where the Pi might need to be overclocked according to various comments in various forums. I also read that the Pi 3+ is the most “forgiving” and most likely to work compared to the older models.

You can see the config details here that worked for me:
http://riscosblog.huber-net.de/2018/03/raspberry-pi-3-b-4k-und-risc-os/

So no autodetection, you have to manually configure every detail.

and ought to be about the same as Titanium clock-for-clock, being the same hardware IP block

The Vivante inside the i.MX6 is the same 2D accelerator internally as the PowerVR inside the OMAP5? Probably I misunderstand what “hardware IP block” means.

Titanium is Sitara AM5728, a close relative of OMAP5 although to what extent they differ I know not. They both contain PowerVR block(s) and a Vivante GC320 block which they call ‘BB2D’ because it’s specialised for 2D rendering operations and doesn’t support 3D. i.MX6 contains instead two Vivante blocks; an instance of GC320 and their 3D block GC355. The accleration code now available from R-Comp uses the GC320 block and does not depend upon GC355; to attempt a port of a 3D driver would obviously be a lot more work, and be pretty pointless without a suitable 3D API library such as Mesa/GL.

Thanks for the details, Adrian. I will have a look at the data sheets to update the various infos in my brain :-)