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
- Code GCC produces that makes you cry #12684 (Prog:27)
- LEAF - game for A3010 released at last! (Games:1)
- GPS becomes Data Logger (News:1)
- RISC OS source code to be ...Apache open source license (News:13)
- Geminus (Gen:14)
- RISC OS London Show Report 2018 (News:5)
- October News Headlines (News:)
- RISC OS London Show 2018 - Notes from the talks (News:4)
- Does this form of documentation annoy you as much as me? (Prog:1)
- RISC OS London Show 2018 - pictures (News:)
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 (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)
 
Adrian Lees Message #124285, posted by adrianl at 03:44, 20/5/2018
Member
Posts: 1574
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
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15066
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: 35
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: 1574
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: 30
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: 30
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: 123
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: 35
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: 1574
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: 34
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: 77
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: 77
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: 1574
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: 1574
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 ]
 

The Icon Bar: General: Geminus