Does anyone notice thats karma XPU with Vulkan viewport its less responsive than karma XPU with opengl viewport?
in heavy scenes you can easly notice that.
***my OS its windows 11
Full Version: Karma XPU in Vulkan viewport less responsive than opengl
Yes. Switched back to OpenGL for now.
If you want to switch back, it can be done in prefrences and with a environment variable.
If you want to switch back, it can be done in prefrences and with a environment variable.
Others have found this too
https://www.sidefx.com/forum/topic/92993/ [www.sidefx.com]
https://www.sidefx.com/forum/topic/92993/#post-428314 [www.sidefx.com]
Its been bug-reported and internal investigations are underway
https://www.sidefx.com/forum/topic/92993/ [www.sidefx.com]
https://www.sidefx.com/forum/topic/92993/#post-428314 [www.sidefx.com]
Its been bug-reported and internal investigations are underway
briansOk thanks for this info
Others have found this too
https://www.sidefx.com/forum/topic/92993/ [www.sidefx.com]
https://www.sidefx.com/forum/topic/92993/#post-428314 [www.sidefx.com]
Its been bug-reported and internal investigations are underway
Soo we need to wait to the next stable point release.
habernir
Soo we need to wait to the next stable point release.
If its an NVidia issue it could take a while. We'll keep you up to date on this ticket as things progress
To me Vulkan viewport it's not only less responsive while Karma XPU is rendering but it hangs the whole programs for several seconds from time to time, totally unusable, switching to OGL fixed the issue, I was surprise.
This is happening even with the latest Studio Nvidia Drivers on Linux
This is happening even with the latest Studio Nvidia Drivers on Linux
I also switched back to OpenGL
You can try the heavy scene in (Caldera data set from Call of Duty®: Warzone™) from Activision:
https://github.com/Activision/caldera [github.com]
Try to grab the USD file e.g. from:
/caldera/map_source/prefabs/br/wz_vg/mp_wz_island/map_airfield/building_set_a.usd
And see how it perform.
You can try the heavy scene in (Caldera data set from Call of Duty®: Warzone™) from Activision:
https://github.com/Activision/caldera [github.com]
Try to grab the USD file e.g. from:
/caldera/map_source/prefabs/br/wz_vg/mp_wz_island/map_airfield/building_set_a.usd
And see how it perform.
The responsiveness is even less if you have a multi view, I submitted an RFE about this few weeks ago, you might want to add more info to that ticket:
SideFX Support Ticket: #155456
Bug#139821
Cheers!
SideFX Support Ticket: #155456
Bug#139821
Cheers!
cdordellyYes, if you're rendering with XPU, do not switch to a multi view. It will basically make Houdini unusable. It won't crash it, but it will make it so slow that it might as well have crashed. I've also submitted the bug report on this, hopefully a fix will come soon.
The responsiveness is even less if you have a multi view
eikonoklastes
Yes, if you're rendering with XPU, do not switch to a multi view. It will basically make Houdini unusable. It won't crash it, but it will make it so slow that it might as well have crashed.
Does this bug still happen if using OpenGL? (instead of Vulkan)
Just wondering if this is related to the OpenGL vs Vulkan thing
thanks!
yeah, it seems that the bug is resolved.
With OpenGL, everything works smoothly, but only one viewport displays materials correctly.
In the second viewport, the materials turn black.
With OpenGL, everything works smoothly, but only one viewport displays materials correctly.
In the second viewport, the materials turn black.
Antti1999
yeah, it seems that the bug is resolved.
Which bug do you mean?
AFAIK there are two bugs mentioned in this forum chain
1) karma XPU with Vulkan viewport its less responsive than karma XPU with opengl viewport?
2) if you're rendering with XPU, do not switch to a multi view. It will basically make Houdini unusable.
and I don't think either are fixed yet
Antti1999
With OpenGL, everything works smoothly, but only one viewport displays materials correctly.
In the second viewport, the materials turn black.
Ahhh ok. So OpenGL doesn't work with multiple displays anyway, so we can't really test
thanks
So, the OpenGL multi view isn’t lagging and crashing anymore that’s what I meant.
Previously, when you split the viewport into two, (I don’t mean two displays, just creating two scene views) using one for XPU and the other for scene manipulations, there were frequent random crashes. Now, I haven’t been able to make it crash at all.
As for materials randomly turning black (Labs - reset viewport triggers this too), I’ve found a temporary solution. I create a second material, 'usd_preview_material,' and set its Purpose to 'Preview Render' when assigning it to the object.
Previously, when you split the viewport into two, (I don’t mean two displays, just creating two scene views) using one for XPU and the other for scene manipulations, there were frequent random crashes. Now, I haven’t been able to make it crash at all.
As for materials randomly turning black (Labs - reset viewport triggers this too), I’ve found a temporary solution. I create a second material, 'usd_preview_material,' and set its Purpose to 'Preview Render' when assigning it to the object.
terry_williamsTerry, can you open
To me Vulkan viewport it's not only less responsive while Karma XPU is rendering but it hangs the whole programs for several seconds from time to time, totally unusable, switching to OGL fixed the issue, I was surprise.
This is happening even with the latest Studio Nvidia Drivers on Linux
dmesgand see if these hangups are caused by CTX SWITCHtimeouts?[Aug24 12:55] NVRM: Xid (PCI:0000:01:00): 109, pid='<unknown>', name=<unknown>, Ch 00000039, errorString CTX SWITCH TIMEOUT, Info 0x4c019
More in this thread [www.sidefx.com].
Antti1999
So, the OpenGL multi view isn’t lagging and crashing anymore that’s what I meant.
Previously, when you split the viewport into two, (I don’t mean two displays, just creating two scene views) using one for XPU and the other for scene manipulations, there were frequent random crashes. Now, I haven’t been able to make it crash at all.
As for materials randomly turning black (Labs - reset viewport triggers this too), I’ve found a temporary solution. I create a second material, 'usd_preview_material,' and set its Purpose to 'Preview Render' when assigning it to the object.
The material issue has not been fixed since H20.
briansSorry, I only just got a chance to test this. Here is what I see:eikonoklastes
Yes, if you're rendering with XPU, do not switch to a multi view. It will basically make Houdini unusable. It won't crash it, but it will make it so slow that it might as well have crashed.
Does this bug still happen if using OpenGL? (instead of Vulkan)
Just wondering if this is related to the OpenGL vs Vulkan thing
thanks!
- With the OpenGL viewport enabled:
- when rendering with either Karma CPU or XPU:
- Houdini is very responsive in the multi view.
With the Vulkan viewport enabled:
- when rendering with Karma CPU:
- Houdini is responsive in multi view, but a lot slower than with OpenGL. There is a noticeable lag when trying to interact with viewport handles, and everything feels a bit slower and laggier than with OpenGL.
- when rendering with Karma XPU:
- Houdini is basically unusable in multi view. It freezes immediately and takes several seconds to respond to any action, and then continues to remain in that state until I disable the renderer or kill Houdini.
Here are some specs:
- Houdini 20.5.332 - Py3.11
- Pop! OS 22.04 LTS
- 128 GB RAM
- AMD Ryzen 9 5950x
- Nvidia RTX 3090 Ti
Hi, I uploaded a video showcasing this issue, Vulkan vs Opengl while the rendering is going, this is only happening with XPU and I also noticed the snappiness of the renderer is way better in OpenGL.
PD: There are timestamps in the description.
@ajz3d - I ran the command in Sudo but I couldn't find in the log anything related to "SWITCH TIMEOUT" the only line related to NVRM said: " NVRM: loading NVIDIA UNIX x86_64 Kernel Module 555.58.02 Tue Jun 25 01:39:15 UTC 2024"
PD: There are timestamps in the description.
@ajz3d - I ran the command in Sudo but I couldn't find in the log anything related to "SWITCH TIMEOUT" the only line related to NVRM said: " NVRM: loading NVIDIA UNIX x86_64 Kernel Module 555.58.02 Tue Jun 25 01:39:15 UTC 2024"
I switched back to OpenGL two weeks ago and the program feels much more responsive. Random crashes are also much, much less frequent than what I had been experiencing with Vulkan viewport. I'm currently working primarily in Copernicus, so with OpenGL viewport I'm missing some COP features that are available in Vulkan (like "Tile Vis: 3", for instance), but even that is better than having to restart Houdini dozens of time a day. I hope that Vulkan stability and performance will be progressively improved within future 20.5.x minor versions, so we don't have to wait until 21.0. After all, it was decided to make Vulkan Houdini's default viewport renderer, and while I don't expect it to be faster than OpenGL (as it's probably more complex), I think it should at least offer stability similar to OpenGL.
terry_williamsThanks for checking, Terry.
@ajz3d - I ran the command in Sudo but I couldn't find in the log anything related to "SWITCH TIMEOUT" the only line related to NVRM said: " NVRM: loading NVIDIA UNIX x86_64 Kernel Module 555.58.02 Tue Jun 25 01:39:15 UTC 2024"
The performance really drop down when heavy geo or very curiously packed obj!!!
It's display faster when not using non packed object, non sense no?
- Also, im still not able to have proper arealight soft shadow with gobo in viewport.
Vulkan handles better Occlusion viewport and Heighfield LOD artifact which is cool as well as real time displacement (despite no dicing support), but still a long way to match the quality and responsiveness of Eeve for example... I hope Houdini could catchup and understand it's important to have better viewport and less bug there. Yes, we are repeating
, it's okay we could wait a little more but please ...
- When using TOP, ropfetch and render GL, it will be great if this node could also do capture using Vulkan! for now, excepted if i missed something, it is not, so the capture image in your TOp network is disconnected from what you see. And OpenCL viewport has a very poor support for Copernicus PBR representation. So that's really a problem i hope Houdini could get fixed soon!
Thanks
PS: Actually im will be free for my client in free weeks, if some of you are you have opening position...
It's display faster when not using non packed object, non sense no?
- Also, im still not able to have proper arealight soft shadow with gobo in viewport.
Vulkan handles better Occlusion viewport and Heighfield LOD artifact which is cool as well as real time displacement (despite no dicing support), but still a long way to match the quality and responsiveness of Eeve for example... I hope Houdini could catchup and understand it's important to have better viewport and less bug there. Yes, we are repeating
, it's okay we could wait a little more but please ... - When using TOP, ropfetch and render GL, it will be great if this node could also do capture using Vulkan! for now, excepted if i missed something, it is not, so the capture image in your TOp network is disconnected from what you see. And OpenCL viewport has a very poor support for Copernicus PBR representation. So that's really a problem i hope Houdini could get fixed soon!
Thanks
PS: Actually im will be free for my client in free weeks, if some of you are you have opening position...