|
Kalles Fraktaler
|
 |
« Reply #180 on: January 22, 2014, 05:04:36 PM » |
|
Dinky, I sent you a PM I made a debug version with exception handling, that display the position of the crash in a popup. I hope you please want to test it and let me know the result. http://biphome.spray.se/karl.runmo/fraktal_sft64d.zipYour screen-dump image was very informative, thanks for that. From it I can see that the progress is 100%, so all 32 threads has been started and finished their job without problem. However the status bar doesn't display the text "Done", so something is crashing the program when the render is completed. (if there is no popup displayed, the crash is happening earlier though...) That is a limited part of the program, that can to be examined further. 16 cores is in it self awesome, maybe tick-tock can be rendered in 1 second, but 32 cores and 0.5 seconds is of course better  |
|
|
|
|
Logged
|
|
|
|
|
Dinkydau
|
|
« Reply #181 on: January 22, 2014, 07:26:31 PM » |
|
Unfortunately it doesn't give any pop-ups. It crashes the same way as other versions of your program.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
Dinkydau
|
|
« Reply #183 on: January 22, 2014, 08:48:24 PM » |
|
What did you change? Keep it this way! It works, without any errors at all.
It asked for the missing ldbl64.dll file to speed up rendering, but it worked even without the file. I copied it from your previous "normal" release and it still works.
|
|
|
|
|
Logged
|
|
|
|
|
Kalles Fraktaler
|
|
« Reply #184 on: January 22, 2014, 09:53:50 PM » |
|
What did you change? Keep it this way! It works, without any errors at all.
It asked for the missing ldbl64.dll file to speed up rendering, but it worked even without the file. I copied it from your previous "normal" release and it still works.
Oh, that is super!! If you put ldbl64.dll in the same folder and restart, and then zoom deeper than e300, does it still work? I have two variants of my parallel thread class, and I changed the execution plan for the one using ordinary double. If it crash when you go past e300, I will simply change all 3 of them (double, long double, floatexp) Otherwise I don't understand this, but that would not matter much  |
|
|
|
|
Logged
|
|
|
|
|
Dinkydau
|
|
« Reply #185 on: January 22, 2014, 10:16:55 PM » |
|
It works when I load such a deep location from a file. The program still crashes every now and then. Sometimes I get the error "pos = 5", sometimes not (even when I do exactly the same things). Let's say it works "most of the times".
Tick tock renders in 1,5 seconds.
|
|
|
|
« Last Edit: January 22, 2014, 10:29:45 PM by Dinkydau »
|
Logged
|
|
|
|
|
Pauldelbrot
|
|
« Reply #186 on: January 22, 2014, 10:34:03 PM » |
|
This sounds like a race condition to me. Between the intermittency, nondeterminism, and dependence on number of physical CPUs, that seems more likely than any alternative.
|
|
|
|
|
Logged
|
|
|
|
|
Kalles Fraktaler
|
|
« Reply #187 on: January 22, 2014, 10:57:17 PM » |
|
I have put a version 2.2.5 that all depths have the simpler execution of the parallel threads (which don't affect anything else since the number of parallel task is the same as threads). "pos = 5" is the last position shown, and this is when memory is freed up. Can it be that competing threads on several physical CPUs is more sensitive? Anyway, I am glad of this progress.    Since you are used with Fractal eXtreme you are probably scrolling alot, with the mouse-wheel, without stopping the ongoing render process, and I have problems to make that total stable. Be gentle with the mouse-wheel  |
|
|
|
|
Logged
|
|
|
|
|
Dinkydau
|
|
« Reply #188 on: January 22, 2014, 11:08:09 PM » |
|
Yeah, I noticed that the program is somewhat sensitive to fast scrolling. I zoom very fast with fractal extreme. With Kalles Fraktaler that's not even possible. Instead of showing very zoomed the last rendered pixels like fractal extreme, the window becomes completely black after a few zooms.
Every time the "pos = 5" error occurs, the rendering continues normally, but then zooming further makes the program crash.
|
|
|
|
|
Logged
|
|
|
|
|
Dinkydau
|
|
« Reply #189 on: January 23, 2014, 01:45:14 AM » |
|
It doesn't even crash anymore with the latest version. You fixed everything in one day. That's some very nice work. I'm zooming to an extreme location, then I will render the most extreme zoom ever, even extremer than that one to 2^3039 and passed several minibrots.
|
|
|
|
« Last Edit: January 23, 2014, 01:48:01 AM by Dinkydau »
|
Logged
|
|
|
|
|
Kalles Fraktaler
|
|
« Reply #190 on: January 23, 2014, 05:01:54 PM » |
|
It doesn't even crash anymore with the latest version. You fixed everything in one day. That's some very nice work. I'm zooming to an extreme location, then I will render the most extreme zoom ever, even extremer than that one to 2^3039 and passed several minibrots.
I have uploaded a new version, 2.2.6, now it is possible to do ungentle scrolling with the mouse-wheel and no black intermediate images appears! I must admit it does improve the exploring experience! An extreme movie from you would be my reward and make my efforts worth it  Please note that if you pass several minibrots, you will unfortunately have a to do a lot of extra efforts to examine the frames and manually add reference to correct glitches that the automatic function fail to discover (even if I constantly improve this function for every new version...) And also, with perturbation and series approximation, all iteration values are stored in a list, 8 byte double up to e300, 16 byte long double up to e4920 and 16 byte floatexp for deeper. So I think there is a limit of maybe some 100 millions iterations, which takes some gigabyte in memory usage. |
|
|
|
|
Logged
|
|
|
|
|
Dinkydau
|
|
« Reply #191 on: January 23, 2014, 09:04:21 PM » |
|
Nice, it's getting better and better. You have created a highly efficient mandelbrot render and exploring program. Several people are using it. It automatically solves blobs, has support for ultra-extreme depths and many CPU cores. You have broken the record of the deepest zoom several times with your own software, and it's getting better by the minute. You have achieved a lot already.
|
|
|
|
|
Logged
|
|
|
|
|
Dinkydau
|
|
« Reply #192 on: January 27, 2014, 01:26:46 AM » |
|
When I use "auto solve glitches" while rendering a zoom out sequence, the center of the images jumps around. It looks like it uses the last calculated reference point to zoom out from, instead of the center of the image. Is that true? If so, why can auto solve glitches not be used in zoom out sequences? It would save a lot of time not having to do it by hand.
|
|
|
|
|
Logged
|
|
|
|
|
Kalles Fraktaler
|
|
« Reply #193 on: January 27, 2014, 08:24:57 AM » |
|
When I use "auto solve glitches" while rendering a zoom out sequence, the center of the images jumps around. It looks like it uses the last calculated reference point to zoom out from, instead of the center of the image. Is that true? If so, why can auto solve glitches not be used in zoom out sequences? It would save a lot of time not having to do it by hand.
No that is not how it should work, not at all. I think most movies are done with auto solve glitch on. Are you combining it with reuse reference? Sorry that is not possible. |
|
|
|
|
Logged
|
|
|
|
|
Dinkydau
|
|
« Reply #194 on: January 27, 2014, 02:57:39 PM » |
|
Yes, I also had reuse reference on. What is the difference between
1. reuse reference + manual solve glitches, and
2. reuse reference + auto solve glitches?
Isn't the glitch solving essentially the same, whether it's manual or automatic?
|
|
|
|
|
Logged
|
|
|
|
|
January 27, 2014, 12:08:08 PM
Dilber MC Theme by HarzeM