I doubt it.

Wonderful cheap hardware or no, you'd be looking at a 4x to 10x system boot time increase before you even do anything. So I'd say that was pretty pants...

Anyway, the main point was that there would be no incentive for non-RISC OS users to buy them, and little incentive for existing users either.

ROR.

In practice it would be worse than that as some fiddling and driver software would be required to get the ARM to talk to the Pentium/ATHLON to ask it to ask the AGP Video 3D controller to draw a line (as an example). Rather than the ARM simply writing to the VRAM on the RPC as it would normally do !

In short an SA on a PCI card would probably (at best) offer less than 50% the speed of an actual ARM in an RPC and (on top of that) would only be as stable as Windows (as it would rely on Windows) for all the I/O - in short it would be a tragic mistake !

ROR!

If you want to draw a square 1000 pixel by 1000 pixels on a RiscPC in a 32 bit colour mode then yes it has to move 4Mbytes across the internal bus. But if you draw from x,y to x+1000,y+1000 on a PCI card then its only going to have to move 20? 30? 50? bytes.
How many CPU cycles does it actually take to plot a humble pixel on the screen? Theres no proof here that even that will be slower.

Even using the FPE the maybe improvements.

Why is it major re-write? Isnt the whole point our system is that anyone who does anything to thescreen does it through the VDU drivers. It would only require a conversion of the VDU character stream to the appropriate 2D/3D stream. I know some programs drive the screen directly but that because they were forced to do it that way for performance reasons. The principle is similar to viewfinders solution, has anyone done any benchmarks on it?

Basically a 3D accelerator improves a machine with an inadequate video bus more than one with a good video bus.

I use a Matrox G-200 on my old Cyrix box, if you turn video acceleration off (so the CPU does all the work) it is slower, but not by that enormous an amount (and at the time the G200 was highly recommended as the fastest 2D card on the market). Point being that the difference is you bypass a slow bus and a large part of the performance is down to that.

In an ideal world both CPU and graphics processor would share the same (fast) RAM over a fast bus. Ideally the CPU would do the graphics (its the most flexible option in fact, as 3D processors are fairly "dumb").

The major re-write I referred to was because we originally speculated about an ARM CPU on a PCI card driving a windows machine which controls and AGP video 3D card. The point is converting the ARM side is not too difficult, but getting good performance (over a PCI bus) will require intricate (ie., tricky) ARM code and (to top that) on the PC side you will need code to detect the drawing requests made by the ARM and then make the appropriate Windows Driver calls.

This is not trivial. The performance issues are between (i). Fast transfers to the slow PCI bus to the P-III/Athlon (2). Running a task to detect drawing requests from the ARM and (3). Translating such calls to equivilent requests to the AGP card.

If you use Microsoft technology (such as DirectX) you may also need to license this for inclusion in your product (I suspect that might be expensive - but if you know differently please let me know).

All in all, the above "song and dance" may even make the old ARM writing the Video RAM on an RPC seem positively speedy.

If you want to use 3D cards on an ARM system you would need to use the ARM natively (no P-III's please) you'd have to implement AGP (an Intel product probably requiring a license) and produce drivers that are specific for the card you intend to use (otherwise ActiveX which may require a Microsoft License) and the active co-operation of the card vendor.

A simpler approach is to get RISCOS 32 bit, use the latest ARMs and implement a multiprocessor strategy on a bus similar to that in Imago. This would give (I feel) the best performance at the lowest cost to the developers.

There have been problems with some of the supporting chipsets for multiprocessor systems (the i840 for example doesn't handle ECC RAM correctly apparently). In the past some multiprocessor Intel systems haven't really multiprocessed properly!

Well to start with, I believe that a 486 DX66 will outperform a SA on FP arithmetic, but then again how much software really needs FP arithmetic?? Looking at the most common uses of the computer and we'll try and point out a few key facts..

Word processing - still just about the most common use of a computer

_No_ benifit in having FP hardware
Benefit in good Anti-Aliasing (RiscOS has this)
Benefit in good WYSIWYG Printer drivers (RiscOS has always had this)

Do you really need a 700MHz Athlon computer to type a letter to a customer? And if you type lots of letters to customrs then you really get to meet the deficiencies in Window's filing system - Mmm that tiny window of 3 or four columns of files, and if one of them has a long Filename - well it could take forever to hunt through them!!

Anyway, I did have more to say, but I'm starting to ramble so I'll arrange my thoughs and get back to you all later.

Regards, Ryan