Posts by Janus

1) Message boards : Comments and discussion : 3468 (Message 15493)
Posted 1 day ago by Profile Janus
Post:
Yes, you are perfectly right, stitching of this session has been manually stopped. Normally it happens as part of the last workunit to return to the server but in this case it will take quite some time before we can proceed.
2) Message boards : Comments and discussion : 3464 (Message 15491)
Posted 1 day ago by Profile Janus
Post:
Updated the guide, thanks!
3) Message boards : Comments and discussion : 3468 (Message 15490)
Posted 1 day ago by Profile Janus
Post:
Streaming the images in a tile-based fashion is actually the way we do it normally for this exact reason.

OpenEXR and OpenEXR multilayer support is still a bit experimental since it relies on a 3rd party piece of software to load and manipulate the files rather than the native support we have for PNG. Unfortunately it has to load an entire colour layer at once in order to allow us to inspect it - at least for now - and that just takes up a whole lot of memory.

There's something wrong with how our current code disposes of the colour layers once they have been used, there is some memory that does not get released immediately. It is not a memory leak as such, but rather a question of needing to get rid of the previous layer before loading the next.
The stitcher definitely has the same issue.

Will have to dig a bit deeper.

I feel kinda bad with my scene causing so much trouble


No need to!

This is an interesting test since the validator system is currently being rewritten to better handle Cycles (and similar physical-based renderers with noisy results) and it would be nice to be able to handle large frames too - even when they are EXR.

Fun fact of the day: If you allocate enough RAM then "top", the Linux task manager, will show resource allocation in terrabytes... never seen that before.
4) Message boards : Comments and discussion : 3468 (Message 15485)
Posted 3 days ago by Profile Janus
Post:
Yeah this one is definitely a bit of a mouthful, each part is using almost 12GB of RAM while being checked. Previously we have been running multiple validators simultaneously but in this case that is a really bad idea because the server simply runs out of memory.

It is probably going to be even worse when it has to stitch it all together.

Switching the session to "best effort" mode which means some results will be marked "invalid" now but they will be fixed and credited later.

I'll have another look at this tomorrow evening.
5) Message boards : Number crunching : I want to be part of this project (Message 15477)
Posted 4 days ago by Profile Janus
Post:
That commandline looks a bit odd - did it get eaten by the forum? (also doesn't BOINC already add the threadcount to the commandline automatically with the current plan class?)

If you post a link to a completed result you can check towards the very top how many cores it was launched with. Check the number following the small "-t" parameter. That is the thread-count (in this case 32):
Executing blender.exe -noaudio --factory-startup -y -b in -P clirender.py -- -F PNG -T 16 -t 32 -f 18 0.0 0.0 1.0 1.0


Just assuming that you want to set this specifically for one app, otherwise it is much easier to set the overall CPU limit for BOINC.
6) Message boards : Comments and discussion : 3464 (Message 15476)
Posted 4 days ago by Profile Janus
Post:
Ah yes, right now EXR is only available on request (through the description).

Since we don't have anything else rendering right now I've re-queued it as EXR over here: #3468
7) Message boards : Comments and discussion : 3465 (Message 15473)
Posted 7 days ago by Profile Janus
Post:
There still seems to be an issue with the splitter being off by 1 pixel in the vertical axis when rendering with high splits. The image will unfortunately be missing 2 rows of pixels.
8) Message boards : Number crunching : What happens with site ? (Message 15472)
Posted 7 days ago by Profile Janus
Post:
The server backend crashed this morning due to running out of memory. This may be related to the very large image currently getting rendered.

The backend has been restarted and we're keeping an eye on the stitching process that caused the issue.

Fortunately BOINC keeps a small cache of work available even when the backend is down, so the rendering has not been slowed down much.
9) Message boards : Comments and discussion : 3462 (Message 15466)
Posted 25 days ago by Profile Janus
Post:
A number of issues with this session:
- Resolution selected in upload wizard not configured to the resolution in the scene. Corrected to the one used in the scene
- Splitframe rendering selected for something that only takes 1 second to render, reset to 1 (full frame rendering). Splitframe rendering is mostly used to split frames that are very heavy to render (multiple hours).
- It only takes 1 second to render these frames and hence you really should consider rendering them locally on your own machine rather than sending them to an online renderfarm - there is a lot of overhead in startup up for renders like this.

You have pretty much had these same three comments on each of your past 5 sessions (or so), is the feedback not clear enough?
10) Message boards : Problems and Help : Sorry, I leave this project !! (Message 15456)
Posted 13 Aug 2018 by Profile Janus
Post:
There's already another thread about that
11) Message boards : Problems and Help : Sorry, I leave this project !! (Message 15453)
Posted 13 Aug 2018 by Profile Janus
Post:
For the same host, same running time, credits vary from 1 to 3.

