[Beignet] Copyright problems in test suite

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

Re: [Beignet] Copyright problems in test suite

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

[Beignet] pow(n), erf(c), tgamma give wrong results

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

Re: [Beignet] pow(n), erf(c), tgamma give wrong results

(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

Re: [Beignet] constant expression bug Re: pow(n), erf(c), tgamma give wrong results

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

Re: [Beignet] I met heavy memory leaks while using beignet library.

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

[Beignet] Fixed: Access denied error on https://01.org/beignet

Now working, thanks. ___ Beignet mailing list Beignet@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet

[Beignet] test suite unbuildable

...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

[Beignet] [PATCH] Return error, don't crash, on allocation failure

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.

Re: [Beignet] runtime_alloc_host_ptr_buffer intermittent failure

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]

Re: [Beignet] compiler_fill_image_1d_array intermittent failure

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

[Beignet] Patches from Debian

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):

[Beignet] Intermittent runtime_marker_list() test failure

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

Re: [Beignet] wrong CMAKE_LIBRARY_ARCHITECTURE on x86_64

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,

[Beignet] [PATCH] Don't crash if device inaccessible

If /dev/dri/cardX is inaccessible, return CL_DEVICE_NOT_FOUND, don't assert-fail. Signed-off-by: Rebecca Palmer rebecca_pal...@zoho.com 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 @@

[Beignet] [PATCH] Use matching versions of clang/llvm and libclang/libllvm

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 rebecca_pal...@zoho.com diff --git a/CMake/FindLLVM.cmake b/CMake/FindLLVM.cmake index

Re: [Beignet] [PATCH] Enable multiarch (32/64-bit co-installation)

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

[Beignet] [PATCH] Crash when hardware inaccessible

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,

[Beignet] [PATCH] Enable multiarch (32/64-bit co-installation)

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:

[Beignet] runtime_alloc_host_ptr_buffer intermittent failure

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

Re: [Beignet] [PATCH] utests: fix test case builtin_tgamma.

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

Re: [Beignet] Haswell issues

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

Re: [Beignet] Problems and questions when using Beignet

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

Re: [Beignet] Haswell issues

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

Re: [Beignet] [PATCH] utests: fix test case builtin_tgamma.

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

Re: [Beignet] [PATCH] Allow building with Python 3

-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

Re: [Beignet] iceweasel mangling patches

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.

[Beignet] Where's the test failure with clang 3.6?

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

[Beignet] [PATCH] Make __local on Haswell an error, instead of silently doing nothing

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 there

[Beignet] [PATCH 1/2] Add a sanity test in clGetDeviceIDs

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 do we

Re: [Beignet] [PATCH 1/2] Add a sanity test in clGetDeviceIDs + [PATCH 2/2] Docs: update/clarify Haswell issues

Sorry, both of those should have been Signed-off-by: Rebecca Palmer rebecca_pal...@zoho.com 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

[Beignet] Copyright problem in backend/src/ir/structural_analysis.*

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

Re: [Beignet] printf not working (or any thing for that matter)

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

[Beignet] [PATCH] Make tgamma meet the accuracy standard

The old tgamma=exp(lgamma) implementation had high rounding error on large outputs, exceeding the 16ulp specification for approx. x8 (hence the test failure in strict conformance mode). Replace this with an implementation based on glibc's

[Beignet] [PATCH] utest_pow: don't fail on declared lack of denormals

(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 rebecca_pal...@zoho.com diff --git

[Beignet] 9e8874c breaking (more) Haswell systems?

http://cgit.freedesktop.org/beignet/commit/?h=Release_v1.0id=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 reports

[Beignet] silently does nothing on large arrays (was ICD interface (only) broken on Haswell)

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?),

Re: [Beignet] ICD interface (only) broken on Haswell

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,

Re: [Beignet] Haswell-ULT Support?

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

Re: [Beignet] Unrecoverable system lockup when allocating too much memory

-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 https

Re: [Beignet] Icedove mangling patches

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

Re: [Beignet] Does LLVM 3.6 still hit a bug?

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 01, 2015 1:32 AM

[Beignet] [PATCH] Don't read past end of printf format string

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

Re: [Beignet] Fwd: [Bug 1277925] New: clinfo: Failed to release test userptr object! (9) i915 kernel driver may not be sane!

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

Re: [Beignet] Unrecoverable system lockup when allocating too much memory

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

Re: [Beignet] [PATCH v3] GBE: Don't read past end of printf format string

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

Re: [Beignet] Unrecoverable system lockup when allocating too much memory

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

Re: [Beignet] [PATCH v2] GBE: Don't read past end of printf format string

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

Re: [Beignet] Unrecoverable system lockup when allocating too much memory

(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

[Beignet] Does LLVM 3.6 still hit a bug?

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

Re: [Beignet] Still getting "Failed to release test userptr object! (9) i915 kernel driver may not be sane!"

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. ___

[Beignet] Pointer load/store - obsolete documentation?

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

[Beignet] [PATCH] Report build failures in backend to the build log

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

Re: [Beignet] cl_khr_fp64 on OpenCL 1.2+

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 ?

[Beignet] [PATCH] FindLLVM: allow LLVM/Clang 3.7

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)

Re: [Beignet] [PATCH] Report build failures in backend to the build log

otype 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) compi

Re: [Beignet] cl_get_gt_device(): error while running OPenCL on Kabylake

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

[Beignet] [PATCH] Clarify status of cl_khr_gl_sharing

Signed-off-by: Rebecca N. Palmer <rebecca_pal...@zoho.com> --- > -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 / clEnqueueRele

