I know how it works on OSX, but thanks anyway 
When you have to select an app, the window does not allow you to open a file by right-clicking. I tried too.
I think loki expect to find a different type of executable (as I can see also on Ubuntu).
Here’s my Amazon test:
8x c3.8xlarge Instances for a total of 256 Threads, and 128 Physical Cores, each with 60GB RAM.
Costs AUD $2.05 per hour for the above, and here’s some tests I did:
A simple 250 frame benchmark (fast file transfer)
- My Quad Core i5 @ 3.2 GHz: 5sec/Frame, ~20 minutes 50 sec
- My 2 GTX 970’s: 1.5 sec/Frame, ~6 minutes 20 sec
- Loki with the above instances (128 Physical Cores) 1 minutes 31 seconds (including transfer)
Here are some screenshots:
Here’s a second test, with a file that takes a fair bit larger/longer to render:
- Quad Core i5: 5m22s/frame, 22.36 hours
- Dual 970’s: 46s/frame, 3 hours, 12 minutes
- Loki with 128 Physical Cores (256 Threads) @$2.05/hour: 48 minutes 23 seconds
Does Loki have a text based config file where you could key in the correct path?
It sounds like the current check to see if the selected file is a valid Blender executable simply doesn’t work on Mac. It would be good to add code that handles Macs differently, but since I don’t have access to a Mac that’s not really feasible.
I think the best option right now is to simply add a query with the check so that the user can override the check, e.g.:
“Loki thinks this isn’t a valid executable, use it anyway?”
Will that work? Is it enough to simply reference the .app file on a Mac?
Awesome, thanks for sharing this comparative test, and it’s fun to see Loki in action on a larger scale!
That’s a substantial speedup with the Nvidia cards for just rendering on the desktop! Do you ever hit memory limits when you’re rendering with them?
Amazon seems like a great option for setting up a render farm on an ‘as needed’ basis, and economical. The greatest appeal is the scalability: you can make it as small or as large as you need, for as short or long as needed.
So, have you prepped a ‘grunt image’ that you then roll out to as many systems as you want? I’ve only worked with instance management on Openstack, but not Amazon, but I would assume it’s quite similar in concept at least. That’s one of the beauties of cloud computing is preparing a ‘pristine’ image catered to a particular use, then using the image on as many instances as you want.
It wouldn’t be too much work to create a ‘Loki grunt’ image that includes the necessary software and configuration needed so that one simply launches as many grunt instances as you want on amazon with the ‘grunt’ image and your farm is ready to go.
I’d like to start a ‘Setups and Benchmarks’ page on the wiki, and if it’s OK with you, I’ll post your test results there.
The problem is that Loki is correct in not seeing the .app file as an executable, because it is just a container, like an archive. I haven’t tried using Loki but I assume it uses some kind of Java dialog and not OSX’s native one, which has the option to drill deeper into the .app structure and select the executable. A simple “path to executable” in the preferences might be a solution, or the File dialog might let you append the rest of the path using the keyboard eg you select “/Users/John/Applications/Blender.app” with the mouse and then type in the rest of the path to make it “/Users/John/Applications/Blender.app/Contents/MacOS/blender”.
Or Loki could detect it’s on OSX and append “/Contents/MacOS/blender” to the selection automatically.
Another workaround I just thought of might be to symlink /Contents/MacOS/blender somewhere and see if Loki lets you select the symlink.
It sounds like the problem is Java isn’t ‘Mac aware’ in the sense that it can’t drill down into .app files to actually look at what’s inside.
Your suggestion to try a sym-link is a good one! If it works, then that’s a very simple and easy workaround for Mac users. Interested to hear if you succeed with it!
Thanks for posting this! I put it on the wiki list of videos, etc.
Regarding your composites question, I’m unfortunately quite ignorant of Blender’s internals. I can only guess that there’s something in a config file somewhere, or some other external files that the composite is depending on that aren’t shipped around with the blend file even when it’s packed. That’s really a question to someone on the Blender dev team that knows what composite’s depend on, internally and externally, to succeed.
OK so despite not having any time I took a quick look and it seems both pointing loki to a symlink as well as just pasting the path (eg /Applications/Blender/blender.app/Contents/MacOS/blender) into the preferences works.
Now, if someone has some thoughts on how to scale this on amason ec3 (automatic client setup is a must IMHO) this would be much appreciated. It might replace brenda which works great but is very cumbersome to set up, not only initially but for every render.
Happy to hear it. I’ll put it up on the FAQ as an easy workaround for Mac users. jDo I assume correctly it’s similar syntax to other *nix like systems? (e.g. ‘ln -s </path/to/sourceFile> </path/to/newSymlink>’)
I agree completely; for scaling beyond more than a handful of nodes, automatic client setup is a must. That’s what I was talking about in my response to above to zeealpal.
The grunt already has the functionality to be run on just the command line, and optionally the master IP address can be passed via the command line if needed. All that’s lacking is prepping an image especially for running on Amazon instances.
I’ll certainly look into it as soon as I have time. For my own personal projects I’d love to easily and quickly push out render jobs to Loki on Amazon, and I’d wager a lot of others would also like to do the same.
Yes that’s the correct syntax. Although one doesn’t even need the symlink, just writing the path by hand instead of using the file dialog works as well. </path/to/blender.app/Contents/MacOS/blender>
Great, I’ll throw that into the FAQ as well.
@DMRadford, zeealpal, and anyone else playing around with Loki on AWS:
I just setup an AWS account tonight and started to put together a lean Loki Grunt AMI based on the stock Ubuntu server AMI. For the grunts you ran in your test, are you using an Amazon stock AMI, or a custom? I’d be interested in hearing more about your setup.
I’ve been using the Ubuntu Server AMI, I’ve found its the easiest to install/setup overall.
At least the micro instances are free to use for a year 
@DMRadford, I tried your startup script, buy I couldn’t get it working. It launches fine if I run the script manually, but it didn’t get run on instance startup 
I’m creating a custom AMI. The process is really simple and straight forward once you understand it. The process is as follows:
1)
Launch a free micro server running Ubuntu and SSH into it.
2)
Update then install needed software:
sudo apt-get update
sudo apt-get install blender
sudo apt-get install default-jre
wget [path to blender tar from blender.org]
wget [path to loki jar from SF]
Extract and simplify names
mv [long download name for loki] loki.jar
tar -xjvf [long blender tar.bz2 name]
mv [long blender folder name] Blender
Art this point if you type “ls” and hit enter, you should see loki.jar, Blender and the blender tar file.
Make startup script:
vi startup.sh
(insert text by pressing "i")
#!/bin/sh
java -jar /home/ubuntu/loki.jar /home/ubuntu/Blender/blender [your external ip address]
ESC
ZZ
Add startup script to rc.local
sudo vi /etc/rc.local
(insert text by pressing "i")
[press the down arrow until the cursor is on the line above "exit 0"]
su ubuntu /home/ubuntu/startup.sh
ESC
ZZ
Make everything executable:
sudo chmod+x loki.jar
sudo chmod +x ./Blender/blender
sudo chmod +x startup.sh
Test and create AMI
sudo /etc/init.d/rc.local start
If loki starts: Go to your ec2 dashboard, right click on the instance and choose create image.
Right now this is all off memory since I’m currently not at home but it should be pretty darn close.
-David
@zeealpal and DMRadford
Good stuff, thanks for posting. Yeah, in my first foray into the AWS world the other day, I came up with similar steps. I also used wget to grab the latest blender version, but then I hit some blender errors because of lacking deps. @DMRadford, your idea to install the blender package (just for the sake of the lib deps) and then still download the latest blender is a great idea, I’ll add that to my setup steps! I’ll try to get a basic recipe up on the wiki for others to use. Just as an aside, I also noted that multicast doesn’t seem to be supported on VPC, so that’s too bad, but not too big of a deal since the Master IP address can easily be passed on the command line now.
Eventually I’d like to setup a ready to go ‘works out of the box’ loki grunt AMI that myself and other users on Amazon AWS can use to launch as many grunt instances as they want, just supplying the IP of the Master. That would be sweet!
I’ve had some free time tonight which I put towards fixing some issues, and improving Loki. Here’s what’s new:
*Loki now handles aborted, terminated, or otherwise lost grunts properly: if a grunt was running a task and then for whatever reason stops or loses contact with the master before the task is done, then the master resets the task to ‘ready’ and hands it out again, without any intervention in the queue. This is really important for unpredictable environments, and should make Loki quite usable in settings such as AWS Spot, where instances can be shut down without notice. Sweetness!
*When grunts are signalled to quit after current task, the queue now correctly marks tasks as finished when they finish and doesn’t mistakenly assign the next task as running to the now defunct grunt.
Version was bumped to 071b. As usual, grab the latest from Sourceforge:-)
@samuraidanieru, good catch on noticing install blender then download for lacking dep issues ;). What do you mean by multicast doesn’t seem to be supported on VPC? What is multicast and what does it have to do with Loki?
I thought about making a universal AMI to put out there as well. Once you have my setup done, it is auto deploy. I can launch 20 instances and they all automatically connect without any issues or additional input. Problems to overcome and consider when it comes to Ec2 in regards to a universal AMI:
-
Feeding the IP address with a global AMI. Could this be done through “User input”? If so, is this convenient, how would this work? If nothing else, a ‘foundation’ AMI could be created where the user only has to input their IP then create their own unique AMI.
-
Automatically terminate instance after loki closes? Could be useful. On/Off option? How?
Growing wish list:
-
High priority imo
Restart jobs or reset jobs. If I’ve run multiple jobs and then realize I had some render settings wrong on the first one, it would be really nice to right click on a job and click “Resubmit” or “Copy to new job” instead of having to recreate the entire job. -
Just dreaming, but it would be awesome
I know this would be huge so it’s basically my Christmas wish you could say. Automatic file transfer is fantastic, it’s what makes ec2 even viable on any level. However this only works with the Blend file, which is exactly what it’s supposed to do. The problem with that is that image sequences and movies can’t be packed into a blend. So animated textures are totally out if you want to use ec2 (or any decentralized computers). Would there be any way to modify the auto file transfer to work with zip files? Ie something like: if file = .zip, extract first then load blend (forgive the pseudo-code). Of course this would be limited by bandwidth vs zip size, and not always viable for logistical reasons, however for many cases I think this would be a fantastic function to have available! -
Pretty important, especially for DIY farms with varied hardware.
Grunt groups. There may be times when users may have a few high powered grunts and a few low powered ones connected at all times. Instead of disconnecting all the low powered grunts for jobs that are too intensive for them, it would be really helpful to be able to dictate “Use grunt group 1 for this project” or “Use all available grunts”. This would allow users to submit different render jobs to different groups of grunts for power or ram restrictions, or to have multiple projects rendering simultaneously. -
Low priority. Would be more important if Loki had a “Client” mode for submitting jobs from PC’s other than the one running the master (Studio setups).
“Shotgun” rendering. Sometimes it’s not always desirable to have renders completed chronologically by order of submission. Related to #2, but automatically dynamic. ie: regardless of groups, if 2 projects exist, 50% of the grunts work on project1 and 50% on project2. Perhaps split by a priority setting? Would need more research on this one.
-David
To over-simplify, multicast is a bit like a directional broadcast on a network. It’s what Loki is using for auto-discovery. The master is sending out an ‘announce’ multicast packet on a given multicast address at regular intervals, and then anyone listening on that multicast address pick up the packet and know the IP of the master (i.e. the grunts). Amazon’s virtual networks for EC2 don’t seem to support multicast, so it’s good that the master IP address can be manually specified to the grunts when running on Amazon.
I’m confident passing in an IP through the user input is doable; being able to pass in config info to a launching instance in a cloud environment is standard, i just need to learn how to set it up.
I don’t see how much of a gain this functionality would give. When the user is done using the farm, simply terminate all the instances from the Amazon console; I don’t really see the need to initiate this from Loki.
I agree this would be a good feature, and should be fairly simple to implement. I’ll try to get to it soon.
Quite the wish list:-)
I don’t foresee taking time to work on the rest of these unless I see a lot of user demand, then I might be persuaded. I’m fairly pleased with the current stability and functionality of Loki now (0.7.1b) and plan on putting more of my free time now into creative projects:-) But I will try and get the whole custom AMI setup working on Amazon. If I get that working, I’ll publish the AMI so others can use it too.
But please put them up on the feature wish-list of the wiki, then others users can indicate if they want it too.
Hey DMRadford, if every node is downloading blender and Loki, don’t the data transfer fees add up? I imagine it could happen with a coupe hundred nodes. Maybe an option would be to mount an S3 location read-only where Loki and Blender reside, transfers in local aws space are free and that way one could supply addons or cache files etc.