mental ray + Cuda = Mental Ray 4.0 ?

#145

Of course it would be preferable if it was written in OpenCL. But there are some advantages to CUDA too. CUDA was written by nVidia for nVidia so there will be inherent optimizations in the compiler and data handling that will be optimal for their hardware.

The down side is that you cant use ATI or Intel and they own the whole architecture and can find ways to jack up the prices on you. At least it looks like you can run it on gaming cards for now.

It is what it is. I do mostly post motion blur right now anyway so its not a deal breaker for it to not have motion blur. Time will tell if its production ready or not.

#146

ya, well the performance hit associated with moving from CUDA to OpenCL will likely be trivial compared to the speed benefit of moving from a Quadro to the latest gaming card. Anyway, if you’re looking to port from CUDA later to mobile platforms where OpenCL will eventually be common, it will be relatively easy from what I’ve read.

#147

The relative ease you are talking about should be true. OpenCL is shaping up nicely. But as to performance gains based on api I have to disagree.

GPUs are much more finicky than CPUs. Almost no cache, no branch prediction, etc. At the core its a stone age primitive architecture. Thats what makes it so fast, potentially. Almost all of your chip is computational logic. In an Intel CPU the majority of your chip doesnt do any actual work, its just cache. Cache is a good thing because it makes a CPU more flexible. But it limits the potential of a chip. If you end up misshandeling your data you can see a 100x decrease in performance. With CUDA they have tighter control over how things work.

Time will tell what works best but CUDA vs OpenCL is not a simple comparison.

#148

Very interesting rBrady.

Time will tell what works best but CUDA vs OpenCL is not a simple comparison.

Completely agree! If it’s like D3D and OGL, CUDA will grow up and OCL will follow him. (Both API doing exactly the same things. The performance more depending about constructors drivers than API himself.)

It will (unfortunatly) more be a question like “will nvidia can force industry to use CUDA more than OCL” than a performance or bench war.

#149

Where is the requirement for needing a Quadro for Iray? I didn’t see that mentioned in the specs. I could’ve missed it though.

iRay is the next in what is likely a long line of Quadro lock-in strategies.

This is based on evidence - it’s not a wacky bash

The only evidence I’ve seen so far is their demo at SIGraph, where they used “15 GPUs” to get accelerated rendering. They don’t state that they’re using Quadros; more likely Teslas. But like has been stated elsewhere, the GTX 285 and the Tesla have the same amount of cores, Tesla only gaining 3 more GB of RAM per unit and quadruple the cost. So it seems certain that imacRay will run on Geforces, but you’d still need 15 of them or so to approach what they demonstrated at the convention.

So will ipodRay simply accelerate MR renders? I’ve still seen no evidence or benchmarks of this occuring. The demo just shows Reality Server working with iRay, and those 15 GPU’s are in a cluster “somewhere in the cloud”.

But from the actual tech document:

The exact GPU hardware specifications vary with content and application requirements and CUDA-enabled GPUs will be required for high performance. While all CUDA-enabled GPUs are supported, iray’s memory requirements will make NVIDIA Quadro®, QuadroPlex® and Tesla® systems for workstations as well as Tesla server units the platforms of choice in most situations.

So, CGB, it was another “wacky bash”. iray is memory-hungry, and as of now Geforces lack the memory to utilize its potential. If anything, they’re trying to justify the Tesla, not the Quadro.

iray is NOT an accelerator for mental ray, but a separate entity altogether.

iray is a new rendering mode of mental ray and RealityServer. Both mental ray and RealityServer (and the iray Integrator Edition) are complete rendering solutions for OEM product integration and standalone deployment.

And one more…

There currently are no plans for supporting OpenCL.

Just wanted to clarify and demistify.

#150

While I agree that iray is in some ways a different animal than mental ray it is still included in mental ray. It could be considered a subset of mental ray and reality server. The reason I draw the distinction is that I have a farm that is fully licensed for mental ray. So now I get the option of rendering in iray mode when maya gets the 3.8 update. This is for free to those who already own mental ray. Its not a separate product based on my financial balance sheet. Whether its awesome or not, I get to play with it and find out free of charge.

#151

so iray will conveniently eat as much memory as MR :stuck_out_tongue:

#152

That’s bad blanket statement.

#153

you’d be the only guy here saying MR wasn’t a memory hog.

#154

it said in the iRay pdf that it will support geforce

Every proffesional CUDA application up till now, namely the photoshop and adobe implementation, has supported geforce. You know they gotta support the people with macbooks.

And VrayRT supports geforces, iRay would shoot itself in the foot if it didn’t let you use gaming cards. I mean, you either buy a $2000 video card to use iray, Or you buy $1000 vray and $1000 worth of nvidia gaming cards and get literally 10 times the speed.

