FW: Release Notes for Beignet Version 0.1

FW: Release Notes for Beignet Version 0.1

[Zou, Nanhai]

[-- Attachment #1.1: Type: text/plain, Size: 9695 bytes --]

Hi,
         We have just released the open source Linux OpenCL project Beignet Version 0.1.

If you are interested in this project. Please try it and provide feedback to us.
We welcome developers to  join this project.

Thanks
Zou Nanhai

From: Zhigang Gong [mailto:zhigang.gong@linux.intel.com]
Sent: Monday, April 15, 2013 4:53 PM
To: beignet@lists.freedesktop.org
Cc: Zou, Nanhai; Fu, Michael; Keith Packard
Subject: Release Notes for Beignet Version 0.1

Beignet (Intel OpenCL Open Source Project) Version 0.1
Release Notes:

We are pleased to release the Beignet version 0.1.

Beignet is a project that provides OpenCL support for Intel platforms.
It includes an LLVM/Clang based OpenCL compiler and a runtime.
This version supports GPU type context on IVY Bridge(IVB) platform only.

New features in this release:

1. 2D image write(typed_write)/read(sampler).
2. Partial support of cl_khr_gl_sharing extension.
3. Cmake build fixup.
4. Add/Enable some OpenCL 1.0 APIs and built-in functions.
5. Various bug fixing.
6. More unit test cases.

For more detailed information, please check the source
code and read the documents.

git web address: http://cgit.freedesktop.org/beignet/
git address: git://anongit.freedesktop.org/beignet
bugzilla address: coming soon
mail list: http://lists.freedesktop.org/mailman/listinfo/beignet

This project was initiated by Ben Segovia, maintained by Intel Linux OpenCL Team.

Contact:
Zhigang.gong@intel.com<mailto:Zhigang.gong@intel.com>
Nanhai.zou@intel.com<mailto:Nanhai.zou@intel.com>

----------------------------------------------------------------
The following changes since commit daeaf821b8101694abd69906a58b8dde60f5abf1:

  Updated comment on lost copy since it is supported now (2012-11-16 18:10:07 -0800)

----------------------------------------------------------------
Feng, Boqun (4):
      Change to Clang/LLVM ToT(Top of the Tree)
      backend: Add LLVM stable version support
      backend: Remove argID in function arguments iteration
      backend: Use alignof keyword when supported

Homer Hsing (63):
      Fix up README.md
      test creating program objects, build program executable, build options, query program objects
      Add test case, OpenCL 1.1 Math Built-in Functions
      Test case for OpenCL 1.1 supported data types
      Test case for OpenCL 1.1 workitem builtin functions
      Test case for OpenCL 1.1 math constants
      Test case for OpenCL 1.1 Preprocessor Directives & Macros
      Test case for OpenCL 1.1 structure attributes
      Test case for OpenCL 1.1 integer built-in functions
      Test case for OpenCL 1.1 address space qualifier
      test case for OpenCL 1.1 conversion & type casting
      test case for OpenCL 1.1 function qualifiers
      Test case for OpenCL 1.1 Atomic Functions
      Test case for OpenCL 1.1 Sampler Objects
      test OpenCL 1.1 sampler declaration fields
      test OpenCL 1.1 Synchronization, explicit memory fence
      Enable build-in vector data types test in kernels/compiler_data_types.cl
      test OpenCL 1.1 Relational Built-in Functions
      Test OpenCL 1.1 Geometric Builtin Functions
      test OpenCL 1.1 Async Copies and Prefetch Functions
      test OpenCL 1.1 Vector Data Load/Store Functions
      support OpenCL 1.1 built-in scalar data types, built-in vector data types
      add test case for bool const, and vector component addressing
      support some OpenCL 1.1 preprocessor directives & macros
      support OpenCL 1.1 floating-point macros
      a more general typedef for size_t and ptrdiff_t
      support OpenCL 1.1 other built-in data types
      add OpenCL 1.1 preprocessor macros ENDIAN_LITTLE
      pass build-options of clBuildProgram to clang compiler
      support OpenCL 1.1 __kernel_exec preprocessor macro
      test case for __kernel_exec
      support OpenCL 1.1 kernel_exec preprocessor macro
      support some of OpenCL 1.1 relational built-in functions
      add missing #define in ocl_stdlib.h: INLINE_OVERLOADABLE and OVERLOADABLE
      support some OpenCL 1.1 relational built-in functions
      support OpenCL 1.1 relational builtin function "signbit"
      support OpenCL 1.1 relational builtin functions "all","any"
      support vector data load/store for char,short,long
      Fix extended math function selection logic for int div.
      Implement clEnqueueWriteBuffer
      implement blocking mode of clEnqueueMapBuffer
      implement blocking mode of clEnqueueUnmapMemObject
      support OpenCL 1.1 integer built-in macros
      more test case for OpenCL 1.1 integer built-in macros
      more test case for vector load/store function
      define macro CLK_{LOCAL,GLOBAL}_MEM_FENCE in ocl_stdlib.h
      support OpenCL conversions & type casting function "convert_type_4"
      support OpenCL conversions & type casting function "as_uchar4(float f)"
      Make integer remainder & division arithmetic work ~ ~
      Add a test case for integer remainder arithmetic
      Test case for integer division arithmetic ~
      Test case for fabs
      fix disassembler: horizontal stride of dest operand
      Add convert_uchar_sat and test case
      Make "logical shift right" work
      Also make "arithmetic shift right" work
      Display function argument name in IR
      Output meaning of special registers in dumped IR
      Delete temp files if compiled successfully
      Output the map from IR reg to ASM reg
      fix unused-result warning
      Add the interface of cl_buffer_map_gtt
      Fix brw instruction field "flag"

Lu Guanqun (34):
      output file name and kernel name when cl_kernel_init() fails
      fix assertion when two kernels exist in cl file
      update headers to OpenCL 1.2 standards
      fix compilation errors when it can't find correct library dirs
      install header files
      cleanup .gitignore files
      add check for memory allocation size
      fix the sign-compare warning
      remove all Makefiles
      add TupleDstPolicy for instructions
      use TupleDstPolicy for SampleInstruction and TypeWriteInstruction
      keep track of saturate flag in GenInstructionState
      add add_sat operation
      add add_sat test case
      fix two unused variables
      add sub_sat operation
      add anonymous namespace to avoid name collision with the next patch
      add sub_sat test case
      fix the wrong zero extend instruction handling
      fix the possible overflow in slm_sz
      add linking library for gcc compiler.
      add a case for MEM_INVALID to fix a warning
      do not use the advanced C++ feature
      fix typo in FindLLVM.cmake
      fix one typo for clCreateContextFromType()
      implement clCreateContextFromType()
      add test case for clCreateContextFromType()
      enhance clGetPlatformInfo() API to return the string length
      change the way clGetPlatformInfo() is called in cl_ocl_init()
      enhance clGetDeviceInfo() API to return the length of string fields
      change the way clGetDeviceInfo() is called in cl_ocl_init()
      add disassembler support for message gateway
      release the contraint of volatile pointer
      throw exception instead of just assert

Lv, Meng (1):
      enable CL_DEVICE_IMAGE_SUPPORT check

Xing, Homer (1):
      Ignore OpenCL kernel copied from Intel OpenCL SDK

Zhigang Gong (45):
      Fixed a potential Null pointer reference in emitMovForPHI.
      Only llvm3.0 and 3.1 have TargetData.h.
      Remove glext.h.
      First implementation for extension cl_khr_gl_sharing.
      new test case from Nanhai.
      Fixed compilation warnings.
      CMake fixup.
      Don't use display :0.0 manually.
      Refine CMake to check llvm version.
      Keep consistent naming rule for LLVM_XXX Cmake variables.
      Find GBM/EGL library at build time.
      Implement OCL extension initizliation.
     Import gbm internal header files.
      Added a new common header file for both kernel and host.
      Add one function generate ARF register.
      Insert ocl_common_defines to the cl source file.
      Finish the incomplete 2d image support in runtime library.
      Implement sampler support.
      Implement SAMPLE instruction.
      Added missed macros/structs for typed write message.
      Implement TYPED_WRITE instruction.
      implement OCL 1.2 new APIs.
      Fix the assertion condition check.
      Don't always set build type to DEBUGO0.
      utest: Added some new helper macros for image2d test cases.
      utest: Added one image2d test case copy_image.
      utest: Added one test case to fill a image2d.
      Fixed TYPED_WRITE instruction bug for SRC register allocation.
      utest: Added one test case for the int4 constant vector.
      Implement cl_khr_gl_sharing by using upstream technology.
      Fixed a bug in write_imagef.
      Split the multiple test cases to individual cases.
      Fixed a bug on 64bit system.
      Add utest case for movforphi's undef case.
      Fixed a bug when expire registers.
      Use new OCL1.2 API rather than those deprecated API.
      Change the cl version to 1.0.
      Set the initial library versions to 0.1.
      Fixed a potential null pointer reference bug.
      Update documents.
      Enable the clFlush.
      Fixed the extension string for both platform and device.
      utests: added cl_khr_gl_sharing related helper functions.
      utests: add a simple test case for cl_khr_gl_sharing.
      utests: refine the helper macros.

Zou, Nanhai (1):
      Fix uninitialize value warning


[-- Attachment #1.2: Type: text/html, Size: 53192 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FW: Release Notes for Beignet Version 0.1

[Dave Airlie]

Why does this exist anymore?

Seriously this project is duplicating functionality we already have
implemented in Mesa/Gallium projects. Its also duplicating code in the
Mesa Intel driver I assume.

So why not just write a gallium ivybridge compute only driver? that
uses the current open source infrastructure.

If Intel are insisting on Beignet, I'd rather it was removed from
freedesktop.org and maybe moved to 01.org so people understand its an
Intel only development project.

Dave.

Re: FW: Release Notes for Beignet Version 0.1

[Zou, Nanhai]

Hi Dave,

	It is not really true to say that the code is duplicated.

	Beignet maps OpenCL into GPGPU pipeline of IvyBridge+ hardware.
	So this is real GPGPU other than mimic GPGPU with 3D functions.

	GPGPU different with 3D pipeline a lot on IvyBridge+.
	Both the pipeline setting and run time are totally different than that in 3D driver.
	The GPU thread spawn model, thread communication model, memory model are also totally different.

	Also the binary representation is different.
	Ben choose LLVM scalar IR for many reasons(you can find the 
	decision make reason in the document), that means IR backend are different.

	For GPGPU programming, I don't see a lot benefit to introduce state tracker. 
	There is not so many states to track.

	The project is already a functional OpenCL implementation on IvyBridge at this point. 
	
	1. Most of the language features are supported.
	2. Most of built-in functions are supported.
	3. Global, Local memory, thread barriers are supported.
	3. OpenGL to OpenCL texture sharing are supported.
	
	We have already implement something like CSS filters with this driver, 
	and we see performance gain than OpenGL filters.

Thanks
Zou Nanhai




-----Original Message-----
From: Dave Airlie [mailto:airlied@gmail.com] 
Sent: Tuesday, April 16, 2013 4:58 AM
To: Zou, Nanhai
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] FW: Release Notes for Beignet Version 0.1

Why does this exist anymore?

Seriously this project is duplicating functionality we already have implemented in Mesa/Gallium projects. Its also duplicating code in the Mesa Intel driver I assume.

So why not just write a gallium ivybridge compute only driver? that uses the current open source infrastructure.

If Intel are insisting on Beignet, I'd rather it was removed from freedesktop.org and maybe moved to 01.org so people understand its an Intel only development project.

Dave.

Re: FW: Release Notes for Beignet Version 0.1

[Dave Airlie]

>         It is not really true to say that the code is duplicated.
>
>         Beignet maps OpenCL into GPGPU pipeline of IvyBridge+ hardware.
>         So this is real GPGPU other than mimic GPGPU with 3D functions.

Nobody mimics GPGPU now with 3D functions. This hasn't been necessary
since DX11 hardware came out, and some DX10.1 hw maybe.
>
>         GPGPU different with 3D pipeline a lot on IvyBridge+.
>         Both the pipeline setting and run time are totally different than that in 3D driver.
>         The GPU thread spawn model, thread communication model, memory model are also totally different.

This is also true mostly for other GPUs, there is only a single shader
stage, and setup for it is quite different. I'm assuming IvyBridge is
based around DX11 Compute so I doubt its that much different. The
gallium compute interface is not the same as that gallium 3D
interface, you could quite easily have written a compute only gallium
driver in the time it would take to even start writing this. I realise
Ben left this code drop, but you guys could have at least spent some
time checking out what else was out there.

>         Also the binary representation is different.
>         Ben choose LLVM scalar IR for many reasons(you can find the
>         decision make reason in the document), that means IR backend are different.

Again not really important, we use LLVM and TGSI backends in the
radeon drivers now. The gallium drivers currently use GPU specific
LLVM IRs produced from specific LLVM backends, but that isn't strictly
necessary just leads to better optimising opportunities.

>         For GPGPU programming, I don't see a lot benefit to introduce state tracker.
>         There is not so many states to track.

Because you now have a whole bunch of code that is useless to anyone
else. Distro want to ship this sort of thing, we don't want 5 Mesa
like implementations for OpenCL, we want one we can actually
distribute and manage, and maybe in 5 years support.

>         The project is already a functional OpenCL implementation on IvyBridge at this point.
>
>         1. Most of the language features are supported.
>         2. Most of built-in functions are supported.
>         3. Global, Local memory, thread barriers are supported.
>         3. OpenGL to OpenCL texture sharing are supported.
>
>         We have already implement something like CSS filters with this driver,
>         and we see performance gain than OpenGL filters.

Some other questions:
a) have you got an ivybridge LLVM backend? are you going to upstream
this, I heard it isn't even written in LLVM machine description
format.
b) have you looked at pocl, libclc etc? Maybe you guys want to run on
CPU as well at GPU at some point, in which case maybe again looking
around before jumping into implementing stuff might help.
c) does this use the open source ICD at least?

