| |
Geminus |
| |
adrianl (03:44 20/5/2018)
Phlamethrower (13:26 21/5/2018)
dfeugey (07:28 22/5/2018)
adrianl (20:37 27/5/2018)
nytrex (08:41 28/5/2018)
nytrex (08:41 28/5/2018)
davidb (12:25 28/5/2018)
dfeugey (09:19 12/6/2018)
adrianl (20:03 1/11/2018)
richw (15:51 2/11/2018)
hubersn (20:47 2/11/2018)
hubersn (20:51 2/11/2018)
adrianl (23:49 2/11/2018)
adrianl (06:51 5/11/2018)
adrianl (22:51 30/12/2019)
robheaton (16:33 31/12/2019)
adrianl (17:11 31/12/2019)
markee174 (18:19 31/12/2019)
adrianl (06:17 22/2/2020)
adrianl (00:45 23/2/2020)
adrianl (13:04 24/3/2020)
adrianl (00:49 26/5/2021)
nytrex (10:02 27/5/2021)
adrianl (16:35 16/9/2022)
adrianl (23:54 22/10/2022)
adrianl (21:09 22/8/2022)
ksattic (16:05 25/2/2020)
adrianl (18:30 25/2/2020)
ksattic (19:54 26/2/2020)
|
| |
|
Adrian Lees |
Message #124285, posted by adrianl at 03:44, 20/5/2018 |
Member
Posts: 1637
|
Anything anyone would like to see from it? To recap Geminus is a software layer that accelerates the desktop and extends it across multiple displays, offering portrait modes and - where necessary - R/B swapping for PC-directed hardware that does not offer efficient component swapping. It was built for the IYONIX pc; that was many years ago.
I'm lavishing some time on it to update it for more recent targets, and - aside from fixing the known issues with certain applications and backwards-compatibility issues in later OS versions - I wondered what its (prospective) users would most like to see?
Best wishes,
A |
| |
 [ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #124288, posted by Phlamethrower at 13:26, 21/5/2018, in reply to message #124285 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
From my perspective a lot of the features which Geminus supports should actually be features of the base OS. So I guess what I'd most like to see would be for those features to make their way into the OS!
I recently posted a summary on the ROOL forums of the pending work that's on my wishlist, so if there's a way that you or Geminus could help with that then that would be great. Or at least, you need to be aware of any incoming changes so that you can adapt Geminus to cope with them (or warn us if we're going to break it in some critical way). |
| |
[ Log in to reply ] |
| |
|
David Feugey |
Message #124289, posted by dfeugey at 07:28, 22/5/2018, in reply to message #124285 |
Member
Posts: 40
|
Acceleration would be great. Dual head support two, but it'll be a short term feature, as RISC OS will provide it one day.
If you focus on the Pi, GPU acceleration and dual (HDMI + VGA adapter) support would be fantastic.
Nota: GPU acceleration could be replaced by "other cores" acceleration. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124290, posted by adrianl at 20:37, 27/5/2018, in reply to message #124289 |
Member
Posts: 1637
|
Acceleration would be great. Dual head support two, but it'll be a short term feature, as RISC OS will provide it one day. I appreciate the point you're making, although it's perhaps a good job that I didn't take the same attitude 14-odd years ago when creating Geminus.
If you focus on the Pi, GPU acceleration and dual (HDMI + VGA adapter) support would be fantastic. Interesting suggestion, thanks. I was unaware of the existence of Gert's VGA adapter. The prototype DisplayLink driver is something I've played with a little, and one of the areas where the SoC-based designs upon which RISC OS now runs are limited is their display capabilities, in terms of head count and/or maximum resolution...
I appreciate the point about it being preferable to introduce/migrate any and all features into the base OS code. The issue remains, as always, in this materialistic, capitalist society, that code written exclusively to be made available to all for free in the OS, does not then pay the bills; and then there will be no more code!
Thanks for the suggestions.
[Edited by adrianl at 21:39, 27/5/2018] |
| |
[ Log in to reply ] |
| |
|
Alan Robertson |
Message #124292, posted by nytrex at 08:41, 28/5/2018, in reply to message #124290 |
Member
Posts: 117
|
snip snip
[Edited by nytrex at 09:42, 28/5/2018] |
| |
[ Log in to reply ] |
| |
|
Alan Robertson |
Message #124293, posted by nytrex at 08:41, 28/5/2018, in reply to message #124292 |
Member
Posts: 117
|
I appreciate the point you're making, although it's perhaps a good job that I didn't take the same attitude 14-odd years ago when creating Geminus. Absolutely agree. We would have missed out in all these goodies you have served up for us.
Thank you for doing the dirty work for us all those years ago. We are reaping the benefits today. |
| |
[ Log in to reply ] |
| |
|
David Boddie |
Message #124294, posted by davidb at 12:25, 28/5/2018, in reply to message #124290 |
Member
Posts: 147
|
I appreciate the point about it being preferable to introduce/migrate any and all features into the base OS code. The issue remains, as always, in this materialistic, capitalist society, that code written exclusively to be made available to all for free in the OS, does not then pay the bills; and then there will be no more code! Maybe those secretive RISC OS lovers at RISC OS Developments could fund you to do that work. A rising tide floating all boats, etc. |
| |
[ Log in to reply ] |
| |
|
David Feugey |
Message #124296, posted by dfeugey at 09:19, 12/6/2018, in reply to message #124290 |
Member
Posts: 40
|
I appreciate the point you're making, although it's perhaps a good job that I didn't take the same attitude 14-odd years ago when creating Geminus. I agree. But please note that there is REALLY ongoing work today about dual head support.
I appreciate the point about it being preferable to introduce/migrate any and all features into the base OS code. I never told this. In fact, I would prefer to have a commercial solution for my acceleration / dual head needs. I use RISC OS as my main OS, so I can't really wait for RISC OS 5.38  .
I'll definitively buy Geminus for my Pi. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124371, posted by adrianl at 20:03, 1/11/2018, in reply to message #124289 |
Member
Posts: 1637
|
A few people at the London show remarked that photos do not a good demonstration of acceleration maketh
So I've uploaded a simple video captured on a mobile phone prior to the RISC OS London Show. This is what Geminus can currently do on the i.MX6/ARMX6/WandBoard.
Please note that is with the window cacheing over and above the graphics acceleration released and available from R-Comp currently. The rest of the code is still alpha quality.
With that 2560x1600 screen, itself occuping over 15.5MiB, Geminus is using 192MiB for off-screen cacheing to remember everything and avoid redrawing, but modern RISC OS machines are not so much short of SDRAM but rather of software capable of using it to provide a better computing experience. |
| |
[ Log in to reply ] |
| |
|
Richard Walker |
Message #124374, posted by richw at 15:51, 2/11/2018, in reply to message #124371 |
Member
Posts: 73
|
What an amazing difference, Adrian!
Silly question: what makes this bespoke to the i.MX6/ARMX6/WandBoard platform? Does it talk directly to the specific graphics hardware in those machines? Which I guess rules out its use in a Pi, for example? |
| |
[ Log in to reply ] |
| |
|
Steffen Huber |
Message #124375, posted by hubersn at 20:47, 2/11/2018, in reply to message #124374 |
Member
Posts: 91
|
What an amazing difference, Adrian!
Silly question: what makes this bespoke to the i.MX6/ARMX6/WandBoard platform? Does it talk directly to the specific graphics hardware in those machines? Which I guess rules out its use in a Pi, for example? The Pi already has rectangle copy acceleration (see http://www.svrsig.org/howfast.htm for benchmark results - would be interesting to see some i.MX6 numbers).
Every accelerator code is somehow special - it depends on the graphics GPU integrated with the ARM on the SoC. |
| |
[ Log in to reply ] |
| |
|
Steffen Huber |
Message #124376, posted by hubersn at 20:51, 2/11/2018, in reply to message #124375 |
Member
Posts: 91
|
What an amazing difference, Adrian!
Silly question: what makes this bespoke to the i.MX6/ARMX6/WandBoard platform? Does it talk directly to the specific graphics hardware in those machines? Which I guess rules out its use in a Pi, for example? The Pi already has rectangle copy acceleration (see http://www.svrsig.org/howfast.htm for benchmark results - would be interesting to see some i.MX6 numbers).
Every accelerator code is somehow special - it depends on the graphics GPU integrated with the ARM on the SoC.
Sorry, this was misleading. Geminus does of course more than "bog standard" Pi acceleration. Adrian would have to fill in the details here, all I know is that Geminus worked in a similar way on the IYONIX pc (where it was much more important, because the CPU was slower, RAM was slower and especially access to GPU RAM over PCI was much much slower). |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124377, posted by adrianl at 23:49, 2/11/2018, in reply to message #124376 |
Member
Posts: 1637
|
What an amazing difference, Adrian!
Silly question: what makes this bespoke to the i.MX6/ARMX6/WandBoard platform? Does it talk directly to the specific graphics hardware in those machines? Which I guess rules out its use in a Pi, for example? The Pi already has rectangle copy acceleration (see http://www.svrsig.org/howfast.htm for benchmark results - would be interesting to see some i.MX6 numbers).
Every accelerator code is somehow special - it depends on the graphics GPU integrated with the ARM on the SoC.
Sorry, this was misleading. Geminus does of course more than "bog standard" Pi acceleration. Adrian would have to fill in the details here, all I know is that Geminus worked in a similar way on the IYONIX pc (where it was much more important, because the CPU was slower, RAM was slower and especially access to GPU RAM over PCI was much much slower).
Most of the code isn't specific to i.MX6 really. The difference you're seeing is mostly from the cacheing but the demo shows switching on/off both the basic copy/fill operations _and_ the cacheing simultaneously. It still does make a surprisingly large difference to the desktop feel on the Pi and, less so, Titaniun, despite the fact that they both have basic copy/fill accelerations already.
As Steffen rightly says, reading from the screen memory on the IYONIX pc was painful, whilst both reading and writing are much less expensive on SoC 'unified memory' systems, but it should be remembered that CPU reads from the uncacheable screen buffer are still bad news on Pi/Ti and I think I'm right in saying that neither can strictly be used to shuffle pixels between screen and cache storage because the GraphicsV API is constrained.
Geminus on the IYONIX pc and indeed the i.MX6 therefore doesn't use the OS API, since it can offer a bit more functionality by direct hardware access in each case. On Pi and Ti, at least for now, it just uses the defined API.
On all platforms, however, the cacheing is beneficial since it can eliminate most of the time involved in switching to an application, having it compute what should be rendered, and actually render it...using what has become my greatest maxim of optimisation; "Don't compute anything, know the answer already!"  |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124379, posted by adrianl at 06:51, 5/11/2018, in reply to message #124375 |
Member
Posts: 1637
|
What an amazing difference, Adrian!
Silly question: what makes this bespoke to the i.MX6/ARMX6/WandBoard platform? Does it talk directly to the specific graphics hardware in those machines? Which I guess rules out its use in a Pi, for example? The Pi already has rectangle copy acceleration (see http://www.svrsig.org/howfast.htm for benchmark results - would be interesting to see some i.MX6 numbers).
Every accelerator code is somehow special - it depends on the graphics GPU integrated with the ARM on the SoC.
Hi, I've just run RISCOSmark on my i.MX6 WandBoard at 1920x1080p60 16M colours; it reports 136% with the OS SW doing the copying, 1324% with the IMXGC320 module loaded. The table doesn't stipulate a frame rate, but I tried dropping to p30 and it only went up to 1395%, so the extra bus traffic doesn't make much difference at that screen res. It does drop to 1137% with my nice big 2560x1600x16Mx60Hz mode. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124671, posted by adrianl at 22:51, 30/12/2019, in reply to message #124379 |
Member
Posts: 1637
|
Quick note to say that, being away from base and the i.MX6 board, I've ported Geminus with its NEON accelerations, JPEG rendering and redraw cacheing onto the ARMbook, giving a significant increase to the slickness/usability of the desktop a la that demoed at the South West show in Feb 2018. No use of the GPU hardware on that chipset yet, however. There is an open source Linux driver/reverse-engineering project for its Mali 400 GPU, but AFAIK nobody has looked at producing a RISC OS port yet. |
| |
[ Log in to reply ] |
| |
|
Rob Heaton |
Message #124672, posted by robheaton at 16:33, 31/12/2019, in reply to message #124671 |
Member
Posts: 76
|
That is good news!
Do you have any plans to release it? |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124674, posted by adrianl at 17:11, 31/12/2019, in reply to message #124672 |
Member
Posts: 1637
|
That is good news!
Do you have any plans to release it? Evince is the priority at the moment . I brought the ARMbook on 'holiday' because at that point its code did not fully support 'PC ordering' screen modes (B first); it now does. - Then Geminus updated for all targets, with NEON accelerations and GPU acceleration where available.
I'd really like to offer multi-monitor support on all targets - Pi4 (dual HDMI output) and ARMbook/i.MX6/other Pi devices (additional monitors via VNC or DisplayLink) and much of the Geminus/Evince code has been written for reuse with that in mind, but I guess that'll have to wait until later. |
| |
[ Log in to reply ] |
| |
|
Mark Stephens |
Message #124675, posted by markee174 at 18:19, 31/12/2019, in reply to message #124674 |
Does all the
work around here
Posts: 154
|
do you have a planned released date for evince? |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124729, posted by adrianl at 06:17, 22/2/2020, in reply to message #124675 |
Member
Posts: 1637
|
It hasn't been the most productive of winters so there's still a bit more work to be done on a couple of Evince features. It'll be there to see at the show today but Geminus updates for the ARMX6 (predating Evince anyway) and (new) for the ARMbook shall see light of day first.
The latter is ready to go to beta testers, with the ARMX6 build requiring a little more work but should also be in beta very soon, with the initial release of the Evince client to happen soon after.
Geminus offers its accelerated and transformed JPEG decoding, as well as window cacheing (far and away the greatest performance enhancement). Cacheing uses GC320 hardware on the ARMX6 and NEON on the ARMbook. Hardware acceleration has not yet been investigated on the latter but owing to the faster CPU<->memory interface of the 64-bit CPU in the ARMbook, the NEON coprocessor alone is able to offer nearly double the performance of the OS code. Later, use of hardware blocks may be investigated in conjunction with R-Comp as per the i.MX6 acceleration.
Anyone interested in helping with beta testing as the above become available can now join the mailing list. Thank you.
[Edited by adrianl at 06:21, 22/2/2020] |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124734, posted by adrianl at 00:45, 23/2/2020, in reply to message #124729 |
Member
Posts: 1637
|
As recorded on the show article, the portability work done for the ARMbook also allows Geminus to run on the Titanium and the Pi 4.
I've previously used it on the earlier Pi versions experimentally and know that all targets benefit from the window cacheing and JPEG features, so I think the thing to do is have three versions: (i) IYONIX pc build, free compatibility update, (ii) ARMX6/WandBoard build, which can make direct use of the GC320 hardware to increase further the speed of the window cacheing an sprite rendering (iii) Generic NEON/CPU build for all other targets. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #124735, posted by ksattic at 16:05, 25/2/2020, in reply to message #124285 |
 Finally, an avatar!
Posts: 1291
|
Just picking up this thread now.
Geminus has never worked properly on my Iyonix, unsure why. By "never worked", I mean that dragging any icons cause screen corruption - namely I'm seeing what looks to be large-ish BLTs with old screen contents smeared across the screen. I should really take a screenshot and add it to this thread later.
It's a launch Iyonix, not one of the dev ones, using the original graphics card with R/B hardware swap (er, the GeForce 2MX). I do have an FX 5200 card but I've never installed it as the primary - only as the secondary while trying to get 3D via DMA working in the past. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124736, posted by adrianl at 18:30, 25/2/2020, in reply to message #124735 |
Member
Posts: 1637
|
Geminus has never worked properly on my Iyonix, unsure why. By "never worked", I mean that dragging any icons cause screen corruption That's because that build of Geminus does not understand additional sprite formats that DragASprite uses in more recent versions of the OS.
There were also a couple of issues relating to window cacheing (applications using particularly Wimp_ForceRedraw in ways that Geminus did not anticipate).
Both are fixed in the the latest build of Geminus, and those issues are the primary reason that I intend to issue a free update of Geminus for the IYONIX pc, although I'm in the awkward position of not having an usable machine at present for testing.
For now, IIRC you can maybe just switch off sprite plotting for all applications including 'Other apps' |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #124738, posted by ksattic at 19:54, 26/2/2020, in reply to message #124736 |
Finally, an avatar!
Posts: 1291
|
Ah, thanks! I will give that a try! It is a nifty piece of software. Actually, the accelerated JPEG decoding is by far the most interesting thing to me... |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #124762, posted by adrianl at 13:04, 24/3/2020, in reply to message #124734 |
Member
Posts: 1637
|
Geminus using Vivante GPU2D block on i.MX6/ARMX6 to move window data to/from its cache At the SW show I was using NEON for the window cacheing because I had the GPU2D block working only for on-screen copies.
Geminus/GPU2D disabled when the red cross is shown over Geminus on the icon bar, ie. at the start and end of the video....Disabled, Enabled and then Disabled again.
... a couple of bugfixes and tidying now and I'll unleash ARMX6 and ARMbook builds together.
Stay safe all.
[Edited by adrianl at 13:06, 24/3/2020] |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #125132, posted by adrianl at 00:49, 26/5/2021, in reply to message #124762 |
Member
Posts: 1637
|
If anybody regularly uses RISC OS 5 under RPCEmu and would be interested in helping beta test Geminus could they please join the mailing list?
I have amused myself over the weekend by implementing an extension to RPCEmu that moves most of the heavy lifting to native code when running Geminus under RPCEmu, as if it had use of a hardware accelerator block. Essentially the host performs the bulk of the pixel shuffling in moving/scrolling/cacheing windows. Anyone wanting to test this will need to integrate small changes into the source tree of their RPCEmu build and then rebuild. I use RPCEmu on Ubuntu but not regularly on macOS or Windows.
ARMbook users can also get access to a beta test build that I now realise I have not mentioned publicly; it's not just i.MX6/ARMX6.
[Edited by adrianl at 01:50, 26/5/2021] |
| |
[ Log in to reply ] |
| |
|
Alan Robertson |
Message #125135, posted by nytrex at 10:02, 27/5/2021, in reply to message #125132 |
Member
Posts: 117
|
RPCEmu is already a fantastic piece of software that delivers a great RISC OS experience. Having some of the Desktop Sprite stuff being accelerated by the host PC sounds like an awesome upgrade.
More Power to you Keyboard. Awesome work. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #125319, posted by adrianl at 21:09, 22/8/2022, in reply to message #125132 |
Member
Posts: 1637
|
Geminus acceleration is now available via the new store, for free Demo-licensed trials or to purchase a Full licence.
https://sendiri.co.uk/store
i.MX6 targets (ARMX6, WandBoard, mini.m and CuBox) and the ARMbook laptop for now, with Raspberry Pi 4 and RiscPC/RPCEmu builds to be released shortly.
Enjoy! |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #125335, posted by adrianl at 16:35, 16/9/2022, in reply to message #125135 |
Member
Posts: 1637
|
RPCEmu is already a fantastic piece of software that delivers a great RISC OS experience. Having some of the Desktop Sprite stuff being accelerated by the host PC sounds like an awesome upgrade.
More Power to you Keyboard. Awesome work. The RPCEmu/RiscPC build has now been released on the store. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #125352, posted by adrianl at 23:54, 22/10/2022, in reply to message #125335 |
Member
Posts: 1637
|
Hello all,
Geminus graphics acceleration is now available for the Raspberry Pi devices and, addressing earlier remarks, the store is now more accessible without the need to login or to register. See Sendiri Store
Geminus Any Pi
To keep things simple, there is a single version of Geminus that runs across the entire current range of Raspberry Pi devices from the lowliest Raspberry Pi 1, through 2, 2 (V1.2) and 3 up to the super fast Raspberry Pi 4. Since Geminus is licensed to the Individual rather than the machine, and Individual licensing permits a single person to install and use the software simultaneously on up to four devices, most users will find that a single licence covers all of their Raspberry Pi needs.
On the Raspberry Pi 4, Geminus is able to leverage the faster DMA4 hardware present in the latest SoC and thus provide rectangle copying that is 3.5 times faster than the on-screen copying supported in RISC OS. Of course this capability is also exploited to redraw window contents even faster, and if there is one thing that RISC OS on the Raspberry Pi 4 is not short of, it's a lot of RAM to create a nice big cache to support even the largest of desktop screens.
Background: Geminus provides a much faster, smoother desktop experience by using spare RAM to remember the contents of windows, by offering faster scrolling and dragging of windows on the desktop, and by making greater use of acceleration hardware. It also provides an accelerated JPEG decoder and renderer, which can benefit any application that asks RISC OS/SpriteExtend to perform on-the-fly JPEG rendering.
Next: Aemulor 2.55 updates for all targets, and Geminus 1.42 updates for the i.MX6, ARMbook and RPCEmu builds. These shall, of course, be free to existing licence holders, but allow a little time for me to complete the necessary website work first.
Best regards,
Adrian |
| |
[ Log in to reply ] |
| |
|
