I’ve spent a year periodically searching for a solution to my serious lag in Max when renering a progressive IPR. This solution seems to have solved it for me. I use a program with which I can assign which processes a particular program uses. I let Max use all but 4 of my 32 processes. When setting it up for Max I just excluded Max from the first two processes and the last two processes for no particualr reason so that other programs could utilize them. I didn’t realize that there was a priority to the processes that was that important. I reassigned Max back to the first two and and excluded it from others in the middle. Like magic, I now have a pleasant experience using Max while IPR is running. I’m thrilled to have found this. Thank you @3d-laboratory .
So if others are having the issue and even if you don’t use a program to manage processes, try making sure that Max has exclusive use of the first process and see if it solves the issue for you.
This is something I say above that was solved. But it came back.
This is something that many of us have been discussing over at AreaMAX. I too have a severe lag with IPR running even on a modest scene with 300K polys. You can see my system in my signature. I’ve tried all the configuration suggestions and process tweaking I can find. No love… I think it’s V-Ray V6 not playing nice with a host of Ryzens and Threadrippers. A kernel thing?
I think this has to do with a recent windows update, I’m seeing this behavior on my 3990X for the past week or so.
What worked for me is bios update + Chipset drivers, then running my memory without XMP(DOCP) (default 2400 frequency)
This seems to work for me
I tried to run the memory at the rated frequency although the behavior comes and goes, I will leave it off for now
Have you tried using game mode via Ryzen Master?
This will activate one CCD only and ensure there are no long-path comms anywhere (i.e. no NUMA, so likely also half the ram, depending on config.).
It alleviates poor performance in gaming, maybe it can help with Max too?
It will depend on your configuration.
In the 3990x in the office, which is stacked with RAM in all slots, disabling NUMA also halves the available RAM.
You may perhaps start by only enabling one CCD without touching NUMA, and see if it helps.
It’s clearly sub-optimal, as one would need a reboot before starting a big render job, so to have the workstation at its 100% specs, but it’s a curiosity as the performance difference for the more lightly threaded games is significant enough.
I’m also unsure, if NUMA, or otherwise long CPU comm paths (like the inter-CCD ones), are the culprits, that anything at all can be done on the coding side: i’ve never seen it fixed in any application: if you need half a tera of data in RAM, you take the NUMA penalty (or many cores) and count your blessings, so to speak.
It’s “fixable” in games because they much favour clock speeds and coherent data allocation, more than many threads and loads of RAM.
EDIT: i am gravitating to this because the haphazard characteristics of the issue may find some rhyme and reason if they depended from scene size, f.e., and so on where the data was allocated, and requested from by Max, us, or any other engine, in a given PC configuration.
Some may not have the issue at all because they don’t cross a NUMA boundary, f.e., when loading a specific scene, or because they don’t have RAM in both NUMA nodes.
Thanks for this. I learned a lot from that great explanation.
I did enable ‘Game Mode’ but didn’t do anything concerning NUMA. I need to research that more and learn how to manipulate it. It sounds like you can. But, I will say that just enabling Game Mode things feel a litte bit smoother and less bogged down with IPR running.
Oh, you have the specs in the signature, i should have read: Ryzens do not have NUMA, ThreadRippers do.
So game mode for you will only turn off one CCD, leaving you with half the cores, but all close together.
Performance for processor comms may be marginally better then, but surely not as if turning NUMA off.
I’d be interested in seeing anyone with a Threadripper try the same.
But this still leaves the question open as to why you’d be bogging down, and if NUMA has anything to do with it at all, given you don’t have it and suffer a similar fate.
Are your v-ray benchmarks in line with other similar processors? Or do you see a constant slack, that might signal some issue?
Hi,
Have there been any new finding or progress on this issue ?
I am also suffering severe UI slowdowns when using V-Ray IPR making it a real pain to use on a Ryzen 5950x Windows 11 3ds max 2023 Ray 6.
I tried un assigning some CPU cores and disabling SMT with Process Lasso but that does not have any impact.
Thanks.
I’m on a 7950X on win 10 (slightly different, indeed.), and have no such issue, surely not generally, and i do get to render and debug a few heavy user scene often enough.
Is there any constant in the way you work (i.e. how your scenes are built) that may be causing this?
Does it slow down simply opening IPR on an empty scene, or a plane and a light?
Is it with trees, scatter, particles, volumes, anything specific you could point out?
To be clear, the slowdowns affect only the material editor. The IPR view itself updates reasonably quickly when moving the camera, no problems there.
But the material editor can become very sluggish : navigation, moving nodes, dragging connections, creating new nodes, everything becomes very slow.
As I had some free time this morning I decided to make a video recording to illustratte the behaviour. Sure enough everything went smoothly. As if 3ds max knew it was being recorded and decided to behave himself
But after 30 minutes the slowdowns started kicking in. It seems that the IPR needs to be restarted a few times becfore the malfunction start happening.
So in the end I was able to make a very short video capture that goes straight to the point and shows the Slate Material Editor slowdown when IPR is active
Here is a link to the video : Unique Download Link | WeTransfer
This is much more useful, thanks a lot!
Have you got a chance to see if this happens also in max 2024?
I ask as the pre-2024 slate is QT wrapped into Win32, and that is well known to be slow (everything you see is born one way, and transformed ont he fly in something else.), and severely single-cored (the translation and drawing of the win32 UI controls is.).
As mentioned in a blog post about the QT-Fication of V-Ray, the win32 translator is known to become progressively (much!) slower, the more controls it draws within the single Max session.
So, that’s more on the win32 translator than it is on us (i.e. not much we can do about it on our side.), particularly as i assume the scene you recorded with isn’t anything special, and you mentioned it’s time-dependent.
We’ll try and repro this on our side as well, but it’d be cool if you could see if the same scene, under the same-ish conditions misbehaves with the QT Slate material editor in 2024.
Unfortenately my 30 day trial of 3ds max 2024 ended recently and I’m not planning to upgrade to their rent-only version in the near future, so I’m stuck with 2023 for now.
I wish I knew earlier about all that QT stuff. Very interesting ! I see why testing the scene with max 2024 would be helpful.
Umh, you could try working for a while in the compact material editor, see if the slowdown happens again.
At least, that is native win32 UI for the editor, and Qt controls for what the editor shows (our maps and materials).
We’ll do our research as well, but i doubt we’ll have success now, after so long trying.
To keep this thread updated : I recently upgraded to max 2024 and latest v-ray 6 and the slowdowns in IPR are just as severe as they used to be in max 2023.
