Psst, Developers, CUDA 6 Release Candidate is Now Available to Download

15

Comments

+ Add a Comment
avatar

AFDozerman

OpenCL 2.0 couldn't come soon enough. Different accelerators are good for different jobs, and locking engineers to one particular vendor is hurtful to the future of programming and the industry alone. For instance, if a certain piece of software is particularly "branchy", an active context switching capable APU can handle the dataset much more efficiently than a GPU alone can by itself, or in the instance of a cluster, a group of smaller CPUs can handle serial code while GPUs can be used for processing large arrays of data. Unfortunately, CUDA requires two completely different code paths, one for the processors and one for the GPU. With OCL, only two compute kernals are recommended, but not even necessary. Thankfully, Nvidia have open-sourced CUDA, but it still only runs on their GPUs efficiently with some small, purposefully gimped CPU support.

avatar

vrmlbasic

Why don't we all just use OpenCL? Screw their proprietary setups.

avatar

Peanut Fox

Why do you hate alternatives?

Having variety and varying approaches creates better products.

avatar

vrmlbasic

CUDA is only an alternative for those who have capable Nvidia cards. OpenCL works on everything. Sounds to me that Nvidia hates alternatives, since they're still pushing their exclusive system when an open standard exists.

avatar

Peanut Fox

nVidia providing a proprietary system for their cards incentivizes purchase of nVidia cards. It makes sense that they would keep that technology exclusive considering they bear all the R&D costs.

Even though CUDA remains exclusive to nVida, they still support the same Open standards as everyone else. You're trying to present the argument that it has some strangle hold on open standards and it doesn't. CUDA is no HDMI, or x86. There's room for BOTH options to exist.

CUDA is something that remains important to me personally. I do 3D modeling with Blender. An open source application. In fact open standards are very important to that community. Years ago Blender adopted the Cycles rendering engine, and while I won't go into detail about what improvements it offers, I'll just say that it's amazing. The speed at which Cycles is able to render an image in real time with a GPU is staggering compared to what options were before, and all that is thanks to CUDA. OpenCL doesn't match the speed in this instance, and while they were working to get it up and running that portion of the project has all but stopped. Not because OpenCL is bad, or isn't as good. It just wasn't a good fit for the application. Blender Cycles rendering engine isn't the only piece of software that works better, or is easier to get moving with a CUDA based implementation, and CUDA remaining an option has only been a benefit to users of Cycles rendering.

What exactly does anyone gain from having one less option in this space, especially when it's a GOOD option?

avatar

AFDozerman

I barley use cycles unless I want to see a model in progress as it happens. Otherwise, LuxRender OpenCL with SLGpath and the random sampler will be faster for the final render.

avatar

Peanut Fox

I haven't used Lux Render in years. Back when I did use it I liked the results you could get, but I hate the way it handles materials, and lighting. I found that Cycles with mesh based lighting to be much nicer

avatar

LatiosXT

Obviously you've never done engineering work before.

When it comes down to it, software and hardware are tools you select for the job. If the tool does the job and does it well for the amount of resources and effort you put into it, then what difference does it make that it's an open standard or not?

Besides that, just because it's open, doesn't mean it's better. OGL has been a laughing stock in the graphics community for years now. They just started to get some street credit back.

avatar

vrmlbasic

CUDA sucks, it was at best a kludge until OpenCL, and now that we have OpenCL there is no reason, except for Nvidia's lame attempts to lock down a market, for it to still exist. Needless stratification.

avatar

LatiosXT

Have you gotten your hands dirty in both to more than just a simple program? Like several years of experience under your belt with both?

Because all I hear is "blah blah blah proprietary standards suck blah blah blah".

avatar

Carlidan

Hey latios, since you have good knowlege about gpu's. I was wondering why when I use fumark for my gpu it's core clock is only running @800 something mhz but not 1000 something mhz. Which is stated on the box. Is it something I have to do on software side? I have a PNY 780 OC editon. If you need more info, I will post it on maximum pc fourms. I had some BSOD issuse, but it seemed to gone away. I also just got the video card recently. If it's a bad gpu I would like to know now before it's too late to get new replacement. Thanks

avatar

Gikero

Time saver during execution or when writing applications to use CUDA? I don't pretend to know what I am talking about, but I am still curious.

avatar

LatiosXT

Possibly both, in the sense that you no longer have to worry about copying data across memory pools. But you now have a new problem: what lives in slower main memory and what lives in faster video card memory?

avatar

QuantumCD

I haven't done much low-level graphics programming in a while, but I think you generally want to store static meshes on the GPU as VBOs, and then you just move your camera and stuff around with simple transformations. This is (understandably) a lot faster than sending the mesh to be rendered every frame. Also, you can cache data for rendering shaders and stuff I think (again, it's been a while since I've done this :P). Textures are also cached, I'm pretty sure. Albeit, I don't remember exactly how this works.

However, there's a ton of "rules" for optimal performance. For example, I vaguely recall that storing skinned meshes (animated meshes, e.g. a player model) on the GPU is expensive, as the CPU calculates all the bones and stuff for the animations. Also, there's dynamic batching, which (IIRC) takes several meshes and combines them into one drawcall for the GPU to render. I'm pretty sure this has to be uploaded to the GPU every frame or something, as the CPU handles the batching in real-time.

The list of rules goes on and on, but obviously you wouldn't store data that is exclusively for your game logic. That is, you wouldn't store something like a player's high score, etc.

avatar

QuantumCD

Of course, that's just for games.