Both [3.18 kernel] and the 3.16 kernel have a different intermittent failure I
have
yet to investigate:
compiler_fill_image_1d_array()[FAILED]
Error: dst[j*w + i] == 0
at file
/home/rnpalmer/Debian/builds/stackbuild/beignet/utests/compiler_fill_image_1d_array.cpp,
function compiler_f
As previously noted, when cl_mem_allocate fails, its error handling then
calls cl_mem_delete on the incompletely-set-up buffer, which aborts at
assert(mem->ctx).
This patch appears to fix the problem, but be warned I don't know this
code well enough to know what else it might break.
Signed-o
Two patches from Debian's packaging of 1.0.1:
Prefer LLVM 3.5 (as recently suggested here):
https://anonscm.debian.org/cgit/pkg-opencl/beignet.git/tree/debian/patches/llvm-search-order.patch
Don't use -D__$(USER)__ (it breaks on usernames containing special
characters):
https://anonscm.debia
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779213
Summary: On hardware where the Intel GPU is disabled, beignet was found
to assert-fail on load, taking the application down with it before it
can do anything (including checking for hardware via clGetDeviceIDs).
This fixes this crash, allo
It is currently not possible to have 32- and 64-bit builds of beignet
installed on the same system, as the path in intel-beignet.icd
can only be one of the two installations. This fixes this by giving
this file a different name when beignet is installed in a multiarch
directory:
intel-beignet-i38
As to the multi-arch support for beignet, I assume the requirement is from
running 32-bit binary on a 64-bit system. Right?
Yes.
Then the 32bit application will call to ocl-icd to search available icd files.
I never test it and don't know whether the ocl-icd library will choose the
32bit beigne
That the file gets named intel-beignet-.icd rather than
intel-beignet.icd is a purely cosmetic issue: it should work either way,
but won't support multiarch, as the names of .icd files need to be
distinct for co-installability but are otherwise irrelevant.
If you want working multiarch, you'll
Compile the OpenCL standard library with the same version of clang
as will compile OpenCL user code, not plain "clang" (i.e. the
system default version, which may be different).
Signed-off-by: Rebecca Palmer
diff --git a/CMake/FindLLVM.cmake b/CMake/FindLLVM.cmake
index e214437..fa13f1d 100644
As beignet now works with LLVM/Clang 3.6, accept this version
when searching for llvm-config.
Signed-off-by: Rebecca Palmer
diff --git a/CMake/FindLLVM.cmake b/CMake/FindLLVM.cmake
index e214437..fa13f1d 100644
--- a/CMake/FindLLVM.cmake
+++ b/CMake/FindLLVM.cmake
@@ -8,12 +8,12 @@
# LLVM_FOUN
If /dev/dri/cardX is inaccessible, return CL_DEVICE_NOT_FOUND,
don't assert-fail.
Signed-off-by: Rebecca Palmer
diff --git a/src/x11/dricommon.c b/src/x11/dricommon.c
index 03f542c..16f50e4 100644
--- a/src/x11/dricommon.c
+++ b/src/x11/dricommon.c
@@ -284,7 +284,6 @@ getDRI2State(Display* dpy,
runtime_marker_list()[FAILED]
Error: ((int*)buf_data[0])[i] == (int)value + 0x3
at file /tmp/buildd/beignet-1.0.2/utests/runtime_marker_list.cpp,
function runtime_marker_list, line 66
As this is only the second time I've seen this (the first was back in
0.9.3), it appears to be rare:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781875
___
Beignet mailing list
Beignet@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/beignet
Any suggestions what is missing here?
clang, and maybe other things. Try again after:
sudo apt-get install debhelper cmake pkg-config python ocl-icd-dev
ocl-icd-opencl-dev libdrm-dev libxfixes-dev libxext-dev llvm-3.5-dev
clang-3.5 libclang-3.5-dev libtinfo-dev libedit-dev zlib1g-dev
__
On 05/04/15 00:08, David Couturier wrote:
This looks like the problem I experienced on my i7-4770. I fixed the issue by
applying this patch to the kernel:
https://01.org/zh/beignet/downloads/linux-kernel-patch-hsw-support
That's the long-standing "no shared local memory on Haswell" problem,
Control: retitle -1 beignet: silently does nothing on large arrays
(previous discussion:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781875 )
This isn't a Haswell-specific problem (and might not be ICD-specific
either: did you test that at these sizes, or only with the testsuite?),
it's
https://01.org/zh/beignet/downloads/linux-kernel-patch-hsw-support
He's already said he has that applied, and is reporting a lot more than
30 test failures.
___
Beignet mailing list
Beignet@lists.freedesktop.org
http://lists.freedesktop.org/mailman/li
with a 4.0.0-rc6 kernel
...which includes that fix as standard.
Has anyone else tried beignet on Haswell-ULT, and if so, did it work?
___
Beignet mailing list
Beignet@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/beignet
The old tgamma=exp(lgamma) implementation had high rounding error on
large outputs, exceeding the 16ulp specification for approx. x>8
(hence the test failure in strict conformance mode).
Replace this with an implementation based on glibc's
http://sources.debian.net/src/glibc/2.19-17/sysdeps/ieee7
(Resend: the first copy appears to have gone missing)
0.01**20.5 is denormal; at least Ivy Bridge does not support
denormals and hence returns 0. As this is allowed by the
OpenCL standard, it shouldn't fail the test.
Signed-off-by: Rebecca Palmer
diff --git a/utests/builtin_pow.cpp b/utests/b
http://cgit.freedesktop.org/beignet/commit/?h=Release_v1.0&id=9e8874c7a16b029d5b857a11ff9b23102752b4db
was intended to catch the "silently does nothing on large arrays" bug,
and does so (with the message "drm_intel_gem_bo_context_exec() failed:
No space left on device").
However, a user report
Should use tgamma instead of tgammaf when generating reference.
That I agree with: we don't want the error of libc tgammaf (~4ulp)
appearing to be our error.
And the ulp bound is <= 16ulp
That I wouldn't: it's defined in terms of the infinitely precise value,
not the correctly-rounded-float va
I will raise this issue to Linux i915 kernel team. And hope we can get a
clean fix in Linux kernel side finally.
I agree that's a good idea, but given how long it is likely to take, I'd
like to at least give a clear user-friendly error in the meantime.
-Is it likely that "drm_intel_gem_bo_con
When I run "./utest_run", I get 18 errors,
Those tests use the __local memory space, which does not work on Haswell
without a kernel patch:
https://01.org/zh/beignet/downloads/linux-kernel-patch-hsw-support
When I run any OpenCL programs, I need root privilege
You shouldn't; you may have acci
Given that really fixing shared local memory on Haswell is likely
to take some time, at least make it an explicit error that points
the user to the kernel patch, instead of returning "success"
without actually doing the computation.
As I can't find an error code to check for this problem (if ther
From http://www.freedesktop.org/wiki/Software/Beignet/ :
Based on our test result, LLVM 3.5 has best pass rate on all the test suites.
Compare to LLVM 3.5, LLVM 3.6 has slightly lower pass rate(caused by one front
end bug at clang 3.6) but has better performance (3% to 5% up).
When I run the
"-61,[8] +62[,8]" means the following block adds one more line:
No, that means the _preceding_ block(s) add one more line, which they do.
raise
all_vector = 1,2,3,4,8,16
There was a space-only line between these: has the email system lost it?
Make the build scripts work in both Python
On 29/04/15 08:54, Zhigang Gong wrote:
The patch LGTM too, but the patch seems broken for me, could you check
and send a new version?
Don't know what's wrong with this one: what error do you get?
Compare with tgamma instead of tgammaf for better accuracy.
Include negative inputs, and handle the
On 29/04/15 10:11, Zhigang Gong wrote:
> Actually, almost all the patches you sent out have similar problem and
> I had manually applied them line by line before. I think it's better to
> find out the root cause.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/em
After revert the beignet's atomic in l3 patch [9e8874c ?], the
i915.enable_ppgtt=2 should work for HSW platform.
If it's that easy to really fix this, I agree we should do so; I'd taken
the absence of anything other than "patch the kernel" in the
documentation to mean that no other fix was know
(hopefully not corrupted this time...the other patch is in
http://lists.freedesktop.org/archives/beignet/2015-April/005614.html )
---
Compare with tgamma instead of tgammaf for better accuracy.
Include negative inputs, and handle the resulting denormals.
Print maximum error found.
Signed-off-by
Since commit d47f6dd8f308323919d2acb0c1b9f562c084866c, beignet has
included backend/src/ir/structural_analysis.* based on gpuocelot.
gpuocelot's license was then "BSD plus you must obey US export
restrictions (even if you are not in the US)". This is non-free by
Debian's definition[1,2], and
"Nothing works on Haswell-ULT" is a known bug, fixed by
http://cgit.freedesktop.org/beignet/commit/?id=83f8739b6fc4893fac60145326052ccb5cf653dc
(Should that also be applied to the 1.0 branch?)
If you prefer not to recompile beignet, a workaround is:
sudo echo 0 > /sys/module/i915/parameters/enab
Run a small __local-using kernel in clGetDeviceIDs; if this returns
the wrong result, return CL_DEVICE_NOT_FOUND.
---
> just check kernel version is not
> an ideal method for those unofficial kernels with back porting patches. Then
> we have the
> following open questions in my mind:
>
> How d
Reflect recent beignet and Linux changes.
diff --git a/docs/Beignet.mdwn b/docs/Beignet.mdwn
index ec528b5..c0650bb 100644
--- a/docs/Beignet.mdwn
+++ b/docs/Beignet.mdwn
@@ -142,7 +142,7 @@ Supported Targets
* 3rd Generation Intel Core Processors
* Intel “Bay Trail” platforms with Intel HD
Sorry, both of those should have been
Signed-off-by: Rebecca Palmer
As usual, I can only test on Ivy Bridge, so someone should
probably check that they actually catch the
no-__local-on-Haswell bug.
On 16/05/15 18:48, Rebecca N. Palmer wrote:
> Run a small __local-using kernel in clGetDevice
I also have an i5-3230M, and get the same error in my build chroots
(Debian sid = libdrm 2.4.64) but not my base system (Debian jessie =
libdrm 2.4.58); I have not attempted to determine whether the problem is
the version or being in a chroot.
___
Be
Debian are planning to switch their default LLVM/Clang to 3.6 soon. Is
it still the case that
The recommended LLVM/CLANG version is 3.5 and/or 3.6. Based on our test result,
LLVM 3.5 has best pass rate on all the test suites. Compare to LLVM 3.5, LLVM
3.6 has slightly lower pass rate(caused by
orked around it.
The bug was exposed by a subcase in Khronos OpenCL conformance test, we will
try to isolate the bug to report to llvm.
Thanks
Zou Nanhai
-Original Message-
From: Beignet [mailto:beignet-boun...@lists.freedesktop.org] On Behalf Of
Rebecca N. Palmer
Sent: Thursday, October 0
Reading p+1 when p==end is an out of bounds read.
Signed-off-by: Rebecca Palmer
---
(Found by valgrind while investigating #90472; probably not the
actual cause of that crash, but still a bug.)
diff --git a/backend/src/llvm/llvm_printf_parser.cpp
b/backend/src/llvm/llvm_printf_parser.cpp
index
When p==end (the null terminator byte), don't try to read p+1
(outside the string, so might be an invalid address or a '%' from
a different object).
Signed-off-by: Rebecca Palmer
diff --git a/backend/src/llvm/llvm_printf_parser.cpp
b/backend/src/llvm/llvm_printf_parser.cpp
index bdaed8a..f42710
On 03/11/15 01:50, Pan, Xiuli wrote:
LGTM, but the commit line is too long,
When it was written, the longest line was 66, but something appears to
have joined it back together; does
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/email-clients.txt#n208
wrote
When p == end (the null terminator byte), don't try to read p + 1:
as this is outside the string, it might be a '%' from a different
object (causing __parse_printf_state(end + 2, end, ...) to be called,
which will fail), or an invalid address.
Signed-off-by: Rebecca Palmer
---
backend/src/llvm/l
Specifically (and assuming it is the same bug on Ivy Bridge and
Haswell), fixed in git master by
http://cgit.freedesktop.org/beignet/commit/?id=f48b4f6766fcaa193652fcbe6ea0bb29f92e45aa
, still present in 1.1.x.
___
Beignet mailing list
Beignet@lists.
This has been the case for some time
(https://bugs.launchpad.net/ubuntu/+source/pyopencl/+bug/1354086); given
that I've also occasionally seen it in graphics-only use, the root cause
may be further down the stack.
___
Beignet mailing list
Beignet@lis
Would this be better if you turn off the overcommit via proc fs?
Only if you also disable any swap space ( sudo swapoff -a && sudo sh -c
"echo -n 2 > /proc/sys/vm/overcommit_memory" #warning, this may itself
crash your desktop); if I disable overcommit but leave swap on, I get a
hang with the
(The example in
https://bugs.launchpad.net/ubuntu/+source/pyopencl/+bug/1354086 no
longer hangs, so the "rapidly allocating and freeing pyopencl objects
doesn't actually free the memory" aspect has evidently been fixed, but
keeping too many objects for the available memory still does hang.
On fu
anhai
-Original Message-
From: Beignet [mailto:beignet-boun...@lists.freedesktop.org] On Behalf Of
Rebecca N. Palmer
Sent: Saturday, November 07, 2015 6:06 AM
To: beignet@lists.freedesktop.org
Subject: Re: [Beignet] Unrecoverable system lockup when allocating too much
memory
(The example in
101 - 147 of 147 matches
Mail list logo
