Any scenario in which a Threadripper 3960x would out-render 2x RTX 3090's?
JasonWNalley
Posts: 122
So, I started rendering a scene, and at around the 30 minute mark I checked the progress, and it had reached about 240 iterations. However, I noticed that it was taxing my CPU rather than my GPU, having recently swapped out texture maps, I know DAZ sometimes doesn't flush out all of the VRAM from the video cards, so I restarted DAZ and started the render over. This time at the 30 minute mark, it was at 75 iterations, I checked and it was definitely using my GPU's and not my CPU. Is there any scenario where this should happen? I opened up GPU-Z and everything seems to be functioning as normal... Not sure where to begin to try and figure this out...
Comments
What does your log say about it? (Help->Troubleshooting->View log file) Do not copy the contents of the log file to the message area, but attach the text file to your post instead.
Well, I read in the log to turn off SLI (though that's never been a problem before) and that seems to have fixed it. I ran a couple of other tests in the interim, Camera 2 is a zoomed in view of the models face and it was the view giving me the issue. The regular camera is a full figured shot and it was rendering just fine with SLI enabled... So I have no idea what's going on. Hopefully I'll be getting a 3060 or something soon to use as my Monitor graphics card and then I can run NVLink on the 2 3090's since I guess for NVLINK to run properly they have to be in TCC mode and not WDDM mode...
I remember it having been said that SLI should not be used. Have not heard the NVLINK needing TCC drivers either.
In WDDM mode, with NVLink Peer Group Size set to 2, it's precarious, textures get kaleidoscoped and colors turn crazy (at least in my experience with it). After digging on the forums, I saw several posts that say that the NVLink doesn't work consistently and has texture issues sometimes with WDDM and that they needed to be run in TCC mode so a 3rd graphics card, or onboard graphics, was a requirement. I have yet to get a 3rd card, so I cannot tell whether or not that will fix my particular issue...
Had a look as well, and didn't get the same impression... Some posts were old, some about the A-series cards (completely different thing) and then one should take into account, how experienced one posting is in troubleshooting and configuring their systems.
These 2 renders in this log are SLI Off, and the first one is NVLink Peer Group 0 with the other at 2 (I do have an NVLink Bridge). If you notice, in the log, it seems to favor 1 card heavily over the other (One is doing less than 100 iterations, and the other doing closer to 7,000 iterations). I'll follow up with an SLI on post here in a bit. The results are interesting... Here are the two resulting images from the first two passes (labeled to include group size).
Edit: Hit submit too early. As you can see from the attached images, there's nothing different about them (don't mind the texturing/coloring I am currently testing different looks in Substance Painter). But what's interesting is what happens when SLI is turned on, which is coming next...
Here's SLI with Peer Group size set to two. I got a bit tied up yesterday and was unable to do SLI with Peer group size 0 so it's running now. Notice the weird kaleidoscoping of textures and strange colors. This only happens in this configuration (SLI + NVLINK both on).
What you call kaleidoscoping (on the boots) is pattern that Substance Painter uses to fill unused areas of the textures and maps
Edit: What are your rendering settings and the dimensions you are rendering to?
Have you checked, which objects these are?
I understand what the Dilation is and know that that's what it is (the stripes on the boots), but that's not what I am calling kaleidoscoping. It's more prevalent in a scene with a background/environment (I first noticed it on an urbanfuture environment), but the textures all seem to disperse themselves over the scene in a spiral pattern, repeating over and over. It for real looks like a kaleidoscope of bad colors and bad textures that are on the wrong object. For instance, if you look at the last one, the teeth map is on the face instead of on/in the mouth. I find it strange that this only happens when NVLINK + SLI Are enabled (so far anyways that's the only time it has shown up). None of the settings or textures were changed between the renders, I only had to restart DAZ when enabling SLI. Everything else was just changing peergroup 0 to peergroup 2 and back again.
I have no idea what those 2 warnings are, and don't really know how to track them down.
Here's SLI only
3840 x 3840 what other settings do you want to know about? I could screenshot the render settings and post here if that helps... but nothing changed at all rendered settings wise between the 4 renders...
Edit: I did retract the lightsaber blades between the last two, forgot about that, I just wanted to see what it looked like retracted and if any light escaped the front. The intent is to animate this scene once I've finished all of the texturing to my liking...
Those warning messages usually indicate the you have set a SubD level that is "too high" for the number of base polygons already present in the object, so your SubD level is being reduced.
Yeh, I figured that much, but I don't know which objects they could be, and since it doesn't seem to affect the render in any way, I just left it as is... the figure and clothing are at SubD 5... I have no idea which objects (if any) are at subD 2 or 3.
I was wondering about why it takes half an hour to render a scene that would probably render under 10 minutes on my single 3060 and dimensions of the render and the rendering settings could give an explanation, but with the latest at 6+ minutes at 3840x3840... Still slow considering, but...
The warnings and info from the log mean that you have objects in the scene that have insanely dense geometry to start with and situation made worse with SubD
If you set the viewport to hidden line, or whatever other mode that shows you the geometry mesh, you should be able to spot the dense mesh.
Should not cause your current problems, but usually insanely dense mesh means the creator is still learning the ropes and there might be other problems as well.
Ahh, the shirt is more dense than the rest of the scene mesh-wise, and so are the buttons/rivets on a couple of pieces of clothing. This is what they look like
I zoomed in on the lightsabers and they seem to be crazy high too, but they don't have a "High Resolution" under the resolution level and I cannot change the SubD (because it's not an option due to not being a High-resolution model).
Try to select the shirt in the scene tab. In the botton of the scene tab mid, there is a little thicker line. Click that and it will expand. Then scroll downm and it will give info about the object mesh.
Primary
Name :
Ahsoka_Suit
Label :
Ahsoka Suit
Class :
DzFigure
Metadata
Scene ID :
/data/levie/Ahsoka/Ahsoka%20Suit/Ahsoka_Suit.dsf#Ahsoka_Suit
Content Type :
Follower/Wardrobe
Compatibility Base :
/Genesis 8/Female
Preferred Base :
/Genesis 8/Female
Object
Name :
Ahsoka_Suit
Class :
DzObject
Shape
Name :
geometry
Class :
DzGraftingFigureShape
Geometry
Name :
geometry
Vertices :
15,383 / 240,110
Faces :
14,882 / 238,112
Lines :
0
Class :
DzFacetMesh
If we're focusing on the shirt, I did use the thickener plugin on the shirt for when I am close up so it's not a razor thin edge (which is some of the poke through you can see on her back from the underlying mesh (it's why the leather pattern looks so patchy). I can remove that object from the scene and see what happens...
Oh yeah, the lightsaber is the culprit.
The lightsabers look like solid objects, so they are the most likely source of "119 million triangles" message.
Dense geometry and high SubD increase the rendering time and use more RAM and VRAM. When increasing the value of SubD by one, every face on the geometry is divided into 4 faces, so If one has one face at SubD 0, the same area is divided into 1024 faces at SubD 5 - How big was that one face originally when projected into real world dimensions and does the result gain anything by dividing it to 1024 faces?
In my experiments, I found that going past SubD 1 (for G8 figures) is waste of resources when doing full body images, but I'm rendering with dimesions fitting my 1920x1200 monitor
Hmm... well, I guess it's time to learn a new skill... I really like the lightsabers, and when I went to create UV meshes from them so I could re-texture them they were a pain. I was going to re-model them, but don't really know how to get an object like that back into DAZ with Morphs (saber off/on) and be able to be parented to the hands. I can work off of base models and sculpt and my own morphs in ZBrush well enough, but creating from scratch is a problem :-D
For the saber. It should anyway be its own surface, and then you can just set cut-out oppacity to 0, and then it will be invisible.
Well, normally I would keep SubD down at 3 or 2, but I will be doing a lot of closeup in this animation and it's going to be rendered out in 8K resolution.
I assume one can reduce the density of the mesh in Zbrush, no need to create the object from scratch.
Yes, that works for simple on/off, but for turning on a lightsaber and it coming out of the hilt, and then going back in a morph works better (these sabers have that morph built in).
I did try that, but something wonky happens when I attempt to re-mesh it... lots of parts become extremely deformed... I will toy around with it some more... I just started using ZBrush a couple of weeks ago (been using DAZ for ages but am starting to get more serious with it) so it could be user error...
8K animation... You really want to keep the density of your objects at what is reasonable.
I understand that, but this is for something specific... I generally work/render in HD or 4K, this project is a bit special... The kaleidascope thing is something that reared its head when I stumbled upon the information about Peer Group Size, previously I had been under the impression that NVLink did not work in windows, and then I read a few posts and decided to mess around with that setting to see if I could use the VRam pooling (I started with a much larger scene, not just a black box) and that's when crap hit the fan. Though it may have exposed a flaw somewhere with my card(s), because I still can't really understand why it would favor one card over the other in a non-sli render. I could see one doing 20% fewer iterations than the other due to also being needed to run the monitor, but only doing 40-50 iterations while the other card does close to 7,000? that tells me something is off somewhere... I would also like to figure out what's causing the weird kaleidoscoping problem when NVLINK and SLI are active, because that's a weird problem that shouldn't happen. It also seems to be inconsistent as sometimes simply re-starting and re-running the render corrects it.
SLI has never been supported (officially) for DS
You could try going back to older drivers and checking if anything changes, there is no rule that newer drivers are better than the older ones, and having been involved in developing GPU drivers in the past, I have learned that sometimes one just need to find the ones that work the best for what one is doing.
nVlink, which is often called SLI though it isn't exactly the same, is supported however.