[Beignet] [PATCH] Make CL-GL sharing available via ICD

Signed-off-by: Rebecca N. Palmer <rebecca_pal...@zoho.com> --- (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" #includ

[Beignet] [PATCH] Fix typo

Signed-off-by: Rebecca N. Palmer <rebecca_pal...@zoho.com> --- 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, "

[Beignet] [PATCH] FindLLVM: Accept LLVM 3.9

Signed-off-by: Rebecca N. Palmer <rebecca_pal...@zoho.com> -- (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_INSTA

Re: [Beignet] Building beignet with OpenCL 2.0 support in distros

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’ve

Re: [Beignet] Building beignet with OpenCL 2.0 support in distros

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

Re: [Beignet] Building beignet with OpenCL 2.0 support in distros

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 : is

Re: [Beignet] Building beignet with OpenCL 2.0 support in distros

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 <rebecca_pal...@zoho.com> --- beignet-1.3

Re: [Beignet] [PATCH v2] Enable OpenCL 2.0 only where supported

> 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

Re: [Beignet] [PATCH v2] Enable OpenCL 2.0 only where supported

[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

Re: [Beignet] Building beignet with OpenCL 2.0 support in distros

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

Re: [Beignet] [PATCH V4] Enable OpenCL 2.0 only where supported

ime-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 <rebecca_pal...@zoho.com> ___ Beignet mailing list Beignet@lists.freedesktop.

[Beignet] [PATCH v2] Enable OpenCL 2.0 only where supported

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 <rebecca_pal...@zoho.com> --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -231,19 +231,8 @@ IF (EXPERIMENTAL_

[Beignet] apply 75cb7ca to 1.2 branch?

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

[Beignet] [PATCH RFC] Add AppStream metadata

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 <rebecca_pal...@zoho.com> --- Before this is pushed, needs to be filled in: AppStream

Re: [Beignet] [PATCH RFC] Add AppStream metadata

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 <rebecca_pal...@zoho.com> ___ Beignet mailing list Beignet@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/beignet

[Beignet] [PATCH] Utest: test pow, not powr, on negative x

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

[Beignet] Status of LLVM 3.9 support?

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.

[Beignet] [PATCH] Docs: Spelling and grammar fixes

Signed-off-by: Rebecca N. Palmer <rebecca_pal...@zoho.com> --- 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

[Beignet] [PATCH] Utests: use clGetExtensionFunctionAddressForPlatform

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

[Beignet] [PATCH] Utests: Don't end an all-tests run when one test fails

Signed-off-by: Rebecca N. Palmer <rebecca_pal...@zoho.com> --- 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_si

Re: [Beignet] [PATCH] Fix build with latest libdrm

+ 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

[Beignet] [PATCH] Utests: respect existing C/CXXFLAGS

This extends 4be3664 to the test suite. Signed-off-by: Rebecca N. Palmer <rebecca_pal...@zoho.com> --- 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/

[Beignet] [PATCH] Utests: Allow testing cl_intel_accelerator via ICD

Signed-off-by: Rebecca N. Palmer <rebecca_pal...@zoho.com> --- 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/

Re: [Beignet] few questions on Beignet-OpenCL-ICD v1.2.0 regarding X11 and kernel patches

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,

Re: [Beignet] Weird clinfo ouput @ FreeBSD-11.0/Intel GPU

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

Re: [Beignet] Weird clinfo ouput @ FreeBSD-11.0/Intel GPU

> 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

Re: [Beignet] Weird clinfo ouput @ FreeBSD-11.0/Intel GPU

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?? ___

Re: [Beignet] [PATCH v3] Utests: Allow testing cl_intel_accelerator via ICD

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

Re: [Beignet] [PATCH] Utests: Allow testing cl_intel_accelerator via ICD

> [ 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

Re: [Beignet] [PATCH] Add clGetKernelSubGroupInfoKHR to _cl_icd_dispatch table

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

Re: [Beignet] [PATCH] Add clGetKernelSubGroupInfoKHR to _cl_icd_dispatch table

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

Re: [Beignet] Weird clinfo ouput @ FreeBSD-11.0/Intel GPU

> 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

[Beignet] [PATCH] Fix build failure with CMRT enabled

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);

[Beignet] [PATCH] Fail, don't assert, if unable to create context

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 <rebecca_pal...@zoho.com> --- The user who reported a crash here ( https://bugs.debian.org/848792 ) was using unsupported hardware, but I do

[Beignet] [PATCH] Docs: Fix spelling and grammar

Signed-off-by: Rebecca N. Palmer <rebecca_pal...@zoho.com> --- 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 commonl

[Beignet] [PATCH] Docs: Fix broken link

Signed-off-by: Rebecca N. Palmer <rebecca_pal...@zoho.com> --- 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-

Re: [Beignet] issue with cl

T 2017 x86_64 GNU/Linux 2017-04-10 9:21 GMT+02:00 Rebecca N. Palmer <rebecca_pal...@zoho.com>: If you can, revert to the jessie (not -backports) kernel: that fixes this issue for me (on Ivybridge). ___ Beignet mailing list Beignet@lists.freedeskt

Re: [Beignet] [PATCH newRT] Add cl_gen_device_common.h file.

+#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

Re: [Beignet] issue with cl

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

Re: [Beignet] [PATCH newRT] Add cl_gen_device_common.h file.

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"

[Beignet] Status of cl_khr_gl_sharing

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

Re: [Beignet] Status of cl_khr_gl_sharing

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

  1   2   >