Hi,
On Tue, Jan 14, 2020 at 07:45:57AM +0100, Jérôme Kieffer wrote:
> By the way, Thanks Rebecca for you work on the driver.
+1.
Simon
___
Beignet mailing list
Beignet@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/beignet
Hi,
On 01.08.2017 23:39, Rebecca N. Palmer wrote:
> As beignet's Debian maintainer, I am considering whether to enable CL-GL
> sharing in our package, given its incomplete state.
I haven't looked at it since the initial package, because back then it
required the Mesa source code in order to get
Hi,
On 08.03.2017 06:27, rander wrote:
> backend/src/libocl/script/ocl_convert.sh | 10 +-
I think you also need conversion from double to other types.
Also (somewhat unrelated): are there no-op conversions for same source
and destination type?
Simon
signature.asc
Hi,
On Fri, Feb 10, 2017 at 06:36:35AM +, Pan, Xiuli wrote:
> You point about the device type is right, but the git commit you found is
> not right the function is just copy form somewhere else. And the this
> patch is not follow the OpenCL spec. As the Beignet does not have a CPU
> device,
Hi,
On Sun, Jan 22, 2017 at 05:07:07PM +, Rebecca N. Palmer wrote:
> - NAMES llvm-config-37 llvm-config-3.7 llvm-config-36
> llvm-config-3.6 llvm-config-38 llvm-config-3.8 llvm-config llvm-config-35
> llvm-config-3.5 llvm-config-34 llvm-config-3.4
> + NAMES
Hi,
On 01.12.2016 13:24, Marek Szuba wrote:
> As suggested in https://bugs.freedesktop.org/show_bug.cgi?id=98885 ,
> here is a Git-friendly patch which makes CMake looking for OCL ICD
> header files depend on a new configuration option, so that the loader
> compatibility mode can be explicitly
Hi,
On 20.12.2016 04:23, He Junyan wrote:
>>> +if (!CL_OBJECT_IS_BUFFER(memobj)) {
>> That would match pipes as well, is that intended?
> Already redefine CL_OBJECT_IS_BUFFER to just match buffer and subbuffer.
> +#define CL_OBJECT_IS_BUFFER(mem) ((mem &&
Hi,
On 19.12.2016 10:21, junyan...@inbox.com wrote:
> --- a/src/cl_api_mem.c
> +++ b/src/cl_api_mem.c
> @@ -71,54 +71,54 @@ clGetMemObjectInfo(cl_mem memobj,
> break;
>case CL_MEM_HOST_PTR: {
> ptr = 0;
> -if (memobj->type == CL_MEM_IMAGE_TYPE) {
> +if
Hi,
On Fri, Dec 09, 2016 at 06:49:56AM +, Yang, Rong R wrote:
> The change is for the case that param_value_size > sizeof(device->FIELD).
> For example:
> cl_ulong max_alloc_size;
> clGetDeviceInfo(device, CL_DEVICE_MAX_MEM_ALLOC_SIZE,
> sizeof(max_alloc_size), _alloc_size, NULL);
>
Hi,
On Thu, Dec 08, 2016 at 03:47:28PM +0800, Yang Rong wrote:
> diff --git a/src/cl_device_id.c b/src/cl_device_id.c
> index 24334fd..71a7be1 100644
> --- a/src/cl_device_id.c
> +++ b/src/cl_device_id.c
> @@ -926,6 +926,7 @@ cl_get_device_ids(cl_platform_idplatform,
> }
Hi,
On 14.07.2016 10:15, junyan...@inbox.com wrote:
> The runtime code is a little verbose in CL object handle.
> Every CL objects should have a reference, a lock to protect itself
> and an ICD dispatcher. We can organize them to a struct and place
> it at the beginning of each CL object.
Does
Hi,
On 30.11.2014 19:34, al acran wrote:
I'm using llvm version 3.4 and clang 3.5. Can anyone help me?
Generally, these have tighter coupling than expected. Using two
different versions has led to problems for me quite often.
Can you try to use 3.5 of each?
Simon
signature.asc
Hi,
I'm not sure, but why we installing libs to prefix/lib but not libdir?
I.e. on x86_64 I have installed beignet in /usr/lib, but not in /usr/lib64.
/usr/lib64 is dead and should never be used.
In principle, it would be good to install to /usr/lib/x86_64-linux-gnu,
but that is actually the
Hi,
On 14.01.2014 18:51, Igor Gnatenko wrote:
From 4a47aac87719b0b56565cd257cac0868ae574cd4 Mon Sep 17 00:00:00 2001
From: Igor Gnatenko i.gnatenko.br...@gmail.com
Date: Tue, 14 Jan 2014 21:22:42 +0400
Subject: [PATCH] build: use auto libdir
That looks immensely useful for distribution
Hi,
I've just rendered the first picture using LuxRays and Beignet.
Observations:
- During rendering, colored dots appeared all over the display at
random locations
- In the final result, there are black pixels
- Fonts in some applications appear garbled
- Rendering was slow (AMD's CPU-based
Hi Ian,
On 14.10.2013 20:22, Ian Daniher wrote:
I'm pretty sure I need to add something to /etc/OpenCL/vendors to make
beignet's presence known, but this doesn't seem to be done automatically
and documentation is spotty.
You need two things: the library needs to be built with ICD support
Hi,
I just got the announcement that Debian is going to freeze the next
release soon.
Presently, Beignet 0.2 with ICD support and EGL enabled is in the branch
being frozen (the more recent stuff is on the separate experimental
branch). Since that is a rather old state, I wonder whether I should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 09.10.2013 09:55, junyan...@inbox.com wrote:
+macro (MakeKernelBinStr KERNEL_PATH KERNEL_FILES) +foreach (KF
${KERNEL_FILES}) + set (input_file ${KERNEL_PATH}/${KF}.cl) + set
(output_file ${KERNEL_PATH}/${KF}_str.c) + list (APPEND
Hi,
I've run the testsuite against the current Debian packages on a Core
i7/IvyBridge2 system, results are at http://psi5.com/~geier/beignet/
Simon
___
Beignet mailing list
Beignet@lists.freedesktop.org
Hi,
With luxrays, I still keep running into
ASSERTION FAILED: it != instrinsicMap.map.end()
at file
/home/geier/debian/beignet-0.2+git20130928+187c17e/backend/src/llvm/llvm_scalarize.cpp,
function bool gbe::Scalarize::scalarizeFuncCall(llvm::CallInst*), line 635
Stack dump:
0. Running
Package: ocl-icd-libopencl1
Version: 1.3-3+debug
Severity: minor
Running the Piglit test suite reports several errors where NULL pointers
are dereferenced in libOpenCL.so. Apparently, OpenCL implementations are
expected to recognize NULL pointers as invalid object references.
I could not find
Hi,
This patch and the following patch is to introduce new API to cl lib.
It's better to put it into include/CL/cl_intel.h, and the naming rule
is to follow other non-standard API : clMapBufferIntel(cl_mem, cl_int*);
clXXXIntel.
In addition, extension functions need to be listed in the
22 matches
Mail list logo
