Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider exposing WARP as CL_DEVICE_TYPE_CPU #19

Closed
MathiasMagnus opened this issue Apr 13, 2021 · 2 comments · Fixed by #45
Closed

Consider exposing WARP as CL_DEVICE_TYPE_CPU #19

MathiasMagnus opened this issue Apr 13, 2021 · 2 comments · Fixed by #45
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@MathiasMagnus
Copy link

MathiasMagnus commented Apr 13, 2021

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 or CL_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!)

@jenatali
Copy link
Member

Hm, I think I agree with you here.

I'll probably add an environment variable to force one way or the other, with CPU as the default, as we like to use WARP as an isolation test to see if issues are caused by graphics drivers, and I wouldn't be surprised if some CL applications will only use GPUs.

I also agree with MCDM being ACCELERATOR, but if we're using DXGI instead of DXCore there's no way to distinguish between the two without initialization a D3D12 device, which would really slow down platform initialization, so I'll probably only make that change if we're using DXCore (which we should be on modern versions of Windows).

@BlohoJo
Copy link

BlohoJo commented Feb 11, 2024

I am a user who needs OpenCLon12 to expose WARP as a GPU device. It always crashed for me in version 22.0 and below . It is now working in version 23.0 and above, but I still can't use it because it was changed to a CPU device! :(

jenatali implied that it could be selected with an environment variable, but I'm not sure if this was done or not, or what the environment variable would be or how to set it.

Please consider allowing users to select how OpenCLon12 exposes WARP to the system: as either CPU, or GPU.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants