1 Reply by labre

(426 replies, posted in Using SVP)

With some help from the LLVM guys, I found the root cause, which was also found by someone else a few weeks ago:
https://github.com/RadeonOpenCompute/RO … /issues/52

Basically comgr-objdump in RocM is originally a copy of llvm-objdump and still explicitly registers an option on LLVM without any need for that. Removing the code registering that option fixes the issue. LLVM also works on the duplication errors in general and likely has CommandLine isolation in version 16. This should prevent the error class for registered options from different libraries.

Go to forum: Using SVP

2 Reply by labre

(426 replies, posted in Using SVP)


NM64 wrote:

It may have been easier if you just used the newly-developed rusticl paired with the standard default kernel-level AMD graphics drivers and mesa 22.3:
https://lists.freedesktop.org/archives/ … 25898.html

I just never said much of anything about it because I've not managed to test it out myself just yet and therefore I cannot say from experience what the exact steps are to enable rusticl for AMD graphics considering that rusticl as a whole is disabled by default.

That won’t work either. With rusticl, SVP will break for all open source drivers in the foreseeable future. I happened to get to the point with preliminary radeonsi support in rusticl, which currently advertises OpenCL 1.2. SVP won’t detect it though (the tool itself works in a shell), because it links against its own mesa and especially LLVM, but let’s start from the beginning.

To hunt down that LLVM error, I looked up the source and eventually found the related bug [1]. The error comes down to libllvm being linked to twice and is triggered by the CommandLine module. So I went ahead, commented the fatal errors out, recompiled LLVM and the whole system afterwards. This resulted in… nothing. The message persists, so it is coming from LLVM linked to by SVP. The main difference between OpenCL use and non-OpenCL use revealed by gdb looking at mpv is simply the linking to libllvm, which means, that the libsvpflow libraries already statically link against it and the dynamic load is the second one, which leads to the abort. This also explains, why the SVP performance test works for OpenCL.

Afterwards I prepared a Gentoo mesa ebuild update for rusticl support. While I can’t test rusticl actually because of the lacking OpenCL support with radeonsi, I now know definitely, that it also links to libllvm, so it will be broken with current SVP linking.

I see about 3 solutions:
1. Link dynamically to the system libs, at least for libllvm.
2. Request LLVM upstream to make a change to ignore double linkage, if that works. If it does not work, ask for suggestions to get this software constellation to work.
3. Remove the dependency on libllvm, if possible. If the Manager’s GUI libraries are the sole consumers, provide a CLI tool, which can act as daemon, read the config and enable the plugin on video playback. SVP overlay is not mandatory beyond the configuration phase.

Edit:

And a 4th:
Compile mesa with Dgallium-opencl (clover) support or install the corresponding package for your distribution. That prevents the error for whatever reason. RocM is still used as OpenCL backend, because unmerging it leads to OpenCL not being detected in SVP. Anyway while Clover is not used in any way, it has to be present for SVP.

Maybe the linking is changed in system mesa lib or SVP loads system libs depending on certain symbols being present in them, which prevents the LLVM error from being thrown, but I’m just guessing. Considering these facts, rusticl might in fact be a solution. Note, that Clover is going to be removed upstream, so if rusticl will not work, we still have a problem.

Edit2:
Nope, Clover was not the fix. Actually RocM broke after restarting the X server, reproducing the LLVM error, like it is warned in the Gentoo Wiki. That’s the error, which should have been patched out on my system. So it seems, the patch did not work, which breaks my assumptions about SVP linking. So, actually I did not change anything, but it started to work after ~2 years and a system update, which did not contain mesa nor RocM, but at least mpv. Maybe it was mpv, a RocM update two weeks ago or a patch in Gentoo, which others are missing. Versions:
Rocm-5.3.3
mesa-22.2.3
opencl-icd-loader-2022.09.30
mpv-0.35.0-r1

Sorry for not having any clues to fix this one.

The last god damned edit:

Found it. The double linking occurs with radeonsi’s vaapi driver in mesa and rocm-comgr:

$ ldd /usr/lib64/va/drivers/radeonsi_drv_video.so
...
libLLVM-15.so => /usr/lib/llvm/15/lib64/libLLVM-15.so (0x00007f933e600000)
...
$ ldd /usr/lib64/libamd_comgr.so.2.4
...
libLLVM-15.so => /usr/lib/llvm/15/lib64/libLLVM-15.so (0x00007f933e600000)
...

