Logo by MandelBRO - Contribute your own Logo!

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

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Support us via Flattr FLATTR Link
 
*
Welcome, Guest. Please login or register. November 27, 2022, 01:39:06 PM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: [1]   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: mandelbulb3D and CUDA  (Read 6166 times)
Description: is mandelbulb3D CUDA compatible ?
0 Members and 1 Guest are viewing this topic.
scavenger
Forums Freshman
**
Posts: 11


WWW
« on: May 01, 2013, 03:13:52 PM »

hello

is mandelbulb3D 1.7.6 CUDA compatible ? or will be ?
Logged
cKleinhuis
Administrator
Fractal Senior
*******
Posts: 7044


formerly known as 'Trifox'


WWW
« Reply #1 on: May 01, 2013, 03:20:09 PM »

hi, most certainly there wont be any cuda adaption for mb3d in the near/far future, but i am not the developer,
most of the program relies on heavy optimised assembly code, for mandelbulb3d the processor is the only one
doing the whole work!
Logged

---

divide and conquer - iterate and rule - chaos is No random!
flexiverse
Safarist
******
Posts: 99



« Reply #2 on: May 06, 2013, 05:37:50 PM »

I was looking at new generation gpu renderers.. Eg..


http://www.indigorenderer.com/


<a href="http://www.youtube.com/v/yzE4auqSCi4&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/yzE4auqSCi4&rel=1&fs=1&hd=1</a>



Writing code that can maximise the GPU power, using parallel gpus,
Is definitly the future.

Certainly would be intesting researching multi-gpu renderer and How you would code one up.
Logged
hobold
Fractal Bachius
*
Posts: 573


« Reply #3 on: May 06, 2013, 06:15:55 PM »

The programming models of CPUs and GPUs still have significant differences. This reflects the differences of the underlying hardware.

This is not just a matter of incompatible instruction sets. Even abstract, high level programming idioms can be unportable between the two kinds of machines. For example GPUs cannot handle recursion well at the hardware level. The newest CUDA SDK allows programmers to write recursive functions, but cannot ensure good utilization of the GPU for these (OpenCL does not allow recursive functions at all for that reason).

Then there are subtler differences between CPUs and GPUs even when both offer the same semantics. Memory bandwidth and memory latency differ widely, for example. That means programs aiming for optimal performance may have to use different layouts of data in memory on CPUs and GPUs (e.g. hash tables tend to work well on CPUs, but they can fail badly on GPUs, performance-wise).

We may eventually see a convergence between GPUs and CPUs such that both can run off of the same source code (a glimpse of that is offered by OpenCL today, but the "common" programming model is the more restricted one of GPUs). But even then ideal performance on either hardware will require specific tuning.
Logged
lxh
Iterator
*
Posts: 178


« Reply #4 on: May 07, 2013, 10:23:38 AM »

Well, i don't know much about hardware programming but i question myself if there's really a need to leave all methods that already work. Maybe a simple prepass render which translates every single pixel of an image into a polygon or group (such as cubes or maybe procedural spheres) sized and placed (maybe as instances) in the right distance could lead to a dramatically increased final CUDA render time (compared to the Monte Carlo renderer). A few million polygons shouldn't be a big deal anymore. Maybe it's just a naive thought ...

PS: Of course there should be a little more objects for shadowing, illuminating and reflecting. I'm not sure if this would be possible. But voxelstack works .. so why not within one procedure?
« Last Edit: May 07, 2013, 11:21:46 AM by lxh » Logged

I've learned so much by my mistakes that I'm planing to do some more.
taurus
Fractal Supremo
*****
Posts: 1175



profile.php?id=1339106810 @taurus_arts_66
WWW
« Reply #5 on: May 07, 2013, 03:26:20 PM »

... A few million polygons shouldn't be a big deal anymore...
Really? Not quite sure if there are the same restrictions on gpus with 32bit software. On cpu most of your RAM is useless with that kind of software.

and btw. one million polygons is nothing for a fine drawn fractal surface. I made whipped cream quats with three million polys a few years ago and sometimes they still looked coarse.
« Last Edit: May 07, 2013, 03:33:15 PM by taurus66 » Logged

when life offers you a lemon, get yourself some salt and tequila!
Jesse
Download Section
Fractal Schemer
*
Posts: 1013


« Reply #6 on: May 07, 2013, 03:55:16 PM »

CUDA and OpenCL discussions are very interesting for me, since i am very new to these options.
How does these compilers handle the GPU code+memory limitations for example?

For m3d i can only say that all extern formulas are 32bit CPU code, so this can't be changed to GPU.
Logged
elphinstone
Alien
***
Posts: 38



mattia.gollub
WWW
« Reply #7 on: May 07, 2013, 04:34:05 PM »

Really? Not quite sure if there are the same restrictions on gpus with 32bit software. On cpu most of your RAM is useless with that kind of software.

and btw. one million polygons is nothing for a fine drawn fractal surface. I made whipped cream quats with three million polys a few years ago and sometimes they still looked coarse.

Agree!

I attached a screenshot of a Direct3D application I wrote last year for visualizing the mandelbrot escape time in 3D. Thanks to dynamic tessellation I was able to handle ~5 millions polygons in realtime, but I was really disappointed by the result. To get a "perfect" result one should increase the polygons by 100x, very close to the limit of OpenGL and Direct3D (2^32). I'm not saying that it is impossible (there is still place for optimization), but I belive fractals doesn't work well with polygons. Ray/path-tracing is still the most efficient choise.

CUDA and OpenCL discussions are very interesting for me, since i am very new to these options.
How does these compilers handle the GPU code+memory limitations for example?

For m3d i can only say that all extern formulas are 32bit CPU code, so this can't be changed to GPU.