Dave.

Re: FW: Release Notes for Beignet Version 0.1

[Zou, Nanhai]

Hi,

> Again not really important, we use LLVM and TGSI backends in the radeon drivers now. The gallium drivers currently use GPU specific LLVM IRs produced from specific LLVM backends, but that isn't strictly necessary just leads to better optimising opportunities.
> Because you now have a whole bunch of code that is useless to anyone else. Distro want to ship this sort of thing, we don't want 5 Mesa like implementations for OpenCL, we want one we can actually distribute and manage, and >maybe in 5 years support.
	
	The point is at the current stage, we don't see the necessary of introduce all those complexity and dependencies. 
	Considering we can share very few code with other part of Mesa(expect some GPU related define in header files).

	We want to keep this project tiny and self-contained at this point, focus on make OpenCL really fast and useful on IVB+ GPU.

	We can merge or hook the backend into gallium when there are other mature gallium based OpenCL implementations. 
	That should not be a lot of task,  consider the common code are very few.


>  Some other questions:
>  a) have you got an ivybridge LLVM backend? are you going to upstream this, I heard it isn't even written in LLVM machine description format.

	No, we convert llvm IR to Gen IR then to IVB assembly.
    There are many choices when implement an execute model of IVB. E.g 8 way or 16 way, SOA mode or AOS mode. 
	We choose 16 way AOS mode in the driver.
	I don't know if it make sense to upstream only this particular combination.


