Re: RFS: pyrit
Upstream here
Paul Wise <pabs <at> debian.org> writes:
> Unfortunately that is non-free. Unless pyrit works with nouveau or any
> of the drivers in Debian main, I think pyrit should go to contrib.
Pyrit has a SSE2-driven CPU-Core that makes it a fully functional,
gpl-compatible package on it's own; the GPU-parts are optional. Pyrit's
functionality does not depend on non-free packages.
>
> Err, isn't the whole point of OpenCL that it is cross-vendor???
>
Yes, but the situation regarding how to accomplish that is not very clear at the
moment. The Khronos Group (where the big OpenCL players like Nvidia and AMD
gather) has screwed up:
1. The main header file does not specify typedefs for the OpenCL-functions; it
is therefor not possible (in a clean way) to link the system-specific
OpenCL-library at runtime.
2. It *should* be possible to link at build-time, take the resulting binary and
load it somewhere else. However the different OpenCL-implementations still use
different calling conventions. Nvidia always used cdecl (with clean symbol
names) while AMD used stdcall (with mangled names) and switched to cdecl later
on. As far as I know it is still undefined which calling convention to use on
any specific combination of Windows/Linux/MacOS/32bit/64bit.
3. Khronos tries to resolve the situation by introducing a "installable client
driver" (ICD). The idea is to have a generic wrapper driver that everyone can
bind to and which knows about the vendor-specific implementations installed on
the system. It then passes function-calls to those drivers. The situation
regarding ICDs and how they should behave exactly is still unclear from my
perspective.
In the end, environments like Debian will probably have a (GPL'ed) ICD
themselve. Packages can link at build-time to this library which passes function
calls to the (non-free) gpu-drivers at runtime...
Reply to: