On 05/04/2018 04:59 AM, Jamie Strandboge wrote: > On Thu, 2018-05-03 at 20:42 +0300, Vincas Dargis wrote: >> Hi, >> >> Story begins with Debian user reporting issue that LibreOffice is >> denied >> access to OpenCL related files [0]. >> >> To fix that I've started to build opencl abstraction. While doing >> so, >> I've discovered that there are quite a few implementations. At least: >> >> * POCL (for CPU only I believe) >> * Intel Beignet (for Intel graphics) >> * Mesa Clover* (for nouveau and AMD) >> * NVIDIA (with proprietary driver) >> >> Current abstraction is found in my GitLab branch [1]. I've been >> testing >> opencl abstraction with help of >> /usr/share/doc/packages/python-pyopencl/examples/demo.py wrapped in >> a >> script with AppArmor profile [2] from python-pyopencl package >> (Debian >> Sid, Ubuntu 18.04 and openSUSE Tumbleweed from some non-official >> repo). >> That demo.py allows to select for OpenCL implementation which helped >> a lot. >> >> Now, the question is, should it be one single abstraction file >> dealing >> with all and different OpenCL implementations? The question arises >> from >> the fact that POCL implementation needs to: >> >> * Execute clang compiler (there's opencl_clang child profile) >> * Execute linker (also child profile exists) >> * mmap for execution compiled & linked modules from user writable >> cache >> directories. (!) >> >> Meanwhile, for the probably first use case of this abstraction, >> namely >> that LibreOffice profile, POCL is not used, as LibreOffice enables >> OpenCL option only when I run it with discrete NVIDIA graphics on my >> laptop (it ignores integrated Intel graphics too). So all that POCL >> stuff allowed by default is kinda too much for my taste... >> >> So I wonder, maybe it's worth to let final profile author to select >> what >> OpenCL implementation should be allowed? >> >> Possible alternatives: >> >> 1. Split into multiple abstractions, like: >> * opencl-common (probably only /etc/OpenCL/** r, maybe something >> else) >> * opencl-pocl >> * opencl-nvidia >> * opencl-whatever. >> > > Personally I like abstractions to be widely useful provided the > permission groupings make sense together and don't introduce anything > iffy. I agree with you that some of the POCL stuff sounds iffy. Without > seeing the actual rules/denials, what about a variation on the above: > > * opencl (has intel, mesa, the non-iffy parts of pocl and the > non-nvidia parts of opencl-nvidia, etc) > * add the nvidia-specific bits of opencl-nvidia to the nvidia > abstraction (ie, there is no 'opencl-nvidia' abstraction) > * omit opencl-pocl and let pocl users add the weird accesses > themselves. *if* this becomes burdensome for people, then > perhaps add opencl-pocl that does an '#include > <abstractions/opencl>' > > I think we need them split out, whether the original proposal or Jamie's I'm unsure.
I do think if we go Jamie's route that instead of having pocl users embed the weirdness we have a pocl abstraction, keeping the semantic from the beginning is worth it. On top of each of the opencl-XXX abstractions I think it would be worth having a generic opencl abstraction that includes the various sub-abstractions, its wide now but the intent will be to tighten it up with conditionals once better support lands. If someone cares they use the finer abstraction, but the generic one is there and can just be used for those who just want opencl to work no matter which system they are on.
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
