Re: [hatari-devel] OS X performance problem

[Thomas Huth <th.huth@xxxxxx>]

Am Fri, 30 May 2014 00:37:32 +0300
schrieb 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.

Hmmm, ... and according to the man-page of SDL_UpdateRects:

 It  is  adviced to call this function only once per frame, since
 each call has some processing overhead. This is  no  restriction
 since you can pass any number of rectangles each time.

So this is likely not only a problem on Mac OS X. I think we should
somehow rework the code so that SDL_UpdateRects is only called once per
frame. I see two possibilities:

1) Statusbar_Update does not do the update on its own but passes a
rectangle list to the caller so the caller can do an SDL_UpdateRects
with all areas.

2) Statusbar_Update does not do the update on its own but passes a flag
to the caller whether the statusbar has been changed. If it has been
changed, the caller simply updates the whole window instead of only
updating the ST screen area.

Eero, what do you think? Could you maybe implement such a solution? (or
shall I have a try?)

 Thomas