General GPU/testing discussion from benchmark thread
This discussion has been closed.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
FWIW, I just ran the Sickleyield on my machine (GTX-1080ti plus GTX-1070) and it used to take 1:20. With 4.11 and all the new drivers it now takes 1:45.
That's 25 seconds, or 30% longer.
It also seems like it's scene dependent, since like I said with a complex interior scene it's now taking 27 minutes, and I'm fairly sure it was much less than half of that in 4.10.
Let's hope so, because simulations can be very time consuming and resource-intensive and I will be among the first in line to adopt a speedier method of producing them. The one sure thing is that technology will continue to march forward and it will be largely financed by those who dare to take the first leap into it, whether it is the most cost-effective purchase or not. These things don't happen quickly or smoothly and there will always be bumps in the road, but in the end, it is technology like this that is enabling small indies and one-man productions to produce media that wasn't even possible some decades ago. I am all for it. Let the speculation begin.
A new tech will always need time to be implemented and nine month is not really long. I recall I said to wait at least one year to get the RT Core profit and in my POV, developments and integration seem to be going faster than what I thought it would take
And if you remember the situation with Pascal Cards, people who bought them couldn't even render in DS with them after one year whereas for those who jumped in the RTX bandwaggon, they can already use them and get a substantial speed up
Sidenote, I don't think the excitement comes from tensor cores, but rather from Raytrace cores.
And really I don't know why you speak of complexity. For the end user, Raytrace acceleration will be tranparent and denoising only needs a few clicks. So no headache. The only choice that you have to do is to use the denoiser or not. And you can still render with 4.10 if you kept a copy (and I hope you did, so you can test if it's DS or the new drivers or some error margin)
Second sidenote : I may have misjudged the way the denoiser is integrated : Iray may have an internal Albedo buffer that would be passed to the denoiser without us knowing. The only way to check that is to do some render tests and compare denoised images with the internal denoiser and also with the external denoiser (or at least just with the internal and verify if it keeps texture details)
Third note : Flex and PhysX are nothing new and did not just appear with RTX. Both have been integrated in DCC apps and in games/game engines. If you want to play with these, you can try with Unreal Engine or Unity (which also happen to have RTX integration). DS has Dforce and since it's relatively new I don't think DAZ plans to kill it
Final remark : I don't know if we can train the denoiser ourselves. That would be great because that's the best way to improve it. If you want to do something about the denoiser, download the Optix SDK and check if the tools for the training are included. And let's hope that the training data are a separate file that we could update ourselves
The other obstacles are to get a correct albedo and normal AOV from Iray and preferably in an automated way
If you really want to get some headache, these are some food for you
Is it render time improvement though? It certainly isn't render time only.
Basically, I have the option of stopping the render after just, 100, 50, 5 or even just 1 iteration.
It is also about perception, about x iterations achieve a finished render, which is not the case from user to user, or even when comparing different use-cases.
Yep, at least it was about a bug being fixed.
Little point I forgot. You don't need to buy a RTX card if you just want to do some DXR testing program. Nvidia activated DXR for Pascal Cards with their latest drivers. That will only be utterly slow (a few fps) but that should be enough for your need if your goal is just comprehension
And if I'm not mistaken there is also a possible fallback in case there is no DXR
Iray has also existed for a bunch of years. And they decided to implement the new RTX-aware Optix API in Iray to get RTX raytracing functionality. There's probably no reason why they can't do the same with the new RTX-aware Physx and Flex, and I'm sure they're already using CUDA10. In fact I wouldn't be surprised if dForce was already built upon some of that technology. Iray is, of course, developed by NVIDIA, as are those other technologies. They added (or are adding) the RTX denoising functionality, so why not everything else? I find it hard to believe that they took Iray from NVIDIA, but added some other unrelated dForce plugin on their own inside Iray? Seems like a bit of a nightmare, espcially when NVIDIA's Iray folks are doing all the internal Iray coding.
And if not, since this is all NVIDIA stuff, it's probably fairly simple for the Iray team to call the Physx/Flex team (hey, they might even be in the same building) and say "Hey, we want to use the fancy new RTX stuff you guys have for physics sims, can you help us integrate it?"
And I presume most of these are written in a plug-in type of design where you can fairly easily grab the code and implement its functionality.
So if Iray is going to continue as a viable plugin for the foreseeable future (which I kinda doubt) then I wouldn't be surprised at all if they also say sometime this year "oh yeah, BTW dForce will also use the new RTX stuff since, it's been an NVIDIA plugin since the beginning. And we're going to include fluids and cloth.".
That's how good software is designed. In a modular fashion, using object oriented concepts, so you can easily address some pre-existing libraries without having to deal with the underlying code. So maybe if dForce is someone else's plugin, not from NVIDIA, it might be just as easy, and a good business decision, to jump to the NVIDIA plugins since it can give you all that cool new RTX stuff.
Though I'm not sure the point of this discussion, other than more tech-enthusiast speculation based on hunches.
Nvidia doens't integrate Iray into DS AFAIK, that's DAZ job. Nvidia just delivers the Iray package. Same for FLEX or PhysX and any Nvidia tech. And these are different from Iray and need to be integrated separately by DAZ team.
As for your "speculation based on hunches" that Dforce is Cuda based, if you already used it you should have noted that it uses OpenCL and not Cuda. Which means anybody can use it. And I don't know why you think it would be harder to integrate a non Nvidia API or to create one from scratch (You know there are other API, with some being Open source, out there right ?)
As to why I think that DAZ won't go full Cuda, it's simple. First it took many month of beta testing before the 4.11 release which in turn allowed Dforce products release. And I don' see why DAZ would restart from zero. There are also still some people who may not have a Cuda capable Card (3delight and Mac users). And going Cuda would prevent them from buying Dforce products. So for a "good business decision" I tend to think that DAZ deliberately chose not going Nvidia for good reasons
As to the point of this discussion, I don't know, you're the one bringing up techs not directly related to Iray or DS since both API are primarily targeted at game engines, so you're the one with the answer. I was trying to orient you to do some research to improve the denoiser since you seemed interrested, but I may have failed
I think you're misunderstanding. I speculated that dForce might be NVIDIA Flex based, or some other NVIDIA physics technology. And that doesn't mean it can't be implemented using API's such as OpenCL for non-NVIDIA hardware. It's done all the time. You write the core functionality, then use multiple API's to implement that on different hardware or operating systems. NVIDIA supports OpenCL (as well as a ton of other stuff) in its drivers. NVIDIA code is certainly not necessarily locked to NVIDIA GPU's. It's just that if the core code (like the new Flex) can utilize the new RTX architecture, then it obviously won't have that benefit on other hardware.
And I'm not sure what you mean by "DAZ won't go full Cuda". DAZ doesn't have to "go full Cuda". I can write an RTX-enabled raytracer that works in Windows Direct X (aka, DXR). I can write it in CUDA. I can use NVIDIA Optix. The sky's the limit on how you can implement code on different hardware and operating systems.
My only point is that I wouldn't be surprised if sometime this year we hear that Studio/Iray has implemented a new cloth/fluids/rigid body simulator based on the RTX aware Flex/Physx. Especially since they've implemented (or are in the process of implementing) two of the other RTX-aware technologies. Makes sense from a business standpoint, doesn't it? Heck, it's the same tech used in Maya's nCloth. And if dForce became RTX-aware? Sounds pretty awesome doesn't it?
And the only reason I brought it up was to emphasize the point I've always raised regarding RTX: it's extremely complicated, and it's gonna take a long time to implement, and we'll probably be here again trying to figure out the new Physx/Flex implementation in Iray like we are with the denoising. And therefore it seems somewhat ridiculous to try to figure out some sort of benchmarking for this stuff until it's better defined.
Maybe not, but it seems reasonable, IMO.
RTX-aware... what does that mean? As far as I know, PhysX and Flex are no more part of RTX than they were of GTX. Just because you see these mentioned in the RTX-platform marketing blurb doesn't mean that they are now improved over previous generations and make any use of hardware other than just the usual CUDA cores. If Daz hasn't implemented these things before, why would they now? And if these were truely RTX technologies, why would they implement something that only few people with RTX cards can use anyway?
Same reason they implmented IRay which only people with Nvidia cards can use
Please Dig and come with accurate infos
Iray works on Nvidia cards which also support OpenCL. Does Iray work with OpenCL ?
There's no OpenCL support for both libraries and there is no special "RTX aware feature". The API are using Cuda and as such are just updated when a new Cuda toolkit is out (aka 10 for Turing). And that's what you certainly take for "RTX aware". And when you know one of these has gone open source, that means that Nvidia pretty much gave up on making profit with it, so I doubt they spent some time making new RTX features for it
But in substance you're saying that DAZ may have made two Cuda Lib to work with OpenCL, even if it's not supported, and without even the need to include these libraries with DS (I've seen no trace of any DLL but didnt really dig ). So DAZ is practically doing magic and I'm impressed because they are stronger than the Octane Dev team as even them couldn't do that
Sorry but there is no way around, if they implement them, it's either DirectX or Cuda, but DirectX is a no go because MacOS. Which leaves Cuda. So to get Flex and/or PhysX it's Cuda....or Cuda. That's why I spoke of....going full Cuda...unless they went to the hassle of rewriting the complete libraries (as well as dependencies) to be OpenCL compatible (that's what you're saying right ?) and rename them which is why I found no trace of them (Damn it! That is a sooo logical explanation).
And finally you're confusing RTX tech which consist of RTcore and Tensors, with some old cuda based tech and speak of complexity of RTX and attempt to dissuade people of doing anything in relation with RTX because...??? It's too difficult ? None of us understands the tech? It will be a burden to take account of all Nvidia tech released since the beginning of Nvidia, for a benchmark that has nothing to do with these techs ? I ate an apple this morning and like my coffee black? It's the Return of The X-men? Or the Rise of The Xenomorph ?
Let's see...do people need to fully know all the engineering complexity of a car to be able to measure it's speed ?
...No. It's about finding a measurement unit and a way to do the measurement in the best possible way by defining key factors and some restrictions (ex : user friendly )
Do we need to wait for the application to begin to discuss a better measurement unit and the way to do it? We know roughly what is to be measured. The big X is the acceleration magnitude of the implementation, although we also already know it should be max 3x. But that only influences the final scene setup. And finalizing it will be done quicker if you have already prepared something instead of waiting. So...should we be waiting as you suggest ????
@Robert Freise The main renderer doesn't prevent sales since there are converters and you can still render with the CPU. And I'm not quite sure but the Reality plugin was available for AMD GPU at the time Iray appeared ?? And there is still the possibility to export to blender via a freebie and I've also read some posts about a Maya exporter which would give access to some other renderers. And there are also still the different export format (not straightforward and user friendly I agree but functionnal). I wouldn't blame DAZ for the choice of Iray. There wasn't a lot of reliable GPU OpenCL renderers at the time DAZ chose Iray
So Takeo.Kensei, I guess you're saying that we'll never see an RTX-enabled physics/cloth/fluids/whatever sim in Iray/Studio?
Bummer. But thanks for the info.
Since I doubt RTcore can be used for solvers and applications that can use Tensors for acceleration are primarily Cuda applications, and didn't see any AI based physics simulation, yes
So back to the benchmarking topic...
I think I mentioned elsewhere the difficulty, IMO, of attempting to do highly accurate benchmark numbers, especially the latest Studio/Iray. So many different cards and configurations and software versions and so on.
But here's yet another wrinkle I noticed recently. I loaded a scene and hit Render. It took 10 minutes, 5 seconds. When it finished I hit Render again. It took 10 minutes, 52 seconds. Exact same scene, exact same computer, exact same configuration, and it took 47 seconds longer. Almost 8% longer.
The only difference was that during the second render I was using Google Earth, which uses a lot of the GPU (which you can see if you use Task Manager where it breaks down GPU usage by process).
So, again, as I mentioned long ago when I put together my simple spreadsheet listing render times for Sickleyield, IMO it makes no sense to get down to 0.1 seconds when reporting render times. I assumed the render times were accurate to maybe +/- 15 seconds, though even that may not be conservative enough.
Unless of course you require that everyone who reports render times first check what other processes are using the GPU and turn them off prior to doing a render. Which requires you also set up Task Manager to show what processes are using the GPU, which apparently isn't a very popular practice.
Makes sense that other processes using the GPU would slow down Iray. I don't think there's anything too complicated about that. Google Earth is essentially like a little game using OpenGL or DirectX. Surely the average joe isn't going to benchmark Iray while playing a game. The same applies to any type of benchmark. If you're doing video encoding while running a CPU benchmark you will mess up the results too.
Of course, in hindsight it makes sense. Yet surprisingly this is the first time I've heard any mention of it here. Was anyone aware that even Google Earth might affect benchmark results?
So unless you state that you shouldn't use any software which uses the GPU while running a benchmark your benchmarks might be very very inaccurate. Which complicates things, don't you think? Lemme guess, you'll say no.
I know that before starting a long, resource intensive render to run unattended, I will at least close/restart DS and close everything else, if not reboot the system. I suspect others do the same.
This exact scenario is one reason why I find Windows 10 so offensive, and completely disagree with the repeated assertions about Windows 10 and VRAM. Windows 10 does in fact hog, pre-allocate, reserve (whatever you want to call it) VRAM. I couldn't disagree more with any characterization that it's simply "doing what any good OS should do".
When Windows 10 reserves VRAM just in case, that is in fact Windows 10 hogging it. It's not some other application that's not even running yet hogging it, it's Windows 10 hogging it.
- Greg
No, a benchmark would be run on a system with as little else as possible going on, certainly with no other activities likely to tax the areas used most inensively by the renderer - which people will generally know since it's also the way to get maximum render speed.
I think that's why RayDant is rooting for a measurement unit like Iterations per Day/Hour/Min/Sec in order to reduce variance
For people still on Win7 the task manager doesn't show GPU usage.
I don't know if googleearth can affect benchmarks. Firefox and Chrome and other browsers have been using hardware acceleration for a few years, without forgetting flash based tech
But they use 2D/3D acceleration and GPU memory to do so and not Cuda. You should check if Compute or Cuda ressource are used
In the same vein, does watching or encoding a video or using any CPU based application (like a lot of these apps you may have that autostart, like Antivirus, Smartscreen...) while benchmarking affect the result?
* Edit to be more clear : Are the numbers taken from DS log where the render time is strictly only render time and doesn't take data transfer in account so that eventual delay due to GPU memory utilisation by other program may be ignored ?
Richard, really? So everyone but me knows exactly what apps you shouldn't run while doing Iray benchmarks? Wow, I'm like all impressed. Where can I find that list? It never occurred to me that Google Earth might be a factor. Apparently I'm the only one....
As far as Windows "hogging" VRAM, while I do agree that ideally it should allow you to select how much VRAM it reserves so that other processes can use it (such as, "I'm a gamer, so don't let Iray use all the VRAM while rendering cuz I might want to play while I'm waiting"), assigning nefarious intent is up to you, but I assure you there is a rational reason for doing it. Especially if you consider how much of your computer resources are taken ("hogged") by other applications.
For example, have you ever considered my many GIGABYTES of system RAM your browser is hogging right now without your approval? Chrome is using 1.8GB of my system RAM right now. Would you prefer that Chrome is allowed to allocate my entire 64GB just in case it needs it? All it requires in the software world is whats call a "memory allocation" request. One line of code, and they can grab your entire memory.
Have you ever considered how much system RAM Windows is using to do all of its stuff without your approval? While you may not fully understand or agree, one of the primary roles of an operating system is to manage resources so that everyone plays together nicely.
You can open a command line and run nvidia-smi.exe to get all the apps that use the GPU. I guess you'll be surprised
Feel free to run your own tests. Google Earth is free, and an excellent application.
I'm just saying VRAM is too expensive and valuable in the rendering process to be sitting idle when it could be in use by the application that the video card was purchased for in the first place. Is that hard to understand?
- Greg
Not at all. Which is why I'm wondering where are the parades of angry Chrome users who are furious about how much system RAM it's hogging? I'm just suggesting we be consistent in our outrage, and understand the rational reasoning behind it all.
Maybe some gamers are glad that Iray doesn't take all the VRAM, so they can play a game while waiting for a render to finish. And render time may not be important.
Google Earth is fairly obvious. How do you think those 3d graphics get rendered? Maybe this has to with your disinterest in games, which get rendered in the same way. These graphics cards we're using are made first and foremost for playing games after all.
How about this: don't touch the damn PC when you benchmark?
I won't. What Richard tried to tell you was that common sense is to not run any other apps while benchmarking unless you want to deliberately sabotage your measurement
Like I said, if you open Task Manager and configure it to show GPU usage under the Details section you can see all the processes using the GPU and its VRAM, per process.
Not touching the PC when you benchmark may not be sufficient, since some processes may be running and using GPU resources that you are totally unaware of unless you first check that list as I suggested.
IMO as long as you don't do anything within these GPU accelerated applications, no work will be done on the GPU. Background processes are not what typically runs on the GPU. You need to do something to evoke activity.
I'd also argue it depends on what exactly is done in these applications. Chrome uses some GPU acceleration, but I doubt that even heavy browsing during a render is going to influence the result much. Photoshop uses GPU acceleration. Maybe if I panned and zoomed none stop like a mad man during a render, I would affect the GPU enough to make a difference. But who does that anyway?