new hardware for real time ray tracing?!?!

Developers will have to build support for the Caustic cards into their applications, but Imagination is providing tools to make that as simple as possible. OpenRL is the low-level API, roughly equivalent to OpenGL on the graphics side,

that sounds pretty promising.

Maybe that’s a bad demo video, but my six year old laptop with Cycles can render almost as quick as that.

i doubt that :3

Doesn’t look too much faster than cycles on my 660ti tbh.

Want real time ray tracing? Just buy 6 GTX 580 :smiley: and you have real time ray tracing.

You’d need quite a motherboard for 6 Graphics cards…
I don’t know how that works.

we know how 5 GTX 680 works… bruttaly fast so imagine 580

gpus dont scale well so the max gpus you can put in a system is about 2 before you start wasting money

well cycles is better :slight_smile: of course. a regular gfx card can help compute compositing effects also.
besides I think brecht and the guys contributing to cycles now can do more stuf above the path tracing
sooner or later like sampling algorithms.

How hard would it be to create plug-in that would enable cycles to make use of this card. It seems that the brazil SDK they are providing can be used to create plug-ins (it was apparently used for the maya plug-in), how hard would it be to apply this to cycles?

I would assume that it is not that relevant for a big chunk of the user-base, as those cards are still quite expensive. But I’d still be interested in the (technical) difficulties of adding such software. Anyone willing to make an educated (or wild) guess?

Also it is my understanding that this would be something that enhances/replaces the foundation of a render engine, and is not an actual render engine in its own right, is this a correct assumption?

if it depends… if you are using SLI with is bad… or if you buy board for like 4 cards and you put just 2 GTX… it will be much faster then normaly connecting it buy SLI… there was topic about that… and the best way is to buy… 1 GTX 580 or 3 GTX 580… or one GTX580 for rendering and some cheap card for viewport…

well if you look at benchmarks if they have one card that can render it in 1 min then they add another that would probably render in 35 seconds and if you add a 3rd one it would probably render in 29 it doesn’t scale linearly

Lol, I guess that’s the anti IT statement of 2013 alrady :smiley:
It pretty much scales linear, if not, the application is to blame.

Anyways. CUDA here, OpenCL there.
You guys forget one thing, this card is specifically tailored for raytracing with a language at hand as well, this OpenRT.

As a developer I’d rather use this language to write a render engine than trying to work out my own parallel algorithms and then re-implement stuff in a kernel that works well on a GPU, trying to avoid recursion and gods know what not to upset the balance of the force in the universe.

So if this card kicks off as the overwhelmingly better standard, will all cycles features have to be rewritten again?
Or is it just a matter of swapping one algorythm for another?

I am not a programmer, so I have no idea what i’m talking about.
I just hope Brecht will not have to start from scratch again.

Ehh from what I see in the video it seems ok, nothing a halfway decent gpu couldn’t do. But I do see where this sort of technology could take us… The only problem is software compatiabitly…

People can just use the OpenRT SDK and programm away :wink:

The article mentions an OpenRT API. While I’m not a programmer, I imagine Cycles would just need to be plugged into the API so the API could plug into the card.

I registered and downloaded the SDK, as soon as I got some air, I’ll peek into it.
Two things they made clear in their forums is, that OpenRT will remain free, for commercial and non-commercial use.
And that it’s not bound to their hardware, it also works on CPUs, can’t tell for GPUs.

For what I gather, the idea is that what OpenGL/GLSL is for rasterization, OpenRT/RLSL should become for raytracing.
And just like OpenGL it can run in a “software mode” via the CPU, or fully hardware accelerated.

OpenRL is designed to be a drop in replacement for OpenGL, you don’t want to implement Cycles or another production render engine on top of that, it’s just too limited. Even if they somehow give lower level access, the hardware doesn’t support hair, motion blur, and other features we might want to implement.

Besides that, while it has the Open prefix, this is still a closed source library that one company has been promoting for about 3 years. As it stands, there’s not much reason to believe this will become a successful standard that other vendors will adopt.