Randall Hopper:
|richard:
| |I am wondering if this will affect our VR application. We use pointers
| |to DX data inside draw operations that occur on multiple graphics heads
| |so memory locks may be important even in DX's single-processor mode.
...
|my aim is to identify which dxexec lock sets are the bottlenecks and
|selectively disable them for the single-process case, ideally leaving the
|libdx locks as-is (always enabled).
Richard, more research convinced me that applying this mod to all
locks was the better choice. Further profiling revealed that over 80% of
the locks toggled during network evaluations are associated with memory
allocation (amalloc, arealloc, afree) -- to my surprise, this is true even
for cached executions. This massive mallocing during cached passes is
another bottleneck to explore at some point.
At any rate, relevent to your usage, memory allocation (and therefore
memory locking) is exposed through the libDX/libDXcallm APIs. So with the
patch I just cooked, the default locking policy defaults to enabled (used
by libDX/libDXcallm clients) as before. However, dxexec will flip this off
internally if it knows it doesn't need it.
--
Randall Hopper (mailto:[EMAIL PROTECTED])
EPA Scientific Visualization Center
US EPA MD/24 ERC-1A; RTP, NC 27711
