Ppixar-ossRegenerate precompiled headers
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Add an untemplated overload of VdfContext::HasInputValue. This change updates clients in pxr to call the new overload. Coming changes will update remaining callers. After all callers are updated, the templated overload of this method will be removed. There is no meaningful change in behavior in switching to an un-templated method, because HasInputValue<ValueType> emits a fatal error if ValueType is different from the input spec's data type. We could change the semantics so that this function would just return false when there's a type mismatch--but that wouldn't be useful because exec requires data types to match when it makes connections, so there's no way to take advantage of the kind of query that would enable. Therefore, we can simplify things and reduce the amount of work the compiler has to do by omitting the template parameter. (Internal change: 2404391) | 6 个月前 | |
Move EfExecutor and EfSubExecutor to Vdf We initially noticed something needed to change here because testVdfSpeculation needs to use EfExecutor, in order to use VdfParallelExecutorEngine. The downstream dependency causes problems in some builds. That pointed out that VdfExecutor is core functionality that it makes sense for Vdf to provide, and VdfSubExecutor is a dependency that comes along for the ride. We need to follow up on this by adding Vdf unit test coverage for the moved classes, but there are no relevant tests in ef that can be moved along with these files. So we're proceeding with moving these definitions in order to fix the problem with the testVdfSpeculation dependencies. Fixes #3871 (Internal change: 2401163) | 7 个月前 | |
Add initial README.md files for all libraries under pxr/exec. More content is needed in these files, but these provide basic landing pages for each of the OpenExec libraries. (Internal change: 2372913) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: use forwarding reference for args in Vdf_AllocateBoxedValue (Internal change: 2376475) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: change is-boxed container trait type to be a template variable (Internal change: 2368475) | 1 年前 | |
vdf: change is-boxed container trait type to be a template variable (Internal change: 2368475) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: VdfLinearMap is now VdfConnectorMap VdfLinearMap was primarily used to store inputs and outputs belonging to a node. There are a small number of other uses but the long-term goal is to specialize this data structure for the input/output case. To this end, rename VdfLinearMap to VdfConnectorMap and restrict its keys to TfToken and it's mapped type to pointers. Furthermore, because the users of VdfLinearMap managed the lifetimes of the pointed-to objects in a way that was coupled to their presence in the map, VdfConnectorMap takes ownership of its mapped values. (Internal change: 2376688) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Don't allow VdfContext::SetEmptyOutput to be called on associated outputs. If a mover were to call SetEmptyOutput, injecting an empty VdfVector into the point pool, that would break numerous assumptions readers make about what they expect to find on their pool inputs. Therefore, we disallow using this API for any output that has an associated input. (Internal change: 2404829) | 6 个月前 | |
Remove the templated overload of VdfContext::HasInputValue, now that all clients have been update to call the non-templated overload. (Internal change: 2408611) | 5 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Removes the TBB arena from the data manager allocator in favor or using work isolation, as well as ensuring forward progress in the single-threaded case bysynchronously performing deallocation. (Internal change: 2371615) | 1 年前 | |
exec: Fix -Winconsistent-missing-override warnings on clang This removes 645 out of 755 warnings when building on Mac. (Internal change: 2387063) | 11 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Move state specific to executors and computed/cached values to a separate class called Exec_Runtime. This change also enables deletion of executor data when a node gets uncompiled. (Internal change: 2367836) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
exec: Fix -Winconsistent-missing-override warnings on clang This removes 645 out of 755 warnings when building on Mac. (Internal change: 2387063) | 11 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
VdfSparseOutputTraverser: Use compile time debug codes to enable debug output, instead of using a #define. Remove compile time debugging that no longer compiled when enabled. (Internal change: 2400294) | 7 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Fix exponential runtime in Vdf_DotGrapher Traversal in Vdf_DotGrapher::_GetLimitedNodes was only constrained by depth, not whether a node has been visited. This was to ensure that each traversal would always find nodes within the requested depths (change 1830101), however it could lead to exponential runtime. Instead, use a separate set of visited nodes for each traversal, so a traversal is still not constrained by previous traversals but will not visit a node multiple times. Added a test which times out without the fix. (Internal change: 2381566) | 1 年前 | |
Fix exponential runtime in Vdf_DotGrapher Traversal in Vdf_DotGrapher::_GetLimitedNodes was only constrained by depth, not whether a node has been visited. This was to ensure that each traversal would always find nodes within the requested depths (change 1830101), however it could lead to exponential runtime. Instead, use a separate set of visited nodes for each traversal, so a traversal is still not constrained by previous traversals but will not visit a node multiple times. Added a test which times out without the fix. (Internal change: 2381566) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: fix check for debug name callback validity Previously, the callable passed to SetDebugNameCallback was captured in a lambda, which was then wrapped in a VdfNodeDebugNameCallback. Checking the validity of that callback could never fail because we had just put a lambda in it. If we had passed an invalid VdfNodeDebugNameCallback, we would have smuggled it past the validity check and then thrown an exception when invoking it later. Instead, construct a VdfNodeDebugNameCallback directly from the callable argument. Also, pass the callback into the network with an r-value reference and move it into place. Two internal callback validity checks were changed to be TF_VERIFY. The check in VdfNode::SetDebugNameCallback is reachable from client API so it remains a coding error. (Internal change: 2365960) | 1 年前 | |
OpenExec: Address build warnings on some platforms - Use PRIu64 macro when printing uint64_t values. - Add #if's to omit a class member in a VdfSparseOutputTraverser nested class because the member is only used when cached traversal is enabled at build time. (Internal change: 2399702) | 7 个月前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
OpenExec: When a value type hasn't been registered with execution, emit a warning that specically recommends calling ExecTypeRegistry::RegisterType, to make it easier for someone who sees this fatal error to figure out how to respond. - Update documentation for the Callback and Constant registrations to include information about registering value types with the execution system. - Add more information to the ExecTypeRegistry::RegisterType documentation, including example code. (Internal change: 2400786) | 7 个月前 | |
OpenExec: When a value type hasn't been registered with execution, emit a warning that specically recommends calling ExecTypeRegistry::RegisterType, to make it easier for someone who sees this fatal error to figure out how to respond. - Update documentation for the Callback and Constant registrations to include information about registering value types with the execution system. - Add more information to the ExecTypeRegistry::RegisterType documentation, including example code. (Internal change: 2400786) | 7 个月前 | |
Move EfExecutor and EfSubExecutor to Vdf We initially noticed something needed to change here because testVdfSpeculation needs to use EfExecutor, in order to use VdfParallelExecutorEngine. The downstream dependency causes problems in some builds. That pointed out that VdfExecutor is core functionality that it makes sense for Vdf to provide, and VdfSubExecutor is a dependency that comes along for the ride. We need to follow up on this by adding Vdf unit test coverage for the moved classes, but there are no relevant tests in ef that can be moved along with these files. So we're proceeding with moving these definitions in order to fix the problem with the testVdfSpeculation dependencies. Fixes #3871 (Internal change: 2401163) | 7 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Fix compilation of executorDataVector.cpp in Linux on arm64 In https://github.com/PixarAnimationStudios/OpenUSD/commit/4b581269d045b4a97931e476345891ddc34570a3 some x86-specific assembly code was added and it was enabled by default in https://github.com/PixarAnimationStudios/OpenUSD/commit/5fdfda11286f566c65745785fc44f26526f433ec . This PR adds a define check to ensure that the x86-specific code is only compiled on x86, even if this will not insert the correct marking on arm64, but as the todo mentions, probably the best thing to do for that is to use valgrind macro `VALGRIND_MAKE_MEM_DEFINED`, as mentioned in the code comments.. However, that should not matter unless the binary is run under valgrind, so for regular users this fixes the compilation. Fix https://github.com/PixarAnimationStudios/OpenUSD/issues/3711 . Closes #3764 (Internal change: 2376127) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: Fix a case of UB, uninitialized reads when moving a default-constructed instance of types that leave members uninitialized by just using default constructors to create the instance in-place. (Internal change: 2375970) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Removes references to external websites. (Internal change: 2362639) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Removes references to external websites. (Internal change: 2362639) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: tweak VdfIndexedWeightsOperand's arithmetic operators to allow NRVO Because the compound assignment operators return This&, return value optimization did not apply nor could the compiler move from w in the return. Returning w directly allows the compiler to apply NRVO. (Internal change: 2398741) | 7 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: consistently use operator== for input vector value equality Only require exec types to implement == even though the vast majority of them also implement !=. (Internal change: 2404389) | 6 个月前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Instead of having clients derive from VdfNetwork::EditFilter, VdfIsolatedSubnetwork API now uses TfFunctionRef for filter parameters. This improved ergonmics by giving clients the option of passing other kinds of function objects, including lambdas. (Internal change: 2369093) | 1 年前 | |
Instead of having clients derive from VdfNetwork::EditFilter, VdfIsolatedSubnetwork API now uses TfFunctionRef for filter parameters. This improved ergonmics by giving clients the option of passing other kinds of function objects, including lambdas. (Internal change: 2369093) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: VdfLinearMap is now VdfConnectorMap VdfLinearMap was primarily used to store inputs and outputs belonging to a node. There are a small number of other uses but the long-term goal is to specialize this data structure for the input/output case. To this end, rename VdfLinearMap to VdfConnectorMap and restrict its keys to TfToken and it's mapped type to pointers. Furthermore, because the users of VdfLinearMap managed the lifetimes of the pointed-to objects in a way that was coupled to their presence in the map, VdfConnectorMap takes ownership of its mapped values. (Internal change: 2376688) | 1 年前 | |
vdf: VdfLinearMap is now VdfConnectorMap VdfLinearMap was primarily used to store inputs and outputs belonging to a node. There are a small number of other uses but the long-term goal is to specialize this data structure for the input/output case. To this end, rename VdfLinearMap to VdfConnectorMap and restrict its keys to TfToken and it's mapped type to pointers. Furthermore, because the users of VdfLinearMap managed the lifetimes of the pointed-to objects in a way that was coupled to their presence in the map, VdfConnectorMap takes ownership of its mapped values. (Internal change: 2376688) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Change GetNumDataEntries to check the affects mask first, since that requires the least amount of pointer indirection. (Internal change: 2365215) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Removes remnants of TBB algorithms from the exec libraries. (Internal change: 2371360) | 1 年前 | |
Add WorkTaskGraph to migrate parallel exec engine code that relies on the deprecated low-level tbb::task interface. WorkTaskGraph implements a base task class that supports spawning additional work from within the execution of a task, continuation passing, recycling of task resources, and scheduler bypass. This change also includes an implementation of tbb::zero_allocator, which was removed in the oneTBB migration as an oversight. This enables pxr to build with oneTBB and continues to support task usage with older TBB versions. (Internal change: 2370806) (Internal change: 2370808) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Replace WorkWithScopedParallelism with WorkIsolatingDispatcher in re-entrant parallel exec engine RunSchedule() loop. WorkWithScopedParallelism was leading to starvation in cases where idle tbb threads were unable to steal tasks from outer isolated regions to make progress. This manifested in nested speculation computation, as threads that entered the nested isolated region (created via tbb::this_task_arena::isolate) were forced to wait idly rather than make progress on tasks queued from outer isolated regions. This change replaces the use of tbb::this_task_arena::isolate with a dispatcher that executes tasks in a pool-allocated tbb::task_arena. This preserves the performance benefits of work isolation while widening the scope for work stealing within the arena. (Internal change: 2374389) | 1 年前 | |
Replace WorkWithScopedParallelism with WorkIsolatingDispatcher in re-entrant parallel exec engine RunSchedule() loop. WorkWithScopedParallelism was leading to starvation in cases where idle tbb threads were unable to steal tasks from outer isolated regions to make progress. This manifested in nested speculation computation, as threads that entered the nested isolated region (created via tbb::this_task_arena::isolate) were forced to wait idly rather than make progress on tasks queued from outer isolated regions. This change replaces the use of tbb::this_task_arena::isolate with a dispatcher that executes tasks in a pool-allocated tbb::task_arena. This preserves the performance benefits of work isolation while widening the scope for work stealing within the arena. (Internal change: 2374389) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Add WorkTaskGraph to migrate parallel exec engine code that relies on the deprecated low-level tbb::task interface. WorkTaskGraph implements a base task class that supports spawning additional work from within the execution of a task, continuation passing, recycling of task resources, and scheduler bypass. This change also includes an implementation of tbb::zero_allocator, which was removed in the oneTBB migration as an oversight. This enables pxr to build with oneTBB and continues to support task usage with older TBB versions. (Internal change: 2370806) (Internal change: 2370808) | 1 年前 | |
Add WorkTaskGraph to migrate parallel exec engine code that relies on the deprecated low-level tbb::task interface. WorkTaskGraph implements a base task class that supports spawning additional work from within the execution of a task, continuation passing, recycling of task resources, and scheduler bypass. This change also includes an implementation of tbb::zero_allocator, which was removed in the oneTBB migration as an oversight. This enables pxr to build with oneTBB and continues to support task usage with older TBB versions. (Internal change: 2370806) (Internal change: 2370808) | 1 年前 | |
Add WorkTaskGraph to migrate parallel exec engine code that relies on the deprecated low-level tbb::task interface. WorkTaskGraph implements a base task class that supports spawning additional work from within the execution of a task, continuation passing, recycling of task resources, and scheduler bypass. This change also includes an implementation of tbb::zero_allocator, which was removed in the oneTBB migration as an oversight. This enables pxr to build with oneTBB and continues to support task usage with older TBB versions. (Internal change: 2370806) (Internal change: 2370808) | 1 年前 | |
Regenerate precompiled headers This change regenerates precompiled headers throughout the tree. It also adds a pch.h file for the newly-created usdLod schema domain. (Internal change: 2414923) | 4 个月前 | |
Consider all associated outputs to be pool outputs if the data that flows through them is vectorized VdfOutput::GetNumDataEntries. Pre-checkin perfevals indicate this recovers from performance regressions caused by change 2363892, which used affects masks to identify pool outputs. It turned out that non-affective movers dont' have affects masks (and also the copy-to-pool node), and that is presumably what made queries that rely on identifying pool outputs to slow down. (Internal change: 2364900) | 1 年前 | |
Change Vdf_IsPoolOutput to consider any output that has an associated input and an affects mask to be a "pool" output, as a step toward generalizing the "pool" concept in Vdf. - For unit tests that otherwise trip the verify VdfPoolChainIndexer::GetIndex, add affects masks for outputs that are treated as pool outputs. - Similarly, update unit performance tests to make sure that we continue to benenfit from the performance benefits of special handling for pool outputs. (Internal change: 2363892) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: track executed nodes by schedule index instead of network index This serves two purposes. First, we reduce the size of the executedNodes bit set. It now scales in the number of scheduled nodes instead of the total size of the network. Second, the pull-based executor engine no longer directly requires the definition of VdfNetwork. (Internal change: 2377871) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Replace Vdf_GetIteratorSource with Vdf_IsIteratorSourcePool (Internal change: 2369690) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Fixes a thread-safety issue with concurrently growing the node filter vector. The concurrent growth methods on tbb::concurrent_vector are thread-safe, with the exception of invocation of constructors of newly added entries not synchronizing with concurrent access of those new entries. This can lead to newly added entries still being under construction, if they are immediately accessed from another thread, for example, after concurrent calls to grow_to_at_least() or grow_by() return. In the past, we have solved this by passing a custom allocator that zero- initializes memory underpinning tbb::concurrent_vector allocations, and then relying on the default-initializing constructor of std::atomic not overwriting that memory at construction time - even though this already dabbles in undefined behavior. Starting with C++20, the std::atomic constructor will be value- initializing the underlying integer object, which runs the risk of constructors resetting the entries to 0 after, for example, atomic increments have already been performed. We will, however, be able to use std::atomic_ref to replace this code once C++20 is available to us. In the meantime, his change attempts to solve the problem in a different way, using an atomic flag to synchronize on concurrent growth, including constructor invocation by the first thread that gets to calling grow_to_at_least. (Internal change: 2362415) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: specialize keep mask accumulation for speculation nodes Determining keep masks is typically a small portion of overall scheduling costs. However, speculation vectorization can produce a pathological input for the previous implementation when a read/write output, which may pass its buffer, has many speculations that read from it. Without vectorization, there are n connections to n speculation nodes, each with a single input and output, so this scales linearly in the number of speculations. However, we vectorize speculations together into a single node with n inputs and n outputs to amortize the overhead of internal speculation scheduling and evaluation. Unfortunately, in the scenario above, this causes _SetBufferPassDataForOutputs to visit n outputs for each of the n input connections. Additionally, though VdfSpeculationNode's _ComputeInputDependencyMask method takes advantage of the knowledge that speculation inputs can only depend on the output with the same name, VdfNode::GetOutput is implemented with linear search. This yields a worst-case O(n^3) time complexity. As a practical result, we see a vectorized speculation node with ~2400 input/output pairs driving ~3 seconds of overhead in _SetBufferPassDataForOutputs. While we could specialize the input connection dependency query as it is currently stated by the scheduler, instead, consider that the role of speculation nodes in the system is to permit evaluation in the presence of topological cycles that are not sparse data-dependency cycles. As such, speculation nodes do not actually read values across their input connections; they use an internal executor to invoke whichever nodes are needed to produce the speculation outputs. So, the result of _ComputeInputDependencyMask does not necessarily capture the potentially relevant keep bits for a speculation node anyway. Therefore, we skip speculation node input dependencies entirely for the purpose of determining the keep mask. (Internal change: 2378936) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
exec: Fix -Winconsistent-missing-override warnings on clang This removes 645 out of 755 warnings when building on Mac. (Internal change: 2387063) | 11 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
VdfSparseOutputTraverser: Use compile time debug codes to enable debug output, instead of using a #define. Remove compile time debugging that no longer compiled when enabled. (Internal change: 2400294) | 7 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Tidy up some exec-related includes This is mostly focused on vdf/network.h because, while the network is an important high-level piece of the architecture, very few parts of the system should actually access VdfNetwork directly. Some other includes were cleaned up as well when it was obvious that they weren't necessary. At a high level, we would expect the owner of the network (e.g. Exec_Program) and compilation (e.g. Exec_Compiler) to require VdfNetwork's definition. Scheduling, evaluation and extraction would operate exclusively on the masked outputs produced by compilation. Network objects are traversable without accessing VdfNetwork directly. In practice, there are some direct uses of VdfNetwork in other parts of execution. Scheduling relies on the network's pool chain indexer. However, this is contained within VdfScheduler's implementation and does not cause downstream users of VdfScheduler to include network.h. Many sites use VdfNetwork's node capacity to presize per-node data structures. A few only need the nested AppendConnection constant. (Internal change: 2370270) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Re-introduce scoped parallelism to nested speculation tasks to ensure that they can make progress independently of parent execution tasks, i.e. inner nested speculation tasks will only be allowed to steal tasks spawned within their isolated scope. This is intended to improve performance by ensuring that idle threads are making progress on blocking inner nested tasks. This change also includes a test for nested speculation using a parallel parent executor with full and limited concurrency. (Internal change: 2378497) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: track nodes by schedule index instead of network index Similar to VdfPullBasedExecutorEngine, track executed and speculated nodes by schedule index to avoid scaling the bitset in the total size of the network rather than the size of the schedule. (Internal change: 2384158) | 11 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Move EfExecutor and EfSubExecutor to Vdf We initially noticed something needed to change here because testVdfSpeculation needs to use EfExecutor, in order to use VdfParallelExecutorEngine. The downstream dependency causes problems in some builds. That pointed out that VdfExecutor is core functionality that it makes sense for Vdf to provide, and VdfSubExecutor is a dependency that comes along for the ride. We need to follow up on this by adding Vdf unit test coverage for the moved classes, but there are no relevant tests in ef that can be moved along with these files. So we're proceeding with moving these definitions in order to fix the problem with the testVdfSpeculation dependencies. Fixes #3871 (Internal change: 2401163) | 7 个月前 | |
vdf: Move VdfSubrangeView::const_iterator::operator== into class def This avoids an "undeclared identifier" error when building with Visual Studio and the /permissive- (standards conformance) compiler option. See #2340 (Internal change: 2386717) | 11 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: small modernization for type dispatch tables Update VdfTypeDispatchTable to use robin_map instead of TfHashMap, pass TfType by value, reword and reformat some doc comments. (Internal change: 2367713) | 1 年前 | |
vdf: small modernization for type dispatch tables Update VdfTypeDispatchTable to use robin_map instead of TfHashMap, pass TfType by value, reword and reformat some doc comments. (Internal change: 2367713) | 1 年前 | |
vdf: allow direct construction of a sized VdfTypedVector Previously, constructing a typed vector with a specific size required constructing a typed vector with 0 elements and then resizing it. Instead, introduce VdfTypedVector<T>::CreateWithSize() that constructs the same vector directly. This is both more convenient and avoids the redundant construction and destruction of an empty impl. (Internal change: 2367210) | 1 年前 | |
Rename PRESTO_MULTITHREADED_MUNGING to VDF_ENABLE_PARALLEL_EVALUATION_ENGINE in preparation for OpenExec. (Internal change: 2363502) | 1 年前 | |
Remove VDF_ID_UNKNOWN constant. The constant only existed to support default-constructed instances of Exec_UncompilationRule. That constructor must be defined to support Exec_UncompilationRuleSet::erase (which uses tbb::concurrent_vector::resize) but we never actually call that constructor, since resize is used to shrink the vector, never grow it. The default constructor remains defined, but now emits a coding error. (Internal change: 2361946) | 1 年前 | |
vdf: implicitly typed VdfContext::SetEmptyOutput VdfOutputSpec already knows its type so requiring users to also specify the type in SetEmptyOutput is just an opportunity to get something wrong. This change also allows the implementation to live entirely out of line. (Internal change: 2401393) | 7 个月前 | |
vdf: implicitly typed VdfContext::SetEmptyOutput VdfOutputSpec already knows its type so requiring users to also specify the type in SetEmptyOutput is just an opportunity to get something wrong. This change also allows the implementation to live entirely out of line. (Internal change: 2401393) | 7 个月前 | |
vdf: change is-boxed container trait type to be a template variable (Internal change: 2368475) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
OpenExec: Changed the VdfVector boxed vector implementation GetNumStoredElements to return 0 when the box iself is empty and 1 if it holds data. Previously, this method always returned 1. This will facilitate removing the template parameter from VdfContext::HasInputValue by allowing GetNumStoredElements to be reliably used to test whether or a given VdfVector contains any data. (Internal change: 2404324) | 6 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: change is-boxed container trait type to be a template variable (Internal change: 2368475) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: Replace negative index with explicit pointer arithmetic This is consistent with other parts of this code and fixes C4146 warnings on Visual Studio builds due to negating an unsigned type. That accounts for 298 out of 1023 total warnings. (Internal change: 2387371) | 10 个月前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: change is-boxed container trait type to be a template variable (Internal change: 2368475) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
vdf: Fix a case of UB, uninitialized reads when moving a default-constructed instance of types that leave members uninitialized by just using default constructors to create the instance in-place. (Internal change: 2375970) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 | |
Initial release of OpenExec libraries in OpenUSD. This code is still in early development and should be considered experimental. It is also still missing critical features required to make the system usable. For now, OpenExec must be explicitly enabled in the build by specifying the PXR_BUILD_EXEC flag when running cmake. (Internal change: 2361730) (Internal change: 2362080) | 1 年前 |
Vdf: Vectorized Data Flow
The vdf library provides the foundation for building and evaluating vectorized dataflow netorks.
Key Concepts
VdfNetwork embodies a dataflow network consisting of nodes (VdfNode) that perform computation with data flowing from node outputs to node inputs (see VdfConnection).