demo/ubuntu-demo-opencl looks like can't work about intel-device-plugins-for-kubernetes HOT 7 CLOSED

@taotriad could you please take a look?

from intel-device-plugins-for-kubernetes.

Hi @taotriad, can you reproduce this issue? or give me some advice about it ?
Thanks.

from intel-device-plugins-for-kubernetes.

I haven't tried the demo; we successfully use the plugin on our test cluster though, so if there's a bug it's likely in the demo rather than the plugin.

But if clinfo cannot get your GPU info it seems that the issue is further down in the stack; is your OpenCL function properly, and does it support the hardware you have?

from intel-device-plugins-for-kubernetes.

I would rather not mount your host's /etc and /opt to a container, because the demo image have its own OpenCL runtime installed in these directories which may differ from what you have in your host (e.g. beignet on the host and non-beignet in the container).

from intel-device-plugins-for-kubernetes.

I think in general you should never mount the host's /etc in your container. There are cases where mounting /opt might makes sense.

from intel-device-plugins-for-kubernetes.

I think simplest test for GPU access is this Dockerfile (named "test-vainfo" in run example below):

FROM ubuntu:18.04
RUN apt-get update && apt-get -y install vainfo

i965 media/VAAPI GPU driver gets pulled in to the container as "vainfo" dependency . That supports HW from Haswell to Coffeelake (whereas new iHD driver available from Github would support HW from BDW upwards).

$ docker run -it --rm -v /dev:/dev -v /etc:/etc -v /opt:/opt --privileged ubuntu-demo-opencl:devel

This worked as expected. Container prevented GPU device writes when that wasn't explicitly enabled.

If you run docker directly instead of using Kubernetes and GPU plugin, you need to do same thing as what the GPU plugin does, i.e. provide GPU device access to the container (you don't need to mount /dev or run container in privileged mode).

Like this:
$ docker run -it --rm --device /dev/dri/renderD128:/dev/dri/renderD128 -t test-vainfo vainfo

If GPU access works, vainfo prints out what HW you have and available VA-API profiles. If you remove the device mapping, i.e. prevent GPU access, vainfo doesn't detect what HW is in question and doesn't print any info.

I think in general you should never mount the host's /etc in your container. There are cases where mounting /opt might makes sense

Sometimes it's useful to mount specific files from host /etc to containers (e.g. passwd and/or group file so that names for numeric user & group IDs match host).

from intel-device-plugins-for-kubernetes.

I'm closing this issue as it seems to be caused by misuse of docker volumes, not a problem in the plugin. Please reopen if correct volumes don't solve the problem for you.

from intel-device-plugins-for-kubernetes.