[hatari-devel] Hatari patches for bitplane conversion

[Thomas Huth]

On Tue, 21 Jul 2009 16:22:27 +0200
Kåre Andersen <kareandersen at gmail.com> wrote:

> Ok, I am no expert on Intel architecture, but I can tell you this
> much: 2MB cache does not mean 2MB that you can freely fill up with
> whatever code and data you wish.

Sure, but since these screen buffers are linear in memory, they should
be copied also quite fast with RAM burst mode.

> > I also don't think that this problem is related to CPU caches -
> > since it does not occur on Linux or Windows with modern CPUs! The
> > problem must have something to do with Mac OS X exclusively.
> 
> That is not what I have been saying at all. What I am saying is, this
> new code fits better - that is all.

And all I am trying to do is to squash false rumors like "Hatari does
not work right on modern CPUs", which might quickly rise when some
people read this thread. Believe me, it's often quite hard to get rid
of such reputations, there were similar things in the past...

Ok, so we agree that the performance problems on Mac OS X are likely
not caused by modern CPU caches, so let's stop this topic and focus on
the real culprit (maybe Eero's LED fix already helps?).

> Again, this is the case, like I have tried to explain before: SDL on
> OS X is crap due to compositing. But helping it suck a bit less when
> it does not hurt the other platforms cant be a bad thing, can it?

Ok, but how do you help the SDL with your new code? Yes, I know, it
fits better in your cache, but that does not affect the SDL, does it?
I mean, if the bottleneck is the SDL screen update, why do you affect
it with your code that does not call any SDL function at all? That's
why I asked you to do some additional tests recently...

By the way, do you also have these performance problems in fullscreen
mode?

> >> > > * On platforms where SDL updates don't incur Vsync, the screen
> >> > > updates could be done so that screen-blitting is skipped for
> >> > > lines that haven't changed.
> >
> > How do you want to detect that SDL feature? Hard-coding it with
> > #ifdefs is a bad idea, IMHO.
> 
> I guess there are several ways to do this, including the check for
> hardware surfaces. The safest way should nevertheless be to do a bit
> of profiling on buffer creation (that is, program start _and_ screen
> mode changes). You can do a wait for vsync, and see how much time will
> pass in between. If its shorter than a given threshold, say 50Hz, then
> you dont have any vsync...

Ok, but that might render the code more complex again, not sure if this
fits your goal to make it easier... ;-)

> A similar test is already done to get fine
> granularity cycle timing (and the comments about OS X in that part of
> the code are wrong mind you - we have HPET just as much as linux do).

I don't know about HPET in general, but SDL_Delay at least has a
granularity of 10 ms on Mac OS X. (Though it might have changed with
recent versions of Mac OS X and the SDL... when I wrote that code, this
was still Mac OS X 10.2 or 10.3).

 Thomas