>  b) have you looked at pocl, libclc etc? Maybe you guys want to run on CPU as well at GPU at some point, in which case maybe again looking around before jumping into implementing stuff might help.

	We do have looked at libclc.
	Again, I don't see the necessary to introduce the complexity at this point
	Almost all the functions in libclc maps to 1 instructions on IVB. We do not see the necessary of introducing a library to wrap those. 

>  c) does this use the open source ICD at least?
	No, we will check that.


Dave.

Re: FW: Release Notes for Beignet Version 0.1

[Zhigang Gong]

> -----Original Message-----
> From:
> intel-gfx-bounces+zhigang.gong=linux.intel.com@lists.freedesktop.org
> [mailto:intel-gfx-bounces+zhigang.gong=linux.intel.com@lists.freedesktop.
> org] On Behalf Of Zou, Nanhai
> Sent: Tuesday, April 16, 2013 2:47 PM
> To: Dave Airlie
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] FW: Release Notes for Beignet Version 0.1
> 
> Hi,
> 
> > Again not really important, we use LLVM and TGSI backends in the
> radeon drivers now. The gallium drivers currently use GPU specific LLVM
> IRs produced from specific LLVM backends, but that isn't strictly
necessary
> just leads to better optimising opportunities.
> > Because you now have a whole bunch of code that is useless to anyone
> else. Distro want to ship this sort of thing, we don't want 5 Mesa like
> implementations for OpenCL, we want one we can actually distribute and
> manage, and >maybe in 5 years support.
> 
> 	The point is at the current stage, we don't see the necessary of
> introduce all those complexity and dependencies.
> 	Considering we can share very few code with other part of
> Mesa(expect some GPU related define in header files).
> 
> 	We want to keep this project tiny and self-contained at this point,
> focus on make OpenCL really fast and useful on IVB+ GPU.
> 
> 	We can merge or hook the backend into gallium when there are
> other mature gallium based OpenCL implementations.
> 	That should not be a lot of task,  consider the common code are very
> few.
> 
> 
> >  Some other questions:
> >  a) have you got an ivybridge LLVM backend? are you going to upstream
> this, I heard it isn't even written in LLVM machine description format.
> 
> 	No, we convert llvm IR to Gen IR then to IVB assembly.
>     There are many choices when implement an execute model of IVB. E.g
> 8 way or 16 way, SOA mode or AOS mode.
> 	We choose 16 way AOS mode in the driver.
> 	I don't know if it make sense to upstream only this particular
> combination.
> 
> 
> >  b) have you looked at pocl, libclc etc? Maybe you guys want to run on
> CPU as well at GPU at some point, in which case maybe again looking
> around before jumping into implementing stuff might help.
> 
> 	We do have looked at libclc.
> 	Again, I don't see the necessary to introduce the complexity at this
> point
> 	Almost all the functions in libclc maps to 1 instructions on IVB. We
do
> not see the necessary of introducing a library to wrap those.
> 
> >  c) does this use the open source ICD at least?
> 	No, we will check that.
[Gong, Zhigang] As I know, Simon implemented ICD for Beignet and it may need
some time to rebase to the latest beignet code base.
If you are interested, this is the link http://psi5.com/~geier/beignet.git.
> 
> 
> Dave.
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FW: Release Notes for Beignet Version 0.1