I missed an occurrence of the report_fatal_error call in my LLVM patch, which has been fixed. Providing the updated patch for reference. Recompiling mesa and rocm-comgr with this patched LLVM resolves the issue. The patched LLVM now prints a warning instead of aborting with an error, which otherwise seems to have zero side effects.

So to summarize:

1. You can either disable hardware decoding, which should get OpenCL to work or disable SVP’s OpenCL use, which should allow hardware decoding.
2. You can patch LLVM and compile mesa and rocm-comgr with it, which gets both to work.
3. You can be angry with LLVM developers for ignoring an issue for ≈8 years, which could have been solved with a 17 lines patch.
4. You’re welcome. wink


[1]: https://github.com/llvm/llvm-project/issues/23326

Go to forum: Using SVP

3 Reply by labre

(426 replies, posted in Using SVP)

I currently have the problem (again [1]), that RocM with Radeonsi and LLVM causes a LLVM CommandLine plugin error like the following, if mpv is started with SVP using OpenCL. The GPU based performance test runs just fine and SVP also works without OpenCL usage.

mesa: CommandLine Error: Option 'dwarf-extended-loc' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
Aborted

This started to happen after an update of mpv to 0.34.1, but downgrading did not fix it. I also backtracked (downgraded) updates of all other linked libraries (LLVM, Clang, Mesa) to see, if that helps, but the only change was made by mesa downgrade from 22 to 21, which changed the message to the one, I reported originally here in [1] 2 years ago. I can’t recall any working fix attempts for that original issue. It just went away some day, maybe by a SVP update.

mesa: CommandLine Error: Option 'help-list' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
Aborted

This error is a result of LLVM plugins being loaded multiple times and caused by bad linking (and the crappy CommandLine plugin (and glibc, mesa, LLVM) implementation(s) [2]). Nowadays this usually happens, if multiple LLVM versions are installed and linked against [3], however I just have LLVM/Clang 13 installed, so this can’t be the case. Usually the linkage in the binary itself has to be fixed, for instance SVP could (indirectly) link against LLVM 12. Other programs using OpenCL Image support like darktable-cltest work just fine.

So my question for the community is: Has anyone with the following library major versions and a RocM supported AMD card has the same issue with mpv, if OpenCL is activated (and OpenCL does work everywhere else)?

Mesa: 22.0.3
RocM: 5.0.2
LLVM/Clang: 13.0.1
mpv: 0.34.1

I’d also kindly ask the SVP developers, if they could check their build with these versions and if they could provide a working build for them in case of problem reproduction. I’m aware, that this build might not work for LLVM 12 systems, but for the transition phase it would be nice to have a working one. Note, that this is not really an urgent issue for me, because I have the necessary CPU power for max settings.

[1]: https://www.svp-team.com/forum/viewtopi … 773#p75773
[2]: https://bugs.gentoo.org/617154#c8
[3]: https://bugs.gentoo.org/651658

Go to forum: Using SVP

4 Reply by labre

(426 replies, posted in Using SVP)

Chainik wrote:

lukesamuel
> but shows an error which would seem to confirm it is using beignet

Performance test did crash for me too on Haswell with Beignet. In theory it
works (according to mpv/SVP), however I didn’t see much of a
performance boost, if any. Beignet is an old unmaintained OpenCL
implementation, which was removed from Gentoo repositories lately for
that reason. Intel-neo however, which supports Broadwell onwards,
gives quite much of a performance boost on my Skylake laptop. For that
reason I doubt, that Beignet really works. I have a dedicated card now
(Navi14).

I can’t seem to get that to run either however.  I have image support
and the performance test runs through just fine with GPU OpenCL.  Also
SVP gives no errors/warnings whatsoever.  If I turn GPU based OpenCL
on, mpv gets broken command line arguments, which does not happen on
CPU based interpolation.

mpv breaks with:

mesa: CommandLine Error: Option 'help-list' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

My setup:
mpv 0.32.0
Vapoursynth 49
Kernel 5.6.3 (proper Navi14 support)
Mesa 20.0.6
Rocm 3.3.0
hsa-ext-rocr 1.1.30300.0 (image support)
LLVM 9.0.1