Oh it can be much much worse than that. Check out some of the graphs from the Payday announcement thread.
12) Message boards : Number crunching : Tasks are not MT (Message 15452)
Posted 13 Aug 2018 by Profile Janus
Post:
Looks like the new plan class may have been missing a flag specifically required to instruct BOINC to pass the number of threads. Really weird that it has been working somewhat for some people and not others.

I've tried cancelling the WU I had that was stuck at 1. The new one I got from the server correctly launched as a proper multithreaded unit. It may be fixed, maybe not, since it seemed a bit random. How does it look at your end?
I don't know if all downloaded WUs are stuck, so I just cancelled everything on my client to get a fresh WU.

You can check very quickly if it launched correctly or not by opening the file "stderr.txt" in the slot directory. If it has "--nthreads detected with value" (and a number) among the first 20 lines or so then it works properly, otherwise it is stuck at 1-thread.
13) Message boards : Number crunching : Estimated runtime, credits,......... (Message 15450)
Posted 13 Aug 2018 by Profile Janus
Post:
Still no any answer from Admin !!!
Nothing !!!


Well, mmonnin is correct. There is not much more to add.

CreditNew is very unreliable for WUs without an estimated GFlop workload. We sometimes run a corrective credit algorithm that brings the variance down considerably.

Two things in the pipeline to change the credit situation:
1) Run Payday more often. Currently it is mostly run when the DB is being purged for big upgrades. It would be nice to be able to run it almost immediately after a session completes, or even replace CreditNew with Payday entirely but it is difficult to do that.
2) Provide a wild guess for runtime estimation up front. This has the to potential to make things better but could also make them way worse.
14) Message boards : Number crunching : Tasks are not MT (Message 15449)
Posted 13 Aug 2018 by Profile Janus
Post:
Really having a hard time nailing this issue but was finally able to reproduce it locally today.

BOINC clearly states that the WU is multithreaded but does not pass the number of threads that the WU should be started with (this differs from client to client depending on settings) to Glue3. Glue3 defaults to 1 thread and passes 1 thread to Blender.
15) Message boards : Comments and discussion : 3456 (Message 15445)
Posted 11 Aug 2018 by Profile Janus
Post:
This renders very quickly (around 0.5 secs per frame), maybe consider rendering this kind of animation locally on your own computer to avoid the delay of submitting it to a renderfarm?
There is a lot of overhead involved both in the review process as well as when sending out the workunits to the computers of the participants who donate resources to the renderfarm. All in all it ends up taking a lot longer than 0.5 seconds.
16) Message boards : Comments and discussion : 3453 (Message 15444)
Posted 11 Aug 2018 by Profile Janus
Post:
This session contains a particle physics simulation but the simulation data was not included in the .blend-file. Unfortunately Blender stores the fluid data on the local machine.

It also renders really fast, maybe you should render this locally instead?

The session was rejected
17) Message boards : Comments and discussion : 3455 (Message 15443)
Posted 11 Aug 2018 by Profile Janus
Post:
This session contains a particle physics simulation but the simulation data was not included in the .blend-file. Unfortunately Blender stores the fluid data on the local machine.

Also it completes almost instantaneously - maybe not the best fit for rendering on a renderfarm?

The session was rejected.
18) Message boards : Comments and discussion : 3442 (Message 15442)
Posted 11 Aug 2018 by Profile Janus
Post:
Check out the results over at #3450, seems to look ok with the new clients that skip unpacking for Cycles sessions.

I just now re-assigned the duplicate session to your user, forgot to do that when it was created as a test.
19) Message boards : Comments and discussion : 3452 (Message 15440)
Posted 3 Aug 2018 by Profile Janus
Post:
This session contains a physics simulation but the simulation data was not included in the .blend-file. Unfortunately Blender stores the fluid data on the local machine.

We're looking to support fluid simulation on the renderfarm but so far it is an unsupported feature unless the fluid data is baked, exported and then included in the .blend-file.

The session was rejected.
20) Message boards : Comments and discussion : 3450 (Message 15438)
Posted 31 Jul 2018 by Profile Janus
Post:
The OpenCL test WU that was sent out for this session didn't seem to succeed at all. No reply was received from any of the machines that received it.
It will take a little while longer for the WUs to time out and hopefully, by then, some logs will show what the problem is.

Unfortunately I don't personally have modern enough OpenCL hardware available for testing yet.


Next 20