Re: First question: Eclipse

From: Johan Klockars <rand_at_cd.chalmers.se>
Date: Wed, 7 Jul 1999 23:56:34 +0200 (MET DST)

> > > If the Eclipse will easily allow me a 1024x768x16bit desktop with
> > > suffering much of a performance hit then I want one. As a matter of

I'll post a few other benchmarks here later, but the text tests in GEMBench
are about 45-50 times faster than a Falcon in 640x480x8bit, the window open
about nine times and the scrolling test 25 times faster.
I think the dialog test is at six times speedup or so.
(This is all on my Falcon+AB040/32MHz, without NVDI.)

Unfortunately, blitting to and (especially) from the card is rather slow.
This is after all a 16 bit mode we're talking about and for some reason
the ATI card isn't very keen on returning data quickly.

Fortunately, fVDI can get around actually doing most of those blits. :-)

Whenever the AES tries to save screen background data in a buffer, fVDI
notices this and uses a local buffer on the card instead (memory permitting).
This is a _lot_ faster and causes menus and such to display 'instantly'.

Icon data (colour images of 32x32 pixels) is also cached on the card, to
speed up normal desktop usage.

Finally, the very latest version of the mach64 driver can also cache
screen->RAM blits done by normal applications. Since there are very few
reasons (and none that I can think of are a good) to ever do such blits
other than to temporarily save the background of something, this will work
well with most programs (for the moment only one such area can be cached
at any one time, so there are some extra problems).

This means that blits from the screen should never need to happen for
most programs and only new data (and then not cached icons (this will
probably also be extended later on)) need to be blitted to the screen.

Naturally, all this caching can be turned off.

> > > interest I presume the normal Falcon video still operates so I suppose it
> > > would be best to drop it to something really small, say 640x400x1bit, to
> > > get the maximum performance out of the whole machine. Is that right?
>
> The best idea would to shut off the Videl all together. You can do this with

Well, I don't think there should be much noticeable performance difference
between a VIDEL set for 640x400x1bit and one that's turned off.
I always keep my SM124 connected to help with debugging. ;-)

> You can easily run in 1024x768x16 bit or even higher. The resolution doesn't
> realy matter. 640x480 would theoreticly be as fast as 1600x1200 on a GFX card,

The available bandwidth on the card will go down with larger resolutions,
but there's a lot to take from and besides large blits/fills the processor
is mostly the bottleneck, anyway.
In really high resolutions the caching won't be very effective (when
there's not much free memory on the card), but on the other hand fVDI is
the first VDI to do any of that, AFAIK. ;-)

> > > My Falcon is an AB040, FreeMiNT, N.AES, Thing, NVDI4.11 powered
> > > machine. My most used apps are aMail (for email) and Oasis2 (for
> > > news), and CAB2 for browsing. For the internet link I use Sting. Other
> > > apps include GEMView and ApexMedia.
>
> All those should work without problems except ApexMedia. :-\ But you can

I've tried Thing and a demo version of CAB and they've worked fine (except
for some version of Thing using the wrong icons, but that must have
something to do with my setup).
Anything that uses the VDI (and doesn't run into something that's
unimplemented (not much and the list is shrinking) or a bug) should work.
Programs that access the screen directly (and there are some that you
wouldn't expect) can potentially have problems (especially now, since fVDI
doesn't yet make the XBIOS return a usable screen address).
The 16 bit mode we use on the RageII is 565 like FalconTC so, theoretically,
it should be possible to get even things like ApexMedia to work. Byte
ordering (x86's put the two bytes in a word the other way around and the
RageII is mainly intended for that market) and such things can be problem,
though.

-- 
  Chalmers University   | Why are these |  e-mail:   rand_at_cd.chalmers.se
     of Technology      |  .signatures  |            johan_at_rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)
Received on fr. juli 16 1999 - 01:05:53 CEST

This archive was generated by hypermail 2.3.0 : ti. nov. 03 2015 - 20:07:54 CET