Title: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on December 15, 2014, 11:54:39 AM EDIT: http://mightymandel.mathr.co.uk
Today I updated my toy (no glitch correction) perturbation-technique OpenGL 4 Mandelbrot set renderer with a command line flag to disable distance estimation - this makes rendering take about 2/3 the time, and uses a bit less GPU memory. Doesn't look as good though: DE: (http://mathr.co.uk/mandelbrot/2014-12-15_mightymandel_de.png) no DE: (http://mathr.co.uk/mandelbrot/2014-12-15_mightymandel_no-de.png) Source code repository: http://code.mathr.co.uk/mightymandel Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on December 15, 2014, 12:41:42 PM I just added .kfr parser to mightymandel - already supported .sft, .mdz, .mm (native format, copy/pasted from console output). Each non-flag argument is tried with all the parsers, the first argument to succeed is loaded.
Distance estimation fails to render sometimes beyond a certain depth (still debugging since years, not sure where the overflow or other fubar is..), this took 75s to render: (http://mathr.co.uk/mandelbrot/2014-12-15_mightymandel_cross_hair_de_buggy.png) The -no-de flag gives a better image in these cases, this took 50s to render: (http://mathr.co.uk/mandelbrot/2014-12-15_mightymandel_cross_hair_no-de.png) The original version of this view I rendered with Kalles Fraktaler still looks better (but I didn't keep track of how long it took to render, probably several minutes with the supersampling and glitch correction): http://www.fractalforums.com/kalles-fraktaler-gallery/cross-hair/ Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on December 20, 2014, 10:02:21 PM mightymandel now ported from gtk2 to glfw3, which should make it easier to compile. There was a massive performance regression but I fixed that now, at the cost of slightly lower responsiveness in the GUI.
Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on December 21, 2014, 10:09:23 AM http://mathr.co.uk/blog/2014-12-21_mightymandel_updates_galore.html
Automatic glitch correction, zoom sequence rendering, tiled rendering for high resolution or anti-aliasing, ... Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on December 24, 2014, 06:20:12 PM http://mathr.co.uk/blog/2014-12-24_mightymandel_v14.html
Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: youhn on December 24, 2014, 08:24:48 PM I've been trying to get all packages and libs to build mightymandel. The process for GLFW3 felt a little awkward to me. Now I get errors which I can't solve:
Code: LINK mightymandel Any pointers for a fix? Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on December 24, 2014, 08:55:18 PM Adam Majewski had the same problem with staticly linked glfw3 on Ubuntu 13.04 (I think I got that version correct).
He wrote about it here: http://en.wikibooks.org/wiki/Fractals/mightymandel#glfw try: Code: make -C src EXTRA_LINK_FLAGS="-lGL -lGLU -lglfw3 -lX11 -lXxf86vm -lXrandr -lpthread -lXi" or if that doesn't work, edit the Makefile to add those -l flags (for missing libraries). Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: youhn on December 25, 2014, 12:08:16 PM Ok, think that error was solved. One step further, but not there yet:
Code: LINK mightymandel I've googled on libm.so.6 and found that this is part of the glibc packge. Currently installed on my Slackware system is "glibc-2.15_multilib-x86_64-8alien" . Do I need a newer version than 2.15 ... ? Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: quaz0r on December 25, 2014, 05:10:23 PM is "-lm" not in your linker flags?
Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: youhn on December 25, 2014, 07:00:41 PM Yes, "-lm" was not in my linker flags. But adding it gives yet another error:
Code: LINK mightymandel Now I suspect problems with the wrong version of Xorg ... ? Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: quaz0r on December 25, 2014, 09:22:34 PM you can usually guess/google what library you might need to link to when you dont have the right linker flags to start with. for instance, looking at /usr/lib/libX* on my system i see a libXxf86vm.so, so for undefined references to xf86vidmode something or other i would probably try adding -lXxf86vm
*shrug* Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on December 25, 2014, 11:12:31 PM is "-lm" not in your linker flags? I should definitely add -lm to the Makefile. But for the other stuff, this is the kind of thing pkg-config (and at a lower level, shared libraries with ldd for .so) was designed to solve, maybe there's a way to get it working with static libglfw3.a so you don't have to hunt down dependencies manually, or alternatively making a shared libglfw3.so might work. Maybe if enough people bug glfw3 they'll fix it for people compiling from source - I don't have this issue thanks to Debian packages being available, so I don't have a huge amount of motivation to find a solution that works everywhere (but if there is one, I'll gladly make it work in mightymandel by default)... Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: youhn on December 26, 2014, 12:42:41 AM Yay! ;D Don't ask me what exactly changed since the previous non-working try ... but it has been compiled now!
(http://i.imgur.com/QbuQKYQ.jpg) First had to upgrade my nvidia drivers to get opengl working, but now the program is running. Navigating through not-so-deep location works great, but further down I notice a lag. While the new location is calculated, the program appears to do nothing. It would be nice to have to kind of visual indication of the progress (showing pixels as they are calculated, perhaps even some low-res pre-renders, or a plain old progress bar). Maybe this won't be an issue when I go out and buy a new GPU card (currently using a Asus GeForce GT 610 ...) In some situations the program can't handle the glitches and says "failed to find reference". I can reproduce this error by first zooming into sparse areas, then some zooms down to a mini, and finally pointing at "empty" space somewhere around the center. A bit for navigation, but more for the renders, I would like to have a rotate function and a adjustable zoom-box. This way we can shoot places to render in the virtual fractal world, just as a photographer would do with the real world. Claude, thank you very much for sharing this new toy! Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: PieMan597 on December 26, 2014, 12:54:22 AM I will definately have to try this out when I get back from vacation... (and get a new computer)
Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: 3dickulus on December 26, 2014, 01:15:17 AM all I had to do (after sorting out pkg deps) was adjust the libs...
-lX11 -lXi -lXrandr -lXxf86vm -lpthread -lGLEW -lGL -lrt -lmpfr -lm -lglfw3 compiles and runs great! thanks "Santa" claude :banana: :chilli: :banana: :chilli: :banana: for the coolest gift, your time ;) Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on December 26, 2014, 03:04:44 AM Yay! ;D Don't ask me what exactly changed since the previous non-working try ... but it has been compiled now! Awesome! Nice image too :) Quote First had to upgrade my nvidia drivers to get opengl working, but now the program is running. Navigating through not-so-deep location works great, but further down I notice a lag. While the new location is calculated, the program appears to do nothing. It would be nice to have to kind of visual indication of the progress (showing pixels as they are calculated, perhaps even some low-res pre-renders, or a plain old progress bar). The lack of progress indication is a bit annoying indeed, but it's related to the way mightymandel works. It doesn't have a fixed iteration limit, so it just keeps going (iterating all the pixels in parallel) until at least 1 pixel escaped, and the rate of escapes is low. This means that it'll never finish if the whole view is interior, though I do have some ideas how to check that before starting the render. Here's the details of how it decides it is finished: http://code.mathr.co.uk/mightymandel/blob/cc2e0f9ed93e3d48adb86872638fba18c43f4e73:/src/render.c#l148 and if you notice line 163 there's a (currently disabled) printout of various statistics - problem is there is no rate limiting so it's quite a flood that slows down the rendering. I plan to fix the rate limiting issue soon - probably by making the new (unreleased so far) --verbose debug option print everything and the --verbose info option (default log level) print a summary every second or so if it changed). In the current version I have on my laptop (away for xmas), I refactored a lot of stuff (mostly boring internals, but once I've got this awkward stuff finished I should be able to work on all the fun parts more productively, and maybe other people will be able to understand wtf is going on too - too much shared mutable global state and undocumented invariants at the moment. Reluctant to even push it to gitorious because I have no way of telling if I broke FP64 rendering or so... Quote Maybe this won't be an issue when I go out and buy a new GPU card (currently using a Asus GeForce GT 610 ...) I'm developing on a Geforce G550Ti (except right now I'm on a laptop with G105M, so I can't test much), so yours should be faster than mine already! Quote In some situations the program can't handle the glitches and says "failed to find reference". I can reproduce this error by first zooming into sparse areas, then some zooms down to a mini, and finally pointing at "empty" space somewhere around the center. Yes Adam already sent me a test case location, it's really annoying. The glitch correction is pretty abysmal at the moment, that's my main priority to fix once I get the code into a normal program style (main loop) instead of callback hell. Quote A bit for navigation, but more for the renders, I would like to have a rotate function and a adjustable zoom-box. This way we can shoot places to render in the virtual fractal world, just as a photographer would do with the real world. Weirdly there is an 'angle' defined somewhere in the code, I think I started implementing it and never finished, or it bitrotted, so I don't think it does anything, and it's not exposed via any user interface. This was mainly intended for rendering series of related minibrots, scaled and rotated so that all the minibrots match up but the hairs are all different. (http://mathr.co.uk/blog/2011-12-06_gruff_spiral_switch_1-3.gif) I did something similar with aligning embedded Julia sets in this video: https://archive.org/details/hairy_julias_2013-06-18 Quote Claude, thank you very much for sharing this new toy! You're welcome! Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: Botond Kósa on December 26, 2014, 04:39:22 PM Nice! Can we expect a compiled executable for all the ones who just want to try it out without going through the adventures of compiling?
Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on December 26, 2014, 05:26:22 PM Nice! Can we expect a compiled executable for all the ones who just want to try it out without going through the adventures of compiling? I can't provide one, it would in anycase be somewhat useless because all Linux distributions have somewhat different sets of libraries and versions, so it wouldn't work. I could provide a Debian binary, but compiling on Debian is really easy as the dependencies are all packaged already, so there isn't much point. Maybe someone on other systems can provide binaries for those, but I'd also say it's a bit soon - development is quite rapid at the moment, so the binary would probably be out of date in a week. I might eventually try and cross-compile one for windows 32bit sometime, just for the learning adventure of it. I'll post when I've got a binary. Probably won't be the next released version (it's likely to have some bugs after my heavy refactoring), but maybe the one after once all the bugs are ironed out. Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on December 31, 2014, 09:24:36 PM v14-164-g9cd6fc7 (current git master) fixes a bad bug:
http://code.mathr.co.uk/mightymandel/commitdiff/50c0de1f6f8da8a6caf9fa036f084463c4a49cbe if you're in the mood to experiment tonight then ignore the bit in the README about getting a stable tag. otherwise... v15 is very nearly ready, barring major problems it should be tomorrow (just need to write the changelog since v14, which will be massive). Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 01, 2015, 11:56:46 PM mightymandel v15 released! http://mathr.co.uk/blog/2015-01-01_mightymandel_v15.html
Here's a short video with the new improved zoom assembler, much less blurry/grainy than before: http://mathr.co.uk/mandelbrot/2015-01-01_mightymandel_zoom_assembler_improved.ogv (5MB) Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: 3dickulus on January 02, 2015, 12:58:49 AM SuSE Linux
Code: LINK mightymandel changed Makefile @ line 19 from... Code: LINK_FLAGS := \ Code: LINK_FLAGS := \ ...compiles and runs great! Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 02, 2015, 03:52:13 PM changed Makefile @ line 19 It works without the additions here, but adding it doesn't break anything for me either, so I committed it: http://code.mathr.co.uk/mightymandel/commitdiff/fd6e22468defdc3e2c1d8122f0025880acb9c408 Quote ...compiles and runs great! :) Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 04, 2015, 09:45:36 PM mightymandel now has its own home page:
http://mathr.co.uk/mightymandel/ updating it is slightly awkward for me, so it may lag behind the git master changes. some changes in git (apart from documentation stuff and the things already mentioned): User interface improvements: new parser for pre-processed FractInt .ppar center-mag variant new parser for FractInt .gif embedded metadata new parser for PNG converted from PPM with mightymandel embedded metadata --interactive mode waits for events instead of polling when rendering is finished, to reduce idle CPU load Rendering speed improvements: interior checking for period 1 cardioid and period 2 circle (fp32 and fp64) increased the default number of iterations performed in each GPU pass increasing the iterations per pass might cause problems on older GPU (mainly laggy system response during rendering, or even a driver crash), if you have problems related to that (or anything else) please do tell me! Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 05, 2015, 03:22:52 AM Nice! Can we expect a compiled executable for all the ones who just want to try it out without going through the adventures of compiling? Here's one cross-compiled for 32bit Windows, just because I wondered if it was possible. Seems to work in WINE, but I've got no Windows to test with. http://mathr.co.uk/mandelbrot/mightymandel-v15-65-g58e77b3.zip Documentation (includes build process and some known bugs): http://code.mathr.co.uk/mightymandel/blob/58e77b3e18ae32e1cbcc52a32dfd647f84da9a2b:/WINDOWS.md Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 05, 2015, 06:34:13 AM Just finished a 3-day render, and found a bug :(
--no-de colouring (and probably the glitch masking too, but that's not so relevant) gives seams at tile boundaries - they're subtle in static images but if there is an even number of tiles, the seam(s) through the center will be static in a zoom video and much more visible. The solution is relatively simple, save the raw iteration data and only colour it once it has been combined into a full image, instead of colouring tiles separately. Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: knighty on January 05, 2015, 02:10:57 PM The win32 version works fine here. Thank you.
Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: cKleinhuis on January 05, 2015, 02:32:56 PM the rendering method is nice, buuuuuuuuuuuuuuuuuuuuuuuuuut i was expecting a pertubation gpu method, and after a few clicks the images takes already 2secs to render ;) i have a i7 3,2 ghz and a radeon 7970 gpu :/
Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 05, 2015, 02:51:27 PM the rendering method is nice, buuuuuuuuuuuuuuuuuuuuuuuuuut i was expecting a pertubation gpu method, and after a few clicks the images takes already 2secs to render ;) i have a i7 3,2 ghz and a radeon 7970 gpu :/ I'll just copy/paste the relevant part of the WINDOWS.md file I linked here - extreme slowness is a known bug ;) Quote \section winbugs Bugs in mightymandel.exe - `clock_gettime()` isn't working in my mingw64 installation, I think a fix is in the works but I don't feel like upgrading my whole system to get a newer version, just to compile binaries for an OS I don't use. This means I just ifdef'd out the offending code, so the timing doesn't work (this has the side effect of making mightymandel a lot slower because it displays the frame and polls for user input after every GPU step, instead of waiting until a timeout is reached). - `localtime_r()` isn't working, so I ifdef'd that out too. All saved files have the same stem, so be aware that each mightymandel session will overwrite PPM saved from a previous session: NOTICE saved: mightymandel_1900-01-00_00-00-00_0000_00_00.ppm - I don't know what happens on real windows wrt stderr or stdout messages. - I don't know what happens on real windows wrt current working directory of a program started by a double click on an icon. So images could get saved to strange places (or saving could fail due to permission issues). - 1926 lines of error messages are printed on stderr at launch (this may be an issue with `wine` instead of `mightymandel.exe`. err:wgl:is_extension_supported No OpenGL extensions found, check if your OpenGL setup is correct! I found this, going to try it soon http://www.decompile.com/cpp/faq/windows_timer_api.htm Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 05, 2015, 05:15:35 PM @cKleinhuis -- oops, I assumed you were on Windows, but re-reading I'm not so sure... anyway...
Timers fixed: http://code.mathr.co.uk/mightymandel/commitdiff/809ce98cf55b921530220905c4d8b754c157e8b7 New win32 binary: http://mathr.co.uk/mandelbrot/mightymandel-v15-74-g4a1a535.zip This one is about 40% faster than the previous one (well, I only tested one parameter, in --one-shot mode, so take that figure with salt). Now ./mightymandel.exe is only about 3.3% slower than ./mightymandel on my system (excluding the time wine takes to start). Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: cKleinhuis on January 05, 2015, 05:18:04 PM i am windows user, yes ;)
Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 06, 2015, 10:35:09 PM Highlights from recent changes in the git version:
b082a74: decouple window --geometry from image --size d37e581: check available video memory on startup 41f6bef: collect lots of metadata and save it in PPM comment See http://code.mathr.co.uk/mightymandel/shortlog for more detail mightymandel is quite greedy with video memory at the moment, 1GB (minus overheads for OS) gives around 3072x1728 image size (and now the window size can be smaller if you don't have a screen that big). I plan to fix this in a way that circumvents the problems(*) with tiled rendering (image uses 20 bytes per pixel, calculation uses (*) problems with tiling include seams when re-assembling output, wasted re-calculation of references, non-termination issues with 100% interior tiles, ... Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 09, 2015, 09:56:50 PM Highlights from recent changes in the git version:
* timeout command line option * sliced rendering * progressive rendering Sliced rendering reduces video memory usage for calculations so larger images can be rendered without having to resort to tiling: --size 7680x4320 with --slice 2 is just about fine on my 1GB card, --slice 3 is more comfortable and a bit faster. Progressive rendering re-orders the slices so that you get a lofi (pixelated) preview image first, which gradually becomes more refined. Reference iteration calculations are shared between slices to avoid recomputation. The slice layout looks roughly like this for --slice 2 (tables up to --slice 8 are generated at runtime): Code: { { 0, 8, 2, 10}Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 11, 2015, 01:33:31 PM Highlights from recent changes in the git version (HEAD at 6467fce375a820575c24ed226a6951c8874fabd5):
* reference finding improved * fewer references should be needed as better references are chosen * two-pass blob extraction method: first pass extracts glitched blobs, second pass extracts most erroneous sub-blobs * --max-blob flag to ignore small blobs (default 1 pixel, set to 0 for previous behaviour) * zoom assembler adds motion blur * variable shutter speed (default 0.5, set to 0.0 for previous behaviour without blur) * some comparison videos at http://www.fractalforums.com/format-printing-and-post-production/motion-blur Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 11, 2015, 04:39:48 PM New Windows binaries are available:
http://mathr.co.uk/mandelbrot/mightymandel-v15-189-g8605661.zip (2.1MB) The zip contains 32bit and 64bit binaries each with standard and nodebug versions. The standard versions are to be preferred, switch to nodebug only if you had no problems and need maximum performance (though the difference is probably tiny). The 64bit binaries are completely untested as I don't have a 64bit WINE yet. Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: youhn on January 11, 2015, 05:10:03 PM mightymandel-v15-189-g8605661-win64.exe is working on Wine 64 on Linux Slackware. Just did a bit of zooming, saving an image, re-render the location from command line. Might need more testing to get a feel of stability, but the basics are working.
Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 17, 2015, 02:09:55 PM mightymandel-v15-189-g8605661-win64.exe is working on Wine 64 on Linux Slackware. Good to know. Thanks for testing!Highlights from recent changes in the git version (HEAD at 4b9d9291ae9c73dca6d275ec29cae396658139d3, changes (https://gitorious.org/maximus/mightymandel/commit/6467fce375a820575c24ed226a6951c8874fabd5/diffs/4b9d9291ae9c73dca6d275ec29cae396658139d3)): * per-pixel vram usage reduced by 4 bytes (--de) or 8 bytes (--no-de) * stopwatch implementation for OS X * better --no-de colouring The OS X changes are untested (I don't have access to any OS X), experience reports very welcome. High priority bugs still to fix before the next release: * GUI is unresponsive during reference point finding and series approximation * version string generation only works from a git clone (no tarball) Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on January 19, 2015, 07:06:46 PM mightymandel v16 has been released!
release announce http://mathr.co.uk/blog/2015-01-19_mightymandel_v16.html new home page http://mightymandel.mathr.co.uk/ source tarball http://mightymandel.mathr.co.uk/download/mightymandel-v16.tar.gz (789kB) windows binaries http://mightymandel.mathr.co.uk/download/mightymandel-v16-windows.zip (2.1MB) documentation http://mightymandel.mathr.co.uk/v16/ Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on March 10, 2015, 03:31:27 PM Recent changes in git (with major changes in bold):
699d922 update atom feed link e0e4d87 automatic orb example e49418f latest test suite results 4eb5aaa test with distance estimate a437627 pre-scale derivative instead of post-scaling de 763b77c update code host d079448 debug shaders as well as programs b59a609 OS X bugs 8eefa05 OS X build system and documentation 98b63f3 rewrite build system: make SYSTEM=system 5cfd6c8 only include perturbation metadata for fpxx 3588da8 re-order window hints to glfw faq 59e4e87 use an explicit format in date instead of --iso=s 0844246 OS X bugs 7761d9c correct frappuccino CPU f278fa1 post-release version bump pre-scaling derivative instead of post-scaling distance estimate means that --de now works all the way to the zoom depth limit of mightymandel (around 1e-300, when double precision floating point underflows to zero it's game over :( ) series approximation for derivative (used in distance estimate) is broken (I don't think it was ever working properly), so pick one of --no-de (fast) or --no-approx (pretty) OS X is not working (someone managed to get it to compile and run, but it displayed a blank window despite the output PPM being saved correctly, and the changes haven't been merged into git yet). Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on May 21, 2015, 02:17:41 AM Recent changes in git:
started porting from transform feedback to compute shaders with the calculation engine in a reusable library (lots of work still to do, so this isn't live yet) 323b505 rename symbols (all with mightymandel prefix, private with additional _ prefix) 373e9e7 remove unimplemented status 6475c03 reduce file count; build a shared library 938ae1e conditional compaction; debug output f7f60ed first compute shader test ba46c6d start of library API with test of threading The primary issue with transform feedback is that the CPU is waiting for the GPU to finish before issuing the next commands to the GPU - with compute shaders and conditional rendering the throughput should increase, at the cost of a little latency when checking whether rendering is done. Compute shaders are also more sane than vertex/geometry shaders when doing computations. The library API will be quite simple - there'll be functions to create/destroy a mightymandel context, start a render, stop the render, wait until the render is done, get current raw iteration results (whether done or not, for progressive display), and clean up after rendering. The rendering runs in a separate thread so your main loop isn't stolen. This work will bump the version requirement to OpenGL 4.3, the no-deep-zoom OpenGL 3.3 version will no longer be supported. changes to the existing engine 2936c26 accumulate error flags to improve reference point finding 2da20be new series approximation in fpxx_approx2; flag --order f23d2b2 series approximation code generator Accumulating error flags means that points that are glitched with multiple references are given higher priority for consideration as the next reference. Seems to reduce the total number of references needed. The series approximation code generator is written in Haskell, so you now need ghc to compile mightymandel. After updating the source from git, run Code: make -C src generate Here's a diagram showing how the 4th order series approximation coefficient recurrence is parallelized. Higher orders would be even more incomprehensible :) (http://mathr.co.uk/mandelbrot/2015-05-21_parallel_4th_order_series_approximation_recurrence.png) Title: Re: mightymandel GPU Mandelbrot set renderer (OpenGL 4) Post by: claude on July 30, 2015, 04:35:41 PM the rendering method is nice, buuuuuuuuuuuuuuuuuuuuuuuuuut i was expecting a pertubation gpu method, and after a few clicks the images takes already 2secs to render ;) i have a i7 3,2 ghz and a radeon 7970 gpu :/ I've been working slowly as time allows on a different renderer (CPU-based so far), trying new algorithms. This helped diagnose the main reason why mightymandel is so slow when zooming: 1. primary reference is recalculated for every image 2. series approximation coefficients are recalculated for every image 3. secondary reference calculation requires analyzing the whole in-progress image for glitches My new renderer solves all of these issues, reducing time taken for a test zoom video from a few days in mightymandel to a few hours in the new renderer. But there are still some bugs, particularly at low zoom depths where an outer reference series approximation skips too many iterations and corrupts regions around visible inner minibrots; also some calculations are not yet interruptible, and there is no GPU usage yet either. |