END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

First of all, let me say what an impressive piece of software Mandelbulber v2 is becoming, and thank you to everyone who's been working on it.

I've been taking a bit of a break, but it looks like I chose the right time to get back into some fractals. The limited OpenCL support in the latest alpha is already producing some extremely impressive results on my machine. (I've finally managed to get around to having a proper explore of Spudsville. Still got lost though  ).

Anyway, I'm happy to report that the OpenCL seems to be working perfectly well on my machine (Windows 10 64bit, GTX 780) as far as Mandelbulber goes, but I'm still running into a problem I had with the previous version (mentioned here). It seems that Windows itself has a time-out for GPU operations, and if part of a render takes too long, it crashes Mandelbulber with a message saying something like "Could not clear OpenCL queue". That's just from memory, I'll have to recreate the crash to get the exact text of the message which does need a very busy scene, or even just some small corner of a scene that's very busy.

In some other renderers, specifically ones that use render buckets rather than scanlines (like the OpenCL renderer), I've seen an option to change the size of the render bucket, usually just multiples of two - (16x16, 32x32, 64x64 etcetera). I'm wondering if something like that could help here. If I could render a scene in smaller buckets, it seems likely that Windows might time-out less often.

Would implementing a render bucket size control for OpenCL be a relatively trivial task, or would it be horribly complicated?

Hi mclarekin, and thanks for the reply.

You've successfully changed the Windows time-outs? I can't seem to find it now, but I'm sure I read a post in the Fragmentarium forum that said this was a bad idea for reasons I can't remember.

I did find this from Syntopia though:


But if you say you've changed the registry without issue, then I can certainly look into this. Thanks for the advice.

I did try reducing the memory available to OpenCL, and that seemed the help in the old versions, but doesn't seem to make a difference here.

Also, I managed to recreate the crash. The exact text of the error is "Error: Cannot enqueue reading OpenCL output buffers". (If I then ask it to render again, it gives me that message followed by "Error: OpenCL command queue cannot be created!").

Anyway, sorry, I feel like I'm moaning when in fact I'm really impressed by what you guys have achieved here, not to mention grateful.

Aha! That looks like it's just what I need actually.

Thanks very much. I'll have a good read of that.  



Edit:

Hi mclarekin. That seems to have done it. Thanks very much for the link.
I've set both the TdrDelay and TdrDdiDelay keys to thirty seconds as the article advises, rebooted, and now the problem frames I had seem to be rendering just fine.

I also read something about how not using the GPU for displaying the Windows desktop doesn't cause the timeout to happen at all. Maybe I'll look into using my onboard video for the display when rendering overnight.

Anyway, thanks again for the advice. Much appreciated.

Ahh perfect. Thanks zebastian.

Oh and good call on adding "as decimal" to the values. That gave me pause when I set the registry keys.