Jump to content

ericvids

Verified Members
  • Posts

    12
  • Joined

  • Last visited

Reputation

1 Neutral
  1. It works perfectly now! Thank you so much! Running as 64-bit binary Starting Hand Tracking SDK 0.9.4 OpenCL: Got 2 platforms OpenCL: Got 1 devices in platform 0 OpenCL: 0.0 extension: cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_d3d10_sharing cl_khr_d3d10_sharing cl_nv_d3d11_sharing cl_nv_copy_opts cl_nv_create_buffer cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_device_uuid OpenCL: 0.0 NVIDIA CUDA GeForce GTX 1050 Ti OpenCL C 1.2 score 1244160 = 6 * 1620 * 128, 0 OpenCL: Got 1 devices in platform 1 OpenCL: 1.0 extension: cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_icd cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_intel_subgroups cl_intel_required_subgroup_size cl_intel_subgroups_short cl_khr_spir cl_intel_accelerator cl_intel_driver_diagnostics cl_khr_priority_hints cl_khr_throttle_hints cl_khr_create_command_queue cl_intel_subgroups_char cl_intel_subgroups_long cl_khr_il_program cl_khr_fp64 cl_khr_subgroups cl_intel_spirv_device_side_avc_motion_estimation cl_intel_spirv_media_block_io cl_intel_spirv_subgroups cl_khr_spirv_no_integer_wrap_decoration cl_intel_unified_shared_memory_preview cl_khr_mipmap_image cl_khr_mipmap_image_writes cl_intel_planar_yuv cl_intel_packed_yuv cl_intel_motion_estimation cl_intel_device_side_avc_motion_estimation cl_intel_advanced_motion_estimation cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_image2d_from_buffer cl_khr_depth_images cl_intel_media_block_io cl_khr_3d_image_writes cl_khr_gl_sharing cl_khr_gl_depth_images cl_khr_gl_event cl_khr_gl_msaa_sharing cl_intel_dx9_media_sharing cl_khr_dx9_media_sharing cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_intel_d3d11_nv12_media_sharing cl_intel_unified_sharing cl_intel_simultaneous_sharing OpenCL: 1.0 Intel(R) OpenCL HD Graphics Intel(R) HD Graphics 630 OpenCL C 2.0 score 26400 = 24 * 1100 * 1, 2 Using OpenCL device: NVIDIA CUDA GeForce GTX 1050 Ti OpenCL C 1.2 Init Cosmos camera error: FailedToInitialize Starting OpenVR... VR HMD: lighthouse LHR-EA95DA8D Camera Firmware: Version: 02.05.017 Date: 2016.Jul.19 Camera 0 intrinsics: 277.2, 277.2, 617.4, 465.24 Stop Video.
  2. Just tested it now. Wow, my iGPU was getting a silly high score after all! I hope this log guides your score calculation. 🙂 Running as 64-bit binary Starting Hand Tracking SDK 0.9.4 OpenCL: Got 2 platforms OpenCL: Got 1 devices in platform 0 OpenCL: 0.0 NVIDIA CUDA GeForce GTX 1050 Ti OpenCL C 1.2 score 1244160 = 6 * 1620 * 128 OpenCL: Got 1 devices in platform 1 OpenCL: 1.0 Intel(R) OpenCL HD Graphics Intel(R) HD Graphics 630 OpenCL C 2.0 score 1689600 = 24 * 1100 * 64 Using OpenCL device: Intel(R) OpenCL HD Graphics Intel(R) HD Graphics 630 OpenCL C 2.0 Init Cosmos camera error: FailedToInitialize Starting OpenVR... VR HMD: lighthouse LHR-EA95DA8D Camera Firmware: Version: 02.05.017 Date: 2016.Jul.19 Camera 0 intrinsics: 277.2, 277.2, 617.4, 465.24 Stop Video.
  3. I do observe the same behaviour in the two pre-built samples. The logs unfortunately don't indicate the OpenCL version being selected, but there is the telltale 2- to 3- minute delay before a hand is detected and gesture recognition is slow; and the registry hack to disable the iGPU fixes the delay/slowdown as expected. I have a suspicion that Unity is fiddling around with the GPU hardware properties that get reported back to your DLL, probably blocking the CUDA device from being reported at all? (I don't know how else to explain the discrepancy when running your standalone device.exe). If you need me to run a debug DLL to log the properties of my hardware from within Unity, I'm more than happy to oblige.
  4. Hi @zzy, I'm using Unity LTS 2019.4.18f1. I'm also using Windows 10 Home Single Language 20H2 in case that's relevant --- since 20H1, Windows introduced hardware-accelerated GPU scheduling which may be wreaking havoc with my GPU preference settings (though nothing changes for me whether I switch it on or off).
  5. Aristo.log does not show any information on which OpenCL is selected. Here's the content after a full run: Running as 64-bit binary Starting Hand Tracking SDK 0.9.4 Init Cosmos camera error: FailedToInitialize Starting OpenVR... VR HMD: lighthouse LHR-EA95DA8D Camera Firmware: Version: 02.05.017 Date: 2016.Jul.19 Camera 0 intrinsics: 277.2, 277.2, 617.4, 465.24 Stop Video. On the other hand, the Unity Editor log does report the following: Using OpenCL device: Intel(R) OpenCL HD Graphics Intel(R) HD Graphics 630 OpenCL C 2.0 I have set the Unity Editor to High Performance (GPU: NVIDIA GeForce GTX 1050Ti), both in the NVIDIA Control Panel and in the new Windows 10 advanced graphics settings panel (since NVIDIA Control Panel as of driver version 461.09 informs me that "Windows OS now manages the selection of the graphics processor"). It is very strange that the device.exe you provided selects the NVIDIA processor while the Unity editor selects the Intel one. Perhaps Unity or some other process along the way is actually locking or hiding the NVIDIA OpenCL driver so that it is not visible to your selection logic? But again, when I do the registry hack, Unity will use the NVIDIA GPU for OpenCL just fine. @zzy
  6. Here's the result of the program on my system:
  7. Is it possible to add a feature to select which OpenCL platform and GPU should be used by Vive hand tracking? (This is in the context of the Unity plugin.) As I recently encountered, I was experiencing long initialization times (see my previous thread https://forum.vive.com/topic/9079-094-fails-to-initialize/). It turns out that the real problem was that the hand tracking library would default to the integrated Intel device on my laptop, even if the NVIDIA driver is installed correctly. This problem has begun apparently when I did a fresh install of my graphics drivers, which resulted in getting the very latest Intel drivers with upgraded (but not faster) OpenCL support. I am not sure how Vive Hand Tracking internally selects the OpenCL platform to use, but my guess is that since the Intel driver has a "newer" OpenCL (version 2.1 NEO) versus the NVIDIA one (version 1.2), it defaults to the former. Unfortunately, Vive Hand tracking performs very poorly on the Intel device versus the NVIDIA one. For now, I manually disable the Intel OpenCL driver by going into the registry and manually removing HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000\OpenCLDriverName and OpenCLDriverNameWow string values corresponding to the intel driver (igdrcl64.dll and igdrcl32.dll respectively). This is quite an ugly hack. Ideally, Vive Hand Tracking should automatically select the "faster" OpenCL ICD available on the system, but there seems to be no reliable way of finding that out in advance (as seen here, since NVIDIA does not support OpenCL 2.1 out of the box). According to GPU Caps Viewer, both Intel and NVIDIA devices present themselves as GPUs (which is technically correct but quite useless for differentiation), and the Intel device reports more compute units (24) versus NVIDIA (6), so an app can be misled to thinking that the Intel device is better. Because of that, I think Vive Hand Tracking should allow a manual override of the OpenCL platform/device that it chooses. Perhaps a system-wide environment variable can be used? (e.g., VIVE_HT_OPENCL_GPU or something similarly named, and it would just be an integer ID, and the error log would enumerate the valid IDs on app startup and auto-choose if the env var is not set?) @zzy
  8. Thanks for this! I tried this just now, however I noticed that once I got the NVIDIA OpenCL driver working correctly, the "Detection initialization completed" message never shows because GetGestureResult returns a nonzero index immediately. (Unlike with the Intel driver.) Maybe the line should be something like this instead? (to also allow transitioning from the initial lastIndex value of -1) if (index > 0 && lastIndex <= 0) Debug.Log("Detection initialization completed");
  9. Hi @zzy, you're right... I just discovered that when I let my headset sit for 5 minutes and pick it up again, the hand gestures would just start working. It's really weird that I didn't experience this long a delay before when using the older version (or maybe I did, but it somehow got cached so subsequent startups just work... in which case, I don't know why it's not caching now). I also noticed from my own log above that "Intel(R) OpenCL Intel(R) HD Graphics 630" was being used for OpenCL. I'm guessing this is not normal, and that it should be using the NVIDIA driver instead? Is it possible to include additional logging in the Unity editor to indicate the GestureProvider state switching from Starting to Running (not just on error)? This way developers can diagnose where the problem is whenever the startup time is unusually long, e.g., in my case, to alert me of the fact that my OpenCL is not working correctly.
  10. I have recently upgraded to Unity 2019.4.16f1 and Vive Hand Tracking SDK 0.9.4. I noticed that the hand tracking has stopped initializing properly, even on the prepackaged demo scenes. From a blank Unity project, I did a fresh import of the hand tracking SDK, and turned on VR support and the OpenVR SDK in Player Settings, then I ran the UISample scene from the SDK's samples. Unfortunately, no hands get shown, and the editor log does not show any problems. I have verified that I am getting camera input by using a Vive controller to go to the Steam settings menu and verifying the camera feed. Now here's the quirky part: Occasionally, when I press Home on the Vive controller, the hand suddenly gets initialized and the rest of the scene actually runs okay. This has happened VERY few times however, and I have been unable to track a log file of when this happened. I have also noticed that whenever the plugin is not initializing, OpenVR shutdown is taking longer than expected. I suspect that it is waiting for unfinished calls to the Hand Tracking DLL. I tried this with both SteamVR regular version 1.15.12 and SteamVR beta 1.15.13.
  11. Thank you for your help @zzy -- the whole process you outlined is flawless! I was previously not using the SteamVR plugin (instead relying on Unity's built-in OpenVR support, which was rather limited), so I was trying to get Unity's own WebCamTexture to work for providing the camera feed. As it turns out, WebCamTexture had a bunch of problems (most important of which is that it exclusively locks the camera). Thanks for pointing me towards the SteamVR TrackedCamera API! @ericvids
  12. The Hand Tracking SDK requires the headset's back-facing camera to be enabled in SteamVR settings. However, this stops Unity from being able to access the same device camera as a WebCamTexture when I import the Unity plugin into my project. Is there a workaround to get camera frames as textures, either through the plugin itself (since obviously the plugin initialized it) or some other means, perhaps my own Unity plugin? (I'm ok with having to write C++ code, I just don't know what camera API to use to be compatible with the Hand Tracking SDK.) Purpose: I want to simulate an Augmented Reality setup with hand tracking, mimicking a (very crude) HoloLens. I'm using the original HTC Vive.
×
×
  • Create New...