GPUs are very powerful, but this power has a cost: low flexibility and difficult to program. Some example:
  • No common memory address space.
  • Complex memory hierarchy.
  • No stl types like vectors and lists.
  • It's easy to parallelize jobs, but it's hard to do that efficiently, expecially if you want to support a wide range of GPUs.
  • No function pointers (in OpenCL, CUDA has them). No pointer to pointer for data
  • The code has to be compiled on every different GPU (again: in OpenCL. CUDA is more portable, but works only on NVIDIA's GPUs)
  • ...

I'm currently working on my own application for raytracing 3D fractals but if you need some informations I'm glad to help you. MB3D was my first love. smiley


* Mandelbrot.jpg (180.27 KB, 1344x723 - viewed 566 times.)
Logged
lxh
Iterator
*
Posts: 178


« Reply #8 on: May 07, 2013, 05:58:56 PM »

Really? Not quite sure if there are the same restrictions on gpus with 32bit software. On cpu most of your RAM is useless with that kind of software.

and btw. one million polygons is nothing for a fine drawn fractal surface. I made whipped cream quats with three million polys a few years ago and sometimes they still looked coarse.

I think it's a difference if you aim a realtime representation or saving time for the final high-end render. Maybe it is possible to decrease the poly count by FOV like M3D optional does with DEStop? It should be much more efficient for a still render than a uniform polygon distribution.

Anyway .. whatever Jesse will decide - i'll get myself the card. grin
Logged

I've learned so much by my mistakes that I'm planing to do some more.
taurus
Fractal Supremo
*****
Posts: 1175



profile.php?id=1339106810 @taurus_arts_66
WWW
« Reply #9 on: May 07, 2013, 06:44:13 PM »

For m3d i can only say that all extern formulas are 32bit CPU code, so this can't be changed to GPU.

I guess that's all we need to know for now wink
Logged

when life offers you a lemon, get yourself some salt and tequila!
lxh
Iterator
*
Posts: 178


« Reply #10 on: May 07, 2013, 06:59:05 PM »

I guess that's all we need to know for now wink

Hmm, this sounds finally for a realtime gpu engine. But i wonder if there's no way to translate a cpu rendered pre-pass to the gpu for final renders.
Logged

I've learned so much by my mistakes that I'm planing to do some more.
hobold
Fractal Bachius
*
Posts: 573


« Reply #11 on: May 07, 2013, 10:45:25 PM »

The code has to be compiled on every different GPU (again: in OpenCL. CUDA is more portable, but works only on NVIDIA's GPUs)
This statement is a bit ... imprecise.

OpenCL's default way of delivering GPU code is as C99 (more precisely "OpenCL C", which is a slightly reduced C99 plus some extensions) source code. CUDA's default way of delivering GPU code is as precompiled bytecode, but targeted at a specific GPU feature set (which Nvidia calls "compute capability level", that closely tracks the historical generations of Nvidia GPUs).

OpenCL C will be compiled at runtime of the application for whatever compute device is present, be it a multicore CPU, a GPU by either AMD or Nvidia or ARM or Qualcomm ..., or a non-graphical compute accelerator (like the SPUs in a PlayStation3), or even an FPGA (field programmable gate array). CUDA C will not be compiled at runtime, but a CUDA application can pack several versions of bytecode for various different Nvidia GPUs.


Having acquainted myself with both programming platforms in the recent weeks, I cannot name a clear winner. Both have unique strengths:

- CUDA is easier to learn, faster to get something up and running, and has more mature tools

- OpenCL is more portable, the limitations of OpenCL C force you to better understand the limits of GPUs and program accordingly, and having a compiler available at runtime can be very powerful (very dangerous, too, if you consider malware)


To anyone out there thinking about getting their feet wet with GPGPU programming, I recommend starting with CUDA if you happen to have an Nvidia GPU. In the long run you might want to write your GPU functions more minimalistically, OpenCL style, and even switch over to OpenCL for portability and to use all processors (CPU + GPU) in a machine.

Those who want to start out with OpenCL (or have no choice) should find some good example code and tweak that. Alternatively, there exist a number of wrappers for OpenCL that reduce the amount of "boilerplate code". But this might give up some amount of portability, especially in the case of platform specific wrappers like, say, Apple's under MacOS X.

I will use OpenCL for my own projects, but I have had the luxury of starting out with CUDA. Starting from OpenCL directly would have been harder.
Logged
elphinstone
Alien
***
Posts: 38



mattia.gollub
WWW
« Reply #12 on: May 08, 2013, 01:25:50 PM »

This statement is a bit ... imprecise.

Definitively. I shouldn't post when I don't have enough time. Excuse me  embarrass
Anyway I agree with the fact that beginning with CUDA is much easyer. There is much more support.
Logged
Pages: [1]   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
New CUDA developer Meet & Greet chacharles 9 3591 Last post May 19, 2011, 01:06:00 PM
by chacharles
CUDA Benoit Announcements & News RogerDahl 7 3299 Last post April 26, 2011, 09:39:00 PM
by RogerDahl
CUDA Y.A.M.Z Programming « 1 2 ... 5 6 » 3dickulus 75 9181 Last post January 27, 2015, 02:38:01 AM
by 3dickulus
CUDA mandelbrot renderer - should I publish? General Discussion kubinator4321 3 5300 Last post January 16, 2015, 04:38:58 PM
by kubinator4321
Anyone played with Arrayfire ? (CUDA/OpenCL/CPU) Programming « 1 2 » ker2x 18 7674 Last post February 16, 2016, 11:35:27 AM
by ker2x

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.221 seconds with 24 queries. (Pretty URLs adds 0.014s, 2q)