Ppixar-ossRegenerate precompiled headers
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
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 年前 | |
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 年前 | |
Avoid invalidating EfDependencyCache entries that are not incrementally updated in response to added and deleted connections that don't affect the cached traversals. (Internal change: 2361947) | 1 年前 | |
ef: fix implicit conversion oversight Prior to C++20, std::memory_order is an unscoped enum and is, therefore, implicitly convertible to bool. This happened to work out because the intended value is false and memory_order_relaxed is the first enumerator. (Internal change: 2403580) | 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 年前 | |
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 年前 | |
Fix bug in AsALeafNode introduced by a recent change. All leaf nodes have 0 outputs. The code was accidentally checking for 0 inputs. Consequently, AsALeafNode always returned false, and leaf nodes were never purged from Exec_CompiledLeafNodeCache. We would then fail to re-compile leaf nodes, because they were still found in the cache. Also, add a unit-test that would have caught the bug. (Internal change: 2369706) | 1 年前 | |
Remove some unused tbb headers. (Internal change: 2396374) | 8 个月前 | |
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 年前 | |
Hooks the leaf node cache up to the exec system, and ensures that said cache can be populated in parallel. (Internal change: 2362188) | 1 年前 | |
Hooks the leaf node cache up to the exec system, and ensures that said cache can be populated in parallel. (Internal change: 2362188) | 1 年前 | |
ef: factor out lofted output set of page cache-based executor The bookkeeping for lofted outputs is independent of the executor's template parameters. (Internal change: 2373090) | 1 年前 | |
ef: factor out lofted output set of page cache-based executor The bookkeeping for lofted outputs is independent of the executor's template parameters. (Internal change: 2373090) | 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 个月前 | |
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 年前 | |
exec: Fix -Winconsistent-missing-override warnings on clang This removes 645 out of 755 warnings when building on Mac. (Internal change: 2387063) | 11 个月前 | |
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 年前 | |
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 个月前 | |
Enables EfPageCacheStorage to be resized after network edits, instead of resizing after every node addition. (Internal change: 2368142) | 1 年前 | |
Enables EfPageCacheStorage to be resized after network edits, instead of resizing after every node addition. (Internal change: 2368142) | 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 个月前 | |
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 个月前 | |
Removes the spline evaluation location from EfTime, now that UsdTimeCode implements the concept of pre-time evaluation. (Internal change: 2366310) | 1 年前 | |
ef: add missing symbol export for EfTime::GetAsString() (Internal change: 2366317) | 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 the spline evaluation location from EfTime, now that UsdTimeCode implements the concept of pre-time evaluation. (Internal change: 2366310) | 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 年前 | |
Adds a cache for time-varying computed values, in order to make computed values persist across time changes. This also addresses a bug with time-dependent outputs that were not also attribute input nodes not invalidating correctly on time changes. (Internal change: 2369820) | 1 年前 |