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
- Git client updated to 0.07 (News:2)
- Archive Edition 27:1 reviewed (News:)
- Rougol April 2024 meeting on monday is Anniversary time (News:1)
- WROCC April 2024 meeting o...changes to our phone lines (News:1)
- April developer 'fireside' chat is on saturday night (News:)
- March 2024 News Summary (News:4)
- WROCC Newsletter Volume 41:11 reviewed (News:)
- WROCC March 2024 meeting o... Hughes and Peter Richmond (News:1)
- Rougol March 2024 meeting on monday with Bernard Boase (News:)
- Drag'n'Drop 13i2 edition reviewed (News:)
Related articles
- RISC OS - the week in comments
- Wakefield 2006 show report
- 50,000 shares, Iyonix Select and a Belated Happy Birthday
- Podcast 2
- Wakefield 2001 show report
- Wakefield 2002 show report
- Wakefield 2005 show report (pictures)
- Wakefield 2004 show report
- Wakefield 2005 show report
- Omega LegPuller at ROUGOL meeting
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: News and features: Omega Update
 

Omega Update

Posted by Richard Goodwin on 13:23, 5/2/2001 | , ,
 
As well as news on the Australian deal, the MicroDigital news page gives us the reason for the long delays in Omega shipping:
As most readers are aware we had hoped to be in a position to ship the first machines before christmas. Unfortunately that was not to be and we are still awaiting delivery our chip set.
It might help readers to understand the problem if we explain that the chip set refered to above is our own design and as such it is not an of the shelf device, so we are unable to go into the market and simply buy an alternative. The reality of the situation is that our order is small compared to other much larger manufacturers and we are told that we going to have to wait our turn.
Had we realised at the time of ordering that any delay would be this long we would have used a different technology, which is still a real alternative.
So it seems that the problem is with the big chip manufacturers, and MD are getting as impatient as we are.
 
  Omega Update
  This is a long thread. Click here to view the threaded list.
 
Lee Johnston Message #88331, posted at 09:28, 12/2/2001, in reply to message #88330
Unregistered user Rich - Annraoi wasn't defending Omega regarding 2D/3D acceleration, he's talking purely about Imago. You're right though a mid to high end AGP card is going to blow the Lightning away. OTOH the latest top end nVidia cards will set you back over 400quid so isn't particuarly practical in an off the shelf RISC OS system right now. Of course you don't have to put one of these in the machine but it would be nice 8)

Regarding the comment that most code will run around 4 times faster if you remove the bandwidth limitations, we know this isn't true because Kinetic doesn't offer a consistent 4 times increase and if it were true the SA would have an awful cache. However code that does do a lot of graphics manipulation will see a huge benefit (and this is exactly the kind of market the Imago is aimed at).

One potential problem is that the processor is still doing all the work. Imago is capable of some very large screen resolutions but, without help from the hardware, the SA has to do all the updating itself. Let's take an extreme look (and I'll emphasise EXTREME here - this is an example of choosing a good benchmark to back a claim up). Assume a 1600*1200 mode in 24bit (top "published" spec of the competition ie Lightning). Also assume a 233Mhz Rev T SA and that it does about 260MIPs (figures from memory). Finally assume that we're doing some graphics manipulation and that we're updating approximately one quarter of the screen.

On a dumb framebuffer system the SA has to load the data from memory and then place it in the framebuffer. Assuming each word (ie each pixel in 24bit) takes one cycle (IIRC early SAs unrolled multiple loads to a series of single loads etc). The CPU has just spent 960,000 cycles redrawing the screen. In the meantime the accelerated competition has just seen the CPU vector through a driver and say "dump the memory from here to here for me" - say a few hundred cycles (at absolute most) - and then got back to running the application. Note as Annraoi has pointed out in the past that it isn't quite this straightforward for Omega as bus contention will halt the processor while the data is being transferred to the graphics card.

I'm not even going to go into full screen animations at fair resolutions as, even without bus limitations, a SA is going to struggle. This represents a problem for me as this is where my main interests lie. I know lightning won't be the complete answer either. However this doesn't mean that I won't buy an Omega, or Imago or whatever when one appears as I do need a major hardware upgrade.

So the point to bear in mind is that all the systems proposed have drawbacks, each has made different compromises. Omega had a price point to match and also had to emulate the VIDC and IOMD. Imago is aimed at high end graphics and video and as such has tonnes of bus bandwidth. However as the screen resolution and number of colours increases then the SA will be under more strain to update the screen - not a huge problem if you're dealing with mostly static screens. Evolution will probably be based on a "CATs+" board; much more than that we can't say. Finally Castle haven't said anything so they may or may not be working on a new machine.
  ^[ Log in to reply ]
 
William Black Message #88332, posted at 11:59, 12/2/2001, in reply to message #88331
Unregistered user They'd be silly not to, wouldn't they!
  ^[ Log in to reply ]
 
Annraoi Message #88333, posted at 19:01, 12/2/2001, in reply to message #88332
Unregistered user Yes, Lee I may well have overstated my case saying that code would run x4 faster with the bandwidth limitations removed. Code or data on cache would still run at the same speed, I/O might improve by up to X4 (as all code is NOT just I/O and is not just all on cache the performance would be somewhere in between). Isn't the data cache on the SA-110 used for screen buffering (a good way to trash the cache) if so the memory bandwidth still remains an important factor in overall performance.

I'd suggest to Richard not to misunderstand what I am driving at, 2D or 3D acceleration is desirable, my only two queries are (i) about putting it on the far side of a slow PCI bus and (ii) addressing the need for a high basic memory system bandwidth that systems such as CATS don't address. A well integrated 2D/3D accelerator whose activities interleave well with the ARM is the way to go, and the faster the memory subsystem the better (and faster) that interleaving will be.
  ^[ Log in to reply ]
 
[mentat] Message #88334, posted at 20:59, 12/2/2001, in reply to message #88333
Unregistered user I'd suggest to Richard W that whilst some of his points are valid (or even "good"), he should really stop calling people 'silly' and 'daft'. This is an interesting enough discussion with that sort of unnecessary personal attack. ROR with peace!
  ^[ Log in to reply ]
 
Richard Walker Message #88335, posted at 08:45, 13/2/2001, in reply to message #88334
Unregistered user For the record, I have not called anyone names. 'Silly' and 'daft' apply to ideas, not people!
  ^[ Log in to reply ]
 
Pages (2): |< < 2

The Icon Bar: News and features: Omega Update