Hi,
I submitted a bug today because anytime I enable the Intel denoiser on Apple Silicon (Mac M1), Houdini crashes.
Support came back with this comment "Unfortunately the M1 chip cannot support the Intel Denoiser."
That is not right, Arnold and Redshift support the Intel Denoiser on Apple Silicon (M1) and https://www.openimagedenoise.org [www.openimagedenoise.org] mention it is supported.
I opened up another ticket mentioning the MPlay button does not do anything in the Karma ROP and was asked some basic questions which led me to believe the support team did not take the time to even try if it was working for them.
This is one of the reason I do not like submitting bug reports, it's ending up generating a lot of unnecessary back and forth.
Thanks
Found 11 posts.
Search results Show results as topic list.
Technical Discussion » Intel denoiser on M1 and feedback on bug submission
- jd_m_007
- 18 posts
- Offline
Technical Discussion » Nested dialectics with Karma
- jd_m_007
- 18 posts
- Offline
It has been a few months and I was hoping to hear from the dev if there is a slight change for absorption and nested dielectrics to be supported in the next release? I render quite a bit of liquids in glass and would really appreciate for this feature to be implemented.
Technical Discussion » Nested dialectics with Karma
- jd_m_007
- 18 posts
- Offline
I have set the refraction and reflection limit to 16 but it does not help, I get the same result.
protozoan
Nested dielectrics are currently unsupported in both regular Karma and KarmaXPU.
For reference, check this comparison table (need to scroll down a bit): https://www.sidefx.com/faq/karma/ [www.sidefx.com]
But I'm not even sure this is the problem in your case, it may be simply too low of a refraction depth (this defaults to 4 now, it was 10 on mantra ROPs).
Technical Discussion » Nested dialectics with Karma
- jd_m_007
- 18 posts
- Offline
I am trying to figure out why the top of the liquid is darker than the bottom. I tried every setting I could think of and I'm unable to have a consistent color between the outside of the liquid and its inside. I played with the at distance but it does not help, when I increase the distance, the bottom of the liquid becomes darker and the top of the liquid becomes lighter.
IOR of glass is 1.5
IOR of water is 1.33
I also made sure the water is slightly overlapping with glass.
Any help would be much apprecicated!
I'm running Houdini 19.5.533
Thanks
IOR of glass is 1.5
IOR of water is 1.33
I also made sure the water is slightly overlapping with glass.
Any help would be much apprecicated!
I'm running Houdini 19.5.533
Thanks
Edited by jd_m_007 - Feb. 18, 2022 12:41:41
Houdini Lounge » Sluggish viewport on OSX
- jd_m_007
- 18 posts
- Offline
Hi Rob,
I tried to set HOUDINI_DISABLE_BACKGROUND_HELP_INDEXING=1 but no success.
I suspect there is something going on with the event loop because if I use Houdini for 10 minutes and let it idle, it consumes a large chunk of CPU (25%) for the hindie process and 50% for the WindowServer process (Quartz renderer on macOS).
If you look at the Stacktrace, it continuously send message to the CA::Render even if Houdini is running in the background. That makes me think it keeps sending draw calls for some reasons. I compared to Cinema4D and Blender and I don't see these constant draw calls there.
Attached is the instrumentation.
Thank you
I tried to set HOUDINI_DISABLE_BACKGROUND_HELP_INDEXING=1 but no success.
I suspect there is something going on with the event loop because if I use Houdini for 10 minutes and let it idle, it consumes a large chunk of CPU (25%) for the hindie process and 50% for the WindowServer process (Quartz renderer on macOS).
If you look at the Stacktrace, it continuously send message to the CA::Render even if Houdini is running in the background. That makes me think it keeps sending draw calls for some reasons. I compared to Cinema4D and Blender and I don't see these constant draw calls there.
Attached is the instrumentation.
Thank you
rvinluanjd_m_007
I had reported the same @ https://www.sidefx.com/forum/topic/77342/ [www.sidefx.com]
Not sure if it's related to the problem but I know when it happens the number of QT widgets increase exponentially, like if there was some type of resource leak.import PySide2.QtWidgets len(PySide2.QtWidgets.QApplication.instance().allWidgets())
Yup. I saw your report when it came in through our support system. I gave this a try and I also noticed that the total number of widgets increased if I continually opened submenus in the TAB menu for example. However, when I continued to open submenus, eventually the total number of widgets dropped back down. I tested for about 5 minutes of opening submenus and the number of widgets stayed in the range of 80 to 120 widgets. It never got past that range.
I believe that is the expected behavior. Houdini doesn't immediately destroy windows (and the widgets that they contain) when the windows are closed. Instead it stores them so that they can be recycled or reused. By opening submenus quickly, that causes Houdini to create new windows since the old windows haven't completely been recycled yet. And then at some future point, Houdini does a garbage collection pass and flushes out the excessive windows.jd_m_007
Another thing to note is that as soon as you startup Houdini, if you look at the CPU utilization it will stick to about constant 20% and force the windowserver process on macOS to gravitate at 60% of the energy efficient core on M1 on a constant basis and never goes down after that.
I assume it has to do with OGL draw calls. A similar problem was addressed in Blender and they switched from a NSOpenGLView to a CAMetalLayer @ https://developer.blender.org/T60043 [developer.blender.org]
Hope this helps.
P.S. Wanted to clarify it's a problem that has been happening since macOS Catalina so Intel as well
Interesting. Some of the user reports that I saw come in suggested that downgrading the macOS version "fixed" the lag problem. That suggested the bug only happened in Big Sur or Monterey. If you also see it in Catalina, then either the other users got lucky when they downgraded or maybe there's more than one issue at play here.
Thanks for the Blender link. I'll take a look. We don't create NSOpenGLView directly. We use Qt, which creates the underlying windows and views. Though looking at the Qt source code, I don't even see where it creates NSOpenGLView objects so maybe it already switched over to CAMetalLayer? I'll have to do more digging.
As for the 20% CPU utilization, can you try settingHOUDINI_DISABLE_BACKGROUND_HELP_INDEXING=1
in your environment before launching Houdini? That will disable the help system's background indexing, which is notorious for chewing up CPU time when Houdini first opens. I just want to rule that out as the source of the CPU utilization.
Cheers,
Rob
Houdini Lounge » Sluggish viewport on OSX
- jd_m_007
- 18 posts
- Offline
I had reported the same @ https://www.sidefx.com/forum/topic/77342/ [www.sidefx.com]
Not sure if it's related to the problem but I know when it happens the number of QT widgets increase exponentially, like if there was some type of resource leak.
Another thing to note is that as soon as you startup Houdini, if you look at the CPU utilization it will stick to about constant 20% and force the windowserver process on macOS to gravitate at 60% of the energy efficient core on M1 on a constant basis and never goes down after that.
I assume it has to do with OGL draw calls. A similar problem was addressed in Blender and they switched from a NSOpenGLView to a CAMetalLayer @ https://developer.blender.org/T60043 [developer.blender.org]
Hope this helps.
P.S. Wanted to clarify it's a problem that has been happening since macOS Catalina so Intel as well.
Not sure if it's related to the problem but I know when it happens the number of QT widgets increase exponentially, like if there was some type of resource leak.
import PySide2.QtWidgets len(PySide2.QtWidgets.QApplication.instance().allWidgets())
Another thing to note is that as soon as you startup Houdini, if you look at the CPU utilization it will stick to about constant 20% and force the windowserver process on macOS to gravitate at 60% of the energy efficient core on M1 on a constant basis and never goes down after that.
I assume it has to do with OGL draw calls. A similar problem was addressed in Blender and they switched from a NSOpenGLView to a CAMetalLayer @ https://developer.blender.org/T60043 [developer.blender.org]
Hope this helps.
P.S. Wanted to clarify it's a problem that has been happening since macOS Catalina so Intel as well.
Edited by jd_m_007 - Jan. 26, 2022 21:09:11
Houdini Lounge » Houdini on macOS and major slow down
- jd_m_007
- 18 posts
- Offline
Sorry to revive this old post but hoping one dev will see this. I recently bought a MacBook Pro 14 (M1 Max) and I have the same problem as on my intel mac. Essentially, Houdini pegs 20% of the `windowserver` process (process responsible for the OS UI display) when it starts and as I work in Houdini the CPU time of this process as well as the hindie process keeps climbing up to 90% CPU utilization on the `windowserver` process in macOS. The only solution is to kill Houdini and start it up again.
There is either a resource leak as mentioned above OR somehow the thread responsible to paint the UI is causing the slowdown overtime.
I have tried to 3 different Macs with varying hardware so I am pretty confident it's a bug in Houdini. If you look a the CPU utilizing at startup you will see what I mean, Hindi and windowserver will start right away and continuously consuming 20% CPU and it keeps climbing from that point on.
There is either a resource leak as mentioned above OR somehow the thread responsible to paint the UI is causing the slowdown overtime.
I have tried to 3 different Macs with varying hardware so I am pretty confident it's a bug in Houdini. If you look a the CPU utilizing at startup you will see what I mean, Hindi and windowserver will start right away and continuously consuming 20% CPU and it keeps climbing from that point on.
Technical Discussion » Can't make @orient to work properly
- jd_m_007
- 18 posts
- Offline
Thank you, that was the problem indeed. I did not realize it, a fuse SOP fixed the problem.
Technical Discussion » Can't make @orient to work properly
- jd_m_007
- 18 posts
- Offline
Hi,
The orient attribute name appears to not work properly in a loop for me. Not sure what I'm doing wrong but it creates artifacts on the cube in my scene by generating additional faces. Does someone has an idea what I may be missing? Here is a screenshot of the setup, you can see some of the cubes getting deformed for no apparent reason.
The orient attribute name appears to not work properly in a loop for me. Not sure what I'm doing wrong but it creates artifacts on the cube in my scene by generating additional faces. Does someone has an idea what I may be missing? Here is a screenshot of the setup, you can see some of the cubes getting deformed for no apparent reason.
Houdini Lounge » Houdini on macOS and major slow down
- jd_m_007
- 18 posts
- Offline
Hi Folks,
I just wanted to make you aware of a bug that is affecting Houdini on macOS (at least on my iMac Pro with Vega 64 video card).
I've been working with support on this to provide as much information as possible but I'm sharing this issue here so folks are careful before upgrading.
The bug is causing major slow downs after a few minutes working in Houdini and appears to be a leak with how QT is releasing (or lack thereof) the QWidget objects on Big Sur.
I've downgraded from Big Sur to High Sierra and then back to Catalina and both of these OS do not exhibit the problem.
I've made a quick video to demonstrate the problem: https://1drv.ms/v/s!Aos_xSmX65yym_MnQZHAvU_-1IZGiQ?e=FhpqNc
If you run this python snippet in the Shell, you'll see the count of QWidget objects keeps increasing as you hover over the TAB menu (it does not do that on previous OS). After a 10 minutes session, Houdini becomes so slow you need to restart it to get back to normal.
So be careful before upgrading (at least if you have an iMac Pro with a Vega 64). It could be a driver bug with the Vega 64 but whoever is working on Big Sur and does not experience this slow down please let us know which Video Card you are using so we can tell whether it's specific to AMD video cards or a more widespread problem.
Thank you
I just wanted to make you aware of a bug that is affecting Houdini on macOS (at least on my iMac Pro with Vega 64 video card).
I've been working with support on this to provide as much information as possible but I'm sharing this issue here so folks are careful before upgrading.
The bug is causing major slow downs after a few minutes working in Houdini and appears to be a leak with how QT is releasing (or lack thereof) the QWidget objects on Big Sur.
I've downgraded from Big Sur to High Sierra and then back to Catalina and both of these OS do not exhibit the problem.
I've made a quick video to demonstrate the problem: https://1drv.ms/v/s!Aos_xSmX65yym_MnQZHAvU_-1IZGiQ?e=FhpqNc
If you run this python snippet in the Shell, you'll see the count of QWidget objects keeps increasing as you hover over the TAB menu (it does not do that on previous OS). After a 10 minutes session, Houdini becomes so slow you need to restart it to get back to normal.
import PySide2.QtWidgets len(PySide2.QtWidgets.QApplication.instance().allWidgets())
So be careful before upgrading (at least if you have an iMac Pro with a Vega 64). It could be a driver bug with the Vega 64 but whoever is working on Big Sur and does not experience this slow down please let us know which Video Card you are using so we can tell whether it's specific to AMD video cards or a more widespread problem.
Thank you
Edited by jd_m_007 - Nov. 1, 2021 14:55:56
Houdini Indie and Apprentice » Slow performance Houdini Apprentice?
- jd_m_007
- 18 posts
- Offline
vvzen
To everyone having the same issue, I spoke with support and they told me that it's actually a known bug and it's affecting many Indie users as well. This is the bug id: #105946 (unfortunately, the bug tracker is only visible to users of the full commercial versions).
I'm still using the Apprentice (tested 17 and 18 under macOS Mojave) but I'll probably switch soon to Indie in order to complete a project, I'll update this post in case things get better.
I am using Houdini 18.5 Indie(tried all build up to 437) and I am impacted by this issue. Houdini will become slower and slower after 10 minutes of use. Complexity of the scene does not matter in my case as I get this problem with a simple sphere. The UI becomes laggy to the point it’s unusable and I can only solve the problem by restarting.
I am using an iMac Pro 10 cores with 64gb RAM and Big Sur 11.1.
Talked to support and associated my case to the same ticket number. I would love to know what is causing this issue so I could possibly work around it but so far Support has not been able to provide any more details or workaround.
Knowing this issue was opened in June makes me very worried as I can’t work in this condition.
Any help would be much appreciated.
-
- Quick Links