Re: [hatari-devel] OSX performance (was: Things still remaining before v1.8 release?)

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On keskiviikko 30 heinäkuu 2014, Troed Sångberg wrote:
> On Wed, Jul 30, 2014 at 1:46 PM, Anders Eriksson <ae@xxxxxx> wrote:
> > Regarding speed on retina display. My friend have such and had to
> > switch off the pixel doubling in Hatari to get it working without
> > slowdowns. Instead using OS X zoom (control+mousehweel) to enlarge
> > works. Not optimal, but better than nothing. That was with 1.7.0
> > though.

1.8 is faster with statusbar/led on OSX due to SDL doing Vsyncs for
every separate update.


> Yeah removing Hatari built in zoom indeed got the windowed performance up
> to where it should be. Maybe this points to an SDL issue with retina
> Macs?

Was this with ST screen mode, that just does doubling, or
with Falcon Videl emulation which can do arbitrate (integer)
scale zooming?  I could somehow understand it for latter [1]
if your display resolution is really high compared to your
memory bandwidth.


> I see some discussion in other forums that could be related. (And
> I just got my retina MBP which would explain why I haven't seen it
> before).

What exact CPU and GPU model you have?

With integrated GPU there shouldn't be a difference in speed
as both CPU & GPU use same memory bandwidth.

With separate GPU, doing the scaling read/write/screen refresh
from within faster GPU memory, can be clearly faster than doing
the scaling on CPU side.


[1] If your retina display is 2880×1800, that's 2880*1800*4 ~= 20MB
per frame.  Doing such screen updates at 60 FPS = 1.2GB/s.

Doing it on CPU side means:
- Hatari/SDL:
  - reading small Atari resolution image (insignificant)
  - writing fullscreen scaled result (1x)
- OSX compositor:
  - reading window (1x)
  - reading background (1x)
  - writing blend result (1x)
- display:
  - reading the data (1x)

I.e. ~5x = 6 GB/s memory bandwidth used.

I think MacBooks should have at least 20GB/s of memory
bandwidth, so those display updates being a problem sounds
fishy.


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/