log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- PhotoFiler get first update in 12 years (News:6)
- RISC OS Direct Videos -4. Networking (News:)
- What is your current RISC OS setup? (Justin Fletcher) (News:3)
- Own a Unique Silver Deuce Case... for Charity (News:1)
- Iris browser continues to evolve (News:3)
- August News round-up (News:)
- Rougol August meeting welcomes Cloverleaf Project (News:2)
- NetSurf reaches version 3.10 (News:18)
- How fast is RPC-Emu? (News:9)
- The London Show goes ahead online only (News:1)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
Site Search
 
Article archives
The Icon Bar: General: Geminus
 
  Geminus
  adrianl (04:44 20/5/2018)
  Phlamethrower (14:26 21/5/2018)
  dfeugey (08:28 22/5/2018)
    adrianl (21:37 27/5/2018)
      nytrex (09:41 28/5/2018)
        nytrex (09:41 28/5/2018)
      davidb (13:25 28/5/2018)
      dfeugey (10: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)
  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 04:44, 20/5/2018
Member
Posts: 1629
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 14:26, 21/5/2018, in reply to message #124285
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15094
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 08:28, 22/5/2018, in reply to message #124285
Member
Posts: 37
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 21:37, 27/5/2018, in reply to message #124289
Member
Posts: 1629
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 09:41, 28/5/2018, in reply to message #124290
Member
Posts: 37
snip snip

[Edited by nytrex at 09:42, 28/5/2018]
  ^[ Log in to reply ]
 
Alan Robertson Message #124293, posted by nytrex at 09:41, 28/5/2018, in reply to message #124292
Member
Posts: 37
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 13:25, 28/5/2018, in reply to message #124290
Member
Posts: 138
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 10:19, 12/6/2018, in reply to message #124290
Member
Posts: 37
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 smile.

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: 1629
A few people at the London show remarked that photos do not a good demonstration of acceleration maketh smile

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: 45
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: 86
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: 86
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: 1629
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!" wink
  ^[ Log in to reply ]
 
Adrian Lees Message #124379, posted by adrianl at 06:51, 5/11/2018, in reply to message #124375
Member
Posts: 1629
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: 1629
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: 73
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: 1629
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
Member
Posts: 84
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: 1629
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: 1629
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
ksattic
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: 1629
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
ksattic
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: 1629
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 ]
 

The Icon Bar: General: Geminus