Jump to content

Why is bool type not available in VEX?


magneto

Recommended Posts

Vex works mostly on geometry attributes, so no bool attribute -> no bool variables I presume. (All Houdini parts are tied closely to things like its geometry library which are used across a whole program, so the design of such thing influences all parts).

Additionally VEX is heavily multi-threaded with SIMD instructions, in which case data alignment and vectorization is crucial for performance. I suspect it is easier for VEX for perform on floats and vectors, which can be piped into registers faster.

Edited by SYmek
  • Like 2
Link to comment
Share on other sites

Thanks Symek, I was mainly using them for parameters, etc so they were one-offs, but I understand what you mean.

Do you also know if I can find more info about the inner workings of VEX beyond what's shown in the VEX reference in the docs, which isn't much.

I was looking for things like:

Prefer this technique:

...

over this:

...

etc

which Python section of the docs have.

What kind of cases are optimized more efficiently, what happens when VEX is compiled into an operator, etc.

I find this sort of info very valuable, but I suspect it would only be available if you grab a drink with the Sidefx developers :)

Link to comment
Share on other sites

I find this sort of info very valuable, but I suspect it would only be available if you grab a drink with the Sidefx developers :)

Oh, apparently you have more chances to meet them than me ;). As to VEX I don't know any insights besides what's scattered across docs, forum and HDK inline comments (which I like to read a lot). There is a book though (mine is lost somewhere...) in which Mark Elendt described in details VEX virtual machine design. Second point is that VEX is not such an isolated case. Once you start reading about SIMD design, Renderman RSL, code optimization, you may reach ( presumably misleading but still :) ) the feeling you know better :)

What kind of cases are optimized more efficiently, what happens when VEX is compiled into an operator, etc.

In mantra there is a verbose mode with vex profiling, which tells you a lot about vex run-time conditions. Other than that it's all about trial&error. Not sure what you mean by "what happens when VEX is compiled into an operator"? When you make an operator with a VEX code, it is still a general Vex-like-SOP, it doesn't change magically into completely custom node (except UI which are spare parms anyway). It's general vex node, which keeps inside your code and on cook calls vex virtual machine, just like a VopSOP. There are differences like in SOPs node has a single virtual machine, unlike Mantra which most probably (can't be sure), has such a machine per thread (what has this effect, that thread-unsafe code, runs well in shaders, but blows up Houdini at sight!).

There are some tips which afaik are common for all parallel environment, like avoiding switches/conditional statements etc. Basically the more streamlined execution tree is the better. It's true about VEX, Cuda, or pure SIMD code. But there really isn't much difference between "naive" and "optimized" code in SOPs. The main slow downs are out of control anyway (like ray intersecting, single threaded write geometry access (in H11), and such). The code itself gets well optimized by a compiler (which apparently gets even better in H12).

  • Like 1
Link to comment
Share on other sites

lol brb heading to Sidefx Toronto office :)

Thanks for the info. Eetu also mentioned the same book, so I will pick up a copy and read the VEX section.

Sorry when I said "what happens when VEX is compiled into an operator?", I meant asking about details along the same lines of your description, like VEX compiler turns your code into bytecode, it's wrapped inside the a special SOP that calls the virtual machine on every cook, etc.

I also try to avoid branching in vex but sometimes it's unavoidable and had to use them for options. Though I did some experiments and found out that in branching if the value is fixed, the vex compiler seems to optimize it. I also found one of Edward's comments where he was saying "the magic of the vex compiler" in regards to a similar question.

Is it possible to maybe take a look at the generated bytecode and compare?

Edited by magneto
Link to comment
Share on other sites

  • 9 years later...

I would like this.

Automatic Toggle Parameter creation. A little less moving into the Edit Parameter Interface.

 

Would such datatypes also not take less memory or something as opposed to an int?

Edited by Krion
Link to comment
Share on other sites

It would add a new data type to take into account for the compiler and memory management.
Generally speaking, having if checks in shader like languages is not extremely efficient anyway, so optimizing for them might also not really matter that much.


I for one looove the fact that you can just add/multiply bools (ints) together, where with most other languages you cannot.
I'm happy to pay a tiny bit extra RAM for that.
 

If you have a lot of && checks, you can just multiply them all together, and if one of them was 0, the result is 0,
whereas if you have a lot of || checks, you can also just add them all together and check if the sum of that, is larger than 0

and you can still use bitwise operators on ints to cover all the functionality bools have like:

  • |=
  • &=
  • ^
Edited by acey195
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...