Understanding that it’s in alpha stage, to what degree is the vulkan viewport actually usable?

What are some major areas for current viewport feature parity still missing?

It's nearing feature parity with GL, and over the course of the H20 production builds, we'll be finishing off those areas. The priority was to get all the core features working first, then move onto the non-critical or lesser used portions of the viewer. We have a reasonable amount of optimization work yet to finish, along with threading the updates and draws (it's all single threaded like GL right now; we have to completely sweep all GL calls out of the part of the pipeline Vulkan shares with GL first). Stability-wise, it's pretty good.

Here's a list of features that currently missing or incomplete (which is far smaller than the completed list):

• General performance needs work
  
• Shadows (all types)
  
• MatCap draw mode and material
  
• Flat shaded draw mode
  
• Bounding box draw mode
  
• Proper area light shading (point light model currently)
  
• Environment light shading needs work
  
• Foreground Images
  
• Volume Visualizer (all other visualizers and markers work)
  
• Fog (volume and uniform)
  
• Pose-state animation outlines missing
  
• Principled Shader and USD Preview Material displacement (MatX works)
  
• Some MaterialX texture issues
  
• Video color correction
  
• Texture paint
  
• MacOS support via MoltenVK (they just announced synchronization2 support last week, which was the last missing feature for HoudiniVK, so yay!)
  
• Some non-performance critical elements, like grids and handles, are still drawn with OpenGL.
  

I'll try to update this post periodically by striking out items from the above list as they're completed.

We also rewrote the part of the viewer that monitors and updates SOPs to get rid of all the ghost and missing geometry bugs; this is live whether you're running Vulkan or not. This should be a big improvement to everyday workflows.

Also, just because it's Beta doesn't mean you can't log bugs that you happen to find in the Vulkan renderer. One of the main reasons it was deferred until next release was because there wasn't enough time to thoroughly test everything, despite the vast majority of the work being complete.

Awesome! Any benefits for using two SLI (nvlinked) cards? Memory pooling, higher frame rate, et al.

citizen
Awesome! Any benefits for using two SLI (nvlinked) cards? Memory pooling, higher frame rate, et al.

We haven't yet looked at supporting multiple devices for split Vulkan rendering. I think the best use of multiple GPUs is still to split viewport Vulkan and sim/XPU tasks onto different GPUs to take advantage of the separate memory space, providing a lot more available VRAM for both. SLI still requires duplication of resources on both GPUs. The best use of it that I could see is to divide the scene and composite, but that could be problematic. The other use might be for thousands of lights - render half on one GPU and half on the other, then add the final results of each. Could also do compute tasks on one and pass the buffers over to the rendering GPU when complete.

I see. It is rumored that nvidia's next GPU series (5000) will be "nvlinked" via PCI-E. The last series that supports multiple GPUs linked via a physical bridge is the rtx 3090 and even though SLI is no longer officially supported, the nvlink is great as it allows for memory pooling and thus instead of having 24 gb on each card, an offline/non-RT render engine (like V-ray, Arnold and others; how about Karma?) can utilize 48 gb and both GPUs.
If rumors turn out to be true, PCI-E linked cards will be connected in more than the current two cards per pool, so it might be worth it in the near future, regardless of medium - viewport or offline rendering. We'll see what nvidia has in store for us. Thanks!

malexander
It's nearing feature parity with GL, and over the course of the H20 production builds, we'll be finishing off those areas. The priority was to get all the core features working first, then move onto the non-critical or lesser used portions of the viewer. We have a reasonable amount of optimization work yet to finish, along with threading the updates and draws (it's all single threaded like GL right now; we have to completely sweep all GL calls out of the part of the pipeline Vulkan shares with GL first). Stability-wise, it's pretty good.

Here's a list of features that currently missing or incomplete (which is far smaller than the completed list):

• General performance needs work
  
• Shadows (all types)
  
• MatCap draw mode and material
  
• Flat shaded draw mode
  
• Bounding box draw mode
  
• Proper area light shading (point light model currently)
  
• Environment light shading needs work
  
• Foreground Images
  
• Volume Visualizer (all other visualizers and markers work)
  
• Fog (volume and uniform)
  
• Pose-state animation outlines missing
  
• Principled Shader and USD Preview Material displacement (MatX works)
  
• Some MaterialX texture issues
  
• Video color correction
  
• Texture paint
  
• MacOS support via MoltenVK (they just announced synchronization2 support last week, which was the last missing feature for HoudiniVK, so yay!)
  
• Some non-performance critical elements, like grids and handles, are still drawn with OpenGL.
  

I'll try to update this post periodically by striking out items from the above list as they're completed.

We also rewrote the part of the viewer that monitors and updates SOPs to get rid of all the ghost and missing geometry bugs; this is live whether you're running Vulkan or not. This should be a big improvement to everyday workflows.

Also, just because it's Beta doesn't mean you can't log bugs that you happen to find in the Vulkan renderer. One of the main reasons it was deferred until next release was because there wasn't enough time to thoroughly test everything, despite the vast majority of the work being complete.

This is amazing. Thank you so much for the response. You guys kick ass!

malexander
It's nearing feature parity with GL, and over the course of the H20 production builds, we'll be finishing off those areas. The priority was to get all the core features working first, then move onto the non-critical or lesser used portions of the viewer. We have a reasonable amount of optimization work yet to finish, along with threading the updates and draws (it's all single threaded like GL right now; we have to completely sweep all GL calls out of the part of the pipeline Vulkan shares with GL first). Stability-wise, it's pretty good.

Here's a list of features that currently missing or incomplete (which is far smaller than the completed list):

• General performance needs work
  
• Shadows (all types)
  
• MatCap draw mode and material
  
• Flat shaded draw mode
  
• Bounding box draw mode
  
• Proper area light shading (point light model currently)
  
• Environment light shading needs work
  
• Foreground Images
  
• Volume Visualizer (all other visualizers and markers work)
  
• Fog (volume and uniform)
  
• Pose-state animation outlines missing
  
• Principled Shader and USD Preview Material displacement (MatX works)
  
• Some MaterialX texture issues
  
• Video color correction
  
• Texture paint
  
• MacOS support via MoltenVK (they just announced synchronization2 support last week, which was the last missing feature for HoudiniVK, so yay!)
  
• Some non-performance critical elements, like grids and handles, are still drawn with OpenGL.
  

I'll try to update this post periodically by striking out items from the above list as they're completed.

We also rewrote the part of the viewer that monitors and updates SOPs to get rid of all the ghost and missing geometry bugs; this is live whether you're running Vulkan or not. This should be a big improvement to everyday workflows.

Also, just because it's Beta doesn't mean you can't log bugs that you happen to find in the Vulkan renderer. One of the main reasons it was deferred until next release was because there wasn't enough time to thoroughly test everything, despite the vast majority of the work being complete.

Since this is such a fantastic explanation I thought I’d maybe follow-up with a couple more:

- other than performance what does the vulkan viewport do better in H20 than the GL viewport? There have been so many complains about the GL viewport in these forums in the last year - hope you’ve been tracking them - from losing selections, to accuracy, to shortcuts etc.

- does it also work in Solaris context? Ie can work with obj and Solaris context?

- Beside real-time rendering what are some of the benefits (once feature parity is attained) that we’ll reap from all your hard work? Some real examples for users, technical directors and artists?

Thank you

Also are drawing and interacting with subs isolines on the horizon?

LukeP
- other than performance what does the vulkan viewport do better in H20 than the GL viewport? There have been so many complains about the GL viewport in these forums in the last year - hope you’ve been tracking them - from losing selections, to accuracy, to shortcuts etc.

Mainly the ability to use new GPU features, such as ray-tracing, as OpenGL is no longer being developed for features like this. It's also much easier to debug than GL thanks to validation layers. Precision is unchanged from GL; it's still 32b without significant slowdowns for 64b due to how the hardware works.

Shortcuts and selection handling are probably not very related to Vulkan or GL.

- does it also work in Solaris context? Ie can work with obj and Solaris context?

Yes. Solaris and /obj are the "front ends" of the viewport. OpenGL and Vulkan provide the backend renderer. If you select Vulkan, it'll be active for both Solaris and /obj.

- Beside real-time rendering what are some of the benefits (once feature parity is attained) that we’ll reap from all your hard work?

Off the top of my head:

• Ability to render more complex scenes (more objects, materials, etc).
  
• More cinematic effects (eg. ray tracing based - reflection, refraction, SSS, light tracing)
  
• More easily free up VRAM when needed for other uses (XPU, CL slims).
  
• General stability improvements since there is no longer a global state to get messed up
  
• The ability to actually run Houdini if OpenGL is discontinued on a platform
  
• Selection of the GPU device to use (maybe more than 1?)
  
• Background updates and rendering on a separate thread (much like Karma in the viewport)
  
• Infinite far plane (no near/far clipping issues, or at least greatly reduced)
  
• Future proofing for anything else that might come along in hardware, since GL is now obsolete.
  

Also are drawing and interacting with subs isolines on the horizon?

Drawing isolines on subd is at least on the horizon, as is GPU-accelerated subd.

Modelling with isolines is a whole different ball of wax which would heavily involve the modelling team, as beyond selection of isolines, this is SOP territory.

As always, huge thanks for the response. Honestly having SideFX respond directly to comments like mine is what makes you guys amazing!

malexander
We also rewrote the part of the viewer that monitors and updates SOPs to get rid of all the ghost and missing geometry bugs; this is live whether you're running Vulkan or not. This should be a big improvement to everyday workflows.

That is such good news : )

malexander
It's nearing feature parity with GL, and over the course of the H20 production builds,

Do you mean that this features will be publish in the next h20 production builds?

Indeed, I haven't had to reload the viewport at all lately, that's great! But there were bugs with displaying the visibility of the current node. Sometimes it shows, sometimes it doesn't, it's unpredictable.
The community should raise money and give developers a 4k monitor so that they can finally see that axes, indexes, arrows and text are very, very poorly visible in the 4k viewport.

Is Vulkan viewport more performant in visualizing string attributes?
The current GL viewport is exceptionally slow.

I made an example file

habernir

malexander
It's nearing feature parity with GL, and over the course of the H20 production builds,

Do you mean that this features will be publish in the next h20 production builds?

Certain features will make their way into H20 (like foreground images, lighting improvements, performance improvements). Some won't simply because they require more infrastructure changes and testing (like threading). But the plan is to make H20 reach parity with GL, and then make Vulkan the default renderer in the next version of Houdini.

Andr
Is Vulkan viewport more performant in visualizing string attributes?
The current GL viewport is exceptionally slow.

Unique strings are simply a bad case for display. We build a buffer containing all the string information and a point attribute to lookup the offset and size of the string. Usually there's a few dozen strings shared by multiple elements, so the text buffer is small. The other bad case is long strings, which because we generate 2 triangles per character times the number of elements, can also lead to sluggishness. Unfortunately there's very little the API can do here, because it's already done in a single shader.

I definitely think there should be other ways of visualizing strings - such as using solid colors and a legend for the few-string-many-elements case, highlighting/zooming to a given string, or being able to more easily inspect strings on primitives. Throwing up thousands of overlapping blue text strings seems very brute force and often not terribly useful.

malexander

Andr
Is Vulkan viewport more performant in visualizing string attributes?
The current GL viewport is exceptionally slow.

Unique strings are simply a bad case for display. We build a buffer containing all the string information and a point attribute to lookup the offset and size of the string. Usually there's a few dozen strings shared by multiple elements, so the text buffer is small. The other bad case is long strings, which because we generate 2 triangles per character times the number of elements, can also lead to sluggishness. Unfortunately there's very little the API can do here, because it's already done in a single shader.

I definitely think there should be other ways of visualizing strings - such as using solid colors and a legend for the few-string-many-elements case, highlighting/zooming to a given string, or being able to more easily inspect strings on primitives. Throwing up thousands of overlapping blue text strings seems very brute force and often not terribly useful.

Why not provide an option in the display setting to zoom in on all the things that are too small that the users are complaining about?

malexander

habernir

malexander
It's nearing feature parity with GL, and over the course of the H20 production builds,

Do you mean that this features will be publish in the next h20 production builds?

Certain features will make their way into H20 (like foreground images, lighting improvements, performance improvements). Some won't simply because they require more infrastructure changes and testing (like threading). But the plan is to make H20 reach parity with GL, and then make Vulkan the default renderer in the next version of Houdini.

That’s awesome.

malexander

habernir

malexander
It's nearing feature parity with GL, and over the course of the H20 production builds,

Do you mean that this features will be publish in the next h20 production builds?

Certain features will make their way into H20 (like foreground images, lighting improvements, performance improvements). Some won't simply because they require more infrastructure changes and testing (like threading). But the plan is to make H20 reach parity with GL, and then make Vulkan the default renderer in the next version of Houdini.

Would the next version potentially include the RT renderer Cristin was talking about?

LukeP

malexander

habernir

malexander
It's nearing feature parity with GL, and over the course of the H20 production builds,

Do you mean that this features will be publish in the next h20 production builds?

Certain features will make their way into H20 (like foreground images, lighting improvements, performance improvements). Some won't simply because they require more infrastructure changes and testing (like threading). But the plan is to make H20 reach parity with GL, and then make Vulkan the default renderer in the next version of Houdini.

Would the next version potentially include the RT renderer Cristin was talking about?

While there will probably be some image enhancements, what Cristin was referring to was a lot more than just that, so No.