GPU : a Global Processing Unit
well we made some tests and its working so far.. one little problem and maybe a request for indigo: the frame size to be uploaded is sometimes very big. almost every render is >50mb. can we have some sort of delta compression for the upload? so that just the differencies will be uploaded to the master?
I can confirm thats working, I for one never thought I'd have an occasion to participate in a network rendering session ! Many thanks to Thexa and GPU developers !
Ok I'm massively editing this post because most of it was incorrect.
clients are limited to 20mn, set frame_upload_period to something that will allow the client to warm up, render, save frame buffer and upload it to server ! By the way this is limiting in practice the resolution a job can handle. With a 3k image fb was 187MB, 90mn transfer from me to master.
jobs can be queued, so after the clients where killed by time limit, they can be called in again by the next job. There is no limit to the number of clients able to connect to the master, unlike I posted b4 !
Ok that's pretty much it for now, just try and ask
edit: I think this formula can be nice for helping WIPs and so on, we can decide for apointements for massive rendering sessions, or people can shake hands in Indigo's shoutbox etc. I think it's great !
@aslocum: write a request for this if that wasn't done already !?
Ok I'm massively editing this post because most of it was incorrect.
clients are limited to 20mn, set frame_upload_period to something that will allow the client to warm up, render, save frame buffer and upload it to server ! By the way this is limiting in practice the resolution a job can handle. With a 3k image fb was 187MB, 90mn transfer from me to master.
jobs can be queued, so after the clients where killed by time limit, they can be called in again by the next job. There is no limit to the number of clients able to connect to the master, unlike I posted b4 !
Ok that's pretty much it for now, just try and ask
edit: I think this formula can be nice for helping WIPs and so on, we can decide for apointements for massive rendering sessions, or people can shake hands in Indigo's shoutbox etc. I think it's great !
@aslocum: write a request for this if that wasn't done already !?
obsolete asset
We did a few tests with the plugin, and concluded that bandwidth is the main problem.
If you have a client with a very slow internet upload speed, it will freeze the uploading of frames for a period.
A minimum speed of 64kb/s upload speed is recommended.
The plugin is not yet stable, and is meant as a prototype.
If you have a client with a very slow internet upload speed, it will freeze the uploading of frames for a period.
A minimum speed of 64kb/s upload speed is recommended.
The plugin is not yet stable, and is meant as a prototype.
This is also because Indigo master can receive only one frame at a time, each client must wait for the previous to finish it's frame upload (althought it continues rendering meanwhile).If you have a client with a very slow internet upload speed, it will freeze the uploading of frames for a period.
Thus the benefits are delayed but still they exist.
If indigo could receive simultaneous frames, main image updates with clients frames would be more frequent.
obsolete asset
-
Lord of the Rings Junkie
- Posts: 222
- Joined: Fri Feb 23, 2007 4:38 pm
AFAIK Thexa4 is in vacations now
Once they have downloaded the scene from the master, slaves don't stop computing, even when they are sending their frame buffer; in that regard I'd tend to say: "as fast as LAN rendering". But, frame buffers transfer from slaves is delayed, obviously by bandwidth/queue order.
-> computatuonally the same, but updates are delayed by transfer times. I don't see this as being very important as sooner or later all samples computed will be sent. BUT, as mentioned earlier, the master can not receive two frame buffers at a time (what I called queue order), so if there are various slow uploaders last update would be delayed by the sum of all transfer times, wich can be... noticeable at the end.
Thus, it is important to know one's uploading speed, so upload times can be set accordingly, not to have to much frame buffers pending and lost when render is killed, that would be a waste.
Sorry I should have done shorter as I'm repeating myself a bit
Once they have downloaded the scene from the master, slaves don't stop computing, even when they are sending their frame buffer; in that regard I'd tend to say: "as fast as LAN rendering". But, frame buffers transfer from slaves is delayed, obviously by bandwidth/queue order.
-> computatuonally the same, but updates are delayed by transfer times. I don't see this as being very important as sooner or later all samples computed will be sent. BUT, as mentioned earlier, the master can not receive two frame buffers at a time (what I called queue order), so if there are various slow uploaders last update would be delayed by the sum of all transfer times, wich can be... noticeable at the end.
Thus, it is important to know one's uploading speed, so upload times can be set accordingly, not to have to much frame buffers pending and lost when render is killed, that would be a waste.
Sorry I should have done shorter as I'm repeating myself a bit
obsolete asset
I'd rather have a BOINC-Project/Client... 
Well... Could some of the mentioned steps be automated somehow? I once took a small look at GPU but thought it would be more of a piece of art/individualism/proof of concept than actual useful software (only 10-15 Nodes online...), maybe that has changed over time.
Indigo doesn't need to be a master or something, just let the "slaves" render independently away and take the igi-outputs and recombine them back to an image - no master needed, only weighted averages of values.
I fear Deltas won't help much, since with noisy renders nearly every pixel would change a bit over time, however if the render gets better this could help - but since a few people would render on the same image, it won't help much to have a clear image on your computer, since this would surely be overkill + a waste of cycles - distributed rendering in indigo is about many "bad" (noisy) pictures calculated into one good one!
So how could (should?) this work:
- "Master" creates a scene and sets a desired spp value in GPU (NOT in indigo!)
- "Master" packs a scene and somehow announces it in GPU
- "Slaves" download the file (maybe via BitTorrent or something, to reduce upload limitations on the master) and start their indigo-rendering (e.g. for 20 minutes)
- "Slaves" end indigo after 20 minutes, take the resulting igi, report the spp-values back to the master and send the igi (independently of indigo, maybe with some checksums or something for better integrity)
- "Master" receives the igis + the spp values and checks if the wanted spp values are already reached
- if yes, he tells the clients that they can delete their packed scenen, if no one or more slaves get another 20 minutes to render (the master now knows ~how many spp to expect from the slaves in those 20 minutes)
- "Master" combines the various igis to the final image.
Done.
Well... Could some of the mentioned steps be automated somehow? I once took a small look at GPU but thought it would be more of a piece of art/individualism/proof of concept than actual useful software (only 10-15 Nodes online...), maybe that has changed over time.
Indigo doesn't need to be a master or something, just let the "slaves" render independently away and take the igi-outputs and recombine them back to an image - no master needed, only weighted averages of values.
I fear Deltas won't help much, since with noisy renders nearly every pixel would change a bit over time, however if the render gets better this could help - but since a few people would render on the same image, it won't help much to have a clear image on your computer, since this would surely be overkill + a waste of cycles - distributed rendering in indigo is about many "bad" (noisy) pictures calculated into one good one!
So how could (should?) this work:
- "Master" creates a scene and sets a desired spp value in GPU (NOT in indigo!)
- "Master" packs a scene and somehow announces it in GPU
- "Slaves" download the file (maybe via BitTorrent or something, to reduce upload limitations on the master) and start their indigo-rendering (e.g. for 20 minutes)
- "Slaves" end indigo after 20 minutes, take the resulting igi, report the spp-values back to the master and send the igi (independently of indigo, maybe with some checksums or something for better integrity)
- "Master" receives the igis + the spp values and checks if the wanted spp values are already reached
- if yes, he tells the clients that they can delete their packed scenen, if no one or more slaves get another 20 minutes to render (the master now knows ~how many spp to expect from the slaves in those 20 minutes)
- "Master" combines the various igis to the final image.
Done.
-
PureSpider
- Posts: 1459
- Joined: Tue Apr 08, 2008 9:37 am
- Location: Karlsruhe, BW, Germany
- Contact:
+1!Sukrim wrote:So how could (should?) this work:
- "Master" creates a scene and sets a desired spp value in GPU (NOT in indigo!)
- "Master" packs a scene and somehow announces it in GPU
- "Slaves" download the file (maybe via BitTorrent or something, to reduce upload limitations on the master) and start their indigo-rendering (e.g. for 20 minutes)
- "Slaves" end indigo after 20 minutes, take the resulting igi, report the spp-values back to the master and send the igi (independently of indigo, maybe with some checksums or something for better integrity)
- "Master" receives the igis + the spp values and checks if the wanted spp values are already reached
- if yes, he tells the clients that they can delete their packed scenen, if no one or more slaves get another 20 minutes to render (the master now knows ~how many spp to expect from the slaves in those 20 minutes)
- "Master" combines the various igis to the final image.
I could make a system like that, but it is already built into Indigo itself.
You can set a desired ssp setting in the Indigo master, and all the clients will stop calculating once that value is reached.
This is how it now works:
- "Master" creates a scene and sets a desired ssp value in Indigo.
- "Master" packs a scene.
- "Master" announces it through GPU
- "Slaves" download the packed file and start rendering it through indigo.
- "Master" receives all the frame buffers and combines it to a picture
- "Slaves stop rendering after 20 minutes, so the "Master" reannounces his scene every 20 minutes.
I could make a small program that makes the first three steps easyer, but I don't see the point in making my own distribution system.
You can set a desired ssp setting in the Indigo master, and all the clients will stop calculating once that value is reached.
This is how it now works:
- "Master" creates a scene and sets a desired ssp value in Indigo.
- "Master" packs a scene.
- "Master" announces it through GPU
- "Slaves" download the packed file and start rendering it through indigo.
- "Master" receives all the frame buffers and combines it to a picture
- "Slaves stop rendering after 20 minutes, so the "Master" reannounces his scene every 20 minutes.
I could make a small program that makes the first three steps easyer, but I don't see the point in making my own distribution system.
-
PureSpider
- Posts: 1459
- Joined: Tue Apr 08, 2008 9:37 am
- Location: Karlsruhe, BW, Germany
- Contact:
Who is online
Users browsing this forum: No registered users and 62 guests