Picture taken from last Nerdcamp july '04. I chose a photo of me with a "Shirow" shirt to give you definite evidence that it's me
The collected works of dexter1 - Page 3
In swmgr, type 'set rulesoverride on' in the console field.
Greetings Maciac,
Go to prom, type "5" to go to command monitor and then type "resetenv"
Reboot and try to start your IRIX.
BTW, polls are crap
Go to prom, type "5" to go to command monitor and then type "resetenv"
Reboot and try to start your IRIX.
BTW, polls are crap
Not that we have time to actually DO this, but then, what's life without a wishlist...
Garlic Molecular Viewer and Editor Version 1.4 http://garlic.mefos.hr/garlic/index.html
Garlic Molecular Viewer and Editor Version 1.4 http://garlic.mefos.hr/garlic/index.html
Because IRIX is designed in such a way that old apps will still run on new OSses, your chances are pretty good that it will work. I've played with illustrator on a O2 with 6.5.19 and although it was a o32 app (i think) it ran fine
Can you give us the IRIX version you want to install and the exact specs of the Octane?
Well, first of all read up on net-installing IRIX machines via linux:
http://software.majix.org/irix/install- ... inux.shtml
Then observe the following caveats:
1) Make sure the machines are on the same subnet
2) Make sure you boot from the 6.5.26 overlay sa and mr. If you boot from the 6.5.0 overlays/base, it will not recognize the R12K CPU
3) dhcpd can be tricky at times. Use separate bootpd and tftpd and make them run from the command-line in debug
4) tcpdump can be handy to follow the connection
5) pdksh as a replacement for sh is very necessary to make miniroot install run!
6) Don't try to boot from the CDROM's via efs. Put the CD's on disk in Linux before starting the bootp game
That's it. I can help some more, because i've done this a dozen or so times, so don't be afraid to experiment a bit and ask questions. Maybe a forum search with keywords 'Linux AND bootp AND pdksh' will give you some more threads...
http://software.majix.org/irix/install- ... inux.shtml
Then observe the following caveats:
1) Make sure the machines are on the same subnet
2) Make sure you boot from the 6.5.26 overlay sa and mr. If you boot from the 6.5.0 overlays/base, it will not recognize the R12K CPU
3) dhcpd can be tricky at times. Use separate bootpd and tftpd and make them run from the command-line in debug
4) tcpdump can be handy to follow the connection
5) pdksh as a replacement for sh is very necessary to make miniroot install run!
6) Don't try to boot from the CDROM's via efs. Put the CD's on disk in Linux before starting the bootp game
That's it. I can help some more, because i've done this a dozen or so times, so don't be afraid to experiment a bit and ask questions. Maybe a forum search with keywords 'Linux AND bootp AND pdksh' will give you some more threads...
dawnview wrote:Initiating automatic miniroot installs from multi-user mode may fail on certain Octane machines. The failure will occur when attempting to boot from the CDROM drive and a message will be displayed on the textport stating that there was an execute format error. If this occurs, a standard miniroot install must be used to install 6.5.
Issuing "single" from the command monitor does not succeed, is this a red herring? And what pretell would a "standard miniroot install" entail?
nonono, that is for automatic installations, i guess they mean 'Roboinst' with that. Forget it, it has nothing to do with standard miniroot install we attempt.
Booting 'single' is only needed when the IRIX on disk is hosed and you need to repair it in some way. But you already need an IRIX on your harddisk in the first place to boot 'single'...
I've finished my build of erlang, the erl-sdl interface and wings yesterday with freeware-gcc, and will try it out today on my O2.
There are some funny gnu-isms in the erlang makefiles (read: they are non-POSIX) and building ssl and java interfaces took some time to get it right.
Let's see what will work...
There are some funny gnu-isms in the erlang makefiles (read: they are non-POSIX) and building ssl and java interfaces took some time to get it right.
Let's see what will work...
True, but since i was going to put these in nekoware, might as well do it proper...
I have wings up and running on my O2 at work with 6.5.25m. There is some work to be done with erlang/esdl and wings compile itself, but it pretty much compiles ok, provided you use gcc(freeware 3.3). Apparently erlang doesn't like being compiled with mipspro...
Next stop is my I2 R10K High Impact and 6.5.22m.
Am currently bogged down in validity testing erlang with the test suites. I should be getting something by the end of the week. Oh and i can reproduce the current errors with wings: selecting lighting hangs the program. and selecting popup menus freezes X
Maybe today i have some time to pull this through cvd...
Next stop is my I2 R10K High Impact and 6.5.22m.
Am currently bogged down in validity testing erlang with the test suites. I should be getting something by the end of the week. Oh and i can reproduce the current errors with wings: selecting lighting hangs the program. and selecting popup menus freezes X
Maybe today i have some time to pull this through cvd...
Running some tests on the esdl extension revealed some odd behaviour (from esdl Readme):
wow, that was quick! Only the second one works fine (a spinning colored cube):
That segmentation fault is also typical when quitting wings on my machines.
I have a distinct feeling that this crapping out of SDL is due to esdl having -lpthread, because neko_sdl has -lpthread as well, but erlang is compiled without threading. Trying to turn on threading breaks compile with a malfunctioning 'beam' executable:
... while a non-threaded 'beam' does this (a normal crash report):
This merits some investigatoin why the erlang --enable-threads produces wrong code...
Oh, and i indeed have no icons on my impact system, but they appear on the O2 just fine...
Code: Select all
mech044 /usr/local/src/esdl-0.94.1025/test> erl -pa ../ebin
Erlang (BEAM) emulator version 5.4.3 [source]
Eshell V5.4.3 (abort with ^G)
1> testsprite:go().
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
Code: Select all
mech044 /usr/local/src/esdl-0.94.1025/test> erl -pa ../ebin
Erlang (BEAM) emulator version 5.4.3 [source]
Eshell V5.4.3 (abort with ^G)
1> testgl:go().
Command:68:SDL_GL_SetAttributeFunc: ok
Command:35:SDL_ListModesFunc: ok
Command:31:SDL_VideoDriverNameFunc: ok
Driver "x11"
Available WindowSizes [{sdl_rect,0,0,1280,1024}]
Command:34:SDL_VideoModeOKFunc: ok
Command:34:SDL_VideoModeOKFunc: ok
Command:34:SDL_VideoModeOKFunc: ok
Command:34:SDL_VideoModeOKFunc: ok
A guess at max video res is 1280x1024:32
Command:36:SDL_SetVideoModeFunc: ok
Command:69:SDL_GL_GetAttributeFunc: ok
Command:69:SDL_GL_GetAttributeFunc: ok
Command:69:SDL_GL_GetAttributeFunc: ok
Command:69:SDL_GL_GetAttributeFunc: ok
Command:69:SDL_GL_GetAttributeFunc: ok
OpenGL attributes
Sizes in bits Red 5 Green 5 Blue 5 Depth 24 Doublebuffered true
Command:297:glGetString: ok
Vendor: SGI
Command:297:glGetString: ok
Renderer: CRIME
Command:297:glGetString: ok
Version: 1.1 Irix 6.5
Command:284:glGetIntegerv: ok
GL AUX BUFFERS [0]
Command:67:SDL_WM_GetInfoFunc: ok
SDL Version {{1,2,7},<<0,0,0,0>>}
Command:297:glGetString: ok
Extensions: GL_EXT_abgr GL_EXT_blend_color GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_convolution GL_EXT_copy_texture GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_object GL_EXT_vertex_array GL_INGR_interlace_read GL_SGI_color_matrix GL_SGI_color_table GL_SGI_texture_color_table GL_SGIS_texture_color_mask GL_SGIS_texture_edge_clamp GL_SGIX_interlace GL_SGIX_texture_scale_bias
Command:75:SDL_WM_IsMaximizedFunc: ok
Maximized: false
Command:721:glGetConvolutionParameterfv: ok
[11.0000]Command:105:SDL_EventStateFunc: ok
Command:105:SDL_EventStateFunc: ok
Command:105:SDL_EventStateFunc: ok
Command:105:SDL_EventStateFunc: ok
Command:23:SDL_GetErrorFunc: ok
Command:470:glViewport: ok
Command:354:glMatrixMode: ok
Command:337:glLoadIdentity: ok
Command:364:glOrtho: ok
Command:354:glMatrixMode: ok
Command:337:glLoadIdentity: ok
Command:256:glEnable: ok
Command:244:glDepthFunc: ok
Command:212:glClearColor: ok
Command:182:SDL_UTIL_DebugFunc: ok
< i pressed <escape> >
Segmentation fault
I have a distinct feeling that this crapping out of SDL is due to esdl having -lpthread, because neko_sdl has -lpthread as well, but erlang is compiled without threading. Trying to turn on threading breaks compile with a malfunctioning 'beam' executable:
Code: Select all
irene /usr/local/src/otp_src_R10B-2/bin/mips-sgi-irix6.5> beam
Failed to create thread: Operation not permitted (1)
Abort (core dumped)
Code: Select all
mech044 /usr/local/src/otp_src_R10B-2/bin/mips-sgi-irix6.5> beam
{"init terminating in do_boot",'no -root flag'}
Crash dump was written to: erl_crash.dump
init terminating in do_boot (no -root flag)
Oh, and i indeed have no icons on my impact system, but they appear on the O2 just fine...
Hold your horses
I am actually repackaging xscreensavers and flireflies and rss-glx right now atm, with some openGL1.1 fixes for some GL -xscreensavers (glmatrix for instance) and a fireflies speedup. rssglx full-mipspro build should be finished early next week.
I am actually repackaging xscreensavers and flireflies and rss-glx right now atm, with some openGL1.1 fixes for some GL -xscreensavers (glmatrix for instance) and a fireflies speedup. rssglx full-mipspro build should be finished early next week.
hamei wrote:dexter1 wrote: Hold your horses
hreeeeheeeheeehee, whicker whicker
Damn, where are those carrots ...
hamei wrote: They do look great .... are there any newer additions out ? Seems like the Linux crowd oughta be good for *something* !
Linux? Who said the reallyslick was Linux? http://www.reallyslick.com/
Hamei is actually using Windows stuff
Good part though is that the Guy who is originally coding them in windows has just released one new screensaver called Hyperspace. It will take some time before the rss-glx guy is resurrected from what coma he is in for the last 2 years, but i took a crack at porting the new helios to rss-glx and i was successful (though is now slower
) so i have hopes for Hyperspace being ported soon.
As you all can see on
Nekochan's home page
i have just finished the nekoware screensavers. A short recap:
Xscreensavers-4.21 (xscreensaver version 3)
Nekochan download page and dexter1 mirror
- Compiled Extrusion, because we now have a static glextruder lib in glut.
- Fixed OpenGL-1.2 reversed packed pixel support in Blocktube, Bouncingcow, Flyingtoasters, GLblur, GLforestfire, GLmatrix, GLplanet, Lament and Sballs. These now work with O2's Indigo2IMPACT, Octane MGRAS, and...
- Fixed all packed pixel textures, so all of the above will now work on RealityEngines (!)
- Fixed Texture fonts bug on Impact systems in Textfont.c and related screensavers Carousel, Fliptext and Starwars.
- Added Powerflip and ElectroPaint scripts (try them!), so that these can run in xscreensaver.
- Added all Reallyslick and the Fireflies screensavers as checkbox option in config file.
Reallyslick-0.7.6 (version 2)
Nekochan download page and dexter1 mirror
- Fixed GL_ALPHA texture bug on Impact systems. 'lattice -T 6' and 'lattice -T 7' now produce correct textures.
- Recompiled all screensavers with -IPA on MIPSPro compilers.
- Fixed display bug in flux and solarview.
- Added all reallyslick screensavers in 4Dwm screensaver panel. Now's your chance, Hamei!
- Cyclone Vortex bugfix is included.
- readded Lisa's single texture and single buffer options, and made the single buffer short option '-1' actually work.
Fireflies-2.06 (version 2)
Nekochan download page and dexter1 mirror
- Changed glVertex3d calls into glVertex3f for a 30% reduction in GL_calls
Some nice snapshots are on the main blog page.
There is (always) some stuff which needs to be fixed:
- Xscreensavers use a nasty Xwidget to make the GLX window for the openGL hacks, so trying to add them in the 4Dwm screensaver menu will result in a nasty left-and-upper line of the screensaver when running full-screen. I've added glMAtrix as an example of this. Not too bad, but still...
- Haven't looked at xscreensaver-getimage-video yet, which supposedly can capture from SGI video boards (!) Could be neat...
- Reallyslick screensavers biof and busyspheres can coredump on IMPACT/MGRAS graphics when resizing them to fullscreen. Happens rougly 1 out of 5 attempts. Weerd...
- Helios is CPU-bound(!) and i've tried (and failed) to optimise it.
- Fireflies is now compiled with SDL. My wish is to add a GLX non-root viewport, so we can drop the SDL stuff and as a bonus, enable it in 4Dwm screensaver menu, because it now doesn't like being SGI-fied...
Took me two weeks of testing, debugging and compiling. Am butt-tired,
Beer!
Xscreensavers-4.21 (xscreensaver version 3)
Nekochan download page and dexter1 mirror
- Compiled Extrusion, because we now have a static glextruder lib in glut.
- Fixed OpenGL-1.2 reversed packed pixel support in Blocktube, Bouncingcow, Flyingtoasters, GLblur, GLforestfire, GLmatrix, GLplanet, Lament and Sballs. These now work with O2's Indigo2IMPACT, Octane MGRAS, and...
- Fixed all packed pixel textures, so all of the above will now work on RealityEngines (!)
- Fixed Texture fonts bug on Impact systems in Textfont.c and related screensavers Carousel, Fliptext and Starwars.
- Added Powerflip and ElectroPaint scripts (try them!), so that these can run in xscreensaver.
- Added all Reallyslick and the Fireflies screensavers as checkbox option in config file.
Reallyslick-0.7.6 (version 2)
Nekochan download page and dexter1 mirror
- Fixed GL_ALPHA texture bug on Impact systems. 'lattice -T 6' and 'lattice -T 7' now produce correct textures.
- Recompiled all screensavers with -IPA on MIPSPro compilers.
- Fixed display bug in flux and solarview.
- Added all reallyslick screensavers in 4Dwm screensaver panel. Now's your chance, Hamei!
- Cyclone Vortex bugfix is included.
- readded Lisa's single texture and single buffer options, and made the single buffer short option '-1' actually work.
Fireflies-2.06 (version 2)
Nekochan download page and dexter1 mirror
- Changed glVertex3d calls into glVertex3f for a 30% reduction in GL_calls
Some nice snapshots are on the main blog page.
There is (always) some stuff which needs to be fixed:
- Xscreensavers use a nasty Xwidget to make the GLX window for the openGL hacks, so trying to add them in the 4Dwm screensaver menu will result in a nasty left-and-upper line of the screensaver when running full-screen. I've added glMAtrix as an example of this. Not too bad, but still...
- Haven't looked at xscreensaver-getimage-video yet, which supposedly can capture from SGI video boards (!) Could be neat...
- Reallyslick screensavers biof and busyspheres can coredump on IMPACT/MGRAS graphics when resizing them to fullscreen. Happens rougly 1 out of 5 attempts. Weerd...
- Helios is CPU-bound(!) and i've tried (and failed) to optimise it.
- Fireflies is now compiled with SDL. My wish is to add a GLX non-root viewport, so we can drop the SDL stuff and as a bonus, enable it in 4Dwm screensaver menu, because it now doesn't like being SGI-fied...
Took me two weeks of testing, debugging and compiling. Am butt-tired,
Beer!
Indeed, as we discussed on #nekochan, the xscreensaver-getimage-file seems to need the tool ppmsave. I had a quick look as to whether this is fixable using imagemagick, but decided it's better to release the package, than wait for another week or two fiddling with it.
So it will be done sometime
So it will be done sometime
neko_gltron-0.70.tardist:
Nekochan download
and
Dexter1's mirror
And its deps:
neko_libmikmod-3.2.0b2.tardist: Nekochan download and Dexter1's mirror
neko_sdl_sound-1.0.1.tardist: Nekochan download and Dexter1's mirror
Everything works pretty ok. Sound and music is there as well as all 43 artpacks. Occasionally the viewpoint camera is screwed up, but can be fixed by throwing away your .gltronrc file and restarting. This is a view with the binary texture pack:
There even is a homegrown icon for gltron, upper left in the picture..
Enjoy!
And its deps:
neko_libmikmod-3.2.0b2.tardist: Nekochan download and Dexter1's mirror
neko_sdl_sound-1.0.1.tardist: Nekochan download and Dexter1's mirror
Everything works pretty ok. Sound and music is there as well as all 43 artpacks. Occasionally the viewpoint camera is screwed up, but can be fixed by throwing away your .gltronrc file and restarting. This is a view with the binary texture pack:
There even is a homegrown icon for gltron, upper left in the picture..
Enjoy!
I know, i know, yet another German Billiard GL game, Please insert the obvious "Play with balls" joke in here
neko_foobillard-3.0a.tardist
Deps are freetype2,libpng,sdl and zlib
This one is not so smooth as BillardGL, but has some nifty features. It's a bit of a rough port, but the damn thing doesn't even play ball (heh
) with my Linux+Radeon9250+Xorg, so i consider that Beta enough
Enjoy!
neko_foobillard-3.0a.tardist
Deps are freetype2,libpng,sdl and zlib
This one is not so smooth as BillardGL, but has some nifty features. It's a bit of a rough port, but the damn thing doesn't even play ball (heh
) with my Linux+Radeon9250+Xorg, so i consider that Beta enough
Enjoy!
Antnee wrote:
Hey, can we get some real UK/US Pool game? I prefer it to any kind of billiards. More of a UK pool fan mind you, old rules!
Sorry old chap, how's this?
I have no clue if the Indy has the same address range. I did however dumped the PROM of the Indy some time ago. Just an EEPROM reader with 40 pin EEPROM support was enough, no hassles
In case you need the O2 PROM, easiest thing is to extract the O2 PROM from a recent overlay. They are on the second disk:
and contain only one file
To extract them, just copy those three files in /tmp and start inst as 'inst -f /tmp -r /tmp -m CPUBOARD=IP32'
- Select from
- List the subsystems to be installed, it should be marked with an 'i'
- 'set rulesoverride on'
- go
- exit
The prom is then in /tmp/usr/cpu/firmware/ip32prom.image
In case you need the O2 PROM, easiest thing is to extract the O2 PROM from a recent overlay. They are on the second disk:
Code: Select all
-rw-r--r-- 1 frank user 405 Oct 8 2003 ip32prom_6522m
-rw-r--r-- 1 frank user 318 Oct 8 2003 ip32prom_6522m.idb
-rw-r--r-- 1 frank user 273828 Oct 8 2003 ip32prom_6522m.sw
and contain only one file
Code: Select all
> showfiles -f ip32prom_6522m
f 21907 431872 ip32prom.sw.prom m usr/cpu/firmware/ip32prom.image
To extract them, just copy those three files in /tmp and start inst as 'inst -f /tmp -r /tmp -m CPUBOARD=IP32'
- Select from
- List the subsystems to be installed, it should be marked with an 'i'
- 'set rulesoverride on'
- go
- exit
The prom is then in /tmp/usr/cpu/firmware/ip32prom.image
MooglyGuy wrote: All MIPS processors have their boot ROMs located at 0xBFC00000, so yes, it will work. Incidentally, if you want to emulate an R5K Indy, just grab the boot ROM here: http://einstein.etsu.edu/~zrah2/ip225015.zip - it's off of a 150MHz R5K Indy. Fair warning, you might have to swap it for endianness, though. It's only in its current format because that's what my own emulator takes.
I can confirm that this image is indeed exactly the same as my rev 11 PROM dump at home. It is byteswapped over 4 bytes however, so you have to swap it back to read all the nice text
Check out http://nova.stanford.edu/~curtis/resear ... byteswap.c
and perform the byteswap with: ./byteswap -o ip225015be.bin 4 ip225015.bin
Thanks Moogly for that info!
MooglyGuy wrote: - An R4x00-based Indigo 2
If you could hook up your machine via the serial console, and from the command monitor, run a "dump -w -x 0xbfc00000:0xbfc80000" in a terminal that supports logging, and then post a link to the log, I'd appreciate it.
One 150MHz R4400 Indigo2 PROM coming up:
minicom dump
bigendian binary dump
To check whether this dump went ok, i extracted the boot image and boot tune(s):
boottune(s)
As for the O2's i doubt that these will be different. They are flash upgraded, so you can extract them from irix overlays
I volunteer, although i'm oversees from the states.
Probably static route again.
IRIX 6.x has this in /etc/config/static-route.options but i suspect that IRIX 5.3 has it in /etc/init/network. Read through that file to see if there is some reference of static routes. When in doubt, use the gui!
IRIX 6.x has this in /etc/config/static-route.options but i suspect that IRIX 5.3 has it in /etc/init/network. Read through that file to see if there is some reference of static routes. When in doubt, use the gui!
Fan-Bloody-Tastic!
Extremely cool done. I wonder how fast these babies run emulated.
Newport is the only Gfx for which docs are readily available, but the dudes porting Linux on Mips have a good trackrecord of reverse engineering Impact Gfx so this might be a future option for the IP22 Indigo2. Don't bother with the GR2 boards like the XZ, though for historical reasons they might be fun to emulate too...
Extremely cool done. I wonder how fast these babies run emulated.
Newport is the only Gfx for which docs are readily available, but the dudes porting Linux on Mips have a good trackrecord of reverse engineering Impact Gfx so this might be a future option for the IP22 Indigo2. Don't bother with the GR2 boards like the XZ, though for historical reasons they might be fun to emulate too...
For the Itanium the intel compiler is called 'ecc'
But yeah, it's standard Intel compiler env. Be it with a few advance patches, which regular Intel compiler customers get with later builds.
But yeah, it's standard Intel compiler env. Be it with a few advance patches, which regular Intel compiler customers get with later builds.
Actually, the tech to use phase information to achieve bidirectional information on a single wire is a prototype from Cray research. This tech has been used to double the bandwith over existing NUMA cabling.
I got this from SGI CTO Eng Lim Goh during a presentation.
I got this from SGI CTO Eng Lim Goh during a presentation.
Satoru wrote:
Having had the unpleasant experience of running a dual itanic in my basement I can confirm that the heat produced is close to nonsense.
Yup, totally agree. Visited my Colleague at Aerospace Engineering Faculty last Wednesday, and he showed me his 12P ringrouted 6 module Altux 350 in that uglee Yellow cabinet. The heated air coming out of the back was astounding, close to 40 degrees celsius! If the air is so hot there, imagine what is must be like on the dies themselves.
Nope, no Itanic near anybody's desk, if it's my call...
gack, must get around of building that one again.
I'm on the mailing list and last builds by me were 0.70. They are now at 0.96. Would be neat to see openGL improvements
I'm on the mailing list and last builds by me were 0.70. They are now at 0.96. Would be neat to see openGL improvements
I haven't had the chance to test neko_firefox but does this mean it's a static build with static gtk1 stuff or .so's?
The whole point of making libraries dynamic is to preserve memory and not getting stuck with several different versions of certain libraries. My vote to including all deps into the nekoware package is a firm no, unless it's a true static build. I've done this with xscreensaver's Extrusion saver, since a) this was the only of 97 savers which needed libgle and b) one complete glut dep on xscreensaver for a tiny app didn't made sense to me, so i linked a static libgle.a to it.
Added to that static builds are generally faster, so i recommend either full static builds of firefox or static builds of firefox + nekoware deps.
Absence of build instructions? Not good.
The whole point of making libraries dynamic is to preserve memory and not getting stuck with several different versions of certain libraries. My vote to including all deps into the nekoware package is a firm no, unless it's a true static build. I've done this with xscreensaver's Extrusion saver, since a) this was the only of 97 savers which needed libgle and b) one complete glut dep on xscreensaver for a tiny app didn't made sense to me, so i linked a static libgle.a to it.
Added to that static builds are generally faster, so i recommend either full static builds of firefox or static builds of firefox + nekoware deps.
Absence of build instructions? Not good.
Be careful when downgrading IRIX. Older pre 6.5.16 versions have no knowledge of XFS version 2 filesystems and try to treat them as version 1 which fails. There is no tool for converting version 2 to version 1 XFS. Been there, done that.
Best thing to do is to reinstall 6.5.9 on a separate disk and try to copy the relevant files to a NFS mount or transfer them to CD...
Best thing to do is to reinstall 6.5.9 on a separate disk and try to copy the relevant files to a NFS mount or transfer them to CD...
Diego wrote: ...mmmhhh
Anyone has completed succesfully the build of YafRay V0.0.7 on IRIX? ...I got the package already compiled, but on the 'make install' phase I get:
Ok everybody please start laughing at Yafray makefile "specialists", 'cause this one is a real screamer:
Code: Select all
.
g++ -shared -nostdlib /usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.3/crtbegin.o .libs/pathlight.o .libs/pathtools.o -Wl,-rpath -Wl,/usr/local/lib -L/usr/local/lib -lyafraycore -L/usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.3 -L/usr/bin -L/usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.3/../../.. -lstdc++ -lm -L/usr/lib32/mips3 -L/usr/lib32 -lgcc /usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.3/crtend.o -Wl,-soname -Wl,libpathlight `test -n "" && echo -Wl,-set_version -Wl,` -Wl,-update_registry -Wl,.libs/so_locations -o .libs/libpathlight
ld32: FATAL 9 : I/O error (-lyafraycore): No such file or directory
collect2: ld returned 32 exit status
libtool: install: error: relink `libpathlight.la' with the above command before installing it
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
g++ ??? what the hell does that do in a mipspro build? Looks like somebody made a sick joke upon us. I tried this myself and even with env settings like 'setenv CXX CC' it still came up with g++.
Sure enough, i found the bug in src/yafraycore/Makefile.in:
Code: Select all
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CXX = g++
CXXCPP = @CXXCPP@
CXXDEPMODE = @CXXDEPMODE@
So add this patch:
Code: Select all
--- Makefile.in.save Fri Jun 17 02:11:56 2005
+++ Makefile.in Fri Jun 17 02:12:16 2005
@@ -51,7 +51,7 @@
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
-CXX = g++
+CXX = @CXX@
CXXCPP = @CXXCPP@
CXXDEPMODE = @CXXDEPMODE@
CXXFLAGS = @CXXFLAGS@
--- vector3d.h.save Fri Jun 17 02:20:41 2005
+++ vector3d.h Fri Jun 17 02:20:54 2005
@@ -26,7 +26,7 @@
#include<config.h>
#endif
-#include<cmath>
+#include<math.h>
#include<iostream>
#include<stdlib.h>
#include<stdio.h>
--- color.h.save Fri Jun 17 02:23:23 2005
+++ color.h Fri Jun 17 02:23:36 2005
@@ -28,7 +28,7 @@
#endif
#include <iostream>
-#include <cmath>
+#include <math.h>
#define COLOR_SIZE 3
And this environment:
Code: Select all
setenv CC c99
setenv CXX CC
setenv CFLAGS '-O3 -mips4 -n32'
setenv CXXFLAGS '-O3 -mips4 -n32'
setenv CPPFLAGS '-I/usr/nekoware/include'
setenv LDFLAGS '-L/usr/nekoware/lib -Wl,-rpath -Wl,/usr/nekoware/lib'
setenv GNUMAKE '/usr/nekoware/bin/make'
setenv PERL '/usr/nekoware/bin/perl'
There are more Makefile.in which also have this harcode. Please fix them accordingly...
The " _ZN6yafray9context_tC1Ev" i recognised as c++ name mangling errors, which would be perfectly logical if one would mix g++ libs with mipspro code.
It could be that the libraries need to be rearchived with CC -ar -WR,-suv -o
I'm rechecking this ATM...
Diego wrote: Nice catch, Dexter!
...but I've also tried using g++ (GCC Version 3.3), and I can't get a clean install here... Hence my words:
Diego wrote: it compiles fine, even with MIPSPRO
As far as I can see, it is not a very clean "multiplatform" sourcecode, but I could be wrong!
No Diego, you're missing the entire point.
With the Makefile.in template you ALWAYS compile with g++ even when the ./configure script says it has found CC and you have set environment variables the right way.
The g++ is HARDCODED in all Makefile.in templates...
If you really managed to get it compiled with MIPSPro 7.4.x you should have had complaints with
Code: Select all
#include <cmath>
That's why you need to change all g++ occurences with @CXX@ in all Makefile.in files. Then do a ./configure again and it should start compiling with MIPSPro CC.
The make install problem is an entirely different one. Looks like the supplied libtool severely screws up. The solution is to get the latest libtool from gnu.org ( 1.5.18 ), ./configure;make that one and copy libtool and ltmain.sh to the yafray top source dir. Then do
Code: Select all
./configure --enable-static --disable-fast-install ; gmake ; gmake install
The next thing that you get is that every cout/cerr stream ending with '<<endl' will segfault and dump core. Looks like the coders got overzealous and decided to overload every << instance in their own ostream class. Handy...
Replacing all '<<endl' with '<<"\n"' seems to fix this. Better get a script to do that for you.
I have this almost done. Good testing still needs to be done before we can go to '-Ofast -IPA'
After some bloody confrontation scenarious with yafray source, i think i have the magic patch file pinned down. Problem only is that i cannot find a mundane test.xml file so i can test the yafray binary. I already tried the test007.zip package and i can't get a sensible xml out of blender. Or the xml code will come out fine, but i get things like this:
... and YBtest.tga is completely black. BTW this is the same in Linux as it is in IRIX. Seems the Yafray coders have their heads firmly in mr Gates' butt...
Can anyone provide me with a small working XML file so i can do some speed testing?
Code: Select all
neo:~>yafray YBtest.xml
Starting YafRay ...
Loading grammar ...
Starting parser ...
[Warning]: Unknown camera attr aspect_ratio
[Warning]: Unknown camera attr bokeh_type
[Warning]: Unknown camera attr bokeh_bias
[Warning]: Unknown camera attr bokeh_rotation
Parsing OK
Loading plugins ...
[Warning]: Unknown shader type blendershader
[Warning]: Unknown shader type blendershader
[Warning]: Unknown shader type blendershader
[Error]: undefined shader MAcristal object ignored
[Error]: undefined shader MArojo object ignored
[Error]: undefined shader MArojo object ignored
[Error]: undefined shader MAMaterial object ignored
[Error]: undefined shader MArojo object ignored
[WARNING]:Unused param angle in light
[WARNING]:Unused param cluster in light
[WARNING]:Unused param color in light
[WARNING]:Unused param depth in light
[WARNING]:Unused param fixedradius in light
[WARNING]:Unused param from in light
[WARNING]:Unused param photons in light
[WARNING]:Unused param power in light
[WARNING]:Unused param search in light
[WARNING]:Unused param to in light
[WARNING]:Unused param use_QMC in light
[WARNING]:Unused param cast_shadows in light
[WARNING]:Unused param color in light
[WARNING]:Unused param from in light
[WARNING]:Unused param power in light
[WARNING]:Unused param cache in light
[WARNING]:Unused param cache_size in light
[WARNING]:Unused param caus_depth in light
[WARNING]:Unused param depth in light
[WARNING]:Unused param grid in light
[WARNING]:Unused param ignore_bumpnormals in light
[WARNING]:Unused param power in light
[WARNING]:Unused param samples in light
[WARNING]:Unused param search in light
[WARNING]:Unused param shadow_threshold in light
[WARNING]:Unused param threshold in light
[WARNING]:Unused param use_QMC in light
[Warning]: Wrong type for background constant
[Loader]: Added camera MAINCAM
Using a world resolution of 0.00142857 per unit
Rendering with 5 raydepth
2 anti-alias passes and 4 minimum samples per pass, 8 samples total.
[Warning]: Background world_background does not exist
Building bounding tree ... OK
Light setup ...
Setting up lights ...
Finished setting up lights
Render pass: [########]
Saving Targa file as /tmp/YBtest.tga
OK
... and YBtest.tga is completely black. BTW this is the same in Linux as it is in IRIX. Seems the Yafray coders have their heads firmly in mr Gates' butt...
Can anyone provide me with a small working XML file so i can do some speed testing?
squeen wrote: Where can I get big.xml, I'd like to run it on the Onyx350?
It's mentioned in thread: viewtopic.php?t=1826&start=112
big.xml
managed resistance wrote: Does anyone know if there's a server anywhere on the Internet that I could use to install IRIX 6.2 on my Indy? I read that IRIX 6.2 is free.
Well, you've read wrong. IRIX 6.2 is only obtainable from SGI for free if it is the original media that came with the Indy, which is the same procedure for all SGI machines/IRIX software. But i haven't heard from anyone succesfully using that option... Best bet is to buy either IRIX 6.2 media via resellers or Ebay, or go directly for IRIX 6.5 base and upgrade to 6.5.22 from supportfolio. The latter is much more modern, albeit slower, and if your Indy CPU is an R5000 you can even run nekoware.
To be honest, i don't see any harm in the progress bars. The information was already there previously with the rank name assignments and the amounts of posts. And at 300 everybody is capped to "complete".
(got a shiny star! w00t!)
(got a shiny star! w00t!)
Don't get your hopes up too high
The IRIX yafray binary has a shortcoming with Caustics, noticable by the missing red spot on the ground of big.xml, of which much of the render time depends on it.
Yesterday evening i found the bug in 0.0.7CVS and 0.0.8 (just out). Stupid me and my ideas of code cleanup.
In vector3d.h:
Somewhere between toilet visits and getting coffee my mind has dropped 4 nibbles. MIPSPro was barking on this (1<<31)-1 line like mad so i wrote it down as 0x7fff. D'OH! Ofcourse it should have been:
Running the code with 0x7fff, causes the random function to spew large numbers, not normalised between 0 and 1. This triggers overflowed vectors in the Caustics code, causing it to reject all rays for Caustics.
Needless to say, the binary runs a lot slower now, with the added caustic rays, but the image is now in par with the Linux one. The red spot is there.
I'll build a 0.0.8 yafray today and a new package should be in somewhere this week. I hope to compensate a little for the slower rendertime by attempting to profile the binary. Wish me luck
The IRIX yafray binary has a shortcoming with Caustics, noticable by the missing red spot on the ground of big.xml, of which much of the render time depends on it.
Yesterday evening i found the bug in 0.0.7CVS and 0.0.8 (just out). Stupid me and my ideas of code cleanup.
In vector3d.h:
Code: Select all
- const int m = (1<<31)-1;
+ const int m = 0x7fff;
Somewhere between toilet visits and getting coffee my mind has dropped 4 nibbles. MIPSPro was barking on this (1<<31)-1 line like mad so i wrote it down as 0x7fff. D'OH! Ofcourse it should have been:
Code: Select all
- const int m = (1<<31)-1;
+ const int m = 0x7fffffff;
Running the code with 0x7fff, causes the random function to spew large numbers, not normalised between 0 and 1. This triggers overflowed vectors in the Caustics code, causing it to reject all rays for Caustics.
Needless to say, the binary runs a lot slower now, with the added caustic rays, but the image is now in par with the Linux one. The red spot is there.
I'll build a 0.0.8 yafray today and a new package should be in somewhere this week. I hope to compensate a little for the slower rendertime by attempting to profile the binary. Wish me luck
Smilies mr Sky, smiliesskywriter wrote: don't worry it'll be something completely different broken in the next release. upgrade!
alos bittorent is annoying. when you're done; please package up with something useful.
Ah that Blender stuff can't be good for one's heart..
And the Yafray code is good, it's just my buttarsed brain that twisted and turned. Rest assured, i am working on bringing back full SGI+pthread support into Yafray. I found the offending bug in the SGI STL-library and i think i have a fix for it. For anybody who cares to know this, and have an cast-iron belly, read up:
Problem description
Consider this small program:
Code: Select all
#include <iostream>
int main() { std::cout << 1 << std::endl;}
Compiled via 'CC -o pth pth.cpp -mips4 -n32 -LANG:std' this indeed gives the desired output.
However, if you need to have pthread support in your C++ STL-Library, you need the -D_PTHREADS flag. And now it gets ugly. Compile with 'CC -D_PTHREADS -o pth pth.cpp -mips4 -n32 -LANG:std' and run, and the program segfaults.
Solution
This is a long outstanding bug, since 2001, but the fix is much more obscure and few people know. This is the fix:
Solution: C++ application compiled using STL, -D_PTHREADS generates segmentation fault or bus error
This bug has been fixed in the 7.3.1.3m compiler. To use the fix compile with the following options :
CC -LANG:std -D_PTHREADS filename.cpp -o filename -lCio_pthreads
"But i use the MIPSPro 7.4.x compiler! What gives?"
Well, the library is still there:
Code: Select all
mech044 /usr3/everdij> versions long | grep Cio_pthreads
f 47975 7566 c++_dev.sw.lib usr/lib32/libCio_pthreads.a
So you need to link all code with that small static archive and presto! 'CC -D_PTHREADS -o pth pth.cpp -mips4 -n32 -LANG:std -lCio_pthreads' will give the correct output.
Phew, messy stuff. Anyway am rebuilding yafray with this feature, and hopefully it will behave much better when using two or more processors...