Geminus brings multi-monitor desktops to RISC OS, along with screen rotation for LCD panels that can be used in portrait modes, and improvements to the quality and speed of image rendering.
Other features include the ability to transform/rotate JPEGs, which is available for all RISC OS machines, and Red/Blue colour swapping to support other graphics cards and digital outputs such as DVI (not supported by the NVidia driver module).
With apologies for the 'Blair Witch' camera work, captured using a mobile phone and unedited, this video shows first the performance of the desktop without Geminus acceleration, and then the increase in usability and slickness that Geminus currently provides on the ARMX6/i.MX6 hardware when using its optimised JPEG rendering and - most significantly - the GPU hardware for remembering window contents.
Geminus mode configuration window.
Supporting multiple monitors and portrait modes on RISC OS for the first time, Geminus provides a setup utility for configuring the desired screen modes. From the current monitor configuration, it will suggest a list of sensible screen modes which may be added to the list of defined modes for fast access.
Geminus mode selection dialog.
Geminus offers an extended mode change window for selecting the extended desktop modes that it offers, including multi-monitor and portrait modes.
Geminus permits the configuration settings to be changed for each application for maximum performance benefit and compatibility
At the RISC OS South West Show 2018 I demonstrated an early prototype of Geminus ported to run on the ARMX6 from R-Comp. This code uses the ARM NEON multimedia coprocessor to accelerate block copies and fills (eg. window drags, scrolling and clearing) in place of the nVIDIA graphics operations that are used by Geminus when running on the IYONIX pc.
All of the following machines support NEON coprocessor instructions and may thus benefit from this version of Geminus when it has been developed to the point of a working release:
I shall be particularly interested to see its performance on the machines that are Cortex-A15 based (Titanium, TiMachine, RapidO, IGEPv5) since this CPU architecture has twice the NEON performance per clock on account of having a wider NEON data pipe (128 bits rather than the 64 bits of the Cortex-A9)
That said, what is really needed to attain maximum performance from any of these targets is to use the dedicated hardware blocks (eg. 2D GPU or, failing that, generic DMA engine) to perform the block copy/fill operations. Using NEON instructions to perform these operations is unlikely to offer comparable performance since CPU hardware is unable to predict sufficiently far ahead of usage, which data within the memory will be required. Hardware blocks are able to perform specific prefetching, and are designed to mask the latency of memory fetches through the use of internal buffering.
Geminus - particularly in the form of cacheing window contents - offers a level of more intelligent acceleration over and above that attainable even with the dedicated hardware blocks. Hopefully, in time, better use may be made of each to attain the best of both.
I have working prototype code for the GPU 2D in the ARMX6 and other i.MX6-based platforms. Coupled with the acceleration code in Geminus it makes such a difference to the feel/speed of the desktop! the code is relatively crude at the moment and is based upon information from the magnificent etnaviv project, and from the open source Vivante drivers.
Still a lot of unexploited potential, and it's wonderful to have some information to use; Geminus was unable to make use of the nVIDIA hardware in the IYONIX pc purely because this information was unavailable.
All of the acceleration functionality of the IYONIX pc build of Geminus is now up and running in prototype form on the ARMX6/i.MX6 platforms now, yay! It does make the desktop a lot slicker, especially given my love of having large amount of screen real estate to work with more web pages, PDF documents and images etc.
The same functionality is now up and running on the Titanium, which benefits mostly from the JPEG acceleration and, of course, the redraw cacheing even with its faster processor. Always quicker to know the results than to have to compute them ;) I've also been experimenting a little with the prototype DisplayLink driver since I think supporting that is definitely something that could benefit all of the more recent RISC OS platforms.
True, my i.MX6 board can drive an UltraHD monitor or my 2560x1600 monitor, but I find additional screen space very useful and would love for it to be able to drive both!
2D GPU acceleration for ARMX6 and other i.MX6-based platforms released as a separate driver by R-Comp Interactive. Geminus itself which also uses the fruits of that development effort, extending it with the cacheing of window contents etc, will take a little long to reach a release state because of other ongoing development work. In the meantime, to accelerate your ARMX6/i.MX6 desktop using the Vivante GPU (particularly beneficial above, say, 2048x1536 because the CPU really isn't suited to reading a large amount of data from the frame buffer) visit the R-Comp store or contact R-Comp. No, I'm not on sales commission, I just want the work to benefit people. :)
Ported Geminus to run on the ARMbook laptop from R-Comp. This is using the NEON acceleration code from the ARMX6 build, introduced before that acquired GPU2D hardware acceleration. It is anticipated that this update to Geminus will see a commercial release in the near future for all NEON-capable non-IYONIX pc targets since it confers a considerable increase in the slickness and usability of the desktop.
We will be demonstrating the beta of Geminus on the ARMbook at the RISC OS South West Show on Saturday 22nd, and a pre-beta of the ARMX6 / WandBoard build too (a little more work required to increased the performance of window cacheing using the GC320 hardware).
Sign up to the Beta mailing list if you wish to help with testing.
Yay, 2D GPU block of i.MX6 is now being fully used for window cacheing, shuffling pixel data to/from the Geminus Cache in system memory. This makes a visible difference to the slickness of the desktop cf the NEON code that was being used at the SW show.
In the video, Geminus is initially disabled, and then the red cross is removed from over the Geminus icon and acceleration is enabled, before once again disabling it, so compare the performance with before that and afterwards.
I've also been playing with different software implementations (scalar and/or NEON) and managed to get substantially higher performance on those targets such as ARMbook, Pi<n> and Titanium where I have to use the CPU to move data to/from the window cache.
Hopefully the software optimisation work will find its way into generic memory copying routines for use elsewhere on all RISC OS targets; for example, an experimental modification to the RAMFS module means that I now have a significantly faster RAM disc on my machine :) ...
Geminus was originally available through Spellings Ltd. Thanks to Neil for distributing my software, and for agreeing to it being made freely available.
Download the original IYONIX pc
version of Geminus now.
Instructions are included in the download, and may also be found here.