On Sat, Apr 4, 2015 at 10:30 AM, Rebecca N. Palmer
rebecca_pal...@zoho.com wrote:
The ICD interface works for me (i5-3230M), which makes this bug _both_
hardware- and interface-dependent, which is weird.
The other person that I'm in contact with and whose machine exhibits
the same problem has an Iris Pro.
Are you saying 1.0.0 didn't work for you at all, or are you saying 1.0.0
worked properly and this is a regression?
The full story goes like this:
until now, I've used the Debian-shipped packages (in a combination of
unstable and experimental versions). I've never tested it extensively
though, mostly running through (my own) clinfo. The first version that
_seemed_ to work properly (at least under clinfo) was 1.0.1-1, which I
recently upgraded to 1.0.2-1. It was only at this point that I
actually tried running some kernels on the device, and noticed the
failures. I've discussed this with the Iris Pro user on FreeNode
(#opencl channel), and it turns out that they had a similar
experience, except they were using the git tree and 1.0.0 actually
worked for them, but 1.0.1 didn't.
I've finally found the time to do the testing and run git bisect,
which found the culprit at this commit:
a27428d2f30d7859cb988c6fa93a2964c443373d is the first bad commit
commit a27428d2f30d7859cb988c6fa93a2964c443373d
Author: Zhigang Gong zhigang.g...@intel.com
Date: Wed Dec 24 09:21:28 2014 +0800
runtime: tweak max memory allocation size.
Increase the maximum memory allocation size to at least 512MB and
will set it to larger if the system has more total memory.
This tweak will make darktable happy to handle big pictures.
Signed-off-by: Zhigang Gong zhigang.g...@intel.com
v2:
reduce max constant buffer to 128MB.
v3:
fix the sysinfo usage.
Signed-off-by: Zhigang Gong zhigang.g...@intel.com
Tested-by: Meng, Mengmeng mengmeng.m...@intel.com
:04 04 af8bd19e9bf6f59d27fa2abc9fb67e4f6d476643
45aa59e8d4e84856d0152db1bcd814c58710e85b M src
which I find odd but honestly I don't know anything about the beignet
internals to judge 8-P
I've been testing the commits primarily with my suite of
overallocation/migration tests available at
http://github.com/Oblomov/cltests which is a bit special, but in fact
even simpler setups will fail.
I'm also testing a much simpler program (trivial vector sum, of which
I can attach the code), from which I have some interesting findings.
The simple vector sum allocates three vectors of ints, initializes two
of them to some specific values (i, numels - i respectively) and then
computes the sum. The findings are:
* up to 128*1024*1024 elements, things work even at the 'bad' commit;
* twice that results in the failure;
* thrice that or more results in an invalid buffer size error (-61).
Now the interesting result is thus that 256Mi elements claim to work
(in term of buffer allocation), _but_ the kernels fail to run _at all_
(with the 'culprit' commit): even the first element in the buffers is
NOT updated correctly.
Instead, with the commit right before that (last 'good' commit), 128Mi
elements fail to allocate (64Mi elements work).
To sum it up, the increase in maximum memory allocation size to at
least 512MiB 'works', but only up to a point: specifically, 512MiB
buffers work correctly, but (at least on my device) 1024MiB buffers
(which are allowed) cause the kernel to fail launching even though the
allocation allegedly works.
Should I Cc: Zhigang Gong on the discussion? I can also produce the
simple vector sum core if needed.
--
Giuseppe Oblomov Bilotta
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
