| From: | NESL |
| Date: | 18 Sep 2000 at 12:39:45 |
| Subject: | AMIOPEN: Load Balancing / Clustering |
I'm wondering if the OS supports or will support clustering and load
balancing.
It seems to me that if this is or will be supported using a platform
independant binaries, and implemented using platform independant binaries,
it would be a big SAM (Surface to Air Missile) that would help sink M$. ;-)
-----Original Message-----
From: Aaron Optimizer Digulla [mailto:digulla@hepe.com]
Sent: Monday, September 18, 2000 9:00 AM
To: open@amiga.com
Subject: Re: AMIOPEN: Dev Questions
On Sat, Sep 16, 2000 at 11:35:49PM +0200, Rady Marusa wrote:
> JvdL> This is somewhat disturbing to me. Using the pixmap plot routines is
just
> JvdL> way too slow to do anything fancy. Allocating a writing to a
programmer
> JvdL> supplied image buffer is just such an often used operation in games,
demos,
> JvdL> and anything else that needs to do a lot of changes from frame to
frame.
> JvdL> Saying that one must use ave/ave/pix/plot to draw your image is just
> JvdL> stupid IMHO. How does Tao's port of Quake and Doom do it?
>
> I agree!
> Pixmap methods are great for applications and simple games,
> but really not for fast, hi-quality games.
>
> But we need direct access to videoram framebuffer, not to
> pixmap buffer.
"fast, hi-quality games" ?? Excuse me, but I know no game who renders
directly
in the framebuffer anymore; they all need specific 3D hardware and thus,
direct access to the framebuffer seems to be futile, at least to me.
One of the more important points is that such "direct access" would also
allow
nasty code to wreck havoc with your system so I'm not at all sure if such
"hacks"
are a good idea at all (because for direct access to work, you must somehow
bypass the memory protection of the system).
And last but not least, I could not play such "fast, hi-quality games" on
my PDA or cell phone because they will run only on one kind of hardware.
Another point which is against the philosophy of the whole system.
IMHO, the only clean solution is this:
- A game must allocate a private pixmap in which it renders. All the
normal security will apply to this (ie. the game can only currupt its
own memory, etc).
- When a frame has been rendered, the game must ask the OS to copy this
pixmap to the framebuffer.
Since every hi-quality game must do double-buffering anyway, they must
already do it this way, so there is nothing new here. The problem is
of course the second step. It's not because "old, hacky" games don't
need to do it but they render into a hidden framebuffer and then
make that second framebuffer visible, so there is no real "copying"
of the data involved. To make the above concept viable, the new AmiOne
must provide a fast DMA-copy method so games will not have to wait
for the copying to be done.
On PDAs and similar systems, the amount of data to be copied is usually
pretty small (but alas is the available power to copy it). So we might
get away with a highly optimized routine to copy the data.
You agree that you have read and understood this disclaimer and you agree to be bound by its terms.
The information contained in this e-mail and any files transmitted with it is confidential and intended for the addressee only. If you have received this e-mail in error please notify the originator or telephone 0191 2102000. This e-mail and any attachments have been scanned for certain viruses prior to sending, but neither Northern Electric plc nor any of the companies in the Northern Electric group of companies from whom this e-mail originates shall be liable for any losses as a result of any viruses being passed on.
Whilst all reasonable care has been taken to ensure that the information contained in this e-mail is correct, no warranty is given and you should be aware it may be incomplete, out of date or incorrect. It is therefore essential that you verify all such information with us before taking any action in reliance upon it.
Northern Electric plc,
Market Street,
Newcastle Upon Tyne,
NE1 6NE.
Registered in England and Wales: Number 2772271.
********************************************************************************************
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html