[flower]

Mauricio,

Can you expand on your comment:

"Next Limit has been rewriting Maxwell for Mac OS X (porting it from C++ to Objective-C)"


Not being techie, I don't understand the significance of this. Can you explain?
Is it do do with writing a true Cocoa app instead of Carbon?

And, back on topic, if Maxwell can use OpenCL eventually, the future is looking good. Just have to wait and see I suppose.

Bim

[msantana]

Mauricio,

Can you expand on your comment:

"Next Limit has been rewriting Maxwell for Mac OS X (porting it from C++ to Objective-C)"

Well, the technologies that Apple supports in Mac OS X are Carbon and Cocoa. Carbon are C++ APIs (Application Programming Interfaces) and very roughly speaking are the instructions you can use under the Mac OS development environment to build an application (Please note that there are exceptions to this). While Cocoa is the set of APIs that are based on Objective-C. The two languages are object-oriented but in essence are different, and incompatible in general. But, you can build an application for a mac with either of the two languages.

Now, Apple has said many times that they want everybody to move to Cocoa. More importantly, Objective-C is the only set of APIs that supports 64-bit instructions, that is, instructions that take advantage of the Core 2 duo cpus and Xeon processors. And this allows you to use more memory (above 4 gigs of RAM or so per application). Apple promised 64-bit C++ APIs 4 or 5 years ago only to not deliver them at all (that is why Photoshop on the mac is still 32-bits, because it is written in C++ and not in Objective C)

Well, Next Limit has been bundling in the mac version an application that is called 64-bit tech preview, which is a 64-bit mac application. Now, you know that these are not possible under C++, so you draw your own conclusion.

In any case, it seems that they have ported the Maxwell code to at least Objective-C (kind-of because there are some issues with it and it is still not rock-solid), who knows, maybe they feel more comfortable now to try to port it to another language like using OpenCL (which is, as far as I understand even simpler than C++, since it is based on an updated version of C called C99), also, CUDA is a variation of C.

[Mihnea Balta]

What are you talking about? Of course there's full support for 64-bit on OSX for C++. The GUI stuff has nothing to do with it. The renderer itself is still C++ and will remain so. Porting it to Objective C would be a pain and pure madness, since it means either using Objective C on the other platforms too (which is a no go from many perspectives) or maintaining two separate implementations of Maxwell (which is a software development nightmare).

Also, nothing but the most trivial tasks scales linearly with "gigaflops". Current GPUs can add numbers quickly, but take ages to get to them. Having linear and coherent memory access patterns is a big deal there and raytracing simply doesn't. There have been attempts to exploit GPUs for raytracing, but the results aren't so hot. This is a question of hardware design, not API. OpenCL, CUDA, RapidMind, the DirectX 11 compute shader and the rest of the GPGPU stuff out there can't help one bit, they just let you talk to the hardware. If the hardware can't do it, no amount of fiddling with APIs will help.

There are tasks where current-generation GPUs provide huge speedups, but it's yet unclear how raytracing (and the other stuff that Maxwell needs) fits into the picture. It's probably going to be easier with future generations, for example Intel's Larrabee. Multicore CPUs are also growing, so it's still going to be some time until it becomes obvious which of the two approaches is be better in terms of rendering performance per dollar (which is what matters, in the end, as somebody else pointed out earlier).

Please note that this is not an official position from Next Limit, it's just my personal opinion. I have nothing to do with NL's endeavors into GPGPU.

[msantana]

What are you talking about?

I guess I just paid the price of making assumptions...

Mihnea is obviously more informed about Maxwell's code than any of us posting in this thread. Anyhow, the post I mentioned earlier is over-simplified and I guess the main problem is that you can always mix and match languages and libraries when developing an app (the exceptions that I mentioned before). And it, of course, depends on how the program is written (which of course about Maxwell I know nothing about). I guess I should have made the point that not all the libraries for the mac environment are available in C++ under 64-bits, a moot point anyhow since Maxwell apparently doesn't need them.

Well, expanding on Mihnea's point: hardware implementation is a tricky point with ray-tracing. Intel has been working for some time on a real-time ray-tracer, but I haven't seen their results yet, maybe they will get somewhere. The optimization is not there yet, and Intel is full of smart people, but they haven't published anything that takes advantage of GPU hardware yet. On the same note, 10 years ago, that was really the edge of the Silicon Graphics computers. They had very high throughputs in their interconnect buses, so there were no bottlenecks between raster managers, video cards, memory, hard disk and their CPUs.

And this is why the specialized hardware for GPU computations tries to use special buses to push the performance of the hardware, but you do need to port your code from C++ to some specialized version of C.

In any case, Mihnea's point I think is very valid, it really depends on how much the hardware can respond to the calculations that Maxwell does. And only Next Limit people can have an idea how much improvement can we get, if any.

[Mihnea Balta]

Well, expanding on Mihnea's point: hardware implementation is a tricky point with ray-tracing. Intel has been working for some time on a real-time ray-tracer, but I haven't seen their results yet, maybe they will get somewhere. The optimization is not there yet, and Intel is full of smart people, but they haven't published anything that takes advantage of GPU hardware yet.

The realtime raytracing stuff was a rather unfortunate choice for their marketing department. I guess they wanted to distinguish their product somehow and tried to push something which is currently out of reach for the competition. However, it kind of backfired, since single-bounce raytracing in games raises serious problems but provides no real benefits over classic rasterization. People in game development paid very little attention to the RTRT blurb.

The good news is that they aren't actually trying to speed up raytracing with special hardware. They've gone in the exact opposite direction and their Larrabee stuff will be as general purpose as possible. The only piece of dedicated hardware it has is a texture fetch unit, since decompression and filtering runs orders of magnitude faster in hardware than in software. Aside from that, it's just a bunch of Pentium 1-like cores with massive vector units. They run OpenGL and Direct3D as software implementations on those Pentium cores (they released a paper about it at SIGGRAPH, it's a really interesting read). They have a full-featured memory management unit and all. On paper it looks much more flexible than current-generation GPUs, which is why it's more likely that you'll see raytracers take advantage of it. Of course, we'll have to see if the paper specs materialize as promised in silicon. :)

Another cool thing is that they run a superset of the x86 instruction set, so you can compile normal CPU code on Larrabee. You can program it in C++. There will be a library for doing certain things and obviously it won't run "regular" code efficiently, but you don't need to switch to some special language to talk to the thing. It's kind of like with the Cell SPEs, which can be programmed in C++ too (though not to the same extent).

[sam7]

It's here!!

http://www.khronos.org/registry/cl/

[leoA4D]

Interesting site. A running chronology of news snippets on the Home page make interesting reading (the Home button is on the left below the upper left cnr of the linked page).

Leonard