Login  •  Register


The time is now: Wed Dec 11, 2019 7:34 pm

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 3 of 4 [ 99 posts ]    Go to page Previous  1, 2, 3, 4  Next
Print view Previous topic  |  Next topic
Author Message
 Post subject:
PostPosted: Tue Jul 14, 2009 7:21 pm 
Online
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 5669
Location: Amsterdam, Netherlands
I got the latest changes from mschmitt and I built a new UB from it:
http://www.xs4all.nl/~ronaldpr/sheepsha ... 090714.zip

I built both Intel and PPC versions in Leopard 10.5.7, XCode 3.1.3, against MacOSX 10.4 SDK, with SDL 1.2.10, and both with:

Code:
./autogen.sh --disable-vosf --enable-sdl-static --enable-sdl-audio --enable-sdl-video


I tested this version on both Intel and PPC in Leopard. I did not test in Tiger.

On Intel it worked as expected, just like the previous recent builds, and with CPU usage well below 20%.

On PPC, overall performance was, as with previous builds, OK but not more than that. It used all available CPU, sometimes up to 95%. Sound was better than with the builds that were built without --enable-sdl-audio (--disable-sdl-audio is the default).


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Wed Jul 15, 2009 11:50 am 
Offline
Tinkerer

Joined: Sat Apr 12, 2008 8:22 pm
Posts: 82
I tried my own experiment, building from unaltered CVS source code, with sdl 1.2.10 and configuration --enable-sdl-static --enable-sdl-video --enable-sdl-audio --disable-vosf.

Two Intel-only builds were performed, one on Tiger and one on Leopard, both on the same Intel MacBook Pro. Each build used an identical, pristine copy of the full source tree, to exclude any possibility of leftover build products hanging around from an earlier build. The exact same build steps were performed in each case, apart from the magic incantation on Leopard to build against the 10.4 SDK.

Each of the two builds was run on Tiger and then on Leopard, on the same machine, using an identical copy of my Mac OS 8.6 disk image, with identical .sheepshaver_nvram and .sheepshaver_prefs files.

Subjective performance was about the same regardless of which build and which OS it was running on. Perhaps the Tiger build was more prone to video "tearing" than the Leopard build, regardless of where running; but the difference was not dramatic and could even be my imagination.

When idle, the Tiger build was consuming 50-60% of a CPU whether running on Tiger or on Leopard.

When idle, the Leopard build was consuming about 16% of a CPU whether running on Tiger or on Leopard.

I profiled each build running on each system, and there was a dramatic difference between the Tiger and Leopard builds, in a certain area that appears related to SDL video. This requires further examination, because artifacts of the profiling technique could be misleading.

If time permits, I'll be looking for differences in compiler optimization of some critical code path, probably video related. No doubt the Leopard compiler is doing a better job, and it may have a different set of optimization defaults as well.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Wed Jul 15, 2009 1:51 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 79
kelvin31415 wrote:
I profiled each build running on each system, and there was a dramatic difference between the Tiger and Leopard builds, in a certain area that appears related to SDL video. This requires further examination, because artifacts of the profiling technique could be misleading.

You could try to isolate it to the SDL programs vs. SheepShaver, by building SS Leopard from SDL Tiger, or vice versa.

I'm leaning against optimizations performed by the compiler itself, as we've discovered that Xcode 2.x and 3.x is installing the same GCC toolchain (GCC version 4.0.1)

I'm wondering if SDL's build process is doing something different, either in the config or in compiler directives in the SDL code.

One thing to check is to compare the Tiger and Leopard SDL_config.h files.

By the way, while hunting around in the SDL config files, I discovered it has specific support for building cross-architecture (and building Universal Binary).


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Wed Jul 15, 2009 2:55 pm 
Online
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 5669
Location: Amsterdam, Netherlands
The PPC versions of SheepShaver consume even more CPU time (up to 95% on my PowerBook G4). This is also true for my latest build which was build in Leopard. Can there be any relation between this extremely high CPU usage and the high CPU usage by the Intel Tiger builds?


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Wed Jul 15, 2009 4:58 pm 
Offline
Tinkerer

Joined: Sat Apr 12, 2008 8:22 pm
Posts: 82
mschmitt wrote:
You could try to isolate it to the SDL programs vs. SheepShaver, by building SS Leopard from SDL Tiger, or vice versa.
I had been planning to try swapping a particular .o that caught my attention in the profiling output. Finding time to play with this stuff is going to be the hard part.

