Why the most important studios use cpu for rendering?
Super cheese sandwich
Posts: 633
in The Commons
I just saw a documental last night. I'm just curious. I don't want to compete with Universal studios lol
If rendering with cpu are the best choise why all the hobbiest uses gpus?
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
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Because most hobbiests can't afford to buy 1000 PC's?
Yes, that too LOL
But the question is why they don't use 1000 gpu instead of 1000 cpus? (leaving aside the memory restriction and the power consumption)
Because, as Kendall Sears would explain more fully than I can, it's actually much easier to adequately cool a CPU than it is a GPU, plus the well known rendering engines like 3Delight that they use have clients that do not require a functional graphical interface on the rendering PC. This means that the main power load on the power supply is the CPU and local drives, not a device that is not essential to operation of the the system.
Memory restrictions of the GPU is no doubt a huge factor, it's not unusual at all for scenes to go over 64Gb, or even 128Gb. My guess is that a frame from the vast majority of animated films made today could not fit in the 12GB of memory available on a Titan X, or even the 24Gb of a Quadro M6000. There are also no doubt certain functions that the studios use for certain effects that don't lend themselves well to efficient processing on GPU's (the stream processors on GPU's have fairly limited capabilities/logic compared to CPU's). There may also be some limiting control and fault tolerance factors when trying to use GPU's in massive production work compared to CPU's.
However there are many small independent studios that have embraced GPU rendering in a big way, because using the GPU to render is like having a render farm. GPU rendering is particularly popular for architectural visualization. Octane Render is very popular with small studios, and independents because it doesn't have memory restrictions like Iray (can store texture memory in system ram, so you are only limited by the amount of RAM on your computer, rather than just what you have on your GPU).
This.
I have a desktop with 2 8 core Xeons and 64 gigs of ram and a GTX 980Ti card with 6 gigs. The amount of time it takes to render an average scene of mine between the two are pretty close whether I use CPU or GPU. That desktop probably looks like a toy compared to some of the rigs in the big studios.
Blush....
There are actually a plethora of reasons but those given are definitely in the mix. For still renders or semi-motion walkthroughs (architectural, design, visualization, etc) PBR rendering works well. For "full motion" VFX and CGI there are a lot of very complex calculations that just don't perform well on GPUs. One can reference the CISC vs RISC CPU wars of a time ago to see why (GPU is RISC while CPU is CISC -- literally).
Cooling can be a problem as datacenters are very sensitive about the BTU output of EVERY piece of equipment in the server rooms. It is also the Watts vs Work equation. For complex operations (motion blur, antialiasing, light matching, and other advanced techniques) it can take several GPU operations to do the work of 1 or 2 CPU operations. Over time the electricity use WILL add up.
With this being said, there are many studios that are using Tesla Units for some precalculations that are done before the scenes are transferred to the render farms. See my post on the MASSIVE amount of work and data required to do dynamic atmospherics (http://www.daz3d.com/forums/discussion/106011/anyone-else-drooling-over/p1) and you can see where the Tesla GPUs can be helpful. In the end though, the final rendering is done on CPUs because of the resource use and other various complications.
It is late, and I can (and have) lectured for hours on these very topics in University Settings (and will be again here very soon). So, for the sake of the reader's sanity, I will refrain from my normal propensity to write a textbook on the various details that come into play. If there is enough interest, I can expound later.
EDIT: To get this back OT, the reason that hobbyists gravitate to GPUs is four-fold:
Kendall
Also, remember that technology is a moving target. I think there will be more movement towards GPU-based computing over the next few years (I see some movement in that direction in the not-quite-related area of scientific computing). Studios aren't going to give up their existing render farms right away, though.
One of the main reasons is memory. Even high end GPUs cannot han
You can already do that. I do it whenever my 4Gb cards can't handle the scene.
TD
We can, but it's slower than the GPU.
Scientific computing has always gravitated to "new things"... witness the use of the PS3's cell processors clustered together as supercomputing (when the PS3 was still allowed to boot into Linux). The vast majority of "scientific computing" is now moving more toward distributed computing and away from centralized supercomputer centers. The computations and analyses done are well understood and no random variance is introduced into the procedures -- any machine in any environment/OS will suffice.
Conversely, Studios have to be very careful about the versions and OS differences of the different nodes. For example, rendering a scene on 3DL or PRMan in Windows will give slightly different results than the same scene rendered in 3DL or PRMan on OSX or Linux. Having to go back and make the scenes look homogenous after rendering is a huge extra cost. So most Studios just render everything on Linux nodes to keep things looking the same and reduce the costs for OS Licenses.
One also has to take into account that Studios do not render "just once" and will use a multitude of methods along the way. Major projects are rendered at different quality levels at many stages along the way. There will be a "functional render" that effectively uses bounding boxes to show whether collisions, poke-thru, or positioning is correct. Then there will be several "pre-viz" renders that will cover different aspects of the process. There may be a rendering for camera angles, another for lighting levels (NOT the same as final lighting), one for rag-doll physics or hard-body interaction (car crashes, etc), another for clothing dynamics (lowres), another for hair/fur (lowres), another for atmospherics, and on-and-on. Many of these stages may be rendered using GPU's and in either real-time (camera), close to real-time (camera), or gaming modes (to allow for frame reversal and free-movement scene examination). Most of the time, this will be done at the design workstation, or at a specific high-powered workstation with a VCA/Plex setup. After all of these are done and approved, then the "final render" is performed.
Kendall
I used to have my PC in one of those parallel distributed medical calculation networks.
You have described our pipeline quite accurately
Any animated Figure you see my animated films has been "rendered" a minimum of FOUR times often more
First the Major body motion is "blocked out"
with a realtime Iclone Avatar or even a very primitive
Stick figures in "Endorphin" if there is any ragdoll physics involved,
so the first "renders" are open GL previs renders with default lighting to check the overall motion.
Then the motion is retargeted to a Nude, gray textureless genesis 2 figures in Daz Studio ,Via BVH from Iclone pro or Endorphin.Refinements are made in Daz studio using graphMate/KeyMate which often involves applying a Globle Fix to the hands& fingers to correct the infamous "BVH Death grip "that occures even with custom bone mapped BVH imported from external sources.
Also any lipsinc is applied Via mimic live or mimic 3 pro
if the figure has a speaking part
The second undressed basic 3Dlight open GL Previs is rendered from Daz studio to verfiy refinements& lipsinc and saved as Daz studio animated pose file.
The "Film ready Actor" is loaded fully dressed and the saved animated pose file is applied to him or her.
Third 3delight open GL previs render is made to inspect how the clothing is holding up under the Character motion.
And **some** DAZ Store clothing items DAZ sadly FAIL this stage of the procees and have to be replaced with clothing that was properly built to remain conformed for more that one single pose.
these full dressed Previs renders are marked "Approved for Export" of their MDD point level Data to maxon Cinema4D to be applied totheir fully lit and textured versions awaiting in C4D.
In C4D the MDD animated mesh is "shot" using C4Ds versatile professional camera system that can actually switch cameras in Mid render so basic camera cuts between interacting Characters can be "Shot" at once
some "in render" visual effects are applied in C4D such as animated computer interfaces/Screens and cloth or hair effects
Fourth Open Gl previs render is done in C4D to check animated camera cuts & Shot framing.if no issues found the shot is approved for final HD render to uncompressed Targa image files with blank Alpha Channel backgrounds if there is the be major compositing of layered background scenery that would choke up the render and exceed
"Frame budget" of Seven minutes per frame."backplates" are rendered in their own separate pass.
...but wait theres more!!!
Uncompressed Targa Sequence is loaded into adobe After Effects
for colorgrading , gamma correction,Sharpening, blooms sometimes time remapping,and of course any Special effects such as lens flares and teleportation effects and other sci fi eye candy.
Multi layered After effects comp is "rendered" one last time to full res composte quicktime ready for final edit& sound into main film project in Apple Imovie.
all resulting in maybe a few mniutes of finished footage.
like below
https://drive.google.com/open?id=0B2TYEp536iB8MkJSNE8xUGV2SXc
Thanks for all the answers!
"""
So a small render farm is a not financially viable for a hobbiest?
My pc consume almost 1000W with 2x980 ti and one 970. How many racks I would need to match the gpu rendering speed? 10-15? (10 racks = +10000W aprox?)
Thanks again
This is completely dependent on what you are trying to render and which GPU setup you are comparing with. If you are using 3DL then the answer is that you are already beyond the speed that GPUs will go since 3DL doesn't use GPUs. If you are shooting for "real-ness" in your renders and are using Iray, there are a number of factors that come into play. You may "never" reach the performance of the GPUs using the CPU mode because Iray is optimized for GPU. Not even the best 4x8 Core Xeon (64 cores = $15000US at least) can compete with a $6000 Quadro M6000 (unless your scene blows past the VRAM size of the card) on a render engine optimized for GPU use.
Where the real comparisons come into play is comparing a CPU optimized engine with a GPU optimized engine. Presuming that you can get comparable results from both engines, it is entirely possible for a CPU optimized render engine to outperform a GPU optimized engine under the right conditions. If the scene being imaged is completely precomputed (no engine based physics or dynamics) then the GPU renderer simply won't be beaten since rendering is a task that scales well to massively-parallel architectures. Once complexity, or great size, becomes involved it is entirely possible for a CPU based system to outperform the GPU system since some of the more complex operations will cause the scene to unload from the GPUs to make the calculations, and then reload the setup to continue the rendering. This unload, calc, reload cycle is a killer for GPU based engines. A similar thing can happen with scenes that blow past the VRAM available and force the GPUs to bail on the process and the CPUs pick up the slack until a scene that fits in VRAM is again encountered. Even with engines that can swap out textures to main memory, there are many conditions that will cause bus stalls long enough that a CPU engine can overtake the GPU engine because the GPUs are sitting idle.
In the end, it boils down to "There is no 'best' for all rendering situations." You must select the best tool for the job that you are doing at the time that you are doing it. This takes the willingness to look beyond "preferred" solutions and the realization that there is very likely going to be constant learning involved if one wants to do the job correctly. Studios have the flexibility to hire the staff to make the decisions and do the work, Indies/amateurs/hobbyists have to learn it themselves. Unfortunately, there is a propensity toward "fanboi" behaviour in the non-Studio arenas that lead people to throw out valid solutions. In the interest of not getting another post deleted, I'll leave it there.
Kendall
Thanks Kendall!!
I have always used the CPU for iray takes anything between 10 to 30 mins ,I just can not spare the money for a super game card ,I dont find any problem.
Thank you! This thread has taught me a lot, andhelped me to understand a few things.
...lots of stuff to digest here (and I already just had lunch).
So to boil all this down.
My interest is single frame illustration, however I need extreme high quality for rendering in large format to create gallery quality prints. Iray is primarily a GPU engine However as mentioned GPU memory is fairly limited 24 GB on the forthcoming P6000 which will most likely retail for around 5,500 - 6,000$ per card. Short of hitting tonight's lotto, that isn't a reality, so my best bet would be a pair of 1,200$ Pascal Titan-X.s with each 12 GB (this is all provided teh SDK, driver, and CUDA 8 stuff gets worked out soon of course).
As I mentioned elsewhere, when I have both the Daz programme open with a scene loaded it takes a whopping amount of physical memory (again my rail station scene alone eats up 8.7 GB in idle mode). So first, how does this this translate to VRAM for rendering purposes, does the scene take up the same amount of memory on the GPU? More? Less? Would I be better served going with the dual 8 core Xeon 128 GB setup originally planned?
Not quite...because part of that 8.7 GB is the program itself...which isn't passed to the GPU. Also Iray does it's own texture compression, so the full, uncompressed image files will be in RAM but not passed to the GPU...but all that said, thinking of that as a max is probably a 'safe' bet. It will probably be much lower than that being given to the card for rendering but it shouldn't go higher than that...
i'd like to use carrara to render for the uhd monitors.
what kinda hardware should i be looking at?
xeon vs i7? cores and render buckets vs higher ghz?
thanks!
this took 11 days to render on my i5 quadcire,
and i reversed the frames in sony movie studio to add another 25 seconds to the clip
This doesn't quite hold. It is true that the effective size of the render footprint and the size of the in memory footprint are mostly independent. However, to say that the render size will be likely less than the "design time" is not completely valid. The memory for the design time use is resolution independent and usually represented at a much smaller resolution on "screen" therefore some things will not necessarily be represented at all by the memory use. It is entirely possible for an image done at "gallery" sizes to vastly balloon when rendering because the textures don't necessarily compress in size, but may in fact expand due to details that would be "pressed out" of the scene at smaller resolutions becoming prominent and causing the texture(s) to be recalcalculated at a size that is now visible. For instance, bump and/or displaccement values that would normally fall under the precision of the engine due to small size/distance from camera suddenly become an issue because not only are they now within the precision to use, they cause the system to recalculate the rises and valleys that previosuly didn't exist and increase the effective surface area by the new volume(s) generated. Then one must take into account that in these situations new "geometry" now exists because of the displacement and that new geometry must now be compensated for in the memory of the engine. In most cases, this will not occur on the VRAM side, but will happen on the CPU side and then the resultant larger render set is loaded and rendered. Now one must consider that reflections and incidental shadows must now be calculated based on a possibly MUCH larger set of facets than were shown and/or used in design time.
There are other complexities that are involved in this but I believe that this gives an introduction to some of the considerations that come into play.
Kendall
I guess we can go back and forth on it...but without actual measurements, it doesn't really matter. You are probably right, though...I wasn't considering a couple of the other things you mentioned.
18 cores pron
Kyoto Kid, if you want to use Iray with your present PC, you could always tick CPU only and use your existing system RAM. It will be slow, like LuxRender, but it's better than nothing and you can save your money for more RAM which will be much cheaper than any high end card. As you have said many times, you are just doing single frames and not animation.
There is not a simple answer, because there a many factors at play. For processor speed, when using the same processor version, it'seems simple. A 4.0 GHZ processor will give you a performance increase of approximately 12.5% over a 3.5GHz system. But, determining the performance increase when using different processor families gets more difficult because of several factors including instruction set optimization, cache, motherboard chip set, application being used, etc.
In general, a dual 6 core processor (12 thread) xeon system running at approximately the same speed will give an approximate 3x speed increase over a single processor 4 core (8 thread) i7 system for rendering get with Carrara. Carrara probably will not take advantage of any of the new instruction set optimization implemented in the i series processors over the last few years, because the render engine hasn' t been updated to take advantage of them. On the flip side, Carrara may take advantage of some of the calculation optimizations and larger cache found on xeon processors. My guess would be that a similar generation i7 would have slightly slower render performance in Carrara than a xeon running at the same speed.
Bottom line, in general more cores/threads means better performance. I would expect a dual 6 core xeon processor system (12 cores - 24 threads) running at 3.2GHZ to easily double the speed of a 3.8 GHZ 4 core (8 thread) i7 system. Using a 6 or 8 core i7 will change this a bit. Also keep in mind that all applications don't scale well when adding processors/cores beyond a certain number. Carrara seems to scale well from what people have posted, so a dual 6 or 8 core system should perform quite well (keep watching the thread over in the Carrara forum to gain more insight on multiple processor/core scaling with Carrara).
In the general case, I would agree with your assertions. Unfortunately, the nature of the content that we're dealing with no longer fits the "general case." Part of the problem lies in the practice of PA's baking details into the bitmaps instead of building them into the geometry. This (obviously) comes from all of the years of 3DL where there is a massive penalty for the use of geometry and almost no penalty at all for adding the detail in the bitmaps. Iray is designed for handling geometry, not maps. It is extraordinarily good at handling massive amounts of vertices and facets, but pretty poor at handling bitmaps, and worse at handling modifiers encoded as maps. Witness how Iray needs to have great levels of sub-division to handle even mediocre detailed displacement maps.
Unfortunately, DS PA's and users are used to being able to use extra-high levels of definition for displacement to replace what would add probably millions of additional facets of geometry. A great example of this is the "Fabricator" line of textures. Baking all of the fabric weaves and textures into geometry would be a nightmare for the UI to handle, even with the larger GPUs. But that is exactly what Iray was built to handle. Many are still trying to make use of previous methods to get by with Iray.
As it stands, many folks have their "render subdivisions" turned up pretty darned high so that displacement maps can actually have some effect. One of the effects of this is that right before the scene is sent to the GPU a great many of those millions of polygons that were mentioned before are created so that the engine actually can do some work with the maps. Holy exploding scene sizes Batman!
Now, as has been mentioned before in other threads, this does not have to be the way it is. The users can make the necessary changes to their workflow to offset the sizes and the PA's can also modify their methods of creating content to more "fit in" with the Iray way-of-doing-things -- although at the expense of 3DL. So far, I've seen no indication of interest on either side of doing any of it. Users continue to rely on hardware growing the necessary VRAM space (sometimes ending up waiting long periods of time), and PA's rely (and hope) on the fact that nVidia and DAZ will likely come up with some magical solution that "makes it all work."
Unfortunately, I think we're rapidly approaching a point where neither of these are going to come to satisfactory conditions, and things are going to "break". We've already seen this with the nVidia pascal architecture and the release of the hardware far before software for non-gaming was ready. Those who were relying on the newest hardware to solve the VRAM issue were/are sorely disappointed and continue to wait. The PA's continue to put out great looking content using the same techniques that were used prior to this point -- minimalistic geometry with huge 4Kx4K textures for every surface, with some small changes for the way that Iray handles/mishandles maps. DAZ is in a holding pattern waiting on nVidia to release the necessary SDKs, while everyone prays nVidia doesn't change something basic again that causes current products to all have to be redone -- again. Everyone is waiting on somebody else to resolve the "issue" while continuing to bang away without making any changes themselves to compensate. When "someone" doesn't make good on "their" part things are going to lock up like a hydraulic system that exhausts the reservoir of fluid.
To bring this back around to the thread topic: Now, knowing all of what has been stated in the thread... you're the Executive of a Studio and you've got 200+ million dollars on the line. Are you going to chance it with technology that continually mutates in unknown directions, or are you going to go with what you know will get the job done in time for the release date?
Kendall
Keep in mind that the dual Xeons have *2* distinct buses to the RAM, one optimised to the RAM primary to the chip and one secondary to the RAM for the "other" chip. Chip A will use DRAM A by default and Chip B will use DRAM B. So long as the processes don't migrate to the other chip, things will go very fast as the RAM accesses are dis-associated from each other and bus locks are fairly rare (also included in this is the Xeon bus controller is MUCH more complex than the 'i' series). The 'i' series forces all cores to share the same memory bus and access locks happen A LOT.
Kendall
access locks dont sound effecient.
would be awesome to do that 11 day render in a few hours
...actually no the with the programme load it is jsut over 8.9 GB