Description
I have already noted to @jenatali that exposing WARP as CL_DEVICE_TYPE_GPU
is counterintuitive, I even tried running a poll on Twitter to see if I'm the only one thinking like it, but my Twitter penetration seems to have betrayed me. (That one vote out of 82 views did 100% agree with me though.) If slightly more votes would be useful, I could run it by the work-group and/or another poll posted by the OpenCLAPI Twitter user.
I understand that it's exposed as a GPU because "WARP for all intents and purposes behaves as a GPU", however OpenCL developers have explicit queries to find where work enqueued to a device executes and expect the ground truth.
- In both single and multi-GPU systems creating a context for all devices of type
CL_DEVICE_TYPE_GPU
of a given context and all of a sudden CPU usage skyrockets, is bad experience and unexpected. - OpenCL devs know, that if one wishes to use both the CPU and the GPU simultaneously, then they have to reserve some CPU cores for driver and app logic execution (using sub-devices). The bubbles in GPU exec created by CPU being busy executing device code is an overall net loss. (LuxMark can easily demonstrate this, as it doesn't employ this reservation.) However, the necessity of this reservation only becomes apparent to applications if the device is "properly" exposed as
CL_DEVICE_TYPE_CPU
. - Similarly non-GPU devices loaded using MCDM instead of WDDM as mentione here are likely expected to be
CL_DEVICE_TYPE_ACCELERATOR
orCL_DEVICE_TYPE_CUSTOM
, which kind of circumvents the issue, of users querying CPU/GPU devices and getting stuff which don't support images.
(ps.: can't wait for OpenCLOn12 to land 3.0 support (SPIR-V support specifically). Keep up the good work!)
Activity