CMake Error: The following variables are used in this project, but they
are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake files:
CLANG_LIB
[...]
Please let me know what I'm missing.
libclang-3.7-dev ?
_
As beignet now works with LLVM/Clang 3.7, accept this version
when searching for llvm-config.
Signed-off-by: Rebecca Palmer
--- a/CMake/FindLLVM.cmake
+++ b/CMake/FindLLVM.cmake
@@ -8,12 +8,12 @@
# LLVM_FOUND - True if llvm found.
if (LLVM_INSTALL_DIR)
find_program(LLVM_CONFIG_EXECUTA
As noted at llvm_gen_backend:94, we currently lack a mechanism for
reporting failures in backend (beignet-managed) compiler passes to the
build log, and instead print the error to stderr and assert-fail.
This patch creates such a mechanism, and uses it for "function not found".
Please note that it
The documentation says "an unsupported feature which is to store/load
pointers to/from memory[...]We plan to fix it in next major release
1.1.0" (docs/Beignet.mdwn:216-219)
Given that 1.1.0 has now been released, and does appear to fix this
(creating an array of pointers works in 1.1.2 but not
prototype cannot use the
spir_function calling convention"), but I don't know whether this
applies to all missing-function errors.
On 06/06/16 23:37, Rebecca N. Palmer wrote:
As noted at llvm_gen_backend:94, we currently lack a mechanism for
reporting failures in backend (beignet-managed
cl_get_gt_device(): error, unknown device: 5916
[...] Is there a support missing for
Kabylake/.?
Yes - that error means "Beignet does not recognize this device, so will
not try to use it" (from
https://cgit.freedesktop.org/beignet/tree/src/cl_device_id.c#n597 ; the
supported devices list is i
I just built beignet in a chroot with no X11 installed; it didn't have
that string, and worked (when run as root - for ordinary users, it
failed with "/dev/dri/card0 not authenticated", but this is expected).
Debian's (with-X) beignet has that string and a few more (__cxx11,
x11_display, x11_s
it seems like the DRI is only available together with X. That's why I'm
specifically interested if you know how to make /dev/dri appear in non-X
environment.
That might explain why my test worked: while I had no X inside the
chroot, /dev/dri was bind-mounted from outside it, where there was X.
The drm.rnodes=1 kernel parameter mentioned in beignet's documentation
no longer exists (render nodes are on by default since
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/drm_stub.c?id=6d6dfcfb883818b40b58bac61cc72cab428a7a03),
but it wasn't supposed to
Signed-off-by: Rebecca Palmer
diff --git a/utests/utest_generator.py b/utests/utest_generator.py
index d66788c..f8fe35e 100644
--- a/utests/utest_generator.py
+++ b/utests/utest_generator.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python2
+#!/usr/bin/python
from __future__ import print_function
import os,
A patch set for supporting LLVM 3.9 was posted here last month
https://lists.freedesktop.org/archives/beignet/2016-August/007843.html
, but not pushed; why?
Debian mesa plans to switch to 3.9
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836913
and we would normally follow.
_
powr(x,y) is explicitly undefined for negative x; on my hardware,
it happens to be correct in default mode, but acts like pow(abs(x),y)
in fast (OCL_STRICT_CONFORMANCE=0) mode, failing the test.
Signed-off-by: Rebecca Palmer
diff --git a/utests/utest_math_gen.py b/utests/utest_math_gen.py
index
+ if (drm_intel_get_pooled_eu(driver->fd) >= 0) {
Shouldn't this be >0 , not >=0? The libdrm commit message (
https://cgit.freedesktop.org/mesa/drm/commit/intel/intel_bufmgr_gem.c?id=98887140e343493f01be7a1dec721c024bcf72c7
) says 0 means not supported.
(>=0 works for me with libdrm 2.4.71,
Signed-off-by: Rebecca N. Palmer
---
docs/Beignet.mdwn | 20 ++--
docs/howto/cross-compiler-howto.mdwn| 4 ++--
docs/howto/stand-alone-utest-howto.mdwn | 8
utests/builtin_global_linear_id.cpp | 2 +-
4 files changed, 17 insertions(+), 17
ocl-icd >= 2.2.8 has this function in its table; as the lookup process
tries the dispatch table before the ICD's clGetExtensionFunctionAddress,
requesting a function that is in the ICD loader's table but off the end
of the ICD's table will return a garbage pointer.
Signed
This is required to find KHR extensions via ICD, as the loader needs to
know which ICD to send the request to.
If the function is not found, fail the test instead of crashing.
---
utests/utest_helper.cpp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/utests/utest_helper.
Signed-off-by: Rebecca N. Palmer
---
utests/builtin_global_linear_id.cpp | 2 +-
utests/builtin_global_size.cpp| 2 +-
utests/builtin_kernel_block_motion_estimate_intel.cpp | 4 ++--
utests/builtin_local_size.cpp | 2 +-
utests
Signed-off-by: Rebecca N. Palmer
---
utests/CMakeLists.txt | 4 ++--
utests/builtin_kernel_block_motion_estimate_intel.cpp | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/utests/CMakeLists.txt b/utests/CMakeLists.txt
index f94256c..a5d8d40
This extends 4be3664 to the test suite.
Signed-off-by: Rebecca N. Palmer
---
utests/CMakeLists.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/utests/CMakeLists.txt b/utests/CMakeLists.txt
index a5d8d40..8b33666 100644
--- a/utests/CMakeLists.txt
+++ b/utests
> [ Chuanbo ] This utest test intel extension cl_intel_accelerator and
> cl_intel_motion_estimation, so it's not beignet specific,
> but it's intel specific. You can add code such as:
> if (!cl_check_accelerator() && !cl_check_motion_estimation())
> The implementation of cl_check_ac
This patch causes a warning:
/home/yr /beignet/src/cl_khr_icd.c:187:3: warning: initialization from
incompatible pointer type
clGetKernelSubGroupInfoKHR,
/home/yr/maintain/beignet/src/cl_khr_icd.c:187:3: warning: (near initialization
for ‘cl_khr_icd_dispatch.clUnknown136’)
I see that as we
Now I see that the problem is the API cannot be used through ICD, but in
OpenCL1.2 it is a vender extension.
Beignet may consider it a vendor extension, but ocl-icd doesn't:
anything with a KHR or EXT name goes through the "check the dispatch
table first" lookup process, whether or not it exist
v3: Use extension check, not beignet check. Treat claiming
to have the extension but not having the kernel as a failure.
---
(v2 was the un-numbered 10/10/16 08:07 version...which I subsequently
noticed was broken in that it assumed a non-NULL
clGetExtensionFunctionAddressForPlatform result meant
2baff9c moved mem->magic to cl_base_object.
---
(Or should this be CL_OBJECT_IS_MEM(mem), i.e. also checking the reference
count?)
--- a/src/cl_cmrt.cpp
+++ b/src/cl_cmrt.cpp
@@ -256,7 +256,7 @@ cl_int cmrt_set_kernel_arg(cl_kernel k,
result = cmrt_kernel->SetKernelArg(index, sz, value);
v3: Use extension check, not beignet check. Treat claiming
to have the extension but not having the kernel as a failure.
v4: Make extension check a function, use stderr.
---
> There is a bug in Beignet: cl_intel_motion_estimation is supported by IVB
> only, but all devices show string cl_intel_mo
> Beignet: self-test failed: (3, 7, 5) + (5, 7, 3) returned (3, 7, 5)
> See README.md or http://www.freedesktop.org/wiki/Software/Beignet/
> Beignet: disabling non-working device
That looks like the "no __local on Haswell" issue (Linux fixed this in 4.2,
but FreeBSD might not have): try
OCL_IGNOR
Weird - setenv.sh has export OCL_IGNORE_SELF_TEST=1, which is supposed
to turn that off (does setting environment variables that way not work
in FreeBSD? if so, you'll also need to set the rest of setenv.sh in
whatever way does work). Does passing that explicitly (i.e.
OCL_IGNORE_SELF_TEST=1 .
> builtin_kernel_block_motion_estimate_intel()[SUCCESS]
> runtime_climage_from_boname()Unresolved symbol:
> _Z22__gen_ocl_write_imagef11ocl_image2dDv2_iDv4_f
> Aborting...
That message is from backend/src/llvm/llvm_gen_backend.hpp:97, and means
it can't find that function (in its internal lis
That looks like abi::__cxa_demangle is sometimes failing completely
(and possibly inconsistently, given that it's failing on a different
symbol this time). Given that it only happens on FreeBSD, possibly
a libc++ (LLVM) vs libstdc++ (GCC) issue??
___
Be
As the "do we have any usable devices?" check uses this,
it needs to not crash even when we don't.
Signed-off-by: Rebecca N. Palmer
---
The user who reported a crash here ( https://bugs.debian.org/848792 )
was using unsupported hardware, but I don't know whether this is
t
When beignet 1.2.1 is built with LLVM 3.9,
OCL_STRICT_CONFORMANCE=0 utest_run -c vload_test_uchar
(and other vload_test_*) hang during kernel compile, deep inside LLVM.
This does not happen in master; a bisect finds the fix to be 75cb7ca,
and applying this to 1.2.1 (at least in the Debian package)
AppStream is a standard for software metadata,
including what hardware a driver supports:
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
Signed-off-by: Rebecca N. Palmer
---
Before this is pushed, needs to be filled in:
AppStream prefer a permissive license (such as CC0
is there any downside in compiling with
OpenCL 2.0 support,
Yes - on older (Ivybridge/Haswell - no emitUntypedReadA64Instruction)
hardware, a 2.0-enabled beignet won't work, at all.
I see two possible approaches:
-Build two beignet packages, with and without 2.0 enabled, and make the
with-2.0
On 21/01/17 15:40, Bruno Pagani wrote:
Le 21/01/2017 à 16:20, Rebecca N. Palmer a écrit :
is there any downside in compiling with
OpenCL 2.0 support,
Yes - on older (Ivybridge/Haswell - no emitUntypedReadA64Instruction)
hardware, a 2.0-enabled beignet won't work, at all.
That’s what
I have a first attempt at "enable/disable 2.0 at run time" written, but
haven't yet tested it.
On 21/01/17 16:08, Bruno Pagani wrote:
Le 21/01/2017 à 16:55, Rebecca N. Palmer a écrit :
On 21/01/17 15:40, Bruno Pagani wrote:
Le 21/01/2017 à 16:20, Rebecca N. Palmer a écrit :
t test that) would be appreciated.
(Upstream may not want to take this as-is, as it doesn't scale very
well to more than one 2.0-supporting hardware generation: it's
intended as a quick relatively-low-risk fix for packagers.)
Signed-off-by: Rebecca N. Palmer
--- beignet-1.3.0.orig/C
As for the "OpenCL 2.0 = worse performance" problem, the OpenCL spec
actually _requires_ 2.0 compilers to default to 1.2, and only enable
2.0 if explicitly asked to:
https://www.khronos.org/registry/OpenCL/specs/opencl-2.0.pdf page 203
beignet currently defaults to 2.0 if it is enabled, but this i
to be faster). Update documentation.
Unconditionally build 2.0-only tests, but skip them on non-2.0
hardware. Add -cl-std=2.0 to tests that need it.
Signed-off-by: Rebecca N. Palmer
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -231,19 +231,8 @@ IF (EXPERIMENTAL_DOUBLE)
ADD_DEFINITIONS
Signed-off-by: Rebecca N. Palmer
--
(Possibly should be higher in the priority order, since it's required for
OpenCL 2.0?)
--- a/CMake/FindLLVM.cmake
+++ b/CMake/FindLLVM.cmake
@@ -8,12 +8,12 @@
# LLVM_FOUND - True if llvm found.
if (LLVM_INSTALL_DIR)
find_pr
Signed-off-by: Rebecca N. Palmer
--- a/backend/src/llvm/llvm_gen_backend.cpp
+++ b/backend/src/llvm/llvm_gen_backend.cpp
@@ -308,7 +308,7 @@ namespace gbe
if(StrTy)
return getTypeByteSize(unit,StrTy);
}
- GBE_ASSERTM(false, "Unspported type
Signed-off-by: Rebecca N. Palmer
---
> -The release notes say cl_khr_gl_sharing is now supported, but
> docs/Beignet.mdwn still says it isn't.
It exists but is off by default, probably because it isn't finished:
clEnqueueAcquireGLObjects / clEnqueueReleaseGLObjects
Signed-off-by: Rebecca N. Palmer
---
(Warning: has not been tested)
diff --git a/src/cl_khr_icd.c b/src/cl_khr_icd.c
index 7b3600c..e4daf79 100644
--- a/src/cl_khr_icd.c
+++ b/src/cl_khr_icd.c
@@ -18,10 +18,14 @@
#include "cl_platform_id.h"
#include "CL/cl_
> regarding whether OpenCL 2.0
> is compiled or not I would rather think of something like that:
>
> – if llvm39 and libdrm2466 are found, compile with OpenCL 2.0 by default.
> – if they’re not, compile without it. Issue an error message if
> -DENABLE_OPENCL_20=1 was passed.
Agreed - we actually
[New recipients: this is a reply to
https://lists.freedesktop.org/archives/beignet/2017-January/008516.html ]
On 24/01/17 08:58, Pan, Xiuli wrote:
> And we have a conformance test with these patches, and the only problem is
> that the sizeof(void *):
> On GEN9 machine, the device will return 32 d
es/opencl2-runtime-detection.patch/#L351
is what I used, though you'll want to remove the (Debian-specific)
jessie-backports reference.
Signed-off-by: Rebecca N. Palmer
___
Beignet mailing list
Beignet@lists.freedesktop.org
https://lists.
7;utf-8')
has an error in python2.x:
Sorry, and that fix looks OK (though I haven't tried it).
Signed-off-by: Rebecca N. Palmer
___
Beignet mailing list
Beignet@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/beignet
Signed-off-by: Rebecca N. Palmer
--- a/docs/howto/gl-buffer-sharing-howto.mdwn
+++ b/docs/howto/gl-buffer-sharing-howto.mdwn
@@ -1,16 +1,16 @@
GL Buffer Sharing HowTo
=
-Beignet now support cl_khr_gl_sharing partially(the most commonly used part),
which is an offcial
Signed-off-by: Rebecca N. Palmer
--- a/docs/Beignet.mdwn
+++ b/docs/Beignet.mdwn
@@ -283,7 +283,7 @@ Documents for OpenCL application developers
- [[OpenGL Buffer Sharing|Beignet/howto/gl-buffer-sharing-howto]]
- [[Video Motion Estimation|Beignet/howto/video-motion-estimation-howto
+#ifdef ENABLE_OPENCL_20
+.address_bits = 64,
+#else
+.address_bits = 32,
+#endif
Should that be 32 unconditionally, like it now is in master?
https://lists.freedesktop.org/archives/beignet/2017-February/008565.html
___
Beignet mailing list
Beignet@lis
I think a better choice is to make OpenCL 1.2 also use 64bit address. So that
we have a unified address_bits across 1.2 and 2.0.
But using 64bit address would hurt some performance. I think we need more work on 64bit
optimization to make "unified address_bits across different ocl version" affect
If you can, revert to the jessie (not -backports) kernel: that fixes
this issue for me (on Ivybridge).
___
Beignet mailing list
Beignet@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/beignet
2:56:22 CET 2017 x86_64 GNU/Linux
2017-04-10 9:21 GMT+02:00 Rebecca N. Palmer :
If you can, revert to the jessie (not -backports) kernel: that fixes this
issue for me (on Ivybridge).
___
Beignet mailing list
Beignet@lists.freedesktop.org
https://lists
Debian 9 (stretch)/Ubuntu 17.04 (zesty) have beignet 1.3.0, libdrm
2.4.74/2.4.76 and Linux 4.9/4.10.
On some hardware (possibly all of Ivy Bridge and Haswell??), this does
not work at all: attempting to run anything fails with
drm_intel_gem_bo_context_exec() failed: Device or resource busy
Be
On 27/04/17 07:49, Yang, Rong R wrote:
As we know, this issue is introduce by commit
https://cgit.freedesktop.org/beignet/commit/?id=ff57cee0519db1287053c7c05a2cb4e9700d3334.
To clarify, this commit is not only for ocl 2.0, ocl 1.2 also need it for null
point check in the opencl kernel.
Does
As beignet's Debian maintainer, I am considering whether to enable CL-GL
sharing in our package, given its incomplete state.
Fedora do enable it, and have a Blender crash bug
https://bugs.freedesktop.org/show_bug.cgi?id=101779 , though as I can't
reproduce this I can't tell whether disabling i
The *missing* functions aren't likely to be a problem: as far as I can
tell,
http://sources.debian.net/src/forge/0.9.2-2/examples/opencl/cl_helpers.h/?hl=72#L72
is the only place in Debian that tries to use one of them, and it
correctly handles its absence.
I'm more worried about the potentia
Debian plans to remove LLVM 3.8 and 3.9, retaining 4.0 and 5.0 [0].
beignet 1.3.1 (currently in Debian) doesn't build with LLVM 4.0+, but
beignet git master does.
Fedora tried applying the 4.0-support patches to beignet 1.3.1, but
found that this made several applications crash, and are now u
(I'm asking for Debian - Fedora is already using LLVM 4 + git beignet)
On 08/09/17 07:57, Yang, Rong R wrote:
LLVM 5. 0 has been released, we are planning to release a minor release
1.3.2 to support LLVM 4.0 and
LLVM 5.0 after beignet's LLVM5.0 patches are ready.
Roughly how long do you
Signed-off-by: Rebecca N. Palmer
---
I'd actually like to make these (and all "invalid input" errors) return
CL_BUILD_PROGRAM_FAILURE instead of asserting, but that's a little
harder. (We have at least two mechanisms for that - GenContext.errCode
and gbeDiagnosticContext
Such patches were pushed to the 1.3 branch 12 days ago, and appear to
work, but I haven't yet checked for the bug Fedora had.
If (as is likely) Debian beignet gets asked to switch soon, should I use
current 1.3 git? and LLVM 4 or 5?
On 10/09/17 22:26, Rebecca N. Palmer wrote:
(I
Signed-off-by: Rebecca N. Palmer
--- a/docs/Beignet/Backend.mdwn
+++ b/docs/Beignet/Backend.mdwn
@@ -37,9 +37,7 @@ Environment variables are used all over
precision math instructions compliant with OpenCL Spec. So we provide a
software version to meet the high precision requirement
Signed-off-by: Rebecca N. Palmer
--- a/docs/Beignet/Backend.mdwn
+++ b/docs/Beignet/Backend.mdwn
@@ -9,10 +9,10 @@ Status
--
After two years development, beignet is mature now. It now supports all the
-OpenCL 1.2 mandatory features. Beignet get almost 100% pass rate with both
-OpenCV 3.0
.
https://bugzilla.redhat.com/show_bug.cgi?id=1478536 ,
https://bugzilla.redhat.com/show_bug.cgi?id=1460400 ), but these may be
unrelated bugs (e.g. the second is
https://bugs.freedesktop.org/show_bug.cgi?id=101485 ).
Signed-off-by: Rebecca N. Palmer
--- a/src/intel/intel_driver.c
+++ b/src
That wording implies this is Debian beignet (upstream beignet uses the
wording "cl_get_gt_device(): error, unknown device: %x"), which is 1.3.0
in stretch. This should support Bay Trail, but I don't have the
hardware to actually try this.
Please post the output of
xrandr --listproviders
glxi
Delete event->depend_events when it is no longer needed, to allow
the event objects it refers to to be freed.
This avoids out-of-memory hangs in large dependency trees
(e.g. long iterative calculations):
https://launchpad.net/bugs/1354086
Signed-off-by: Rebecca N. Palmer
---
*Possibly* a
Output a meaningful error message instead of just sel.has*Type.
In the case of double inputs (i.e. possibly literals), specify
how to make a literal single precision.
Signed-off-by: Rebecca N. Palmer
---
Previously submitted as
https://lists.freedesktop.org/archives/beignet/2017-September
LLVMContext::setDiagnosticHandler and LoopInfo::markAsRemoved
have been renamed.
Signed-off-by: Rebecca N. Palmer
--- a/backend/src/llvm/llvm_to_gen.cpp
+++ b/backend/src/llvm/llvm_to_gen.cpp
@@ -322,7 +322,11 @@ namespace gbe
DataLayout DL(&mod);
gbeDiagnosticContext dc;
LoopSimplifyID, LCSSAID and
some create*Pass have moved to
4.Define our DEBUG whether or not we just undefined LLVM's
(theirs is now LLVM_DEBUG, but we never actually use it)
Signed-off-by: Rebecca N. Palmer
--- a/CMake/FindLLVM.cmake
+++ b/CMake/FindLLVM.cmake
@@ -113,10 +113,10 @@ macro(add_on
When beignet added out-of-order execution support (7fd45f15),
it made *all* command queues out-of-order, even if they were
created as (and are reported by clGetCommandQueueInfo as) in-order.
Signed-off-by: Rebecca N. Palmer
---
Not sure whether this one is actually worth it: it's clearly
ag
A demonstration that "in-order" queues currently aren't:
//g++ -o queue_order_test queue_order_test.c -lOpenCL
//Depends: beignet-opencl-icd ocl-icd-opencl-dev
#include
#include
int main()
{
cl_int status;
cl_device_id device;
clGetDeviceIDs(NULL,CL_DEVICE_TYPE_ALL,1,&device,NULL);
char devi
clCreateCommandQueueWithProperties can already create them, but
that's a 2.0 function.
Signed-off-by: Rebecca N. Palmer
---
yes, this currently gives you out-of-order if you ask for in-order,
but says "can't do that" if you ask for out-of-order...
--- a/src/cl_api_comma
I plan to update Debian's beignet package soon, with some of the patches
I recently sent.
Is there anything else, e.g. from the master branch, that I should include?
In particular, these two look reasonable and build in 1.3, but I don't
have the hardware to check whether they are useful:
7e18
Some Intel-specific extensions (e.g. cl_intel_accelerator) are in
cl_ext.h in Beignet's included OpenCL headers, but in cl_ext_intel.h in
the upstream (Khronos) OpenCL headers:
https://github.com/KhronosGroup/OpenCL-Headers/tree/master/CL
What are your plans here? (This is an API change for us
Does your system need this patch to make Beignet work at all, or only to
get rid of the message? What hardware (lspci -nn | grep 0300) and what
version of Beignet?
That message is known to trigger on Wayland, but when I tested it,
Beignet still worked after it was shown. It has already been
ned-off-by: Rebecca N. Palmer
---
Looks like I introduced this (in 6e60548a) - sorry.
Examples at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913141
diff --git a/backend/src/llvm/llvm_unroll.cpp b/backend/src/llvm/llvm_unroll.cpp
index 813e116d..f378b63d 100644
--- a/backend/src/llvm/llvm_
See https://reproducible-builds.org for what this means.
Making beignet reproducible requires additional setup including Debian's
patched Clang (https://bugs.debian.org/877359), but building it with
this patch does not.
Signed-off-by: Rebecca N. Palmer
---
The first link is currently do
Signed-off-by: Rebecca N. Palmer
diff --git a/docs/Beignet.mdwn b/docs/Beignet.mdwn
index 75039d41..57308a7a 100644
--- a/docs/Beignet.mdwn
+++ b/docs/Beignet.mdwn
@@ -227,7 +227,7 @@ Known Issues
Project repository
--
Right now, we host our project on fdo at:
-[http
Signed-off-by: Rebecca N. Palmer
---
Is it a typo that Apollolake is described as 5th (rather than 6th)
generation? Should the reference to Broxten be removed, as the
hardware was reportedly cancelled?
The Neo supported list is taken from
https://github.com/intel/compute-runtime#supported
Dynamically linked LLVM crashes when two libraries using the same
LLVM version (e.g. Beignet and another OpenCL ICD) are dlopen()ed
in the same application, due to shared global state:
https://bugs.llvm.org/show_bug.cgi?id=30587
https://bugs.debian.org/852746
Signed-off-by: Rebecca N. Palmer
https://gitlab.freedesktop.org/beignet/beignet/issues/7
In Debian we're fully reverting 81755054
(https://sources.debian.org/src/beignet/1.3.2-4/debian/patches/885423.patch/),
but other comments suggest a smaller fix also works.
___
Beignet mailing
Passing -g through to LLVM fails the build, which violates the OpenCL
2.0 standard, and breaks at least clblas stable:
https://bugs.debian.org/881054
Signed-off-by: Rebecca N. Palmer
--- a/backend/src/backend/program.cpp
+++ b/backend/src/backend/program.cpp
@@ -985,6 +985,12 @@ EXTEND_QUOTE
Debian's beignet-opencl-icd package currently uses LLVM 7, and fails to
build with anything newer. This will no longer be an option when LLVM 7
is removed from Debian ( https://bugs.debian.org/947438 ).
Patches exist that allow beignet to build in LLVM 8 and 9, originally
from FreeBSD ( https
Progress so far:
compiler_rotate()ASSERTION FAILED: Unsupported intrinsics
The intrinsic in question is an fshl (funnel shift left). I suspect
this issue appeared because LLVM started optimizing rotates to this
intrinsic:
https://github.com/llvm/llvm-project/commit/654e6aabb9f25d0d0fbad19
Block rotate to fshl optimization, as we don't implement fshl.
Set reg for physical registers to avoid out-of-range index crash.
Signed-off-by: Rebecca N. Palmer
---
(where patches 1 and 2 are the LLVM 8/9 ones from
https://svnweb.freebsd.org/ports/head/lang/beignet/files/ ;
see also
Benson Muite wrote:
There are a number of people with older hardware. Is there enough of a
community to sustain this?
The Debian package has patches from 3 contributors since upstream
development stopped, but most of the commits are mine. This has been
enough to get us from LLVM 5 then to 9
This gets it to build, but *crashes when run* with
builtin_acos_float()clang (LLVM option parsing): for the --pgo-warn-misexpect
option: may only occur zero or one times!
This vaguely reminds me of multiple-LLVMs bugs like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768185 ,
but Debian beig
Ridley Combs suggests that adding the PCI IDs would be enough to support
Comet Lake:
https://github.com/intel/beignet/pull/20/files
https://bugs.launchpad.net/ubuntu/+source/beignet/+bug/1905340
but neither they nor I have the hardware to test this. Does anyone here?
__
The Beignet test suite contains two groups of files that do not appear
consistent with the project's LGPL license:
1. Derived from the Len(n)a standard test image:
kernels/lenna128x128.bmp kernels/compiler_box_blur_float_ref.bmp
kernels/compiler_box_blur_ref.bmp
This is not generally distribut
kernels/compiler_mandelbrot.cl kernels/compiler_mandelbrot_alternate.cl
kernels/compiler_mandelbrot_alternate_ref.bmp
kernels/compiler_mandelbrot_ref.bmp were included in my previous report
by mistake: they are not actually part of the Shadertoy set, so can be kept.
To keep the test suite runn
In current beignet (commit 4caba11ce88b3c1ec80ee119ceaf4bf778b96471):
-pow/pown ignore the sign of their first argument (e.g. pow(-2,3) gives
8 instead of -8)
-erf/erfc diverge (instead of converging to 1 or 0) for arguments above
about 2
-tgamma is actually lgamma, a related but very different fu
(Referring to
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=Fix-pow-erf-tgamma.patch;att=3;bug=768090
)
And it triggers some other bugs related to constant expression
handling when run all unit test cases.
I didn't see that when I ran the tests in 0.9.3 on IvyBridge M GT2 (only
And it triggers some other bugs related to constant expression
handling when run all unit test cases.
I didn't see that when I ran the tests in 0.9.3 on IvyBridge M GT2
(only builtin_pow and builtin_tgamma failed, both due to the
absolute error checking you've already fixed) but your patch says
t
https://bugs.launchpad.net/ubuntu/+source/pyopencl/+bug/1354086
It may help to wait for one run of the kernel to finish before starting
the next: for me, repeated pyopencl.enqueue_copy(cq0,bCL.data,aCL.data)
leaks memory (sometimes ending in a crash, sometimes a whole-system
hang) but repeated
The project website https://01.org/beignet is currently displaying
Access denied
You are not authorized to access this page.
where the main text of the page should be (the header and footer are
there, but not the sidebar). Other 01.org project pages work.
I'd like to package the 1.0 release, a
Now working, thanks.
___
Beignet mailing list
Beignet@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/beignet
...due to a stray . at utests/builtin_pow.cpp:79:112.
Also, the strict-conformance spec for pow and tgamma is 16ulp, not 1ulp.
___
Beignet mailing list
Beignet@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/beignet
Debian have a hybrid they call GNU/kFreeBSD (FreeBSD kernel but GNU C
library) that can be run in a chroot or jail under FreeBSD:
https://wiki.debian.org/Debian_GNU/kFreeBSD_FAQ#Q._Can_I_run_Debian_GNU.2FkFreeBSD_in_a_chroot_under_FreeBSD.3F
It includes beignet, but I don't know if anyone has t
In beignet 1.0.1 on i5-3230M Debian 8 (libdrm 2.4.58, kernel
3.16.7-ckt2-1 with the "whitelist OpenCL registers" patch), the recently
added runtime_alloc_host_ptr_buffer (CL_MEM_ALLOC_HOST_PTR) test often
fails when run as part of the whole set, but not when run by itself.
The backtrace points
Further investigation found that ret = drmIoctl(bufmgr_gem->fd,
DRM_IOCTL_I915_GEM_USERPTR, &userptr) (at libdrm
intel/intel_bufmgr_gem.c:895) was failing with EINVAL, but it's not
obvious what's invalid about the parameters.
vload_test_int()[SUCCESS]
vload_test_float()[SUCCESS]
runtim
The dmesg output from a failure is:
[ 427.521907] [drm:drm_ioctl] pid=776, dev=0xe200, auth=1,
I915_GEM_THROTTLE
[ 427.533899] [drm:drm_ioctl] pid=2340, dev=0xe200, auth=1,
I915_GEM_MADVISE
[ 427.533905] [drm:drm_ioctl] pid=2340, dev=0xe200, auth=1, I915_GEM_PWRITE
[ 427.533916] [drm:drm_i
1 - 100 of 147 matches
Mail list logo