The LoadLib failures in clinfo.log are warnings. The aqlprofile library is an
optional package. [1] I could not find anything except [2] on
libhsa-ext-finalize64, which states, that it is an old library dropped
in Rocm 1.9. Besides that, these warnings were not present in 3.0.0,
which also failed with the above CLI arg error and again: the
performance test runs through without errors and GPU based OpenCL
enabled.

Any ideas? Maybe Rocm needs a quirk? I’ll attach the usual logs (mpv,
SVP, clinfo).

[1]: https://www.phoronix.com/forums/forum/l … 4-17/page2
[2]: https://github.com/RadeonOpenCompute/RO … -421691921

Go to forum: Using SVP

5 Reply by labre

(426 replies, posted in Using SVP)

Chainik wrote:

> On Ubuntu 16.4

is it 64-bit version?

In fact I get the same from ldd and SVP works. No idea, why ldd
fails. As chainik pointed out, a quick search reveals, that ldd
typically fails, when 32 bit support is missing on a 64 bit
operating system.  SVP is 64 bit though, so if you have that version and your OS is 64 bit, everything is fine. In a comment on stackoverflow it was however
mentioned, that readelf is more reliable in some cases. Also file
reports SVPManager as dynamically linked.

readelf -d gives:

 0x0000000000000001 (NEEDED)             Shared library: [libmediainfo.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Widgets.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Gui.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Qml.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Network.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Concurrent.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Core.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x000000000000000f (RPATH)              Library rpath: [/opt/Qt5/5.5/gcc_64:/opt/Qt5/5.5/gcc_64/lib]

Do you have those dependencies installed?
Just do a quick search. Assuming "$HOME/SVP 4" as your installation directory.

cd ~/SVP\ 4
for lib in $(readelf -d SVPManager | grep NEEDED | sed -rne 's/^.*\[([^]]+)\]$/\1/p' | xargs -d '\n'); do find /usr/lib/x86_64-linux-gnu/ -name "*${lib}*" -printf "${lib}: %p\n"; done

Go to forum: Using SVP

6 Reply by labre

(426 replies, posted in Using SVP)

Can’t seem to find one. So the error with the performance test is a false alarm? I didn’t test beignet-1.3.2 for so long and was using git version before. After ca. 30 seconds beignet messes up and freezes the whole computer including the reset button. Fun fact: The mainboard was manufactured by Intel, so it is messing up simultaneously on several levels.
Anyway, the git version seems to work. The main reason for the post was, that the performance on my Ultrabook was low, but I guess the CPU, which throttles at a temperature threshold, is the bottleneck there. Would you agree?

mpv.log: Shortened a bit to spare you from the duplicate lines. Searched for “code” before truncating it.

Playing: https://www.youtube.com/watch?v=*
 (+) Video --vid=1 (*) (h264 1280x720 59.940fps)
 (+) Audio --aid=1 --alang=und (*) 'DASH audio' (aac 2ch 44100Hz) (external)
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
AO: [alsa] 48000Hz stereo 2ch float
Using hardware decoding (vaapi-copy).
VO: [opengl] 1280x720 nv12
AV: 00:00:00 / 00:02:49 (0%) A-V:  0.000 DS: 1.000/0 Cache:  9s+6KB
AV: 00:00:00 / 00:02:49 (0%) A-V: -0.011 DS: 0.667/0 Cache: 10s+54KB
(Paused) AV: 00:00:00 / 00:02:49 (0%) A-V:  0.003 DS: 0.778/0 Dropped: 2 Cache: 10s+670KB
Opening video filter: [vapoursynth file=/home/user/.local/share/SVP4/scripts/2f2a596b.py buffered-frames=4 concurrent-frames=23]
[ffmpeg] tls: The TLS connection was non-properly terminated.
Using conversion filter.
(Paused) AV: 00:00:00 / 00:02:49 (0%) A-V:  0.000 Cache:  0s+2MB
VO: [opengl] 1280x720 yuv420p
(Paused) AV: 00:00:00 / 00:02:49 (0%) A-V:  0.000 DS: 1.000/0 Cache: 10s+3MB
[ffmpeg] tls: The TLS connection was non-properly terminated.
AV: 00:00:33 / 00:02:49 (19%) A-V:  0.017 DS: 0.980/18 Dropped: 22 Cache: 10s+26MB
[vapoursynth] Filter error at frame 2040: EOF or filter reinit/uninit
AV: 00:00:33 / 00:02:49 (19%) A-V:  0.017 DS: 0.980/18 Dropped: 22 Cache: 10s+26MB
Opening video filter: [vapoursynth file=/home/manu/.local/share/SVP4/scripts/2f2a596b.py buffered-frames=4 concurrent-frames=23]
Using conversion filter.
AV: 00:00:33 / 00:02:49 (19%) A-V:  0.017 DS: 1.240/18 Dropped: 22 Cache: 10s+26MB
VO: [opengl] 1280x720 nv12
AV: 00:00:33 / 00:02:49 (19%) A-V:  0.036 DS: 1.240/0 Cache: 10s+26MB
VO: [opengl] 1080x720 yuv420p
AV: 00:00:34 / 00:02:49 (20%) A-V:  0.027 DS: 1.230/0 Cache: 10s+26MB
AV: 00:02:11 / 00:02:49 (77%) A-V:  0.013 DS: 1.000/45 Dropped: 60 Cache: 10s+10MB
[vapoursynth] Filter error at frame 5876: EOF or filter reinit/uninit
AV: 00:02:11 / 00:02:49 (77%) A-V:  0.012 DS: 1.000/45 Dropped: 60 Cache: 10s+10MB
Opening video filter: [vapoursynth file=/home/user/.local/share/SVP4/scripts/2f2a596b.py buffered-frames=4 concurrent-frames=23]
Using conversion filter.
AV: 00:02:11 / 00:02:49 (77%) A-V:  0.013 DS: 1.260/45 Dropped: 60 Cache: 10s+10MB
VO: [opengl] 1280x720 nv12
AV: 00:02:11 / 00:02:49 (77%) A-V:  0.014 DS: 1.260/0 Cache: 10s+10MB
VO: [opengl] 1280x720 yuv420p
AV: 00:02:12 / 00:02:49 (77%) A-V:  0.027 DS: 1.260/0 Cache: 10s+10MB
AV: 00:02:49 / 00:02:49 (99%) A-V:  0.000 DS: 0.970/16 Dropped: 22 Cache:  0s+0KB
[vapoursynth] Filter error at frame 2254: EOF or filter reinit/uninit
[vapoursynth] Error filtering frame.
[vapoursynth] Filter error at frame 2272: EOF or filter reinit/uninit
[vapoursynth] Error filtering frame.
[vapoursynth] Filter error at frame 2259: EOF or filter reinit/uninit
AV: 00:02:49 / 00:02:49 (99%) A-V:  0.000 DS: 0.970/16 Dropped: 22 Cache:  0s+0KB
[vapoursynth] Filter error at frame 2261: EOF or filter reinit/uninit
[vapoursynth] Error filtering frame.
[vapoursynth] Filter error at frame 2263: EOF or filter reinit/uninit
AV: 00:02:49 / 00:02:49 (99%) A-V:  0.000 DS: 0.970/16 Dropped: 22 Cache:  0s+0KB
[vapoursynth] Filter error at frame 2260: EOF or filter reinit/uninit
(Paused) AV: 00:02:49 / 00:02:49 (99%) A-V:  0.000 DS: 0.970/16 Dropped: 22 Cache:  0s+0KB


Exiting... (Quit)

Go to forum: Using SVP

7 Reply by labre

(426 replies, posted in Using SVP)

Has anyone managed to get Intel OpenCL GPU support using beignet to work?
It is detected using ICD, but the system performance assessment always fails immediately when starting to test GPU OCL.

I have a Haswell desktop CPU with HD 4600 and a Skylake Ultrabook with a little bit more capabilities. Both do not work.

piglit tests on Skylake did work mostly. (400 fails, 11 crashes out of 12000)

Versions:
beignet-1.3.2 (tried also 1.3.1, git)
beignet is configured with experimental OpenCL2 support.
ocl-icd-2.2.11
mpv is not involved for this test, but CPU based rendering works.

SVP log:

18:13:57.045 [i]: Main: starting up SVP 4 Linux [4.2.0.122]... 
18:13:57.046 [i]: Main: args: none
18:13:57.046 [i]: Main: working dir is /home/manu/SVP 4/
18:13:57.046 [i]: Main: data dir set to /home/manu/.local/share/SVP4/
18:13:57.046 [i]: Settings: loading reg.cfg OK
18:13:57.047 [i]: Settings: loading main.cfg OK
18:13:57.047 [i]: Settings: loading ui.cfg OK
18:13:57.047 [i]: Settings: loading frc.cfg OK
18:13:57.047 [i]: Settings: loading profiles.cfg OK
18:13:57.047 [i]: Settings: loading custom.cfg OK
18:13:57.048 [i]: Settings: loading lights.cfg OK
18:13:57.048 [i]: Main: using Qt 5.7.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 5.4.0)
18:13:57.048 [i]: Main: device scale is 1, user defined scale is 1
18:13:57.048 [i]: Main: system locale is [de]
18:13:57.048 [i]: Main: preferred language is [de-de]
18:13:57.050 [i]: Main: setting language file to de.qm...
18:13:57.051 [i]: Main: module 'plugins/libsvpflow1_vs64.so': 4.2.0.133
18:13:57.052 [i]: Main: module 'plugins/libsvpflow2_vs64.so': 4.2.0.142
18:13:57.053 [i]: Main: VLC filter (64 bit): 0.9.0.114
18:13:57.053 [i]: Main: running OpenCL info...
18:13:57.055 [i]: D-Bus system tray: no
18:13:57.056 [i]: Main: collecting system information...
18:13:57.058 [i]: OS: Linux 4.12.12-gentoo #2 SMP PREEMPT Sun Sep 17 21:00:03 CEST 2017 x86_64
18:13:57.067 [i]: Desktop environment: /usr/bin/slim / 
18:13:57.069 [i]: CPU: Intel Core i5-4570 [base frequency 3539 MHz, 4 threads]
18:13:57.069 [i]: Video: reading OpenCL info...
18:13:57.169 [i]: Video: 1 GPU OpenCL device(s) on Intel Gen OCL Driver [OpenCL 2.0 beignet 1.3] (Intel)
18:13:57.170 [i]: Video 1: device name 'Intel(R) HD Graphics Haswell GT2 Desktop' (Intel, ver.1.3) [gpuID=11]: OK
18:13:57.171 [i]: Memory:  6983  MB total,  5301 MB free
18:13:57.172 [i]: System: finding network settings...
18:13:57.197 [i]: Power: AC is ON [1]
18:13:57.205 [i]: Screens: updating information, 1 screen(s) found
18:13:57.205 [i]: Screens: screen 0 (DP-1) - 1920x1200 @60.000 Hz, x1.7 [84 DPI]
18:13:57.205 [i]: Screens: primary screen is 0
18:13:57.217 [i]: Main: preparing FRC profiles...
18:13:57.254 [i]: Main: preparing performance graphs...
18:13:57.291 [i]: Main: preparing mpv...
18:13:57.303 [i]: Main: preparing remote control...
18:13:57.303 [i]: RemoteControl: started
18:13:57.304 [i]: Main: preparing main menu...
18:13:57.325 [i]: Main: loading extensions...
18:13:57.328 [i]: Extensions: found svpcode 0.9.0.122 ...
18:13:57.329 [i]: Settings: loading code.cfg OK
18:13:57.346 [i]: Extensions: found svplight 2.0.0.115 ...
18:13:57.347 [i]: Settings: loading leds.cfg OK
18:13:57.389 [i]: Main: initialization completed in 334 ms
18:13:57.627 [i]: Updates: checking now...
18:14:00.258 [i]: Performance: quick estimation = 575 (previous value was 597)
18:14:24.901 [i]: Performance: motion vectors estimation = 2277
18:14:35.411 [i]: Performance: CPU-based frame rendering = 3105
18:14:35.479 [W]: Video [gpuID=11] initialization failed
18:14:35.484 [W]: Performance: GPU-based frame rendering [gpuID=11] FAILED