mschmitt wrote:
I'm leaning against optimizations performed by the compiler itself, as we've discovered that Xcode 2.x and 3.x is installing the same GCC toolchain (GCC version 4.0.1)
I did notice that I had 4.0.1 on both systems, but they are different builds (5370 on Tiger and 5484 on Leopard). Might not be significant. However, I seem to vaguely recall reading somewhere that some optimizer bug(s) had been fixed, allowing different default optimizations to be enabled. Possibly that's just an old or spurious memory.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Sun Jul 19, 2009 11:49 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 79
I fixed the PPC code so the RAM/ROM shifting works, which means that PPC now supports 1 GB of RAM. And it should fix the "Cannot map RAM: File already exists" error on PPC Leopard.

I uploaded a new Universal Binary version, dated 2009-07-19. (The date is in ISO format to avoid confusion.)

http://files.getdropbox.com/u/879516/Sh ... -07-19.zip

This version is compiled with sdl-audio.

I updated the link in this thread's top post.


PowerPC assembly language is sure a lot different than z/OS, that's all I can say. :-)


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 20, 2009 9:08 am 
Offline
Site Admin
User avatar

Joined: Mon May 20, 2002 4:37 am
Posts: 3742
Location: Uiwang
Does this build have the full screen fixes from the other stickied build?


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 20, 2009 9:26 am 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 4716
Location: Sittard, The Netherlands
Apparently yes!

Cat_7


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 20, 2009 11:35 am 
Online
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 5669
Location: Amsterdam, Netherlands
All previous fixes since 2006 are in this build and in CVS. These latest "Cannot map RAM" fixes are not (yet) in CVS. I wonder if and how they would affect compiling for Windows and Linux.

On PPC this build still has the the enormous CPU consumption. Any thoughts on that? The CPU consumption on PPC is related to the Refresh Rate settings. Maybe PPC users should be advised to set Refresh Rate to 15. With a refresh rate of 15 (frameskip 4) CPU consumption is considerably less and it is still workable for most applications, also because the hardware cursor is not affected by the low refresh rate.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 20, 2009 3:35 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 4716
Location: Sittard, The Netherlands
I already reported on building for Windows: that still works.

I'll also install some linux distro to check.

Cat_7


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 20, 2009 3:47 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 79
Ronald P. Regensburg wrote:
I wonder if and how they would affect compiling for Windows and Linux.

I tried it in Ubuntu Linux (Intel) last night. I think it worked, but it did reveal that I need to change how I fixed the error messages. Fix forthcoming.

One thing to test is Linux on PPC -- especially because Apple uses a custom assembler, which uses different syntax than the GNU Assembler. That affects the assembly code I changed.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 20, 2009 4:15 pm 
Online
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 5669
Location: Amsterdam, Netherlands
The changes are still made only to the SheepShaver source? So we do not need to worry about effects for BasiliskII?

Is this page on Gwenole's site known?
http://gwenole.beauchesne.info/en/proje ... /compiling
(For MacOSX, the essential difference with these older instructions is that now we do not install Fink and do not use Fink to install SDL.)

I have ubuntu 9.04 on my netbook. Maybe I can try and see what happens if I compile SheepShaver there when I get the latest changes.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 20, 2009 4:28 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 79
Ronald P. Regensburg wrote:
The changes are still made only to the SheepShaver source? So we do not need to worry about effects for BasiliskII?

As of today, all my changes are within SheepShaver source.

But, I think I'm going to need to change the VM allocation routine in the Basilisk II source.

Remember the "File already exists" bogus message? That was because the Mach memory allocation function used by Basilisk II on OS X doesn't set the C errno variable, which the program was using to get the error code.

I fixed it by changing the higher level code to ignore the errno value, and instead use a constant that indicates it couldn't allocate memory.

However, the memory allocation function it uses on Linux does set errno, which means that my code is losing valuable information, expecially when it can't set the low memory area due to permissions issues.

I'm thinking that a better fix would be to change the Basilisk II code so that when it gets a bad result from the Mach memory allocation, it sets errno. Then the higher level code can go back to the way it was before, and it will work for both OS X and Linux.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 20, 2009 8:54 pm 
Online
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 5669
Location: Amsterdam, Netherlands
I wonder...
There is a sourceforge basilisk-devel mailing list. Shouldn't this discussion (also) take place there?


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Thu Jul 23, 2009 9:57 pm 
Offline
Granny Smith

Joined: Mon Dec 25, 2006 4:09 am
Posts: 109
mschmitt wrote:
I'm thinking that a better fix would be to change the Basilisk II code so that when it gets a bad result from the Mach memory allocation, it sets errno. Then the higher level code can go back to the way it was before, and it will work for both OS X and Linux.


I think that's an acceptable solution. When you have a patch ready, please send it to the basilisk dev list, and I can commit it to CVS. Thanks.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 27, 2009 12:26 am 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 79
I fixed the problem with the error logic and rebuilt. This version incorporates the latest changes committed by Myrd to CVS.

