Vray future

[GatesB]

Yeah, and the sweet part is that IBM Cell Blades are OpenCL compliant as well.

OpenCL, so it's vendor agnostic and not necessarily restricted to GPU rendering. It should scale across anything that has OpenCL drivers hopefully heh

[QuakeMarine1]

Hi Patrick,

In our business we allways have the problems of rendertimes! With GPU this changes, I think GPU is the future.

rog!

never ever - if you render today 10min per image you will do so in 10 years even ur using a 128core CPU or GPU hardware
I guess there is a name for it like "moorsche law"

compare rendertime ToyStory to Shrek

[bardo]

never ever - if you render today 10min per image you will do so in 10 years even ur using a 128core CPU or GPU hardware
I guess there is a name for it like "moorsche law"

compare rendertime ToyStory to Shrek

I read that was Jim Blinn to say that the rendertimes will be always the same because more cpu power allow more details (or something like this) and I think it's true, probably it's better to compare the image quality (more photoreal, more artistic freedom, more tools to communicate what everyone wants).

[tammo]

Yes i think thats right.
Software is always evolving, getting more powerful and needing more processing power.
First it was GI, then glossy reflections, now the switch from SD to HD animations.
Maybe Stereo-3D will be next, that alone would double the render time.

Also the expectations of the clients always get bigger because of the rendered hollywood movies and TV-Spots.
Hard to impress someone who has just walked out of avatar.

[rogerteddy]

Yes you are right but 10 years ago, we couldn´t get photorealistic solutions. Nowadays we reached a picturequality that is allready photorealistic (maxwell etc). And what I seen so far is that this is now possible at 10 to 100 times faster with GPU.

[Bechstein]

Vlado wrote somewhere that to write a gpu based unbiased renderer is not a big deal. therefore we see so much grow up in the last time. In my opinion chaos should not (only) follow this fork.
Can you imagine how fast and usefull vray would be if chaos combine gpu speedup with the biased solution that vray has for years? In the past it was the big advantage of vray to have an biased solution which is qualitatively comparable to an unbiased solution but many times faster to calculate. Have you ever seen an longer maxwell video?
Okay. I am not in deep with gpu or opencl progamming. But is it possible to mix gpu and cpu calculation? Let's take an example. The irradiance map was developed to find points in an image were it is necessary to calculate the light. The calculation in this point ist a kind of bruteforce. Or not? Is it possible to make this step gpu based?
We have many parts in vray were bruteforce/dmc ist taking for calculation. When all these parts go for calculation by gpu the production renderer would not be a realtime renderer but the fastest production renderer on the market.
If this would be possible vray will be unique beside the other renderes. Okay. Up to this point when the others adopt vray technology again

[Mnietek2707]

... In my opinion chaos should not (only) follow this fork.
Can you imagine how fast and usefull vray would be if chaos combine gpu speedup with the biased solution that vray has for years? In the past it was the big advantage of vray to have an biased solution which is qualitatively comparable to an unbiased solution but many times faster to calculate. Have you ever seen an longer maxwell video? ...

I wanted to write exactly the same, but my English is too weak

[vlado]

This is true, of course, but it is not quite easy, for the following reasons.

The irradiance map, the light cache, photon maps etc. all use some common data structure. Creating and maintaining this common data structure with multiple rendering threads requires some syncrohization between the processing units (so that it is not possible for two threads to overwrite each others' data, for example). For the relatively low number of CPU cores, access to the structure can be syncronized efficiently between the rendering threads. However as the number of cores increases, this synchronization becomes a bottleneck. For GPUs, where you have hundreds of threads running simultaneously, this becomes a serious performance issue. Of course, this can be worked around, but it requires significant changes to the underlying algorithm to make the solution efficient.

Also, GPUs are only really efficient when they have large amounts of data to process. Ensuring that they have this data is also a problem. For example, currently V-Ray calculates the irradiance map samples on the CPU one by one as they are needed. Transferring this same approach to the GPU will not give any significant speed-up. You need hundreds of samples to calculate at the same time in order to see performance benefits.

And finally, transferring data to and from the GPU is slow and must be done as rarely as possible.

These are of course problems that can (and will be) worked around, but it is not simply a matter of plopping some GPU code into the whole thing and expecting it to run N times faster. For many of the V-Ray components, this means practically rewriting them from scratch.

Best regards,
Vlado

[vlado]

To give a more concrete example: V-Ray spends about half of its time for intersections of rays with the scene geometry (raycasting), and the other half - shading these rays and determining what rays to trace next.

If you transfer just one of these two basic tasks to the GPU, you can only get up to 50% speed up in the ideal case, and usually much less. For the GPU to be efficient, both of these tasks need to work on the GPU. One of the consequences is that we cannot use any already existing CPU code (like Standard materials, maps, 3rd party plugins) - everything must be coded from scratch for the GPU, pretty much like we did for V-Ray RT (Which is just as good, because we can easily port that code to the GPU )

Best regards,
Vlado

[Mnietek2707]

... everything must be coded from scratch for the GPU ...

I bought recently 2 socket xeon machine.
it looks like it was a pointless purchase

[rogerteddy]

If a GPU biased solution is that difficult, why not changing Vray to an unbiased renderer What exaclty are the benefits of biased engines, if unbiased is faster or the same speed then bias with GPU??

Because isn´t it generally better to have it unbiased?

Best regards

rog!

[vlado]

If a GPU biased solution is that difficult, why not changing Vray to an unbiased renderer

This is why we have V-Ray RT

Best regards,
Vlado

[GatesB]

All this complaining, did anyone even see the Siggraph VrayGPU video?

http://www.cgarchitect.com/news/SIGG...ROUP-GPU.shtml

[devin]

Vlado is that to say that Vray RT is the same as Maxwell and Fry, that we are getting interactive physically accurate results?

[instinct]

There are a lot of Buzzwords and misleading marketing terms out there these days. For example beeing "unbiased" is mistaken as physically correct, wich it is not. It is just less biased than other more "cheating" methods.

There's still way too much left out of the equation in terms of beeing physically correct (so much for rendertimes to drop any time soon :P ).

And while we're at it i dont consider "unbiased" renderers superior in a normal production if they rule out cheating. Am not talking only rendertime here, but a client wish (make the chrome more chrome would be a classic example) might not be possible if you can't override raytraced reflections. So if i end up retouching the renders as much as i would with photos (the amount of retouching these days is pretty insane actually) then where's the point ?

Regards,
Thorsten