Menu
▾
▴
basilisk-devel
|
From: Tomasz J. <to...@je...> - 2004-05-15 19:55:08
|
I've finally managed to run the newest snapshot of SheepShaver on
another PC (will probably also work on the previous one). I had to
modify the generated Makefile and replace -O2 with -O1 everywhere. Not
it works fine with JIT. It seems that there is a bug in GCC (3.3.2) or
your code is too hackish. However when I removed -O2 altogether,
SheepShaver did not compile at all.
This is a result of 'make' (last lines):
=========
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\"
-g -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include -c
../kpx_cpu/src/cpu/jit/cxxdemangle.cpp -o obj/cxxdemangle.o
c++ -o dyngen obj/dyngen.o obj/cxxdemangle.o
./dyngen -o basic-dyngen-ops.hpp obj/basic-dyngen-ops.o
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\"
-g -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include -c
../kpx_cpu/src/cpu/jit/basic-dyngen.cpp -o obj/basic-dyngen.o
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\"
-g -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include -fomit-frame-pointer
-mpreferred-stack-boundary=2 -falign-functions=0 -mmmx -msse -msse2
-finline-limit=10000 -fno-reorder-blocks -fno-optimize-sibling-calls -c
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In static member function
`static
void op_V2DI::set(powerpc_vr&, int, long long unsigned int)':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: error: unable to find a
register to spill in class `GENERAL_REGS'
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: error: this is the insn:
(insn 15 14 17 0 0xbd201898 (set (mem/s/j:DI (plus:SI (mult:SI (reg:SI
60)
(const_int 8 [0x8]))
(reg/f:SI 59)) [0 <variable>.j S8 A64])
(reg:DI 61)) 59 {*movdi_2} (nil)
(expr_list:REG_DEAD (reg:DI 61)
(expr_list:REG_DEAD (reg:SI 60)
(expr_list:REG_DEAD (reg/f:SI 59)
(nil)))))
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: confused by earlier
errors, bailing out
make: *** [obj/ppc-dyngen-ops.o] Error 1
==========
I haven't measured how much faster is the newest version, but it still
suffers from some strange 'stops'. Sometimes you need to wait several
seconds until you can regain control of the emulated system (no response
from mouse or keyboard). Beside this, it is reasonably fast.
There is also problem with configuration interface. In video modes tab
there is one checkbox that is not described (the 6th one). Selecting
only 'Windowed 800x600' result in termination of application and
message:
SheepShaver.ok: video_x.cpp:1166: bool VideoInit(): Assertion `cur_mode
!= -1' failed.
Jerzu
|
|
From: Gwenole B. <gb...@di...> - 2004-05-15 20:51:59
|
Hi, > I had to modify the generated Makefile and replace -O2 with -O1 > everywhere. I am only aware of two types of miscompilation with gcc on x86: 1) Don't use -mcpu=pentiumpro, at least with -march=i586 with gcc 3.3.2. You would get a hang during boot 2) gcc 3.2.2 miscompiles some SSE code, but I workarounded that in the sources. > However when I removed -O2 altogether, SheepShaver did not compile at > all. Have you tried to only lower -O2 to -O1 in DYNGEN_OP_FLAGS? What about adding -fno-strict-aliasing and keeping -O2? In the latter case, there could indeed be a bug in the code. > ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o *-ops.cpp files have to be compiled with optimizations. Otherwise you will end up with poorer performance. Do you really have a stock FSF gcc 3.3.2? Have you tried to upgrade to 3.3.3? At some point, I wanted to exercise a testcase for my hang problem with gcc 3.3.2, but getting a crash would be better. ;-) > I haven't measured how much faster is the newest version, but it still > suffers from some strange 'stops'. I have noticed that on AMD64 with gcc 3.3.2 too when experimenting with the asm based locking code. I will probably try other alternatives. In Unix/sysdeps.h, could you try to disable HAVE_TEST_AND_SET for i386 and rebuild at least main_unix.cpp and video_x.cpp? > There is also problem with configuration interface. In video modes tab > there is one checkbox that is not described (the 6th one). Selecting > only 'Windowed 800x600' result in termination of application and > message: > SheepShaver.ok: video_x.cpp:1166: bool VideoInit(): Assertion `cur_mode > != -1' failed. OK, I will have a look. Thanks, Gwenole. |
|
From: Tomasz J. <to...@je...> - 2004-05-15 21:46:45
|
On Saturday 15 May 2004 22:52, Gwenole Beauchesne wrote:
> Hi,
>
> > I had to modify the generated Makefile and replace -O2 with -O1
> > everywhere.
>
> I am only aware of two types of miscompilation with gcc on x86:
> 1) Don't use -mcpu=pentiumpro, at least with -march=i586 with gcc
> 3.3.2. You would get a hang during boot
Hang of Linux or hang of the application? I must say that on Fedora 2
SheepShaver sometimes hangs the OS (the newest one - the February version
didn't). It does not happen on the other PC with Fedora 1 (this is where I
managed to run it with -O1).
> 2) gcc 3.2.2 miscompiles some SSE code, but I workarounded that in the
> sources.
>
> > However when I removed -O2 altogether, SheepShaver did not compile at
> > all.
>
> Have you tried to only lower -O2 to -O1 in DYNGEN_OP_FLAGS?
I can't. DYNGEN_OP_FLAGS does not contain any O's in my Makefile. See below.
========
DYNGEN_OP_FLAGS = -fomit-frame-pointer -mpreferred-stack-boundary=2
-falign-functions=0 -mmmx -msse -mss
e2 -finline-limit=10000 -fno-reorder-blocks -fno-optimize-sibling-calls
========
> What about
> adding -fno-strict-aliasing and keeping -O2? In the latter case, there
> could indeed be a bug in the code.
>
Didn't help.
> > ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o
>
> *-ops.cpp files have to be compiled with optimizations. Otherwise you
> will end up with poorer performance.
>
> Do you really have a stock FSF gcc 3.3.2?
No. This is Fedora 1 GCC.
> Have you tried to upgrade to
> 3.3.3?
In Fedora 2 test 3 there is GCC 3.3.3 and it exhibits the same behaviour.
FC2 contains also GCC 3.4.0. The error is almost the same:
==============
g++34 -o dyngen obj/dyngen.o obj/cxxdemangle.o
./dyngen -o basic-dyngen-ops.hpp obj/basic-dyngen-ops.o
g++34 -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g
-I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include
-c ../kpx_cpu/src/cpu/jit/basic-dyngen.cpp -o obj/basic-dyngen.o
g++34 -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g
-I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include -fomit-frame-pointer
-mpreferred-stack-boundary=2 -falign-functions=0 -mmmx -msse -msse2
-finline-limit=10000 -fno-reorder-blocks -fno-optimize-sibling-calls
-c ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In static member function `static
void op_V2DI::set(powerpc_vr&, int, uint64)':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: instantiated from `static
void do_vector_execute<OP, VX, VA, VB, VC, N>::apply() [with OP = op_and_64,
VX = op_V2DI, VA = op_V2DI, VB = op_V2DI, VC = op_VNONE, int N = 1]'
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1437: instantiated from `static
void vector_execute<OP, VX, VA, VB, VC>::apply() [with OP = op_and_64, VX =
op_V2DI, VA = op_V2DI, VB = op_V2DI, VC = op_VNONE]'
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1490: instantiated from here
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: error: unable to find a
register to spill in class `GENERAL_REGS'
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: error: this is the insn:
(insn 17 16 19 0 ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400 (set
(mem/s/j:DI (plus:SI (mult:SI (reg:SI 60 [ i ])
(const_int 8 [0x8]))
(reg/f:SI 59 [ v ])) [0 <variable>.j S8 A64])
(reg:DI 61 [ x ])) 58 {*movdi_2} (nil)
(expr_list:REG_DEAD (reg:DI 61 [ x ])
(expr_list:REG_DEAD (reg:SI 60 [ i ])
(expr_list:REG_DEAD (reg/f:SI 59 [ v ])
(nil)))))
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: confused by earlier errors,
bailing out
make: *** [obj/ppc-dyngen-ops.o] Error 1
============
> At some point, I wanted to exercise a testcase for my hang
> problem with gcc 3.3.2, but getting a crash would be better. ;-)
>
> > I haven't measured how much faster is the newest version, but it still
> > suffers from some strange 'stops'.
>
> I have noticed that on AMD64 with gcc 3.3.2 too when experimenting with
> the asm based locking code. I will probably try other alternatives. In
> Unix/sysdeps.h, could you try to disable HAVE_TEST_AND_SET for i386 and
> rebuild at least main_unix.cpp and video_x.cpp?
>
I've noticed something noteworthy in KDE System Monitor. During such a stop
CPU is 100% 'User' time, but during normal operation CPU is 100% 'Nice' time.
I don't get it, but this information might be helpful. As of other hints, I
will try them later.
> > There is also problem with configuration interface. In video modes tab
> > there is one checkbox that is not described (the 6th one). Selecting
> > only 'Windowed 800x600' result in termination of application and
> > message:
> > SheepShaver.ok: video_x.cpp:1166: bool VideoInit(): Assertion `cur_mode
> > != -1' failed.
>
> OK, I will have a look.
>
> Thanks,
> Gwenole.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
|
|
From: Gwenole B. <gb...@di...> - 2004-05-16 06:42:05
|
Hi, >> I am only aware of two types of miscompilation with gcc on x86: >> 1) Don't use -mcpu=3Dpentiumpro, at least with -march=3Di586 with gcc >> 3.3.2. You would get a hang during boot > > Hang of Linux or hang of the application? Hang of the application after the happyface appeared. > I must say that on Fedora 2 > SheepShaver sometimes hangs the OS (the newest one - the February=20 > version > didn't). It does not happen on the other PC with Fedora 1 (this is=20 > where I > managed to run it with -O1). In that case please really tell me if you are running as root or not.=20 If so, this can change things wrt. threads behavior. >>> However when I removed -O2 altogether, SheepShaver did not compile = at >>> all. >> >> Have you tried to only lower -O2 to -O1 in DYNGEN_OP_FLAGS? > > I can't. DYNGEN_OP_FLAGS does not contain any O's in my Makefile. See=20= > below. You can because DYNGEN_OP_FLAGS is used after CXXFLAGS. So, you can=20 leave -O2 in CXXFLAGS and simply add -O1 or -fno-strict-aliasing in=20 DYNGEN_OP_FLAGS so that only basic-dyngen-ops.cpp and=20 ppc-dyngen-ops.cpp are built with those. Then, with the default flags (aka -O2 everywhere and in that case it=20 should crash again for you), please try the patch attached. And try, in=20= order, to disable some code generation for VMX, FPU, and ALU units. But=20= first try to set DISABLE_DBC to 1 so that you don't do block chaining. If that still doesn't help, edit Unix/sysdeps.h to disable=20 DYNGEN_ASM_OPTS and rebuilt ppc-dyngen-ops.cpp. Ideally, if you are patient enough to have all DISABLE_* set to 0 and=20 manually comment out case PPC_I(XXX) things, so that you can identify=20 the faulty synthetic opcode generated, that would be fine. Could you=20 make ppc-dyngen-ops.o available to me along with the exact compilation=20= flags? Thanks, Gwenol=E9.= |
|
From: Gwenole B. <gb...@di...> - 2004-05-16 06:45:19
Attachments:
sheep_no_jit_insns.diff
|
dimanche 16 mai 2004, =E0 08:42 am, Gwenole Beauchesne a =E9crit : > Then, with the default flags (aka -O2 everywhere and in that case it=20= > should crash again for you), please try the patch attached. And try,=20= > in order, to disable some code generation for VMX, FPU, and ALU units.=20= > But first try to set DISABLE_DBC to 1 so that you don't do block=20 > chaining. And I forgot the patch. |
|
From: Tomasz J. <to...@je...> - 2004-05-21 22:12:10
|
Gwenole Beauchesne wrote: >> I haven't measured how much faster is the newest version, but it still >> suffers from some strange 'stops'. > > > I have noticed that on AMD64 with gcc 3.3.2 too when experimenting with > the asm based locking code. I will probably try other alternatives. In > Unix/sysdeps.h, could you try to disable HAVE_TEST_AND_SET for i386 and > rebuild at least main_unix.cpp and video_x.cpp? > It did the trick. Now SheepShaver rums smoothly and reasonably fast, especially when color depth of the host display is set to 16 bit (32 bit is somehow slower). This trick doesn't work on the latest CVS version (compilation fails after modification). Now if only did SheepShaver run OS-X... I wish it were, but I am aware that it would require adding MMU support, what is a major speed bottleneck in PearPC. Nonetheless, it's still fun to play with OS 8.6 on my PC. Speedometer indicates that on P4 1.4 SheepShaver is faster than real PowerMac 80Mhz. Impressive. I will play with the crashes with -O2 later (following your advices). Jerzu |
|
From: Gwenole B. <gb...@di...> - 2004-05-22 05:37:12
|
Hi, > It did the trick. Now SheepShaver rums smoothly and reasonably fast,=20= > especially when color depth of the host display is set to 16 bit (32=20= > bit is somehow slower). This is understandable because we could need to do color conversion as=20= well. The 16-bit version can be processed faster than the 32-bit=20 version because simply more pixels can be processed at a time. However, since you indicate a noticeable difference, it then may be=20 interesting to write MMX/SSE blitters to bring 32-bit blitting to=20 current 16-bit blitting speeds. > This trick doesn't work on the latest CVS version (compilation fails=20= > after modification). Please post the error message + date of CVS version. I have committed a=20= hopefully fixed version of testandset(), aka the one from LinuxThreads=20= so it should really work. However, please only grab the sysdeps.h (testandset) change as the rest=20= could break too. Aka, I sometimes get a crash when a *lot* of ADB=20 events are coming up (e.g. mouse). > Now if only did SheepShaver run OS-X... I wish it were, but I am aware=20= > that it would require adding MMU support, what is a major speed=20 > bottleneck in PearPC. Actually, I think we can get rid of address translation or at least=20 minimize it a lot, even on 32-bit systems. However, we will still need=20= memory protection, but this can be trivially achieved in a fast way=20 with a JIT compiler. An interpreter would require explicit recovery=20 points. > Nonetheless, it's still fun to play with OS 8.6 on my PC. Speedometer=20= > indicates that on P4 1.4 SheepShaver is faster than real PowerMac=20 > 80Mhz. Impressive. And using an Athlon 64 or Opteron at the same speed could easily bring=20= up to a 2x increase. That's because the current (portable) JIT1 engine=20= makes heavy use of load/stores. The next could speed up things by at=20 least a factor of two. Imagine that the current JIT already does less=20 than 1/8 of native speed. ;-) > I will play with the crashes with -O2 later (following your advices). Another user reported that on the forum, setting DISABLE_DBC to 1 with=20= the patch I sent you earlier fixed his problems. That's why I am=20 working on a more complete direct block chaining code that should fix=20 corner cases of the previous method. However, it currently breaks on=20 kpxrun test/test-powerpc, where test-powerpc is a statically linked ppc=20= binary with the same emulator. I'd rather say it's slow and since I am=20= an unlucky guy, it breaks after several minutes... Bye, Gwenol=E9.= |
|
From: Gwenole B. <gb...@di...> - 2004-05-23 08:39:24
|
Hi, > I will play with the crashes with -O2 later (following your advices). If you used recent CVS code, I have committed this morning two=20 important fixes. One is related to NativeOp code generation (e.g. call=20= to VideoVBL). The other is an incorrect block chaining to NULL. It does=20= not seem to crash any longer randomly. Hope this helps you too. Bye, Gwenol=E9.= |
|
From: Tomasz J. <to...@je...> - 2004-06-02 18:38:39
|
Tomasz Jerzykowski wrote:
> Gwenole Beauchesne wrote:
>
>>> I haven't measured how much faster is the newest version, but it still
>>> suffers from some strange 'stops'.
>>
>>
>>
>> I have noticed that on AMD64 with gcc 3.3.2 too when experimenting
>> with the asm based locking code. I will probably try other
>> alternatives. In Unix/sysdeps.h, could you try to disable
>> HAVE_TEST_AND_SET for i386 and rebuild at least main_unix.cpp and
>> video_x.cpp?
>>
>
> It did the trick. Now SheepShaver rums smoothly and reasonably fast,
> especially when color depth of the host display is set to 16 bit (32 bit
> is somehow slower). This trick doesn't work on the latest CVS version
> (compilation fails after modification).
>
Let me follow my old thread. This is how SheepShaver CVS doesn't compile
when HAVE_TEST_AND_SET is commented out (tested serveral days ago):
=========================
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g
-O2 -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include
-c ../kpx_cpu/src/cpu/jit/cxxdemangle.cpp -o obj/cxxdemangle.o
c++ -o dyngen obj/dyngen.o obj/cxxdemangle.o
./dyngen -o basic-dyngen-ops.hpp obj/basic-dyngen-ops.o
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g
-O2 -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include
-c ../kpx_cpu/src/cpu/jit/basic-dyngen.cpp -o obj/basic-dyngen.o
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g
-O2 -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include -fomit-frame-pointer
-mpreferred-stack-boundary=2 -falign-functions=0 -mmmx -msse -msse2
-finline-limit=10000 -fno-reorder-blocks -fno-optimize-sibling-calls
-c ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o
In file included from ../kpx_cpu/src/cpu/ppc/ppc-registers.hpp:151,
from ../kpx_cpu/src/cpu/ppc/ppc-cpu.hpp:31,
from ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:25:
../kpx_cpu/src/cpu/spcflags.hpp:39: error: 'spinlock_t' is used as a
type, but
is not defined as a type.
../kpx_cpu/src/cpu/spcflags.hpp: In constructor `
basic_spcflags::basic_spcflags()':
../kpx_cpu/src/cpu/spcflags.hpp:44: error: class `basic_spcflags' does not
have
any field named `lock'
../kpx_cpu/src/cpu/spcflags.hpp:44: error: `SPIN_LOCK_UNLOCKED' undeclared
(first use this function)
../kpx_cpu/src/cpu/spcflags.hpp:44: error: (Each undeclared identifier is
reported only once for each function it appears in.)
../kpx_cpu/src/cpu/spcflags.hpp: In member function `void
basic_spcflags::init(unsigned int)':
../kpx_cpu/src/cpu/spcflags.hpp:54: error: `lock' undeclared (first use this
function)
../kpx_cpu/src/cpu/spcflags.hpp:54: error: `spin_lock' undeclared (first use
this function)
../kpx_cpu/src/cpu/spcflags.hpp:54: error: `spin_unlock' undeclared
(first use
this function)
../kpx_cpu/src/cpu/spcflags.hpp: In member function `void
basic_spcflags::set(unsigned int)':
../kpx_cpu/src/cpu/spcflags.hpp:60: error: `spin_lock' undeclared (first use
this function)
../kpx_cpu/src/cpu/spcflags.hpp:60: error: `spin_unlock' undeclared
(first use
this function)
../kpx_cpu/src/cpu/spcflags.hpp: In member function `void
basic_spcflags::clear(unsigned int)':
../kpx_cpu/src/cpu/spcflags.hpp:63: error: `spin_lock' undeclared (first use
this function)
../kpx_cpu/src/cpu/spcflags.hpp:63: error: `spin_unlock' undeclared
(first use
this function)
make: *** [obj/ppc-dyngen-ops.o] Error 1
=========================
Jerzu
|
|
From: Gwenole B. <gb...@di...> - 2004-06-02 22:35:29
|
mercredi 2 juin 2004, =E0 08:40 pm, Tomasz Jerzykowski a =E9crit : > Let me follow my old thread. This is how SheepShaver CVS doesn't=20 > compile when HAVE_TEST_AND_SET is commented out (tested serveral days=20= > ago): Yes, I fixed that this afternoon, as the new spinlock code did not help=20= so I disabled it and now use pthreads by default on x86 and amd64.=20 Otherwise, I indeed get some occasional hangs... |
|
From: Tomasz J. <to...@je...> - 2004-06-03 08:05:39
|
Is it true tha sound n SheepShaver can be enabled only if you are using OldWorld ROM file? It doesn't work with NewWorld one on my PC, even though host OS supports sound just fine. I cannot test it on another ROM for obvious reasons - not having such a file. There are no errors concerning inability of opening of /dev/dsp or anything during startup, but still, there is no audio device in MacOS 8.6 control panel. I have also ran a game (www.spidweb.com) and it complains about lack of sound output (beside this it works fine although not very fast). Jerzu |
|
From: Gwenole B. <gb...@di...> - 2004-06-03 09:46:54
|
On Thu, 3 Jun 2004, Tomasz Jerzykowski wrote: > Is it true tha sound n SheepShaver can be enabled only if you are using > OldWorld ROM file? It doesn't work with NewWorld one on my PC, Actually, it does. I found it out by luck. In the sound control panel, can't you select the output device (even if it's already selected)? I don't know what exactly I did though. I could not revert to the old non-functioning state. > I have also ran a game (www.spidweb.com) and it complains about lack of > sound output (beside this it works fine although not very fast). which one? any free downloadable demo? |
|
From: Tomasz J. <to...@je...> - 2004-06-03 10:19:05
|
> On Thu, 3 Jun 2004, Tomasz Jerzykowski wrote: > > > Is it true tha sound n SheepShaver can be enabled only if you are > > using OldWorld ROM file? It doesn't work with NewWorld one on my PC, > > Actually, it does. I found it out by luck. In the sound > control panel, can't you select the output device (even if > it's already selected)? I don't know what exactly I did > though. I could not revert to the old non-functioning state. > I can't select any sound device in the control panel because there is no one listed - the box is empty. > > I have also ran a game (www.spidweb.com) and it complains > about lack > > of sound output (beside this it works fine although not very fast). > > which one? any free downloadable demo? > Blades of Avernum (downloadable demo). Requires installing CarbonLib from Apple site. |
|
From: Tomasz J. <to...@je...> - 2004-06-04 11:07:58
|
Hello. Just a wild thought... Wouldn't be useful if SheepShaver were using SDL as graphics subsystem? Recently PearPC guys employed that library in their project and users were pretty happy with it (performance wise). It would also make SheepShaver a little bit more portable (eg. to Windows - if anyone wanted to perform such a noble task). How difficult would be implementing of SDL then? I'm wondering if I would be able to help somehow (5 year experience in Windows/C++ programming, modest experience in Linux programming, no clue about Mac programming). If so, what source files should I look at first? Jerzu |
|
From: Christian B. <Chr...@un...> - 2004-06-04 11:22:57
|
Hi! On Fri, Jun 04, 2004 at 01:12:01PM +0200, Tomasz Jerzykowski wrote: > If so, what source files should I look at first? Graphics and user input are in src/Unix/video_x.cpp (though you might get a heart attack from looking at it...), audio in src/Unix/audio_oss_esd.cpp, and CD-ROM stuff in src/Unix/sys_unix.cpp. Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/ |
|
From: Gwenole B. <gb...@di...> - 2004-06-04 14:17:08
|
Hi, > Just a wild thought... Wouldn't be useful if SheepShaver were using SDL as > graphics subsystem? Recently PearPC guys employed that library in their > project and users were pretty happy with it (performance wise). Performance wise, our graphics subsystem is performing quite well already [*]. Though plain x86 could benefit from SDL/Hermes/x86 blitters. In my opinion, at 30 Hz, it doesn't seem that slow. [*] If it seems slow to you, can you make sure you are running local so that Xshm can be used too? Besides, could you try a build configured with --disable-vosf. If this causes faster graphics on Linux/x86 (at the same frameskip level), then there is a problem. > It would also make SheepShaver a little bit more portable (eg. to > Windows - if anyone wanted to perform such a noble task). Indeed, SDL for portability can be interesting. And as for a Windows port, I still don't have any suitable system to host that either. > How difficult would be implementing of SDL then? I'm wondering if I would be > able to help somehow (5 year experience in Windows/C++ programming, modest > experience in Linux programming, no clue about Mac programming). If so, what > source files should I look at first? > > Jerzu > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > >From Windows to Linux, servers to mobile, InstallShield X is the one > installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > |
|
From: Tomasz J. <to...@je...> - 2004-06-04 14:57:05
|
> -----Original Message----- > From: bas...@li... > [mailto:bas...@li...] On Behalf > Of Gwenole Beauchesne > Sent: Friday, June 04, 2004 4:15 PM > To: bas...@li... > Subject: Re: [B2-devel] SheepShaver and SDL > > Hi, > > > Just a wild thought... Wouldn't be useful if SheepShaver were using > > SDL as graphics subsystem? Recently PearPC guys employed > that library > > in their project and users were pretty happy with it > (performance wise). > > Performance wise, our graphics subsystem is performing quite > well already [*]. Though plain x86 could benefit from > SDL/Hermes/x86 blitters. In my opinion, at 30 Hz, it doesn't > seem that slow. > > [*] If it seems slow to you, can you make sure you are > running local so that Xshm can be used too? Besides, could > you try a build configured with --disable-vosf. If this > causes faster graphics on Linux/x86 (at the same frameskip > level), then there is a problem. > I was bored yesterday and made a little comparison between BasiliskII/Win (no JIT version, MacOS 8.1, 68x) and SheepShaver (MacOS 8.6). The benchmark was Speedometer 4.0. Even though SheepShaver results were noticeably higher in most tests, including QuickDraw ones, SheepShaver's graphics feels a lot slower than Basilisk's - repainting of Finder windows is visible, menus don't appear instantly and stuff like this. The difference increased when I installed Kaleidoscope theming applet and Aqua-like themes on both systems. That's why I've drawn a conclusion that there might be something wrong with SheepShaver graphics performance. I'm aware that my benchmark is not very good (different host OS's, different architectures emulated, different OS's emulated). Jerzu |
|
From: Gwenole B. <gb...@di...> - 2004-06-04 18:00:00
|
Hi, > Even though SheepShaver results were noticeably higher > in most tests, including QuickDraw ones, SheepShaver's graphics feels=20= > a lot > slower than Basilisk's - repainting of Finder windows is visible, = menus > don't appear instantly and stuff like this. I did notice that too but I don't think it's caused by the graphics=20 subsystem. e.g. I ran extra MacBench 5.0 graphics test CopyBits=20 (srcCopy) and performance was really good. Last time I tried to=20 investigate that, reasons why Finder windows repainting it slow might=20 be: - a non neglectable portion is 68k code - the code uses a lot of branches that are not translated effeciently=20 yet - cache is invalidated a lot of times. I noticed that when pulling down=20= a single menu, at least 3 cache invalidation occur for specific regions. I hoped NQD acceleration would help, but it didn't. > The difference increased when I > installed Kaleidoscope theming applet and Aqua-like themes on both=20 > systems. Is Kaleidoscope native PPC nowadays? If not, we really must find a=20 decent way to translate 68k code to native code too. Problem is Apple's=20= special opcodes, and checkpoints for interrupt handling. That can be=20 workarounded but not effeciently. Well, I will try to look at it again. Bye, Gwenol=E9.= |
|
From: Gwenole B. <gb...@di...> - 2004-06-04 18:15:27
|
[About slow windows repainting and general graphics performance.] > I hoped NQD acceleration would help, but it didn't. What's more, the Unix graphics subsystem for SheepShaver is almost the same as in Basilisk II. Noticeable difference is design (object-oriented in B2), and an extra ppc routine that is called 60 times per second. I hoped that recent JIT rentrancy + little optimizations would improve it but it didn't either. That's why I definitely think it's not related to stuff in Unix/video_x.cpp. But I can be wrong. ;-) Really, latest features and optimizations (NQD, reentrant JIT, use of DR emulator, etc.) were meant to attempt to speed up the problem you mention. Finder is also slow on my PBG4 in emulated mode, though graphics performance as reported by benchmarks looks good. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X