[Chi-Thanh Christopher Nguyen]

Zou, Nanhai <nanhai.zou <at> intel.com> writes:

> 
> Hi,
>          We have just released the open source Linux OpenCL project
Beignet Version 0.1.
>  
> If you are interested in this project. Please try it and provide feedback
to us.
> We welcome developers to  join this project.

It appears that CMakeLists.txt contains the following copyright header:
http://cgit.freedesktop.org/beignet/tree/CMakeLists.txt?id=Release_v0.1

#############################################################################
#                  INTEL CORPORATION PROPRIETARY INFORMATION                #
#     This software is supplied under the terms of a license agreement or   #
#     nondisclosure agreement with Intel Corporation and may not be copied  #
#     or disclosed except in accordance with the terms of that agreement.   #
#          Copyright (C) 2009 Intel Corporation. All Rights Reserved.       #
#############################################################################

Is that an oversight or is it necessary to sign an agreement with Intel to
redistribute the code?


Best regards,
Chi-Thanh Christopher Nguyen


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FW: Release Notes for Beignet Version 0.1

[Simon Richter]

Hi,

On 16.04.2013 09:50, Zhigang Gong wrote:

> [Gong, Zhigang] As I know, Simon implemented ICD for Beignet and it may need
> some time to rebase to the latest beignet code base.
> If you are interested, this is the link http://psi5.com/~geier/beignet.git.

