Re: [hatari-devel] OS X performance problem

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 29 toukokuu 2014, Anders Eriksson wrote:
> On Thu, 29 May 2014, Eero Tamminen wrote:
> > Ok, this is Sandy Bridge.  Do you have 1600Mhz DDR3 memories
> > or something slower?
> 
> It is 1333 MHz DDR3.

OK, then your real, max system memory throughput is something like:
	25.6 * 1333/1600 * 0.6 = 12-13 GB/s

....
> > What you calculated, is Hatari part of the operations.  Then there
> > are operations that SDL OSX backend does, and the OSX desktop
> > compositor.
> 
> Yes, although everything else is smooth as butt so I imagine things are
> normally using OpenGL for all that. For example, throwing up 1080p or
> even 1440p movies with VLC in a window is no issue, not a frame drop and
> the datarate from that wastly overshadows Hatari. But again, that's
> not SDL.

Videos normally use FPS that's half of Atari's screen update frequency.


> > [1] If you aren't running other applications besides Hatari,
> > I think we can be pretty sure that rest of the system hasn't
> > caused graphics card to run out of memory. :-)
> 
> Well the entire UI is OpenGL so it's using a lot of memory, and the
> screen is 2536x1440 that eats up some bandwidth by the displayport as
> well.

Hm.  Just refreshing that screen @ 60 FPS takes 836 MB/s on that
screen.


> I dug up an old message from the Hatari mail list (from 2008) when this
> topic was discussed, the painting program Grafx2 had some serious
> perfomance issues, SDL based just like Hatari, this is what they found
> out:
> 
> "Ok, here's the deal: under macosx SDL_UpdateRect() automatically waits
> for vblank so calling it for each pixels drawn isn't a good idea at all.
> What i did is to remove all those updates calls for macosx and just use
> one in Get_Input()."
> 
> So if there are two calls to UpdateRect, it would use 2 vbl. If the
> status bar indeed does that, then it's pretty clear that there will be
> slowdown.

Ouch.  So OSX SDL backend doesn't saturate the HW, it just does
redundant waiting.

Working around that wouldn't be nice as there are two completely different
screen handling code bases in Hatari, one for ST/e and another for Videl
+ a few other places from where Statusbar_Update() is called.


....
> :) It's a bit funny, because if you run Hatari in a Linux-VM it won't
> suffer from these problems.

Because Linux has saner SDL backend... :-)


	- Eero