Re: [Beignet] beignet and LLVM 8+
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
Re: [Beignet] Status of cl_khr_gl_sharing
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 offsets into an internal structure. If that has changed, I'd be totally in favour of enabling it, because we're early in the buster cycle, so this is the time to get "new" features in. Simon signature.asc Description: OpenPGP digital signature ___ Beignet mailing list Beignet@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH] Backend: add double support to convert_uchar|char|short|ushort|int|uint|long|ulong_sat(double x) HW support Double to int16, int32 from IVB, others done by software. Double to in
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 Description: OpenPGP digital signature ___ Beignet mailing list Beignet@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH] Only provide device IDs if the type matches
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, we should just return CL_INVALID_DEVICE_TYPE.
If the device type does not match, CL_DEVICE_NOT_FOUND is correct. The
description of clGetDeviceIDs[1] says
CL_DEVICE_NOT_FOUND if no OpenCL devices that matched device_type were
found.
The function should return CL_INVALID_DEVICE_TYPE if a bit is set that is
not defined in the version of the spec that is implemented, so
if(device_type &
~(CL_DEVICE_TYPE_DEFAULT|CL_DEVICE_TYPE_CPU|CL_DEVICE_TYPE_GPU|CL_DEVICE_TYPE_ACCELERATOR|CL_DEVICE_TYPE_CUSTOM))
{
return CL_INVALID_DEVICE_TYPE;
}
at the beginning of the function is needed. Otherwise this patch is
correct, but suboptimal as we don't need to search for a device if we're
going to throw away the result anyway.
Simon
[1]
https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/clGetDeviceIDs.html
>
> I will send a patch to fix this problem.
>
> Thanks
> Xiuli
> -Original Message-
> From: Beignet [mailto:beignet-boun...@lists.freedesktop.org] On Behalf Of
> Giuseppe Bilotta
> Sent: Friday, February 10, 2017 6:46 AM
> To: Beignet ML
> Cc: Giuseppe Bilotta
> Subject: [Beignet] [PATCH] Only provide device IDs if the type matches
>
> If the user is asking for (say) CPU devices only, we should not return a GPU
> device instead. This fixes a regression introduced with the refactoring done
> in 494081299ac3f6970b906cb4d7d1eb1fc2fb23c8, by reinstating the check that
> used to be in cl_check_device_type() (except that instead of hard-coding
> CL_DEVICE_TYPE_GPU we use the device type reported by the device).
>
> Signed-off-by: Giuseppe Bilotta
> ---
> src/cl_device_id.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/cl_device_id.c b/src/cl_device_id.c index b2810635..b8184486
> 100644
> --- a/src/cl_device_id.c
> +++ b/src/cl_device_id.c
> @@ -880,8 +880,14 @@ cl_get_device_ids(cl_platform_idplatform,
>
>openlog("beignet", LOG_CONS, LOG_USER);
>
> - /* Do we have a usable device? */
>device = cl_get_gt_device();
> +
> + /* Is the device of the correct type? */ if (device &&
> + ((device->device_type | CL_DEVICE_TYPE_DEFAULT) & device_type) == 0)
> +device = 0;
> +
> + /* Do we have a usable device? */
>if (device) {
> cl_self_test_res ret = cl_self_test(device, SELF_TEST_PASS);
> if (ret == SELF_TEST_ATOMIC_FAIL) {
> --
> 2.11.1.658.g6a0cb3eb68
>
> ___
> Beignet mailing list
> Beignet@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/beignet
> ___
> Beignet mailing list
> Beignet@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/beignet
___
Beignet mailing list
Beignet@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH] FindLLVM: Accept LLVM 3.9
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 llvm-config-37 llvm-config-3.7 llvm-config-36 > llvm-config-3.6 llvm-config-38 llvm-config-3.8 llvm-config-39 llvm-config-3.9 > llvm-config llvm-config-35 llvm-config-3.5 llvm-config-34 llvm-config-3.4 Does LLVM 3.4 still work? Simon ___ Beignet mailing list Beignet@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] Proposed patch: add CMake option for toggling OCL ICD Loader compatibility
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 disabled. From a distro point of view, having a way to force failure if a dependency is missing would also be great -- because otherwise behaviour still depends on the build machine. Would it make sense to require the ICD loader header, and ask users to explicitly disable ICD support if they do not want to provide it? Simon signature.asc Description: OpenPGP digital signature ___ Beignet mailing list Beignet@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH] Refine mem.h and improve the related macro defination.
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 &&
> \
> + ((cl_base_object)mem)->magic ==
> CL_OBJECT_MEM_MAGIC && \
> + CL_OBJECT_GET_REF(mem) >= 1 &&
> \
> + ((cl_mem)mem)->type <=
> CL_MEM_SUBBUFFER_TYPE))
Exactly my point. A pipe object would not match CL_OBJECT_IS_BUFFER(),
so the negated test would return true, and the code would look at
memobj->host_ptr in a pipe object, which is wrong.
Simon
signature.asc
Description: OpenPGP digital signature
___
Beignet mailing list
Beignet@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH] Refine mem.h and improve the related macro defination.
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 (!CL_OBJECT_IS_BUFFER(memobj)) {
>ptr = (size_t)memobj->host_ptr;
> } else {
That would match pipes as well, is that intended?
Simon
signature.asc
Description: OpenPGP digital signature
___
Beignet mailing list
Beignet@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH] Runtime: Use cl_ulong as CL_DEVICE_MAX_MEM_ALLOC_SIZE's return type.
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); > param_value_size is 8, if beignet's device->max_alloc_size is size_t, > sizeof(device->max_alloc_size) is 4 in i386 systems. Yes, but this has been fixed now. > Because max_alloc_size hasn't been initialized, is garbage, and > memcpy(param_value, >FIELD, sizeof device->FIELD); > only copy the low 4 bytes, the high 4 bytes is still garbage. > For example max_alloc_size is 0xdeaddeaddeaddead before call clGetDeviceInfo, > and device-> max_alloc_size is 0x4000, > After clGetDeviceInfo, max_alloc_size's value is 0xdeaddead4000. Right, but the returned size value is 4, so the program should know that there was a communication error, and bail out anyway, because if Beignet doesn't return sizeof(cl_ulong) there, then obviously it hasn't stored a cl_ulong, so the result cannot be interpreted that way. If a program doesn't do that check, it is broken. I cannot expect __uint128_t max_alloc_size; clGetDeviceInfo(device, CL_DEVICE_MAX_MEM_ALLOC_SIZE, sizeof(max_alloc_size), _alloc_size, NULL); to work either. People need to write this out completely, as __uint128_t max_alloc_size; cl_uint max_alloc_size_size; int error = clGetDeviceInfo(device, CL_DEVICE_MAX_MEM_ALLOC_SIZE, sizeof max_alloc_size, _alloc_size, _alloc_size_size); if(error != CL_SUCCESS) goto error; if(max_alloc_size_size != sizeof max_alloc_size) goto error; and if they don't, I want valgrind to say "btw, they are using a value with uninitialized bits here." > So add memset(param_value, 0, param_value_size) to clear param_value, the > param_value's size is param_value_size, I think it is safe. Safe, yes, because the spec doesn't say what should happen to the rest of the buffer (so overwriting with zeros is fine), but also unnecessary. Simon ___ Beignet mailing list Beignet@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH] Runtime: Use cl_ulong as CL_DEVICE_MAX_MEM_ALLOC_SIZE's return type.
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, > } \ > if (param_value_size < sizeof device->FIELD)\ >return CL_INVALID_VALUE; \ > +memset(param_value, 0, param_value_size); \ > memcpy(param_value, >FIELD, sizeof device->FIELD); \ > return CL_SUCCESS; > I don't see the point -- programs are not supposed to behave differently here, and it might hide errors when running under valgrind. I don't have any strong feelings on this though. The rest of the patch looks good to me. Simon ___ Beignet mailing list Beignet@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH] Runtime: Add CL base object for all cl objects.
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 that mean that only a single call to DEFINE_ICD() and SET_ICD() remains? If so, can/should these be inlined? Simon signature.asc Description: OpenPGP digital signature ___ Beignet mailing list Beignet@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] Error during build on Linux Mint 17 -- segmentation fault
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 Description: OpenPGP digital signature ___ Beignet mailing list Beignet@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] Libdir
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 problem of distribution maintainers, rather than something packages should do on their own. Another unsolved issue is concurrent installation of 32 and 64 bit libraries as OpenCL ICDs. Simon signature.asc Description: OpenPGP digital signature ___ Beignet mailing list Beignet@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH] build: use auto libdir
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 maintainers. Not sure about technical correctness, I'm not a cmake expert. Simon signature.asc Description: OpenPGP digital signature ___ Beignet mailing list Beignet@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet
[Beignet] Beignet vs LuxRays, again
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 OpenCL implementation was significantly faster on the same machine, an i7-3612QM) I think there may be something wrong with the buffer management here, if the on-screen buffer and off-screen textures owned by different apps can be overwritten by OpenCL code. Simon ___ Beignet mailing list Beignet@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] Backend visible to other apps?
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 enabled (for that, you need ICD development headers), and a file in /etc/OpenCL/vendors needs to point at the library (simply use the full path as the file contents). If you use Debian, the packages handle this. Simon ___ Beignet mailing list Beignet@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet
[Beignet] Debian will freeze soon(tm)
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 do another upload before that. - EGL support would be dropped (current state is dependent on a Mesa source tree, which I cannot easily provide during automated builds) - ICD support will be included, and the package built against the current 1.2 headers. - Right now, we do not support non-inline functions, which stops most of the existing apps from working. - Nonetheless, we appear to be the only completely free OpenCL implementation in town, so Beignet resolves lots of licencing issues with OpenCL software. Any opinions on what would be the best possible state of Beignet to put into the stable release? Simon signature.asc Description: OpenPGP digital signature ___ Beignet mailing list Beignet@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH V2 2/4] Add the internal used kernels for buffer copy
-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
KERNEL_STR_FILES ${output_file}) + add_custom_command( +OUTPUT
${output_file} +COMMAND rm -rf ${output_file} +COMMAND
${CMAKE_CURRENT_BINARY_DIR}/../backend/src/gbe_bin_generater -s
${input_file} -o${output_file} +MAIN_DEPENDENCY ${input_file})
+endforeach (KF) +endmacro (MakeKernelBinStr)
This fails to compile from clean tree with -j, because there is no
dependency ordering:
/bin/sh: 1: ../backend/src/gbe_bin_generater: not found
Simon
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iJwEAQECAAYFAlJVIVgACgkQ0sfeulffv7tEkAQAlLisoaKm8oMnkluxxVg8lXhM
JKPOgpE3DQzylIY8QfEUErcpTwTvDXfAwXSLCjDeIHnp5wtd3+VQ9sT+KD+NWefa
oAjp/y5Phjp37qLON/bB6iMx6ZnIVPtz6IlpUD3RdMUwC3ghefRku5VM//FtPERT
1HS+4qto+nbaLkyFj+c=
=4uO4
-END PGP SIGNATURE-
___
Beignet mailing list
Beignet@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/beignet
[Beignet] Piglit results
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 http://lists.freedesktop.org/mailman/listinfo/beignet
[Beignet] Failure to compile more complex kernels
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 pass 'Function Pass Manager' on module '/tmp/filel4ExUA.ll'.
1. Running pass 'Unnamed pass: implement Pass::getPassName()' on
function '@Intersect'
The call instruction in question appears to be the call to
QBVHNode_BBoxIntersect in line 259 of the attached CL source.
Any idea why Beignet is expecting the function to be an intrinsic here?
Simon
#line 2 qbvh_kernel.cl
/***
* Copyright (C) 1998-2013 by authors (see AUTHORS.txt) *
* *
* This file is part of LuxRays. *
* *
* LuxRays is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation; either version 3 of the License, or *
* (at your option) any later version. *
* *
* LuxRays is distributed in the hope that it will be useful,*
* but WITHOUT ANY WARRANTY; without even the implied warranty of*
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
* GNU General Public License for more details. *
* *
* You should have received a copy of the GNU General Public License *
* along with this program. If not, see http://www.gnu.org/licenses/. *
* *
* LuxRays website: http://www.luxrender.net *
***/
typedef struct QuadRay {
float4 ox, oy, oz;
float4 dx, dy, dz;
float4 mint, maxt;
} QuadRay;
typedef struct {
float4 origx, origy, origz;
float4 edge1x, edge1y, edge1z;
float4 edge2x, edge2y, edge2z;
uint4 meshIndex, triangleIndex;
} QuadTiangle;
typedef struct {
float4 bboxes[2][3];
int4 children;
} QBVHNode;
#define emptyLeafNode 0x
#define QBVHNode_IsLeaf(index) (index 0)
#define QBVHNode_IsEmpty(index) (index == emptyLeafNode)
#define QBVHNode_NbQuadPrimitives(index) ((uint)(((index 27) 0xf) + 1))
#define QBVHNode_FirstQuadIndex(index) (index 0x07ff)
// Using invDir0/invDir1/invDir2 instead of an
// array because I dont' trust OpenCL compiler =)
int4 QBVHNode_BBoxIntersect(
const float4 bboxes_minX, const float4 bboxes_maxX,
const float4 bboxes_minY, const float4 bboxes_maxY,
const float4 bboxes_minZ, const float4 bboxes_maxZ,
const QuadRay *ray4,
const float4 invDir0, const float4 invDir1, const float4
invDir2) {
float4 tMin = ray4-mint;
float4 tMax = ray4-maxt;
// X coordinate
tMin = fmax(tMin, (bboxes_minX - ray4-ox) * invDir0);
tMax = fmin(tMax, (bboxes_maxX - ray4-ox) * invDir0);
// Y coordinate
tMin = fmax(tMin, (bboxes_minY - ray4-oy) * invDir1);
tMax = fmin(tMax, (bboxes_maxY - ray4-oy) * invDir1);
// Z coordinate
tMin = fmax(tMin, (bboxes_minZ - ray4-oz) * invDir2);
tMax = fmin(tMax, (bboxes_maxZ - ray4-oz) * invDir2);
// Return the visit flags
return (tMax = tMin);
}
void QuadTriangle_Intersect(
const float4 origx, const float4 origy, const float4 origz,
const float4 edge1x, const float4 edge1y, const float4 edge1z,
const float4 edge2x, const float4 edge2y, const float4 edge2z,
const uint4 meshIndex, const uint4 triangleIndex,
QuadRay *ray4, RayHit *rayHit) {
//--
// Calc. b1 coordinate
const float4 s1x = (ray4-dy * edge2z) - (ray4-dz * edge2y);
const float4 s1y = (ray4-dz * edge2x) - (ray4-dx * edge2z);
const float4 s1z = (ray4-dx * edge2y) - (ray4-dy * edge2x);
const float4 divisor = (s1x * edge1x) + (s1y * edge1y) + (s1z * edge1z);
const float4 dx = ray4-ox - origx;
const float4 dy = ray4-oy - origy;
const float4 dz = ray4-oz - origz;
const float4 b1 = ((dx * s1x) + (dy * s1y) + (dz * s1z)) / divisor;
//--
// Calc. b2 coordinate
const float4 s2x = (dy * edge1z) - (dz * edge1y);
const
[Beignet] Bug#724808: ocl-icd-libopencl1: Handle invalid object references
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 scripture to support this, but it might be a good idea nonetheless (i.e. clGetKernelInfo returns CL_INVALID_KERNEL if given a NULL pointer, etc.). Higher than wishlist as it makes running the compliance test suite show false negatives. Simon -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ocl-icd-libopencl1 depends on: ii libc6 2.17-93 ii multiarch-support 2.13-38 ocl-icd-libopencl1 recommends no packages. Versions of packages ocl-icd-libopencl1 suggests: ii amd-opencl-icd [opencl-icd] 1:12-6+point-3 ii beignet [opencl-icd]0.2+git20130928+187c17e-1 ii nvidia-opencl-icd [opencl-icd] 304.88-1+deb7u1 -- no debconf information ___ Beignet mailing list Beignet@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet
Re: [Beignet] [PATCH 2/3] add clCreateBufferFromLibva() api
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 resolver function clGetExtensionFunctionAddress (also in cl_api.c), so the extension function is available when going through the ICD loader (which is also the reason for the Intel suffix -- so the loader knows which resolver to call). Simon ___ Beignet mailing list Beignet@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet
