Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Just a few more benchmarks from a laptop, we threw the 2080 (at the factory default clock) in an external enclosure to see how well it would work:
Laptop + eGPU 2080: 6m10s
Laptop built-in 1070: 11m34s
Laptop built-in 1070 + eGPU 2080: 4m16s
So good news from those of you wanting to do external GPU stuff. Not only does it not seem to slow it down much, but it will still even work with a built-in card to get a render done faster.
Let's not get distracted from what my "benchmarks" are here for, so that you all know that the 20-series cards work with the latest public beta of Daz Studio. That was not the case with the 10-series, which took some time between when those cards were released and when they weren't a very expensive paperweight in Iray. Also, in case any of you were looking forward to the 6x speed improvement with the RTX functionality I wanted to show that the current build of Daz Studio doesn't have any accelleration for the RTX's additional hardware functionality. So while these cards are faster than their 10-series counterparts (2080 faster than 1080 and maybe a touch ahead of a non-OC 1080ti) even without those features enabled should make people very optimistic about the potential speed increase of the RTX hardware being fully utilized.
Thanks for taking the time to post, @DAZ_Rawb - much appreciated. Care to shed any light on DAZ/Iray’s plans to make use of the RTX tech? Not looking for any promises - just a general idea about whether the benefits will be confined to preview renders? Or will it speed full photoreal renders as well?
Thanks in advance for any info (if any) you can provide.
- Greg
Are these benchmarks from sickleyield's test scene? Using her scene (or my scene for that matter) would be a much better bench. And please...post your results in the benchmark thread! If they are only posted here they will eventually get lost when this thread dies. So please post them there.
https://www.daz3d.com/forums/discussion/53771/iray-starter-scene-post-your-benchmarks/p1
Her scene is on the first post. If you are feeling frisky you test my scene which is a bit tougher on the hardware, and in theory might demonstrate a bigger performance gaps. (because the margain of error on 45 second benchmarks is getting very small.) The download for mine is here.
https://www.daz3d.com/gallery/#images/526361/
Important notes: Use the Iray Preview mode. This eleminates the load time that is not part of rendering speed.
Post clockspeeds please. Especially with Turing, there is a huge spread in clockspeed and some Turing chips are not overclocked at all.
I was saying that it might be possible for Turing to work "out of the box". Its great that it does. I wonder when the drivers will get updated for Turing proper. The current tests are probably running on the pure power of CUDA alone, which lines up with the percentages given so far.
Redshift users have benchmarked the GTX2080ti as a little faster than the Titan V. Also, developers on the Octane and V-Ray teams have confirmed that memory stacking works on the 2080ti and they will implement it into their renderers. (source: Redshift Facebook page)
Rendered Outrider42's test scene (5000 iterations, 520x400) in 8 min 25 seconds, with GPU only ; GTX1080 oc at 1658 MHz / Memory at 1797 MHz.
My CPU is a Core i7 6700 (dunno if it's relevant for GPU only render).
Vindication!
Of course Iray probably needs to update, too. There is a tiny shot in the dark that it may work now, there was a very vague nvlink footnote in the 411 driver update.
....need to see the proof.
Nvidia unlocking the NVlink in iRay so that Architects can take advantage of a historically professional Quadro feature using a lower end consumer card? Yeah, good luck with that.
If anyone can do it, it's the V-ray devs. They are the only 3D vendor that I know of that implemented Quadro NVLink with the Volta cards. Quadro RTX bridges aren't available yet, so I'm not sure if they had access to that. It seems legit, especially if Octane devs said the same thing. You can check out the conversation about it on the Facebook page.
As far as CUDA goes, they've had "Unified Memory" since back in 2013, and as I mentioned before, it's NIVDIA's attempt to rule the world by merging all system RAM and GPU VRAM together into one contiguous pool. And a full NVLink implementation bypasses also the PCI bus to make it all one big NVLink across the CPU/system RAM and all GPU's. So the core functionality of VRAM stacking has been there for a long time, and like I said, you can today write CUDA code (using "cudaMallocManaged()") which treats all memory as one pool. And CUDA uses that today to page memory in and out of system RAM as needed. The problem is the slow PCI bus.
So my big question has been "yeah, the low level CUDA functionality has existed for VRAM and other memory stacking for a long time, and the Quadro NVLink hardware connector is certainly capable of doing it between GPU's, but does the cheapo RTX NVLink connector support it, and is there anything in the CUDA 10 that disables VRAM stacking if, for example, that Quadro connector isn't being used?".
In fact, you can query each GPU via CUDA and get a long summary of the features it has available/enabled. Attached is the summary for my GTX-1080ti. Note it says stuff like "Device supports Unified Addressing", and with Pascal and above that's a "yes", but there's also stuff like "Integrated GPU sharing Host Memory", and some other features I'm not quite sure exactly what they do. I'm wondering if with CUDA 10 there's a feature that basically says "Fancy expensive NVLink Connector Installed", and if set to "yes" then CUDA enables VRAM stacking or something. Maybe there's a CUDA C++ code something like this:
As usual, it all comes down to the bits and bytes, and without knowing those details it's all just speculation based on guesses and wishful thinking. I'm hoping to download CUDA 10 one of these days and look at the details and see what they did to support memory stacking with the new Turing.
By the way, for those who might think that "if there's a will, there's a way", I'd caution you to keep in mind that if a particular feature is either not documented or not made available to developers, there ain't no way you're gonna implement it. You have to know what function to call in your C/C++ code, and if you don't know what to write it ain't gonna happen. They can do a ton of stuff "under the hood" to control whatever they want. Trust me, even if a feature IS documented sometimes it can be a real challenge to figure out the correct syntax to make it work (along with the correct configuration for debugging and #include files and paths and such).
For example, I spent much of last weekend wasting time because some code I was using for GPU access ("gpu::GpuMat") was throwing a bunch of errors and driving me nuts. Turns out "oh, yeah, well the documentation on the website is for an older version. Now it's "cuda::GpuMat". We never updated it. Sorry."
Anyway, what makes most sense to me with VRAM stacking is they'll only allow developers who are using the expensive connector to do it on the RTX cards. You get what you pay for.
Well, golly, how come nobody told me the CUDA 10 documentation is already available?
Okay, I took a quick look and found this:
__host__ cudaError_t cudaDeviceCanAccessPeer ( int* canAccessPeer, int device, int peerDevice )
Queries if a device may directly access a peer device's memory.
Parameters
canAccessPeer
- Returned access capability
device
- Device from which allocations on peerDevice are to be directly accessed.
peerDevice
- Device on which the allocations to be directly accessed by device reside.
Returns
cudaSuccess, cudaErrorInvalidDevice
Description
Returns in *canAccessPeer a value of 1 if device device is capable of directly accessing memory from peerDevice and 0 otherwise. If direct access of peerDevice from device is possible, then access may be enabled by calling cudaDeviceEnablePeerAccess().
Note:
Note that this function may also return error codes from previous, asynchronous launches.
Note that this function may also return cudaErrorInitializationError, cudaErrorInsufficientDriver or cudaErrorNoDevice if this call tries to initialize internal CUDA RT state.
Note that as specified by cudaStreamAddCallback no CUDA function may be called from callback. cudaErrorNotPermitted may, but is not guaranteed to, be returned as a diagnostic in such case.
Now I'm not sure exactly what "CUDA RT state" is, but it could be that it's gonna throw an error if it detects an RT device, and won't allow it to access it's peer's GPU memory.
Have ordered two ASUS RTX 2080 TI Turbo's and an NVLink that will arrive on Friday CET.
Will bench them then.
Now doing a comparison bench to prepare for friday, with my two ASUS GTX 1080 Strix. Stay tuned on DAZ Benchmark page for the results. Love to se your analysis!
/ Jonas
Cool. So did you get the expensive NVLink or the RTX version?
Out of curiosity I ran some code with the "cudaDeviceCanAccessPeer" function on my dual GPU's (1080ti + 1070), and as expected it said they were not capable of peer-to-peer memory access. I assume that's the big issue, whether the two GPU's can access each other's VRAM so, for example when a scene is rendering and a ray is bounced from one object that's being held in one GPU's VRAM to an object that's in another GPU's VRAM, the two GPU's can discuss among themselves about what happens to the ray.
As expected neither of the two GPU's on my system are capable of "P2P" (see attached printout). So it seems this might be a key indicator if, on an RTX card with an NVLink connector installed, the two can share a common VRAM.
So presumably with the right driver, and right NVLink connector, and whatever else is required, then VRAM stacking is do-able and CUDA will allow it.
According to the videos I saw on YouTube the NVlink for RTX is smaller and is a single link, whilst the Quadro Links are dual and are wider and won't fit. So I ordered the RTX link directly from Nvidia. ;)
I am very interested in your results with this as I am looking at getting the same pair with the nvlink but am waiting a couple of months to see what is what.
Right! Good desicion. I'm too impatient, but your way is the clever way.. but your way wouldn't be clever if impatient guys like me didn't buy the cards. ;)
I'm really curious about this VRAM stacking thing. Linus claims "There will be no fancy resource pooling with the RTX cards", but Octane and V-Ray developers apparently claim they've done it. But clearly the RTX NVLink isn't the full version (only supports SLI, not bidirectional, fewer links). I guess we'll just have to see what happens.
Didn't you say the same thing about Nvidia giving gaming cards ray tracing and tensor? I also recall you saying that Tensor cores were strictly for scientists and AI research and that non researchers had no use for them. You were unable to think forward about how Tensor could impact gaming, when it should have been clear that denoising could be applied to gaming just like I said it could.
If Nvidia has any aspirations of keeping Iray relevant then they have to do this to compete with the renderers that do. If Octane and vray do this and Iray does not, Iray will truly die. And considering what they've already done so far, I tend to believe they likely will. This does not in any way encroach on Quadro. Quadro does not enhance Iray in any way whatsoever, the one and ONLY reason anyone would buy Quadro for Iray is purely VRAM. And besides, its not like the 2080ti is exactly cheap. You are still talking about a $2500 investment. And I'll say it again, if Nvidia really wanted to prevent this, all they had to do was lock VRAM stacking out at the hardware level to begin with. They did not.
The gaming links are physically different. Just like nvlink 1.0 and 2.0 are physically different.
Again, Nvidia could have locked this at the hardware level. They did not. And there is your answer. I keep telling you the price of Quadro nvlink is not relevant, everything Quadro cost more. The low end Quadro nvlink have the same speed as 2080ti nvlink.
I guess it escaped me that the RTX cards don't have the double sets of NVLink fingers/pins/connectors/whatever like the Quadro cards do. So it seems even if you wanted you can't use the full Quadro NVLink bridges on the RTX cards. So if they only support uni-directional (master-slave) SLI at a much lower bandwidth than the full NVLink, how the heck can they get VRAM stacking to work? Anyone know? This is confusing. Or maybe it works, but not nearly at the full implementation of the Quadro cards. As in "yeah, we got it to work, but oh by the way your renders will slow down a lot due to the neutered bridge" or something like that.
I'm inclined to think Outrider42 and I are on the same page. I'm thinking that comparing a Quadro or dual Quadro's to RTX card(s) is to make us all a dis-service.
As I'm into motorsport I think there are similarities to this.
Lets say I love MotoGP and would like to buy something like a MotoGP bike for myself. Well I won't be able to afford a REAL motoGP bike, and also that it's stupid to buy a MotoGP bike, because I can't use it on the road to show off for all the girls.
SO, I buy a new sports bike that claims to have racing pedigree, and it actually does. It has engine features that derive from MotoGP, along with DTC, Racing ABS and the likes.
It will never BE a MotoGP bike, but it has the pedigree of one, and it is still fast!
So why would NVidia make a quadro card for us mortals (Gamers / Hobbyists)?
Well for the same reason that Motorcycle companies makes racebikes, because they can only sell a certain amount of quadro's to companies, but they can sell millions of cards to gamers and hobbyists like us. So therefore they introduce the RTX card, wich will please us, but be inadequate for companies. Because they are in MotoGP, and here you cant compete with a mere streetbike.
Maybe a lame comparison, but I think there might be some truth to it. Also, where would the next gen graphics come from if not from the MotoGP of Graphics?
So, in short. I think the RTX cards are Baby-Quadro's! ;)
I'm merely trying determine the facts, to address the belief that the RTX cards will allow VRAM stacking even though their NVLink bridges are not the full implementation. I'm certainly not trying to knock the RTX cards or anything like that, just get the facts.
Linus says no, there will be no resource pooling. Tom Peterson of NVIDIA says something like "yeah, but only if developers do the work to implement it", and it's not automatic like with the Quadro cards. Octane and V-Ray developers seem to be claiming that they have implemented VRAM stacking. And based on the major NVLink hardware differences between the Quadro and RTX NVLink interconnections, it doesn't quite compute (IMO) that VRAM stacking is do-able. Arguably the RTX version is just a high-speed SLI bridge, and since VRAM stacking hasn't occurred over all these years on other SLI connections, I wonder why (or if) it's really do-able now?.
There's no question that the RTX cards have the capacity to be amazing. And even without all the software pieces in place yet they still have more than what might be expected for a new generation of GPUs.
Well what if they are all telling the truth, and Linus's claim is derived from the awesome power of the Quadro's and that it seem unlikely that the RTX's will have it, from his stance. But will pooling need the awesome high speeds of the Quadro's NVlink or will it be enough with the RTX NVLink?
And do we KNOW that the RTX NVLink is one-way only? Or is that another assumption?
Why didn't they use SLI-Bridge on the RTX cards if that was enough for having an SLI option for the RTX cards, Why make a faster NVLink for the use of SLI???
https://www.pcgamesn.com/nvidia-rtx-2080-ti-nvlink-performance
FWIW, my simplified (and probably incorrect) view of SLI vs. NVLink is something like this:
SLI is used for stuff like gaming, where you do "alternate frame rendering". So if you have a game you're rendering, there's a master GPU and a slave GPU and they're connected by SLI. Both GPU's hold the entire scene in their memories, and the master assigns an entire frame to the other GPU. So for example GPU1 works on scene 36, and GPU2 works on scene 37. And you don't really need a lot of high speed, 2-way interaction between GPU's. They pretty much go off and do their own thing.
But NVLink is more about taking a single scene and, say, breaking it into two parts, and each GPU holds only a part of a scene in memory, thereby effectively doubling the total VRAM available. And if GPU1 is shooting a ray into the scene and it hits a cube that happens to be in GPU1's memory, no problem. However, if the ray has to bounce off a sphere object that's in GPU2's memory, you need to do some super fast communication between GPU's, or else the entire render slows down waiting for the rays to jump back and forth between GPU's. So I think in order to effectively do VRAM stacking you need a super fast, bi-directional communication between GPUS, and one that can handle zillions of rays bouncing around in a scene, like a single GPU does.
So the question becomes to what extent can a high speed SLI connection do what's needed for a high speed, bi-directional communication that requires a ton of bandwidth? So my point is, yeah, maybe technically the RTX NVLink can do VRAM stacking, but maybe due to the limitations of the connection (whatever those may be) maybe it will affect the results in terms of render time, because it slows down those calculations that occur between GPU's.
At least that's my thinking.
I'm most interested about the NVlink actually fitting the cards, then it doing what we think it says on the tin.
Interesting quotes by Nvidia’s technical marketing director, Tom Petersen from: https://www.pcgamesn.com/nvidia-rtx-2080-ti-nvlink-performance
“Think of the bridge more as we want to lay a foundation for the future,” Petersen explains, “and that requires us to move the infrastructure along. So we already have a multi-GPU application called SLI, why don’t we just make that work on a really high-bandwidth bridge bus? And once that works, and we get our bridges deployed, and people understanding that hey, this is a 100GB/s bridge, then game developers will see that.”
“NVLink fixes all that. So NVLink brings the latency of a GPU-to-GPU transfer way down. So it’s not just a bandwidth thing, it’s how close is that GPU’s memory to me. That GPU that’s across the link… I can kind of think about that as my brother rather than a distant relative.”
“What NVLink does is create the opportunity for new types of compute. That new type of computing could be cooperative – two GPUs working on similar workloads – or maybe it could be a pipeline where one GPU does the first part of the frame, the second GPU does a later part of the frame. Maybe it’s pre-processing or post-processing. When the GPUs are closer together you can start thinking about really different of processing things.”
Exactly. And my point is that is seems likely or obvious that the differing configurations of the two NVLink bridge connectors (RTX and Quadro) means there is some difference in performance or features. I'm just trying to figure out what that difference is.
I agree!
But one thing puzzles me.. How important is the Speed between two cards with the NVLink if you have no FPS to be bothered about, what if there is only one scene to render like in DAZ3D Studio?
IF the RTX cards support Pooling but it's too slow for gaming, might it still work and be a valid option for rendering programs like Octane, DAZ3D etc?
Maybe the higher bandwidth is only being used to get the frame data to the primary display card faster, thus an attempt to reduce the dreaded micro stutter that SLI historically had. Imagine the data load at resolutions of 4k and beyond. I suppose we could do the math...
I find it curious that, since multi card NVLINK reviews have appeared, no one really seems to be bothering with memory pooling. I wonder why? Maybe it's because gamings needs haven't really eclipsed 8-11 GB of VRAM and nVidia knows this?
Omen