[hatari-devel] Hatari patches for bitplane conversion

[Kåre Andersen]

On Wed, Jul 22, 2009 at 9:34 AM, Thomas Huth<huth at users.berlios.de> wrote:
> 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.

Yes sure, but still.... It can be done better. So why not do that then? :)

>> > 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...

Hatari works quite right on modern CPUs. Because they are hellishly
fast anyway :) And still, we can make it even better...

> 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?).


Indeed! Things are already looking up, I just compiled a new version
from Hg that seems to fly here! Mono troubles are still there tho, but
I am confident we can weed that out fairly quick now... This is pri 1
for me at the moment.

>> 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...

Well, not doing the conversion back and forth to 8-bit certainly helps
:) The rest (vsync, memcmp() etc) is still to come...

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

Nope. Except for the new Monochrome problem, which is still there.
Like said, fullscreen SDL bypasses compositing. Or so i read
somewhere...

>> >> > > * 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... ;-)

There are always tradeoffs...

>> 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).

I think HPET arrived in 10.3, but that does not really matter - its there now :)

/Kåre - running a much faster Hatari this time around - On OS X - On
Modern Hardware(tm) :D