mandelbulb3D and CUDA

[scavenger]

hello

is mandelbulb3D 1.7.6 CUDA compatible ? or will be ?

[cKleinhuis]

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!

[flexiverse]

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.

[hobold]

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.

[lxh]

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?

[taurus]

... 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.

[Jesse]

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.

[elphinstone]

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.

[lxh]

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.

[taurus]

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

[lxh]

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

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.

[hobold]

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.

[elphinstone]

This statement is a bit ... imprecise.

Definitively. I shouldn't post when I don't have enough time. Excuse me 
Anyway I agree with the fact that beginning with CUDA is much easyer. There is much more support.