clinfo:

Number of platforms                               1
  Platform Name                                   Intel Gen OCL Driver
  Platform Vendor                                 Intel
  Platform Version                                OpenCL 2.0 beignet 1.3
  Platform Profile                                FULL_PROFILE
  Platform Extensions                             cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_spir cl_khr_icd cl_intel_accelerator cl_intel_subgroups cl_intel_subgroups_short cl_khr_gl_sharing
  Platform Extensions function suffix             Intel

  Platform Name                                   Intel Gen OCL Driver
Number of devices                                 1
  Device Name                                     Intel(R) HD Graphics Haswell GT2 Desktop
  Device Vendor                                   Intel
  Device Vendor ID                                0x8086
  Device Version                                  OpenCL 1.2 beignet 1.3
  Driver Version                                  1.3
  Device OpenCL C Version                         OpenCL C 1.2 beignet 1.3
  Device Type                                     GPU
  Device Profile                                  FULL_PROFILE
  Max compute units                               20
  Max clock frequency                             1000MHz
  Device Partition                                (core)
    Max number of sub-devices                     1
    Supported partition types                     None, None, None
  Max work item dimensions                        3
  Max work item sizes                             512x512x512
  Max work group size                             512
  Preferred work group size multiple              16
  Preferred / native vector sizes                 
    char                                                16 / 8       
    short                                                8 / 8       
    int                                                  4 / 4       
    long                                                 2 / 2       
    half                                                 0 / 8        (n/a)
    float                                                4 / 4       
    double                                               0 / 2        (n/a)
  Half-precision Floating-point support           (n/a)
  Single-precision Floating-point support         (core)
    Denormals                                     No
    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                              2147483648 (2GiB)
  Error Correction support                        No
  Max memory allocation                           1610612736 (1.5GiB)
  Unified memory for Host and Device              Yes
  Minimum alignment for any data type             128 bytes
  Alignment of base address                       1024 bits (128 bytes)
  Global Memory cache type                        Read/Write
  Global Memory cache size                        8192
  Global Memory cache line                        64 bytes
  Image support                                   Yes
    Max number of samplers per kernel             16
    Max size for 1D images from buffer            65536 pixels
    Max 1D or 2D image array size                 2048 images
    Base address alignment for 2D image buffers   4096 bytes
    Pitch alignment for 2D image buffers          1 bytes
    Max 2D image size                             8192x8192 pixels
    Max 3D image size                             8192x8192x2048 pixels
    Max number of read image args                 128
    Max number of write image args                8
  Local memory type                               Local
  Local memory size                               65536 (64KiB)
  Max constant buffer size                        134217728 (128MiB)
  Max number of constant args                     8
  Max size of kernel argument                     1024
  Queue properties                                
    Out-of-order execution                        No
    Profiling                                     Yes
  Prefer user sync for interop                    Yes
  Profiling timer resolution                      80ns
  Execution capabilities                          
    Run OpenCL kernels                            Yes
    Run native kernels                            Yes
    SPIR versions                                 1.2
  printf() buffer size                            1048576 (1024KiB)
  Built-in kernels                                __cl_copy_region_align4;__cl_copy_region_align16;__cl_cpy_region_unalign_same_offset;__cl_copy_region_unalign_dst_offset;__cl_copy_region_unalign_src_offset;__cl_copy_buffer_rect;__cl_copy_image_1d_to_1d;__cl_copy_image_2d_to_2d;__cl_copy_image_3d_to_2d;__cl_copy_image_2d_to_3d;__cl_copy_image_3d_to_3d;__cl_copy_image_2d_to_buffer;__cl_copy_image_3d_to_buffer;__cl_copy_buffer_to_image_2d;__cl_copy_buffer_to_image_3d;__cl_fill_region_unalign;__cl_fill_region_align2;__cl_fill_region_align4;__cl_fill_region_align8_2;__cl_fill_region_align8_4;__cl_fill_region_align8_8;__cl_fill_region_align8_16;__cl_fill_region_align128;__cl_fill_image_1d;__cl_fill_image_1d_array;__cl_fill_image_2d;__cl_fill_image_2d_array;__cl_fill_image_3d;
  Device Available                                Yes
  Compiler Available                              Yes
  Linker Available                                Yes
  Device Extensions                               cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_spir cl_khr_icd cl_intel_accelerator cl_intel_subgroups cl_intel_subgroups_short cl_khr_gl_sharing

NULL platform behavior
  clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  Intel Gen OCL Driver
  clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   Success [Intel]
  clCreateContext(NULL, ...) [default]            Success [Intel]
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU)  Success (1)
    Platform Name                                 Intel Gen OCL Driver
    Device Name                                   Intel(R) HD Graphics Haswell GT2 Desktop
  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                                 Intel Gen OCL Driver
    Device Name                                   Intel(R) HD Graphics Haswell GT2 Desktop

ICD loader properties
  ICD loader Name                                 OpenCL ICD Loader
  ICD loader Vendor                               OCL Icd free software
  ICD loader Version                              2.2.11
  ICD loader Profile                              OpenCL 2.1

Go to forum: Using SVP