http://files.getdropbox.com/u/879516/Sh ... -07-26.zip


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 27, 2009 12:44 am 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 79
Ronald P. Regensburg wrote:
On PPC this build still has the the enormous CPU consumption. Any thoughts on that? The CPU consumption on PPC is related to the Refresh Rate settings. Maybe PPC users should be advised to set Refresh Rate to 15. With a refresh rate of 15 (frameskip 4) CPU consumption is considerably less and it is still workable for most applications, also because the hardware cursor is not affected by the low refresh rate.

I tried profiling with Shark. It says that the cpu time on PowerPC is spent in the BasiliskII program video_sdl.cpp, function update_display_static_bbox, in a call to memcmp.

One possibility is that the memcmp function is much less efficient when compiled for PPC. I'm wondering if glibc has an optimized memcmp for PowerPC with Altivec, and if we are using the right compile parameters to enable it.

Another is that the code path for Intel is taking a different route through this program. I looked into that but got lost.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 27, 2009 6:59 am 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 4716
Location: Sittard, The Netherlands
I,

I get an "not enough memory is available when using sound manager error" when using this build on Intel mac, with memory set to 512 Mb.

And after updating a disk to 9.04, it wouldn't start anymore with your current build. Only if I set memory to 256Mb or lower, it will start. This is on a 1Gb memory machine.

Best,
Cat_7


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 27, 2009 11:42 am 
Online
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 5669
Location: Amsterdam, Netherlands
Runs fine both 9.0.4 (with newworld rom) and 7.5.5 (with oldworld rom) on my Intel Core 2 Duo iMac (4GB) with RAM set to 512. Have not tried on PPC yet.

I would like to try the new "self-contained .sheepvm bundle", but how do I turn a xxxx.sheepvm folder into a bundle?


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 27, 2009 12:14 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 79
Cat_7 wrote:
I,

I get an "not enough memory is available when using sound manager error" when using this build on Intel mac, with memory set to 512 Mb.

And after updating a disk to 9.04, it wouldn't start anymore with your current build. Only if I set memory to 256Mb or lower, it will start. This is on a 1Gb memory machine.

Best,
Cat_7

That is weird. The only changes are:
  1. Fix to the memory error code
  2. Built with SDL Audio on
  3. Incorporates Myrd's code.
I can try backing out Myrd's changes and see if it makes any difference.

The "not enough memory is available when using sound manager error" is within the guest Mac OS?

When you say a 9.0.4 disk won't start, does it throw an error?

I assume you're testing the pre-built version, not building from source.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 27, 2009 12:24 pm 
Online
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 5669
Location: Amsterdam, Netherlands
Cat_7 wrote:
And after updating a disk to 9.04, it wouldn't start anymore with your current build. Only if I set memory to 256Mb or lower, it will start. This is on a 1Gb memory machine.

Runs fine on my (4GB) machine with both RAM set to 512 and RAM set to 1024.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 27, 2009 1:42 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 79
Another change I picked up from CVS appears to be for handling illegal memory access in the PowerPC emulator.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 27, 2009 8:49 pm 
Online
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 5669
Location: Amsterdam, Netherlands
Your 2009-07-26 build runs OK on my PowerBook G4 Leopard, still with the huge CPU consumption.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 27, 2009 9:08 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 79
Ronald P. Regensburg wrote:
I would like to try the new "self-contained .sheepvm bundle", but how do I turn a xxxx.sheepvm folder into a bundle?

I haven't tried this yet, but I'm guessing it works like this:
  1. You need OS X to recognize the new Info.plist.

    OS X Launch Services automatically registers applications in the Applications folder, any subfolder of Applications, or when the Finder becomes aware of the application (such as when you open the folder containing the application).

    Sometimes you have to force it to refresh and pick up new information for an .app. I use the Nudge contextual menu for this purpose, it is easier than logging out and back in.
  2. Once Launch Services has recognized the new Info.plist, xxx.sheepvm folders should automatically turn into packages. However, sometimes the Finder needs to be kicked into refreshing; again, I give the folder a Nudge when this happens.
I see a problem in the future: us testers may have multiple copies of SheepShaver on our hard drives. Once we get two versions that both have Myrd's code change, how will Launch Services decide which one to launch (when you double-click a .sheepvm bundle)?

The rule is that in the case of a tie, the app with the highest version number wins. Does this include the date we are appending to the version string? If so, then we'll have to standardize on ISO dates; otherwise we're going to get very strange results.


Top
 Profile  
Reply with quote Post a reply  
 Post subject:
PostPosted: Mon Jul 27, 2009 9:58 pm 
Online
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 5669
Location: Amsterdam, Netherlands
Well, I have a folder "sheepshaver.sheepvm" but whatever I do, it remains an ordinary folder.

Also, the Info.plist file does not look any different from the one in previous builds.


Top
 Profile  
Reply with quote Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 3 of 4 [ 99 posts ]    Go to page Previous  1, 2, 3, 4  Next


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
 

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group