Indigo 0.9 test 7
Nice !
Not only faster, but also better for me !
I tried to render some high res (A4 300dpi) files, and I always have a "runtime error" message and crash of indigo, sometimes during the build of the scene, usually during or at end of the warmup.
I tried it with different files and it always happens, but I should not be out of ram, since the windows monitor always showed a memory usage lower than the ram I have.
It seem to begin crashing at approx 1.6k-2k wide renders.
And perhaps it has to do with highly uv mapped scenes or huge textures files since I should remove some uv mapping and reduce some textures size to get a render pass the runtime error.
Not only faster, but also better for me !
I tried to render some high res (A4 300dpi) files, and I always have a "runtime error" message and crash of indigo, sometimes during the build of the scene, usually during or at end of the warmup.
I tried it with different files and it always happens, but I should not be out of ram, since the windows monitor always showed a memory usage lower than the ram I have.
It seem to begin crashing at approx 1.6k-2k wide renders.
And perhaps it has to do with highly uv mapped scenes or huge textures files since I should remove some uv mapping and reduce some textures size to get a render pass the runtime error.
Its still an out of RAM issue dude! Indigo crash if all your base are belong to us. Indigo doesn't like to use your swapfile, and windows isn't that generously giving RAM away (by default) so it gave Indigo some of the Swapfile cake even if there was some MB of the tasty RAM cake left...delic wrote:I tried to render some high res (A4 300dpi) files, and I always have a "runtime error" message and crash of indigo, sometimes during the build of the scene, usually during or at end of the warmup.
I tried it with different files and it always happens, but I should not be out of ram, since the windows monitor always showed a memory usage lower than the ram I have.
polygonmanufaktur.de
Linux 32bits does, but not more !
I would like to render up to 3gb ram with xp without runtime error.
I'll try with Wine on ubuntu32bits to see if goes better.
With ubuntu64 bits too, but not sure wine does handle the 64 bits build of indigo. Does it ? "EDIT" it doesn't !
and the problem seems to be the swap of XP, not the onboard memory.
I would like to render up to 3gb ram with xp without runtime error.
I'll try with Wine on ubuntu32bits to see if goes better.
With ubuntu64 bits too, but not sure wine does handle the 64 bits build of indigo. Does it ? "EDIT" it doesn't !
and the problem seems to be the swap of XP, not the onboard memory.
:O
The render speed is WRONG!!!!!! ONO, YOU FAIL!
When you resume renders Indigo is all like "omg its done 200 samples like 5 seconds after warming up" and then its all like "woah 999999999999 samples / second"
Ya know....
I haven't installed this version yet (am waiting for stable) but its on beta two and older versions and I just remembered and I think its on this one too but dunno
The render speed is WRONG!!!!!! ONO, YOU FAIL!
When you resume renders Indigo is all like "omg its done 200 samples like 5 seconds after warming up" and then its all like "woah 999999999999 samples / second"
Ya know....
I haven't installed this version yet (am waiting for stable) but its on beta two and older versions and I just remembered and I think its on this one too but dunno
- Heavily Tessellated
- Posts: 108
- Joined: Thu Aug 10, 2006 4:20 pm
- Location: Huh?
delic -
Uhm, it's got nothing to do with linux or Windows or ANY 32-bit OS, this is analogous to a plane being over-booked; regardless of it's size, there's just no more seats. Err, address space. Especially if you have a modern high-RAM gfx card. This RAM needs to be addressable along with every other hardware device, and gets precedence. Getting 3.1G usable system RAM on a 32-bit OS w/o PAE is quite impressive, actually!
Enabling the 36-bit PAE extension adds a bit to try and work around this (/PAE kernel boot flag) which will let you map like 64G of memory addresses, but no app is going to get assigned more than 2G (or /3GB), ever. Unless it's specifically coded to, using the AWE API. There's also a performance hit for doing this; you are cheating, making the CPU count those extra 4 bits on it's fingers and toes, adding a bit of overhead. Depending on the app it can be harsh, -10% or so. What sucks is that it's globally slower, not just when using said monster memory app.
Just switch. And welcome to the 64-bit Early Adopters Club.
At the present it means Windows x64, because there's no x64 wine support as you've discovered, and nik hasn't been badgered enough to release native linux builds. (in lieu of badgering, I suppose paypal donations would work.)
Uhm, it's got nothing to do with linux or Windows or ANY 32-bit OS, this is analogous to a plane being over-booked; regardless of it's size, there's just no more seats. Err, address space. Especially if you have a modern high-RAM gfx card. This RAM needs to be addressable along with every other hardware device, and gets precedence. Getting 3.1G usable system RAM on a 32-bit OS w/o PAE is quite impressive, actually!
Enabling the 36-bit PAE extension adds a bit to try and work around this (/PAE kernel boot flag) which will let you map like 64G of memory addresses, but no app is going to get assigned more than 2G (or /3GB), ever. Unless it's specifically coded to, using the AWE API. There's also a performance hit for doing this; you are cheating, making the CPU count those extra 4 bits on it's fingers and toes, adding a bit of overhead. Depending on the app it can be harsh, -10% or so. What sucks is that it's globally slower, not just when using said monster memory app.
Just switch. And welcome to the 64-bit Early Adopters Club.
At the present it means Windows x64, because there's no x64 wine support as you've discovered, and nik hasn't been badgered enough to release native linux builds. (in lieu of badgering, I suppose paypal donations would work.)
>just switch
Well hold on there some of us are using 32bit for commercial reasons
I havent heard before of any significant performance hit using the 3gb switch - and besides its the memory space we want to get the job done.
With the 3gb switch you actually only get about 2.6 gb to use but hey thats a whole extra gb.
Rather than volunteering everyone to use 64 bit how about you give the 32bit users a break and let us have the switch if we need it
I have a 3gb switch set in my boot file for running Solidworks and an optimised Blender build if projects require it and if Indigo could run it as well I would be very happy indeed however I can make 'includes' so I can get around it to some extent
Well hold on there some of us are using 32bit for commercial reasons
I havent heard before of any significant performance hit using the 3gb switch - and besides its the memory space we want to get the job done.
With the 3gb switch you actually only get about 2.6 gb to use but hey thats a whole extra gb.
Rather than volunteering everyone to use 64 bit how about you give the 32bit users a break and let us have the switch if we need it
I have a 3gb switch set in my boot file for running Solidworks and an optimised Blender build if projects require it and if Indigo could run it as well I would be very happy indeed however I can make 'includes' so I can get around it to some extent
Who is online
Users browsing this forum: DotBot [Bot] and 42 guests