Intel Broadwell On Linux Has Working OpenCL 1.2, VP8 Video Acceleration

[-MacNuke-]

After all those years... OpenSource OpenCL is still a mess on Linux...

splittet projects (beignet, clover, pocl, freeocl, ...), "works mostly, except ...", "covers 99% of ...", or is still at OpenCL 1.1 nearing OpenCL 1.2 in times of OpenCL 2.0, Hardware-related bugs or shortcomings (beignet on Haswell for example)...

aaaaaaand dead or slow progress on pure CPU implementations...

[dungeon]

After all those years... OpenSource OpenCL is still a mess on Linux...

Which OpenSource OpenCL you have on other OSes?

splittet projects (beignet, clover, pocl, freeocl, ...), "works mostly, except ...", "covers 99% of ...", or is still at OpenCL 1.1 nearing OpenCL 1.2 in times of OpenCL 2.0, Hardware-related bugs or shortcomings (beignet on Haswell for example)...

You have OpenCL 2.0 with Catalyst on Linux.

If you only ranting about how opensource drivers lagging in terms of features/versions when compared with blob drivers on Linux or other OSes, that is nothing new - that is pretty much always had been like that

[schmidtbag]

I doubt AMD is even close to Intel in term of features in the open driver.

Not sure about OpenCL, but at least for openGL, I've found (in my experience) AMD's open source drivers have been better. Intel might have a smaller performance gap compared to to the closed-source Windows drivers, but there are games I've played on the intel drivers that had lighting or texture issues that didn't happen on AMD hardware. Sometimes there were games that were unplayable slow, and weren't even that detailed. My intel system uses ivy bridge.

Generally speaking, the intel drivers are probably the best you can get in linux for non-gaming purposes. Not that intel graphics should ever be used for gaming anyway.

[Marc Driftmeyer]

No, AMD still has this, without even any image support:

niko@gentoo-desktop ~/devel/clinfo-master $ ./clinfo 
Number of platforms                               1
  Platform Name                                   Clover
  Platform Vendor                                 Mesa
  Platform Version                                OpenCL 1.1 MESA 10.5.0-devel
  Platform Profile                                FULL_PROFILE
  Platform Extensions                             cl_khr_icd
  Platform Extensions function suffix             MESA

  Platform Name                                   Clover
Number of devices                                 1
  Device Name                                     AMD TAHITI
  Device Vendor                                   X.Org
  Device Vendor ID                                0x1002
  Device Version                                  OpenCL 1.1 MESA 10.5.0-devel
  Driver Version                                  10.5.0-devel
  Device OpenCL C Version                         OpenCL C 1.1
  Device Type                                     GPU
  Device Profile                                  FULL_PROFILE
  Max compute units                               28
  Max clock frequency                             810MHz
  Max work item dimensions                        3
  Max work item sizes                             256x256x256
  Max work group size                             256
  Preferred work group size multiple              1
  Preferred / native vector sizes                 
    char                                                16 / 16      
    short                                                8 / 8       
    int                                                  4 / 4       
    long                                                 2 / 2       
    half                                                 0 / 0        (n/a)
    float                                                4 / 4       
    double                                               2 / 2        (n/a)
  Half-precision Floating-point support           (n/a)
  Single-precision Floating-point support         (core)
    Denormals                                     Yes
    Infinity and NANs                             Yes
    Round to nearest                              Yes
    Round to zero                                 No
    Round to infinity                             No
    IEEE754-2008 fused multiply-add               No
    Support is emulated in software               No
    Correctly-rounded divide and sqrt operations  No
  Double-precision Floating-point support         (n/a)
  Address bits                                    32, Little-Endian
  Global memory size                              1073741824 (1024MiB)
  Error Correction support                        No
  Max memory allocation                           268435456 (256MiB)
  Unified memory for Host and Device              Yes
  Minimum alignment for any data type             128 bytes
  Alignment of base address                       128 bits (16 bytes)
  Global Memory cache type                        None
  Image support                                   No
  Local memory type                               Local
  Local memory size                               32768 (32KiB)
  Max constant buffer size                        268435456 (256MiB)
  Max number of constant args                     0
  Max size of kernel argument                     1024
  Queue properties                                
    Out-of-order execution                        No
    Profiling                                     Yes
  Profiling timer resolution                      0ns
  Execution capabilities                          
    Run OpenCL kernels                            Yes
    Run native kernels                            No
  Device Available                                Yes
  Compiler Available                              Yes
  Device Extensions                               

NULL platform behavior
  clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  No platform
  clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   No platform
  clCreateContext(NULL, ...) [default]            No platform
  clCreateContext(NULL, ...) [other]              Success [MESA]
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU)  Success (1)
    Platform Name                                 Clover
    Device Name                                   AMD TAHITI
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL)  Success (1)
    Platform Name                                 Clover
    Device Name                                   AMD TAHITI

I'm not discussing the FOSS support. The OpenCL 2.0 support is in the current AMD stack. Using CodeXL 1.6 and AMD APP SDK 3.0 Beta together the following are OpenCL 2.0 ready:

http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/system-requirements-driver-compatibility/

You've got options while AMD advances their next generation driver that merges the Catalyst and R600 LLVM stacks.

[darkbasic]

I'm not discussing the FOSS support. The OpenCL 2.0 support is in the current AMD stack. Using CodeXL 1.6 and AMD APP SDK 3.0 Beta together the following are OpenCL 2.0 ready:

http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/system-requirements-driver-compatibility/

You've got options while AMD advances their next generation driver that merges the Catalyst and R600 LLVM stacks.

Oh I'm sorry, but I don't even consider Catalyshit as an option

[SystemCrasher]

I'm not discussing the FOSS support. The OpenCL 2.0 support is in the current AMD stack.

To be honest IMO Catalyst suxx beyound acceptable limits. For example, this crap unable to remove itself in clean way. Not even single time. There're always some leftovers left, scattered all over whole system, no matter what you do. Then it can break upon system upgrade, leaving you in black screen. Which is not very friendly to fix. It also tend to crash running system somewhere about once a week or so with some really hardcore errors in kernel code. I never seen opensource driver crashing whole kernel with GPF...

So in AMD shoes I would better ditch Catalyst completely and reassign resources to opensource stack. Just like Intel did.

[Kano]

If you use the packages from your distribution and delete the xorg.conf i see no problem to remove fglrx. I can even switch on the fly to mesa or back to fglrx during boot.

[SystemCrasher]

If you use the packages from your distribution and delete the xorg.conf i see no problem to remove fglrx. I can even switch on the fly to mesa or back to fglrx during boot.

Still, there're usually some leftover files. And deleting xorg.conf manually? In first place, I never created one myself! This one only needed by Catalyst crap only and I explicitly unwelcome this MS-DOS style plug-n-play approach in my system (where drivers required explicit entry in config.sys and system reboot to take effect). Seriously, lets just ditch this stuff and get proper system integration (be it panic notifier, ability to work under kdb, displaying boot logo, more or less decent framebuffer-like consoles, or other stuff where kernel may want to draw something itself), REAL plug-n-play (where it just works!) and smooth upgrades. Intel got it right. Amd got it half way. Nvidia... oh, mr. Torvalds told them already what they should do.

[Kano]

There are no leftover files when done right. For Debian/Kanotix i have correct uninstall instructions in the IRC (!nvdebrm or !amddebrm), after that do "apt-get autoremove --purge" and everything is fine. If you used the amd/nvidia run installer directly it was your fault not mine.