 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"hi,
Mirfaelltkeinerein" <nomail@nomail> wrote:
> "jr" <cre### [at] gmail com> wrote:
> > are you sure about the resolution being the .. culprit? at least one user
> > renders (much) larger images with no mention of ill-effects.
> > <http://news.povray.org/web.5ceaeabd5e75640e3c1c78400%40news.povray.org>
>
> No, not at all. But the problem manifested itself at higher resolutions and
> vanishes at lower ones.
having read the other replies, I now wonder, what if you'd installed a GNU/Linux
distro on a virtual machine, and build and run POV-Ray on that. could be
instructive.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 10/02/2020 à 20:15, Mirfaelltkeinerein a écrit :
> "jr" <cre### [at] gmailcom> wrote:
>> hi,
>>
>
>>
>> are you sure about the resolution being the .. culprit? at least one user
>> renders (much) larger images with no mention of ill-effects.
>> <http://news.povray.org/web.5ceaeabd5e75640e3c1c78400%40news.povray.org>
>>
>>
>> regards, jr.
>
> No, not at all. But the problem manifested itself at higher resolutions and
> vanishes at lower ones.
>
The bottleneck is a single thread doing all the I/O for the temporary
storage on disk of the rendrered pixels until the whole image is ready.
You have a hord of threads doing the computation of each block, feeding
a queue that is processed by a single thread T.
When the resolution is small enough (see my other reply), T stores the
blocks in memory (usually fast enough).
BUT when the resolution is bigger than the setting, thread T must
perform disk I/O (and from the file point of view, it is really random
access, and can be very bad with Windows file system). As T is
overburden, the rendering threads are starving to get new blocks
(otherwise, the queue from them to T would explode).
try adding +MI3210 to the option and see per yourself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Sounds a lot like this:
>
>
http://news.povray.org/povray.windows/thread/%3Cweb.56edd77df9a19c455e7df57c0%40news.povray.org%3E/
>
That was the point!
Not rendering slowed down quite a bit, but image composition. Rendering was
finished and all which had to be done was putting all together. With a more
complicated scene or larger tiles (I used 8x8 tiles before, now 32x32 or 64x64)
it's no problem at all any more.
Thank you for pointing me to the solution and thank you all for the tips and
links to v3.8 and the AMD patch.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2020-02-11 à 09:31, Mirfaelltkeinerein a écrit :
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> Sounds a lot like this:
>>
>>
http://news.povray.org/povray.windows/thread/%3Cweb.56edd77df9a19c455e7df57c0%40news.povray.org%3E/
>>
>
>
> That was the point!
> Not rendering slowed down quite a bit, but image composition. Rendering was
> finished and all which had to be done was putting all together. With a more
> complicated scene or larger tiles (I used 8x8 tiles before, now 32x32 or 64x64)
> it's no problem at all any more.
> Thank you for pointing me to the solution and thank you all for the tips and
> links to v3.8 and the AMD patch.
>
>
>
>
You used +rb8 on that massive server ? OUCH !
It's no wonder that it tended to bog down.
Yes, using the default 32x32 should improve things.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