Indeed, the extension handling is entirely different. I've gotten the
code to compile, but it is not yet recognized as a valid ICD module. I
also need to implement clGetExtensionFunctionAddress() for the "ocl-icd"
implementation to accept the module.

   Simon

Re: FW: Release Notes for Beignet Version 0.1

[Tom Stellard]

Hi Nanhai,

I'm a developer for AMD working on an Open Source OpenCL implementation
for our GPUs.  I am very familiar with a number of the active Open
Source OpenCL projects, and I have a few comments:

>	It is not really true to say that the code is duplicated.
>

Have you done a survey of all the current OpenCL related Open Source
projects, because it really looks like several parts of Beignet
duplicate functionality that exists in one or more Open Source projects:

OpenCL API Implemtation:
  clover (http://www.mesa3d.com)
  pocl (http://pocl.sourceforge.net/)

OpenCL Builtin Library:
  pocl
  libclc (http://libclc.llvm.org/)

OpenCL Test Suite:
  piglit (http://cgit.freedesktop.org/piglit)

IvyBridge Compiler
  intel mesa driver ??

>	Beignet maps OpenCL into GPGPU pipeline of IvyBridge+ hardware.
>	So this is real GPGPU other than mimic GPGPU with 3D functions.

The Gallium compute interface has separate state setup and dispatch for
compute, so there is no need to mimic anything with 3D functions.

>
>	GPGPU different with 3D pipeline a lot on IvyBridge+.
>	Both the pipeline setting and run time are totally different than that in 3D driver.
>	The GPU thread spawn model, thread communication model, memory model are also totally different.

The 3D and compute pipelines are different on radeon hardware too, and
the gallium interface is designed for hardware like this.

>
>	Also the binary representation is different.
>	Ben choose LLVM scalar IR for many reasons(you can find the 
>	decision make reason in the document), that means IR backend are different.

Clover passes LLVM scalar IR to the drivers.  If you had a gallium compute
driver for ivy bridge you could tell clover to give you LLVM IR targeted for
NVPTX (which appears to be what you are currently generating from clang)
and you would get the exact same IR that use for Beignet.

>
>	For GPGPU programming, I don't see a lot benefit to introduce state tracker. 
>	There is not so many states to track.
>

I think pretty much any OpenCL implementation is a "state tracker", even
if it is not called that explicitly.  You're right there is not much
state for OpenCL, but I think the amount of overhead added by clover is
really minimal.

>	The project is already a functional OpenCL implementation on IvyBridge at this point. 
>
>	1. Most of the language features are supported.
>	2. Most of built-in functions are supported.
>	3. Global, Local memory, thread barriers are supported.
>	3. OpenGL to OpenCL texture sharing are supported.

>	
>	We have already implement something like CSS filters with this driver, 
>	and we see performance gain than OpenGL filters.

It sounds like a lot of progress has been made.  Are there any popular
OpenCL applications that work with Beignet?

I would be really disappointed to see yet another Open Source OpenCL
implementation, and I would encourage you to take another look at clover
or pocl and see if it would be possible to merge the Beignet code into
one of those projects.

I think it would be really easy to merge this code into a gallium driver,
because you could drop in your compiler backend completely unchanged and there
are really not very many gallium API functions that need to be implemented.

I would also encourage you to take a look at the piglit OpenCL
framework for tests.  The framework is very good and has a lot of
convenient helpers that make it easy to write tests, including a
scripting language for writing kernel tests.

If you have any questions about any of this, please let me know.  I am
happy to help and look forward to being able to collaborate with your
team as I already do with your terrific Open Source graphics team.

Thanks,
Tom Stellard

Re: FW: Release Notes for Beignet Version 0.1

[Simon Richter]

[-- Attachment #1.1: Type: text/plain, Size: 3667 bytes --]

Hi,

On 16.04.2013 09:50, Zhigang Gong wrote:

> [Gong, Zhigang] As I know, Simon implemented ICD for Beignet and it may need
> some time to rebase to the latest beignet code base.
> If you are interested, this is the link http://psi5.com/~geier/beignet.git.

I've rebased on top of the release 0.1 tag, and updated accordingly.

These changes have not yet been widely tested and should be subject to
extensive debate.

I've uploaded a build of the package to Debian experimental to allow for
some testing by brave adventurers. Note that these packages do not
support OpenGL sharing as Debian has an old version of Mesa.

Changes:

commit 13c650fb4492b7c96b1a1dfb31cf048da3de9729
Author: Simon Richter <Simon.Richter@hogyros.de>
Date:   Tue Apr 2 15:01:52 2013 +0200

    Use "clang" command from PATH

    This assumes that LLVM is installed in the system path, but avoids
    compiling the path of binaries into the library.

commit 8d468fcc820330c872441f552cf0edcc73e10341
Author: Simon Richter <Simon.Richter@hogyros.de>
Date:   Tue Apr 16 20:04:42 2013 +0200

    Make EGL optional

    This fixes builds if EGL is unavailable. The OpenGL sharing
extension will
    be disabled then.

commit bb03533ee094f4b0a9e0a5f17fe20388e960c7d3
Author: Simon Richter <Simon.Richter@hogyros.de>
Date:   Tue Apr 16 20:02:08 2013 +0200

    Prefer versioned llvm-config

    If multiple versions are installed, prefer version 3.2 before
falling back
    to the default version.

commit 122229cee97add90abcd7e3410b7b8d748c4e99e
Author: Simon Richter <Simon.Richter@hogyros.de>
Date:   Fri Apr 12 11:21:19 2013 +0200

    Accept glibc's implementation of memalign()

    If the platform is not Linux, but glibc based, we assume that the
    memalign() function is working satisfactorily.

commit dceb446181a23209888595d13b0382e49b1a43bc
Author: Simon Richter <Simon.Richter@hogyros.de>
Date:   Wed Apr 3 20:32:45 2013 +0200

    Implement KHR ICD extension

    This adds a pointer to the dispatch table at the beginning of every
object
    of type

     - cl_command_queue
     - cl_context
     - cl_device_id
     - cl_event
     - cl_kernel
     - cl_mem
     - cl_platform_id
     - cl_program
     - cl_sampler

    as required by the ICD specification. The layout of the dispatch table
    comes from the OpenCL ICD loader by Brice Videau
<brice.videau@imag.fr> and
    Vincent Danjean <Vincent.Danjean@ens-lyon.org>.

    To avoid dispatch table entries being overwritten with the ICD loader's
    implementations of the CL functions (as would be the proper
behaviour for
    the ELF loader), the -Bsymbolic option is given to the linker.

commit 2756d1a9a2446faad1bacd203c234ce81581179b
Author: Simon Richter <Simon.Richter@hogyros.de>
Date:   Tue Apr 2 15:11:01 2013 +0200

    "Implement" clGetExtensionFunctionAddress()

    This function should not fail if a function entry point cannot be
found --
    instead we return NULL.

commit 4fe13e919524378b799205e71aa2c35f7049bbf9
Author: Simon Richter <Simon.Richter@hogyros.de>
Date:   Tue Apr 16 20:05:54 2013 +0200

    Avoid extension names as preprocessor tokens

    The Khronos Group headers define constants with the names of
extensions if
    the header defines the extension API. When the preprocessor sees one of
    these names, it performs macro substitution, leading to compilation
errors.

commit 644432d586d47ddcdbc9e9e91732a715a73884c2
Author: Simon Richter <Simon.Richter@hogyros.de>
Date:   Tue Apr 2 14:51:52 2013 +0200

    Fix typo in cl_get_platform_info function name

   Simon


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx