Would the D700 be overkill?

Re:

If u can afford it, get them...

I'm pretty sure u can run all if the above with just a top end iMac...

I'm not sure here. Some of those things have gpu functionality but only with CUDA. For example After Effects has an okay raytracer. It is based partly off research from NVidia, so it runs on CUDA. OpenCL still has a long way to go. I kind of wonder if it will allow for pointers to virtual memory at any point.

My ignorant opinion is that if you're really going to be limited to 1080 video, it would be hard to imagine that you would need the D700 *2. I'd buy the D500s, put the $1000 in the bank, and use it to upgrade in 4 years

OpNora said:

My main uses for the machine will be running Photoshop CS6, Logic Pro X, Premiere Pro CS6, After Effects CS6 (everything that I will be editing will be at a 1080p resolution)

Click to expand...

I'd recommend that if you're considering a new Mac Pro, that you also entertain the idea of upgrading from the CS6 suite to the CC suite. Yes, the subscription model does suck, but... Premiere at least can access multiple GPUs, and it scales linearly with them. The CS6 version can only address one of the cards.

thekev said:

OpenCL still has a long way to go. I kind of wonder if it will allow for pointers to virtual memory at any point.

Click to expand...

In OpenCL 2.0, if I recall correctly. Whether Apple will make us wait for OS X 10.10 (that's a lot of tens) or quietly slip support in before then is hard to guess.

ZnU said:

In OpenCL 2.0, if I recall correctly. Whether Apple will make us wait for OS X 10.10 (that's a lot of tens) or quietly slip support in before then is hard to guess.

Click to expand...

That made it into 2.0? A lot of recent model gpus will never support 2.0, but that is excellent news for some of the bleeding edge hardware, assuming developers are quick to leverage it. Realistically that may be great downstream when enough people can make use of it to motivate the aforementioned developers. The issue of having to pass all data to the framebuffer is really quite limiting, which is why I say that.

thekev said:

I'm not sure here. Some of those things have gpu functionality but only with CUDA. For example After Effects has an okay raytracer. It is based partly off research from NVidia, so it runs on CUDA. OpenCL still has a long way to go. I kind of wonder if it will allow for pointers to virtual memory at any point.

Click to expand...

Pointers to virtual memory is nifty, but you can't use it with a discrete GPU. It'll help on the Iris Pro, but it won't help on the Mac Pro.

I also don't think it works with a discrete GPU for CUDA. It really makes no sense with a discrete GPU.

Here's how it's described in the announcement:


That sounds like it works with discrete GPUs.

goMac said:

It really makes no sense with a discrete GPU.

Click to expand...

How so? My concern was that you're still limited on vram for some highly computationally intensive stuff. The trend toward 2GB being basically the norm helps quite a bit, but is there any other way of dealing with large chunks of data on the gpu?

thekev said:

How so? My concern was that you're still limited on vram for some highly computationally intensive stuff. The trend toward 2GB being basically the norm helps quite a bit, but is there any other way of dealing with large chunks of data on the gpu?

Click to expand...

A discrete GPU can't perform computations with data unless it's in VRAM. So the concept of having a pointer to data off VRAM makes no sense. You can point to it, but you can't do anything with it. At some point you've still got to do the copy to VRAM.

An integrated GPU does it's computations from RAM. So in that case VM pointers make a lot of sense. Rather than copy something redundantly to it's own dedicated buffer, just refer to it's location in RAM.

goMac said:

A discrete GPU can't perform computations with data unless it's in VRAM. So the concept of having a pointer to data off VRAM makes no sense. You can point to it, but you can't do anything with it. At some point you've still got to do the copy to VRAM.

Click to expand...

Yeah I actually got that part. Many of these applications including those mentioned by the OP are limited by the need to load everything into the framebuffer prior to calculations. This means your scene size and textures must fit in the framebuffer for After Effects and its raytracer. I can think of a few things they could do to work around that to a degree, but nothing substantial without at least some method to dynamically load data as needed. I may have phrased it poorly, but I considered the possibility that the language would eventually allow some better method of loading and flushing data from the framebuffer as needed.

thekev said:

Yeah I actually got that part. Many of these applications including those mentioned by the OP are limited by the need to load everything into the framebuffer prior to calculations. This means your scene size and textures must fit in the framebuffer for After Effects and its raytracer. I can think of a few things they could do to work around that to a degree, but nothing substantial without at least some method to dynamically load data as needed. I may have phrased it poorly, but I considered the possibility that the language would eventually allow some better method of loading and flushing data from the framebuffer as needed.

Click to expand...

Sorry, didn't mean any offense. It's hard to tell what everyone's technical level is on the forums.

It seems possible to me the API could abstract that (I haven't looked at the OpenCL 2.0 spec.) You won't get any performance gain in since it's the same work you'd have to do by hand.

The only risk I can think of is your output is based on input spread throughout the data you're giving as an argument, it may have to do multiple loads from VRAM on a single pass of the OpenCL kernel, which could be bad. Imagine if you were doing a blur, and one pixel of data you need was in the portion that had been flushed, and so the kernel has to wait for another load from RAM. Bleh.

That's the sort of situation where I could imagine that OpenCL couldn't have the intelligence necessary to do all the loading for you, and might continue pushing that off on the developer.

As far as I can tell, OpenCL 2.0 is only targeting virtual memory pointers at integrated GPUs.

http://www.anandtech.com/show/7161/...pengl-44-opencl-20-opencl-12-spir-announced/3

The biggest addition here is that OpenCL 2.0 introduces support for shared virtual memory, the basis of exploiting GPU/CPU integrated processors.

Click to expand...

That said, the performance win for when you're working with data that is far bigger than a discrete GPU's frame buffer is obvious. Integrated GPUs are looking better and better.

goMac said:

Sorry, didn't mean any offense. It's hard to tell what everyone's technical level is on the forums.

It seems possible to me the API could abstract that (I haven't looked at the OpenCL 2.0 spec.) You won't get any performance gain in since it's the same work you'd have to do by hand.

Click to expand...

My knowledge is actually somewhat sparse when it comes to the inner workings of GPGPU, but I didn't interpret that as hostility. I know some Python and C++ (C too). I have years of experience with Maya (I remember maya complete) and Photoshop, and I'm decent with After Effects. It's kind of why I comment on threads like this and ones that involve color management or display questions.

goMac said:

The only risk I can think of is your output is based on input spread throughout the data you're giving as an argument, it may have to do multiple loads from VRAM on a single pass of the OpenCL kernel, which could be bad. Imagine if you were doing a blur, and one pixel of data you need was in the portion that had been flushed, and so the kernel has to wait for another load from RAM. Bleh.

That's the sort of situation where I could imagine that OpenCL couldn't have the intelligence necessary to do all the loading for you, and might continue pushing that off on the developer.

As far as I can tell, OpenCL 2.0 is only targeting virtual memory pointers at integrated GPUs.

http://www.anandtech.com/show/7161/...pengl-44-opencl-20-opencl-12-spir-announced/3

Click to expand...

That wouldn't really help the OP. I'm pretty sure most of his use is going to be OpenGL, as there's no guarantee that anything else will ever leverage it. Regarding the issue of blurring, it depends what kind of blur. A motion blur typically requires a vector obtained by the difference in point position between frames. A blur based on z-depth obviously needs to know what occludes what and either standard distance from camera or you could probably do it with a polar coordinate distance if applicable. Displacement would be a bigger issue, as it can affect position and necessary subdivision. Where I'm confused is that I haven't seen much effort from Adobe or any of the others to do simple raw lighting calculations, then pass that data back. Given the parallel nature of stochastic ray tracing or GI, it seems like a good fit if they could get away with loading only geometry and displacement channels.

goMac said:

That said, the performance win for when you're working with data that is far bigger than a discrete GPU's frame buffer is obvious. Integrated GPUs are looking better and better.

Click to expand...

I could see that given the time lost to loading and unloading data. This is part of why I'm slightly puzzled by the memory configuration. I kind of understand the concept, but the D300s are somewhat limited for certain things. 2GB is certainly not bleeding edge, and while it may be a base model, it's a base model that begins at $3k. I'm sure someone will claim that the word Xeon adds 40% in spite of being a $300 base cpu. Since the D700 upgrade wasn't priced into the stratosphere, it could always be an option. It's sort of interesting to me to debate whether the OP could in fact leverage it. Unfortunately I don't know enough about software development in a couple years to guess.