I was a great suse fan when I used geforce Ti 4600 on my old machine.
I had standard drivers installed via YOU (nvidia display driver) and quality/performance was superb when compared to windows.
Now I have brand new M70 with quadro 1400go, installed the same driver using automatic update and the result is worse than in windows, there are some artifacts and viewport operations aren't as fluent.
What drivers are you using with quadro on linux?
Are there any settings to adjust?
I'm also a bit upset about houdini stability…the newest apprentice hangs whet I overload the memory, no matter the OS.
As soon as I copy a few (2 up) millions of polys I get segmentation fault, is it normal.
Iremember about swap/virtual memory, there is always enough.
Thanks
Full Version: SUSE 9.3 graphics question.
1.0-7676
I suspect the issue is with the card + drivers, as opposed to just the drivers. Anyway, with this system and card(64 bit, FX3600, SUSE 9.3/XOrg) it was necessary for me to get the latest and greatest drivers(at the time) *plus* update the kernel to deal with a few basic driver issues. In that case, it was definitely related to being 64 bit, however. It's solid as a rock right now - only Jim can make it crash(he's got some issues). I haven't had a lockup or crash with either X or Houdini since(a few months). Certainly I have no glitches or odd display problems(remember, though, the FX3600 has been around a little while - new NVidia cards always seem to have issues).
However, I did override the default SUSE driver version - it almost *never* changes(check the script that does the updating).
As far as hanging when you overload memory…don't!
The app crashing when the system runs out of memory isn't particularly a sign of a buggy app. The system is designed to keep the OS running, at the expense of the app causing the problem, not the other way around.
Cheers,
J.C.
I suspect the issue is with the card + drivers, as opposed to just the drivers. Anyway, with this system and card(64 bit, FX3600, SUSE 9.3/XOrg) it was necessary for me to get the latest and greatest drivers(at the time) *plus* update the kernel to deal with a few basic driver issues. In that case, it was definitely related to being 64 bit, however. It's solid as a rock right now - only Jim can make it crash(he's got some issues). I haven't had a lockup or crash with either X or Houdini since(a few months). Certainly I have no glitches or odd display problems(remember, though, the FX3600 has been around a little while - new NVidia cards always seem to have issues).
However, I did override the default SUSE driver version - it almost *never* changes(check the script that does the updating).
As far as hanging when you overload memory…don't!
The app crashing when the system runs out of memory isn't particularly a sign of a buggy app. The system is designed to keep the OS running, at the expense of the app causing the problem, not the other way around.Cheers,
J.C.
Thanks for a rapid reply
So I'll have to download the newest drivers and reinstall.
Well, these peculiarities aren't very bad, just the ogl display is worse quality than on xp, and there are drawbacks in speed, for example when I orbit, it waits a while then starts orbiting, also when orbiting around 200k of polys (what is really not much) it doesn't work smoothly but jumps. In xp everything works supernice.
The memory overload is strange since I have 5 gb swap and my scene never got bigger than 2 million polys (I can check out exacly)
It should drop data to swap space not crash.
My system is a strong M70 2.26 2gigs of ram and it handles almost smoothly over 4 millon of polys in max viewport, not to mention xsi.
Are there any hidden memory settings(not these in prefs)?
Peter
So I'll have to download the newest drivers and reinstall.
Well, these peculiarities aren't very bad, just the ogl display is worse quality than on xp, and there are drawbacks in speed, for example when I orbit, it waits a while then starts orbiting, also when orbiting around 200k of polys (what is really not much) it doesn't work smoothly but jumps. In xp everything works supernice.
The memory overload is strange since I have 5 gb swap and my scene never got bigger than 2 million polys (I can check out exacly
)It should drop data to swap space not crash.
My system is a strong M70 2.26 2gigs of ram and it handles almost smoothly over 4 millon of polys in max viewport, not to mention xsi.
Are there any hidden memory settings(not these in prefs)?
Peter
It really sounds like you aren't using the nvidia drivers i.e. your driver install failed. I'd try again, following the process carefully. Read the README on the nvidia site for SUSE install…lots of good info there. it tells you how to check and see if you're running the driver properly. I'm getting faster response on a linux system over anything I've seen in windows, so I really think that's the problem.
Swap on linux/page file on windows isn't intended to be used on a regular basis…it's there for a single reason - should an app you're running exceed the available physical memory of the system, the OS can protect itself and start gobbling up the swap file. Stops it killing the app immediately. Should the app continue to gobble, the OS kills it, keeping the integrity of the system. It's intended as a stopgap convenience only - in the event you unintentionally exceed your expected memory use. Don't use disk grinding as a replacement for memory. In fact many people I know just turn off the page file in windows because the MS method of managing virtual memory seems like it was coded by a braindead troll. Windows outfitted with 2G and up will run a lot faster that way.
You have two options: buy more memory, or be more efficient in the way you use apps. If you really, seriously need to have 2 million polys(which btw isn't really all that much - I've loaded that in 2G I'm sure), and want to keeping loading flipbooks, more apps, more flipbooks…then buy more mem. You can't compare different apps - there's more to the memory usage than the number of polys. Don't forget - Houdini is a multi-use tool. You been using the compositor? Memory usage for Houdini is pretty well automatic *except* for the compositor…look in the prefs for that.
The notion of a 5G swap file has been pretty well discounted nowadays as a waste of disk space. The rule used to be to make it half your physical mem(which you're exceeding by a lot!), but nowadays they pretty well say set it to 512M. Maybe 1G, at most. Better solution is to get more mem.
Cheers,
J.C.
Swap on linux/page file on windows isn't intended to be used on a regular basis…it's there for a single reason - should an app you're running exceed the available physical memory of the system, the OS can protect itself and start gobbling up the swap file. Stops it killing the app immediately. Should the app continue to gobble, the OS kills it, keeping the integrity of the system. It's intended as a stopgap convenience only - in the event you unintentionally exceed your expected memory use. Don't use disk grinding as a replacement for memory. In fact many people I know just turn off the page file in windows because the MS method of managing virtual memory seems like it was coded by a braindead troll. Windows outfitted with 2G and up will run a lot faster that way.
You have two options: buy more memory, or be more efficient in the way you use apps. If you really, seriously need to have 2 million polys(which btw isn't really all that much - I've loaded that in 2G I'm sure), and want to keeping loading flipbooks, more apps, more flipbooks…then buy more mem. You can't compare different apps - there's more to the memory usage than the number of polys. Don't forget - Houdini is a multi-use tool. You been using the compositor? Memory usage for Houdini is pretty well automatic *except* for the compositor…look in the prefs for that.
The notion of a 5G swap file has been pretty well discounted nowadays as a waste of disk space. The rule used to be to make it half your physical mem(which you're exceeding by a lot!), but nowadays they pretty well say set it to 512M. Maybe 1G, at most. Better solution is to get more mem.
Cheers,
J.C.
The reason adding more swap space isn't helping is because Houdini is running out of virtual address space, which is 2Gb on most 32bit operating systems. It's never really been introduced to users before as a limit, since it's only recently that workstations have approached that limit with real physical memory. Most people assume that installed memory equals program-addressable memory, which isn't the case. Here's a quick rundown on the difference:
Physical Memory - the amount of memory installed in your computer.
Virtual Address Space - the amount of memory given to any one process, which maps to physical memory. Some of this address space is mapped to the physical memory, and some is mapped to swap. The OS manages the mapping, and it is transparent to you and the application – until the app runs out of it.
32bit operating systems use 32bit addressing - which can theoretically map up to 4Gb of memory. However, the upper 2Gb is normally reserved for the system's use, leaving any given application with 2Gb of addressable memory. Once the process maps all its addressable memory, there is no way to refer to more memory even if you're using 5Gb of swap and 2Gb of real memory - the 32 bit address just isn't big enough to refer to it all. It's sort of like trying to store an HDR image in 24bit RGB color - it just can't represent the super-brights because it's out of the 8bit range.
The solution? Well, use a 64bit OS and 64bit hardware, capable of addressing up to 4Tb. Then a 5Gb swap file would make a difference to a single application (though it would run very, very slowly). Since it's not terribly realistic to run out and buy new hardware and reinstall an OS, there are some things you can do in Houdini to reduce memory usage:
- Open the Cache Manager and reduce some of the cache sizes (Windows->Cache Manager, Houdini 8 only)
- Set the ‘unload’ flag on some SOPs. Normally each SOP caches the last cook's geometry; setting the unload flag will stop that SOP from caching (at the expense of recooking the next time the geo is needed). In the SOP's RMB menu, select ‘Toggle Unload’).
- Write out old procedural chains of OPs to a file, and load them with a File OP, and reference the File OP instead of the chain. You can keep the old chains around in the network in case you need to rework them.
Physical Memory - the amount of memory installed in your computer.
Virtual Address Space - the amount of memory given to any one process, which maps to physical memory. Some of this address space is mapped to the physical memory, and some is mapped to swap. The OS manages the mapping, and it is transparent to you and the application – until the app runs out of it.
32bit operating systems use 32bit addressing - which can theoretically map up to 4Gb of memory. However, the upper 2Gb is normally reserved for the system's use, leaving any given application with 2Gb of addressable memory. Once the process maps all its addressable memory, there is no way to refer to more memory even if you're using 5Gb of swap and 2Gb of real memory - the 32 bit address just isn't big enough to refer to it all. It's sort of like trying to store an HDR image in 24bit RGB color - it just can't represent the super-brights because it's out of the 8bit range.
The solution? Well, use a 64bit OS and 64bit hardware, capable of addressing up to 4Tb. Then a 5Gb swap file would make a difference to a single application (though it would run very, very slowly). Since it's not terribly realistic to run out and buy new hardware and reinstall an OS, there are some things you can do in Houdini to reduce memory usage:
- Open the Cache Manager and reduce some of the cache sizes (Windows->Cache Manager, Houdini 8 only)
- Set the ‘unload’ flag on some SOPs. Normally each SOP caches the last cook's geometry; setting the unload flag will stop that SOP from caching (at the expense of recooking the next time the geo is needed). In the SOP's RMB menu, select ‘Toggle Unload’).
- Write out old procedural chains of OPs to a file, and load them with a File OP, and reference the File OP instead of the chain. You can keep the old chains around in the network in case you need to rework them.
Thanks for an enlightment.
By the way how much ram can 32 bit linux address? In Xp it is around 3.5 Gb isn't it?
JC you've just saved 4 Gb's of my precious mobile space, thanks.
And about that polycount problem…I've realized it wasn't pure geometry load issue because when I rop-file'd it and than duplicated, It easily reache over 4 million.
I'll check that driver but everything seems to be just fine, YOU installation without any problems, opengl working, driver “nvidia”.
One thing I like about linux is in a few months it made me understand my computer far better than 10 years of using windows.
cheers
Peter
By the way how much ram can 32 bit linux address? In Xp it is around 3.5 Gb isn't it?
JC you've just saved 4 Gb's of my precious mobile space, thanks
.And about that polycount problem…I've realized it wasn't pure geometry load issue because when I rop-file'd it and than duplicated, It easily reache over 4 million.
I'll check that driver but everything seems to be just fine, YOU installation without any problems, opengl working, driver “nvidia”.
One thing I like about linux is in a few months it made me understand my computer far better than 10 years of using windows.
cheers
Peter
By the way how much ram can 32 bit linux address? In Xp it is around 3.5 Gb isn't it?
As Mark inferred, it's not really a locked value - essentially it depends on what the particular kernel was compiled for. You'll get one value for XP Home, another for Windows Server. Mark's right, though, a lot of the freely availabe Linux kernels have until recently tended to be in the 2G range, while MS pro solutions tend to be around double that. There's advantages and disadvantages to making the top end really huge. However, most enterprise level OS's nowadays are way up there - we're running SUSE Enterprise 9 here and the stats on that release are stupid: up to a TB of physical mem in 64 bit, a million processes, 8 EB filesystem sizes(yes, that's *E* bytes
)..and it runs like the wind. You get what you pay for. Cheers,
J.C.
On default 32-bit WinXP, the theoretical address limit is 2 GB. With Houdini, it's effectively 1.6 GB. With the right switch, you could supposedly increase the theorectical limit to 3 GB but to my knowledge, no one has tried that with Houdini.
Interesting this conversation came up because I am actually getting ready to install suse 9.3. I am trying to decide between the 32 bit install and the 64 bit install.
Any comments?
ps. I have a quadro fx 1100, I assume that I have to take the previously mentioned precautions to run stable.
Any comments?
ps. I have a quadro fx 1100, I assume that I have to take the previously mentioned precautions to run stable.
You won't get a choice. Whatever hardware you're running determines what flavour of SUSE will install(the install program will tell you).
Assuming you mean you're going to buy a new system…64 bit is nice, but I've not noticed any fall-on-the-floor, drop dead wow advantages to it with Houdini, or mantra for that matter. I installed the debian 64 bit and those were my findings, anyway. Everything *feels* a little snappier(related to XOrg and nvidia drivers in my case), but it's not night and day. I think it's the way things are going, but it's not doubling your experience by any means.
Cheers,
J.C.
Assuming you mean you're going to buy a new system…64 bit is nice, but I've not noticed any fall-on-the-floor, drop dead wow advantages to it with Houdini, or mantra for that matter. I installed the debian 64 bit and those were my findings, anyway. Everything *feels* a little snappier(related to XOrg and nvidia drivers in my case), but it's not night and day. I think it's the way things are going, but it's not doubling your experience by any means.
Cheers,
J.C.
You won't get a choice. Whatever hardware you're running determines what flavour of SUSE will install(the install program will tell you).
So suse 9.3 doesn't let you choose which install?
Assuming you mean you're going to buy a new system.
My system is already 64 bit capable. Do you recommend doing the 64 bit install of suse then?
If it's 64 bit hardware, it wants 64 bit software. In SUSE's case, if you're using the DVD it will just put 64 stuff on there, if you're using the CDs and try to install32 bit, it comes up with “Cool machine, but you're trying to put 32 bit software on a 64 bit system”.
Don't worry, it also installs 32bit compatible libs, and Houdini and other 32 bit apps run just fine on it.
Cheers,
J.C.
Don't worry, it also installs 32bit compatible libs, and Houdini and other 32 bit apps run just fine on it.
Cheers,
J.C.
I installed the debian 64 bit
I installed the debian 64 bit and had several errors… any ideas?
houdini debian 64 bit 8.383
suse 9.3 amd64
quadro fx 1100
Installing: Side Effects License Management Tools
Creating /usr/lib/sesi
chmod 775 /usr/lib/sesi
Checking for running server… It has to be stopped before
we can install the new version
warning: saving copies of sesi* tools and licenses in BACKUP_SESI.20051008175438
Checking for existing server…
LMHOST is: linux
/usr/lib/sesi/sesictrl: error while loading shared libraries: libstdc++.so.6: cannot open shared object file:le or directory
One moment please…
starting: sesinetd License manager daemon
Starting Side Effects Houdini License Manager
One moment please…
17:55:15 10/08/05 /usr/lib/sesi/sesinetd_safe: nohup /usr/lib/sesi/sesinetd -l /var/log/sesinetd.log -D -V 2-R /var/run/sesinetd_linux.pid
17:55:15 10/08/05 /usr/lib/sesi/sesinetd_safe: sesinetd terminated
Licensing information about currently installed licenses follows:
/usr/lib/sesi/sesictrl: error while loading shared libraries: libstdc++.so.6: cannot open shared object file:le or directory
Current License Status:
/usr/lib/sesi/sesictrl: error while loading shared libraries: libstdc++.so.6: cannot open shared object file:le or directory
Please install licenses using the Houdini License Administrator
(hkey). Start hkey by first changing to the directory where
houdini is installed and then running:
source houdini_setup
hkey
License tools have now been installed.
Houdini 8.0 Installation completed.
The 64-bit debian version is compiled with gcc 3.4 where as SuSE 9.3 uses gcc 3.2
In other words…it might be some sort of library problem, but I'm not sure.
In other words…it might be some sort of library problem, but I'm not sure.
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=4612 [sidefx.com]
Look towards the end of this thread. Seemed to work OK. Be warned - if you're expecting some sort of knock-on-your-ass performance boost by going 64bit, you won't get it. You'll see some improvements when you're pushing the renderer hard. Primarily, 64 bit gets you a larger address space.
Cheers,
J.C.
Look towards the end of this thread. Seemed to work OK. Be warned - if you're expecting some sort of knock-on-your-ass performance boost by going 64bit, you won't get it. You'll see some improvements when you're pushing the renderer hard. Primarily, 64 bit gets you a larger address space.
Cheers,
J.C.
I tried using yast actions to install the gcc 4 update however yast would just open then close with nothing done. I searched for any changes and it showed that I was running 3.3.5. Any tricks to get it to work?
Try downloading the RPM and installing it with ‘rpm -i’
The rpm -i command seemed to work. However I still get
I suppose i'll have to just go the 686 route…. unless there is a way around this.
ps. what does the -i do? I did a man on the rpm command and didnt see -i.
houdini: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
I suppose i'll have to just go the 686 route…. unless there is a way around this.
ps. what does the -i do? I did a man on the rpm command and didnt see -i.
You need to put it somewhere that the system will find it. You may not want to be doing this if you're uncomfortable with it - if you make a mistake you can seriously screw up your install.(-i means install - its there in the man).
A quick solution is to copy all the files starting with “libstdc++.so.6” to the /usr/lib64 directory, ensuring first that no other files by that name live there. they are currently installed in
/usr/lib64/gcc/x86_64-suse-linux/4.0.2
Again, you may just want to pass on this. You aren't going to get powers of ten improvement on anything.
Cheers,
J.C.
A quick solution is to copy all the files starting with “libstdc++.so.6” to the /usr/lib64 directory, ensuring first that no other files by that name live there. they are currently installed in
/usr/lib64/gcc/x86_64-suse-linux/4.0.2
Again, you may just want to pass on this. You aren't going to get powers of ten improvement on anything.
Cheers,
J.C.
Yeh for now I will skip on the whole 64 bit install.
I managed to install the 686 gcc 3.2 version and got it running! It ran very well. However uppon turning off the computer and coming back to it later this day I recieved an error.
I sourced the houdini_setup_bash which inturn brings up the license manager where I try to install a non commercial license(dont know why it needs to since it already had a license keys). This is where I get the error
From there I ran hkey and found
I managed to install the 686 gcc 3.2 version and got it running! It ran very well. However uppon turning off the computer and coming back to it later this day I recieved an error.
I sourced the houdini_setup_bash which inturn brings up the license manager where I try to install a non commercial license(dont know why it needs to since it already had a license keys). This is where I get the error
error installing key :license…………blah blah
Sever linux: Unable to contact local host
ERROR: Key installation failed for linux
From there I ran hkey and found
License server host: linux
Server code: (not running)
License server version (not running)
Red The license server is not running
Red The license server may not server licenses
Red The license server does not allow this machine to read licenses