Nvidia might want to boost quadro sales, but there not stupid. They know requiring a quadro will kill any cuda application with openCL, ati and larabee right behind them.

#155

ya, well honestly if OpenCL wasn’t here to curb that desire, I’m not so sure that iRay wouldn’t be just like the Elemental encoder, which was brought out well before OpenCL was a buzzword. VRayRT is not Nvidia, it’s Chaosgroup, who is interested in selling software, not hardware so obviously they want to support what works on all hardware indefinitely.

#156

you’d be the only guy here saying MR wasn’t a memory hog.

I’d totally agree with you, except that decent scene management and a 64-bit Maya defeat MR’s otherwise insatiable thirst for RAM. Give it a shot sometime and it’ll open up those worlds you’ve been dreaming about.

Hell, that should be their slogan. “Open up the worlds you’ve been dreaming about!” Is that taken already? Awesome. Reminds me of Metacreations or something…

But it would appear that iPhoneRay is designed to eat MORE memory than mental ray itself already. Basically, it’ll eat as much as you have on you combined GPU’s. How cool is THAT? Develop a product that eats up RAM on your GPU’s that you don’t even have? It’s just plain genius!

Like marketing cereal to people with no bowls, nor mouths. Nor spoons. Maybe they has milk. Great work Nvidia. “Here’s some technology that sucks and will be dead and buried by the time anyone can afford it or use it. BUY IT NOW, stockholders!”

At the risk of unnecessary fluff…

#157

it said in the iRay pdf that it will support geforce

Exact, I hadn’t seen it

Does iray run on GeForce and Tesla?
iray Integrator Edition and iray in mental ray support GeForce and Tesla.

And just behind:

Does iray run on non-NVIDIA GPUs?
No.

Paf!

Am I the only one wich think that MR is not a RAM eater? Seriously, the only thing wich explose my memory is displacement… But if you don’t use that and use de memory mapping MR isn’t more greedy than others renderers…:shrug:

#158

When it comes to video ram in this instance you have to remember that CUDA can address memory globally. So you can use your main memory for your video card. If you have 16gb of memory then you can use all of that in CUDA. The catch is that accessing this memory takes a lot longer and can cripple performance if your not careful. So you really could run iray on a 8200 that has no dedicated memory at all. It wouldn’t go very fast, but you could run it.

#159

When it comes to video ram in this instance you have to remember that CUDA can address memory globally.

So? CUDA use first the GPU memory (on the GC) and, once it’s full, the CPU memory? It’s that?
Or it’s only CPU memory and GPU memory is not use? :shrug:

You can choose wich memory you want to use?

#160

It would make sense for it to use the GPU memory first and then the system memory if it had to. Otherwise it would be slow since it has to go through the system bus instead of just staying on the card.

#161

Most of the people I know of that are developing in CUDA have said that not using main memory too much is a huge performance tweak for some of their code. I don’t know if the movement of the data from main memory to to GPU memory is explicit in the code or not. The compiler might handle that. But on execution the GPU cannot do a main memory access directly. It has to go through the CPU to get to main memory. So you take an extra hit in performance when you try to compute from main memory. I know most people try to keep all the data the code is grinding on in GPU memory as much time as possible.

#162

not using main memory too much is a huge performance tweak for some of their code

Seems to be logic, the “dark beast” in CPU GPU programming is the access between they memories.

So I suppose (for iray) that all the scene have to be in the GPU memory else you may have “swap” (on the CPU memory :cool:).

I don’t know if the movement of the data from main memory to to GPU memory is explicit in the code or not.

If it’s like “traditional langage” no (it’s the OS wich manage memory and choose to swap when main memory is full).

But I don’t think it’s as easy because GPU look more like a “mini-central-unite” than a x86 architecture component.

I don’t know how the both (CUDA and OCL) API work and maybe it’s transparent for devs. But insofar as the memory of the GPU is still low, it must be hard to manage in code.

But on execution the GPU cannot do a main memory access directly.

So the CPU have to give information to GPU before compute.

If we sum, you first have to give information to GPU memory, prepare “kernel” (GPU procedures), just say: “GO” and wait for the result.

I know most people try to keep all the data the code is grinding on in GPU memory as much time as possible.

Once again, seems to be logic and I have the impression that it’s the “royal road” for GPU computing. :wink:

#163

No.
Of course you want your stuff to be on GPU memory, but the memory accesses are explicit. i.e. the compiler doesn’t do the transfer for you, plus you can access CPU mem from the GPU (it’s called zero-copy).

P.

#164

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.