blender 2.42 with 4 threads instead of 2

does anyone know if there is a 2.42 build with 4 thread capability or does anyone know of anybody that could edit the source and send me a build?

I’d be extremely psyched for this as well. Unfortunately I have nothing to offer except good karma and cash. Ooops out of cash! kidding. if this is would be a big project I would definitely donate to a good coder.

I’m not a developer, but I thought that part of the new render pipeline for 2.42 automatically used all available CPUs, so you shouldn’t need a special version for this. Just increase the XParts & YParts in the render options, and make sure the “threads” button is pushed.

http://bebop.cns.ualberta.ca/~cwant/multi-render.html

Looks like I’ll have to dive into the source. I have a SGI Origin 2000 I’d love to run blender on. Some day…16 300Mhz processors…yeah!

How do I open and edit a source file with a windows pre-compiled install? is it even possible? I am a total programming newbian

about x/y parts - does that render the image into separate files I have to stitch together and how many parts should I split it into for a quad CPU?

[quote=F/StopDigital]How do I open and edit a source file with a windows pre-compiled install? is it even possible? I am a total programming newbian

Not possible. If you want the source, you have to download it.
http://www.blender.org/cms/Source_Code.12.0.html

[quote]about x/y parts - does that render the image into separate files I have to stitch together and how many parts should I split it into for a quad CPU?
Basically, It breaks the image up into rectangles, like a checkerboard, and hands a tile to a CPU. When the CPU finishes rendering one tile, Blender hands it another one until they’re all done. If you have X/Y Parts turned up, you can see this tiles being filled in one at a time while you watch it render. It all comes together as one render, as normal.

From the release notes:

For an efficient and memory-friendly rendering, the “Render Result” is subdivided into a number of tiles, which get each rendered fully in its own thread. Not only does it allow more efficient use of threaded render - since all rendering now happens in a thread - the system is also ready now to allow more threads than just two (unlimited, in theory… but some render code for it has to be fixed still).

The pipeline default first allocates all memory for the final RenderResult of rendering, to which the result of each tile gets copied. The new option “Save Buffers” will write all tiles to disk first - using the OpenEXR format - and when rendering is finished Blender reads back that file, which can save quite some memory when many render-layers are used.

Set the desired amount of tiles with the “Xparts” and “Yparts” buttons in the Render buttons. Note that using more tiles will generate overhead and slower rendering, a typical optimum is somewhere between 16 and 64 tiles per image.

just to clarify… 16 tiles = X/YParts are both set at 4. 64 = 8x8, obviously.
Having this too high will slow down your render. Having it too low will increase the RAM usage. Just find any ol’ scene and do some tests.

kidb: that sort of helps me but I need someone to compile it and change that number, since at the moment I have nothing to compile it with and I’m on dial-up so I don’t have the time to download the source and edit it.

My system rendered the example .blend in 3:38.41 with two threads (dual xeon 3.02 ghz, 1GB RAM, Win2k - standard 2.42) and 2:59.55 w/ two threads using the 2.42 SSE2-optimized build. I beat out Blarg’s Debian setup that has better specs!:slight_smile:

I agree with TML - could anybody compile a four-thread WinXP SSE2 version for us lazy slackers? I don’t know the first thing about what I’d need to do that and I’d sure like to test those benchmarks.

I think I have found a way to use my processors to the full.
when I turn threads on and set x parts and y parts to 2 it renders the quickest for me and shows 100% or close to that of cpu usage.

My comp is pretty slow and in 2.41 my scene was too detailed and had too many particles so my computer couldn’t handle it. But if I divide the render in maybe 32 threads do you think it would be possible for me to render it?

Now that’s interesting. On my MacBook Pro (2x 2.0 GHz, 2GB) with the official OSX-Intel-Build of 2.42 it took 2:31 to render that file with threads enabled. :eek: It means this Laptop is faster than your Dual Xeon. :eek: This post is not meant to be bragging it’s just the amazement of how technology improves.

Stephan

I messed up on my x and y parts earlier on.
I meant for it to say x parts 2 and y parts 1

1:06 for that with four threads (extrapolated from a dual-thread time of 2:10) and I forgot firefox and photoshop were running in the background. I’m faster than “nihon”!
oddly tml I got the best times with xpart = 2, y part =4
AMD FTW!

now - anyone know how to set/code multithreading for fluid or physics sims?