compute-runtime

compute-runtime copied to clipboard

Immediate Command Lists - Event Query

[]

I have the following simple test case: ``` #include #include // Simple time-consuming kernel without arguments __global__ void slowKernel() { float val = 0.0f; for (int i = 0; i...

pvelesko

Cannot detect a NEO-supported device if there is another non-NEO-supported Intel device on the system

[{"_id":"66c4b63fd340b986da0d02d5","body":"Also, perhaps issue #663 is related?","issue_id":1708607650176,"origin_id":1653426767,"user_origin_id":6310153,"create_time":1690457239,"update_time":1690457239,"id":1724167743342,"updated_at":"2024-08-20T15:29:03.341000Z","created_at":"2024-08-20T15:29:03.341000Z"},{"_id":"66c4b63fd340b986da0d02d6","body":"hi @agrn \r\ncould you please share strace log ? ","issue_id":1708607650176,"origin_id":1653440824,"user_origin_id":36925973,"create_time":1690457842,"update_time":1690457842,"id":1724167743345,"updated_at":"2024-08-20T15:29:03.345000Z","created_at":"2024-08-20T15:29:03.345000Z"},{"_id":"66c4b63fd340b986da0d02d7","body":"Sorry for the late answer.\r\n\r\nHere is the log of `strace` with the iGPU enabled: [clinfo-a770-hd4600.txt](https:\/\/github.com\/intel\/compute-runtime\/files\/12187483\/clinfo-a770-hd4600.txt)\r\n\r\n(Sorry for the `openat()` noise, that's a side-effect of NixOS\u2026)\r\n\r\n`libigdrcl.so` is opened on line 70, and I believe the actual operation of the ICD begins around line 170. Both peripherals are opened on line 237 and 239. There is more `ioctl()`s than I remembered, though. At the end, you can see that there is no listing of OpenCL capabilities (ie. no platform were reported).\r\n\r\nFor contrast, here is the log of `strace` with the iGPU disabled: [clinfo-a770-only.txt](https:\/\/github.com\/intel\/compute-runtime\/files\/12187519\/clinfo-a770-only.txt) \r\n\r\nYou can see `libigdrcl.so` opened on line 70. A single device is opened this time, still on line 237.\r\n\r\nBetween these two runs, I only changed the iGPU setting in the system firmware.","issue_id":1708607650176,"origin_id":1654400154,"user_origin_id":6310153,"create_time":1690485943,"update_time":1690486161,"id":1724167743349,"updated_at":"2024-08-20T15:29:03.348000Z","created_at":"2024-08-20T15:29:03.348000Z"},{"_id":"66c4b63fd340b986da0d02d8","body":"@agrn could you verify if the issue is visible on most recent release?\r\n\r\nIt should be fixed in f63dd1f4f2648f8becdbc0fbdf455379b5810ee5 ","issue_id":1708607650176,"origin_id":1985294281,"user_origin_id":36925973,"create_time":1709887935,"update_time":1709887935,"id":1724167743354,"updated_at":"2024-08-20T15:29:03.353000Z","created_at":"2024-08-20T15:29:03.353000Z"},{"_id":"66c4b63fd340b986da0d02d9","body":"Hi, I'm afraid I no longer have this system, and hence cannot test this change for now.","issue_id":1708607650176,"origin_id":2002410158,"user_origin_id":6310153,"create_time":1710673547,"update_time":1710673547,"id":1724167743358,"updated_at":"2024-08-20T15:29:03.357000Z","created_at":"2024-08-20T15:29:03.357000Z"}]

Hi, I have a pretty peculiar system, with an i5-4690k and its associated iGPU (HD Graphics 4600), and an Arc A770. The iGPU is not supported by the NEO driver...

agrn

`ocloc` fails to compile SYCL kernels with an unsupported subgroup size

[{"_id":"66c4b62118409968dc0b6156","body":"@auroraperego FYI","issue_id":1708607650181,"origin_id":1646579913,"user_origin_id":4069793,"create_time":1690031014,"update_time":1690031014,"id":1724167713099,"updated_at":"2024-08-20T15:28:33.098000Z","created_at":"2024-08-20T15:28:33.098000Z"},{"_id":"66c4b62118409968dc0b6157","body":"@igorvorobtsov FYI","issue_id":1708607650181,"origin_id":1646581033,"user_origin_id":4069793,"create_time":1690031346,"update_time":1690031346,"id":1724167713104,"updated_at":"2024-08-20T15:28:33.103000Z","created_at":"2024-08-20T15:28:33.103000Z"},{"_id":"66c4b62118409968dc0b6158","body":"Hi Andrea,\r\nI believe this should be implemented on the SYCL runtime side and not on compute runtime (or probably both). I will escalate this.","issue_id":1708607650181,"origin_id":1647771447,"user_origin_id":101756871,"create_time":1690199950,"update_time":1690203778,"id":1724167713108,"updated_at":"2024-08-20T15:28:33.108000Z","created_at":"2024-08-20T15:28:33.108000Z"},{"_id":"66c4b62118409968dc0b6159","body":"This is indeed a SYCL toolchain problem and I think that this issue can be closed","issue_id":1708607650181,"origin_id":2249804703,"user_origin_id":6417047,"create_time":1721897324,"update_time":1721897324,"id":1724167713115,"updated_at":"2024-08-20T15:28:33.115000Z","created_at":"2024-08-20T15:28:33.115000Z"}]

According to the [latest SYCL 2020 specification](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html): > ## [5.7. Optional kernel features](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:optional-kernel-features) > > A number of kernel features defined by this SYCL specification are optional; they may be...

fwyzard

clinfo on WSL2 using A770 causes BSOD

[{"_id":"66c4b62665e3f042b8062dcb","body":"Hi @maleadt could you please ensure that if you remove intel.icd from `\/etc\/OpenCL\/vendors` in the WSL and run `clinfo`, then there is no BSOD? I would like to confirm that the BSOD is related to our package ","issue_id":1708607650186,"origin_id":1643836299,"user_origin_id":36925973,"create_time":1689856071,"update_time":1689856071,"id":1724167718958,"updated_at":"2024-08-20T15:28:38.958000Z","created_at":"2024-08-20T15:28:38.958000Z"},{"_id":"66c4b62665e3f042b8062dcc","body":"Yes, when I hadn't installed an Intel ICD (i.e. before installing any of the compute-runtime packages) `clinfo` just returned `0 platforms`.","issue_id":1708607650186,"origin_id":1643856133,"user_origin_id":383068,"create_time":1689856915,"update_time":1689856915,"id":1724167718962,"updated_at":"2024-08-20T15:28:38.962000Z","created_at":"2024-08-20T15:28:38.962000Z"},{"_id":"66c4b62665e3f042b8062dcd","body":"Thanks for confirmation.\r\n\r\n> freshly set-up WSL2 Ubuntu \r\n\r\nwhich Ubuntu version? ","issue_id":1708607650186,"origin_id":1643891672,"user_origin_id":36925973,"create_time":1689858292,"update_time":1689858292,"id":1724167718966,"updated_at":"2024-08-20T15:28:38.966000Z","created_at":"2024-08-20T15:28:38.966000Z"},{"_id":"66c4b62665e3f042b8062dce","body":"> which Ubuntu version?\r\n\r\nThe one Microsoft defaults to, which seems to be 22.04 (all packages fully updated).","issue_id":1708607650186,"origin_id":1643939442,"user_origin_id":383068,"create_time":1689860125,"update_time":1689860125,"id":1724167718970,"updated_at":"2024-08-20T15:28:38.969000Z","created_at":"2024-08-20T15:28:38.969000Z"},{"_id":"66c4b62665e3f042b8062dcf","body":"Do you mean that there's **Windows** kernel BSOD when trivial operations are done with Linux user-space compute stack under WSL? (Does not really sound like compute-runtime problem)\r\n","issue_id":1708607650186,"origin_id":1969612769,"user_origin_id":4669102,"create_time":1709145787,"update_time":1709145787,"id":1724167718972,"updated_at":"2024-08-20T15:28:38.972000Z","created_at":"2024-08-20T15:28:38.972000Z"},{"_id":"66c4b62665e3f042b8062dd0","body":"> Do you mean that there's **Windows** kernel BSOD when trivial operations are done with Linux user-space compute stack under WSL?\r\n\r\nCorrect. ","issue_id":1708607650186,"origin_id":1969669799,"user_origin_id":383068,"create_time":1709147388,"update_time":1709147388,"id":1724167718975,"updated_at":"2024-08-20T15:28:38.975000Z","created_at":"2024-08-20T15:28:38.975000Z"},{"_id":"66c4b62665e3f042b8062dd1","body":"Unless you're using PCI passthrough for the device, and mention of \"dgx\" (directX) is just co-incidence, I do not see how this could be Linux side compute-runtime problem, rather than Windows driver issue. Have you reported the issue to Windows side?\r\n\r\nVirtual machine using virtualized host drivers should not be able to BSOD the host...","issue_id":1708607650186,"origin_id":1969688151,"user_origin_id":4669102,"create_time":1709148158,"update_time":1709148158,"id":1724167718978,"updated_at":"2024-08-20T15:28:38.977000Z","created_at":"2024-08-20T15:28:38.977000Z"},{"_id":"66c4b62665e3f042b8062dd2","body":"After recently updating both NEO\/IGC, this issue doesn't occur anymore. Sadly, the native Intel GPU driver was updated too, so it's impossible to tell which updated fixed the issue... Anyway, I'm glad it got fixed, so this can be closed.","issue_id":1708607650186,"origin_id":1988738578,"user_origin_id":383068,"create_time":1710171479,"update_time":1710171479,"id":1724167718981,"updated_at":"2024-08-20T15:28:38.980000Z","created_at":"2024-08-20T15:28:38.980000Z"},{"_id":"66c4b62665e3f042b8062dd3","body":"Thanks for testing, reporting the results here!","issue_id":1708607650186,"origin_id":1988783254,"user_origin_id":4669102,"create_time":1710172637,"update_time":1710172637,"id":1724167718984,"updated_at":"2024-08-20T15:28:38.983000Z","created_at":"2024-08-20T15:28:38.983000Z"}]

I'm using the following set-up: - Windows 10 22H2 (also tested 22H1) - 64-bit x86 (i5-6600K) with an Arc A770 (ReBAR not enabled/supported on this system, but Above 4G decoding...

maleadt

clinfo crashes in intel-compute-runtime

[{"_id":"66c4b60ea5570c2d15033446","body":"please share strace log and igc library versions ","issue_id":1708607650191,"origin_id":1617636203,"user_origin_id":36925973,"create_time":1688373564,"update_time":1688373564,"id":1724167694374,"updated_at":"2024-08-20T15:28:14.374000Z","created_at":"2024-08-20T15:28:14.374000Z"},{"_id":"66c4b60ea5570c2d15033447","body":"strace log\r\n[clinfo.txt](https:\/\/github.com\/intel\/compute-runtime\/files\/11938273\/clinfo.txt)\r\n\r\nlibsigc++ v2.12.0-1.1","issue_id":1708607650191,"origin_id":1618655924,"user_origin_id":8528033,"create_time":1688398044,"update_time":1688398044,"id":1724167694378,"updated_at":"2024-08-20T15:28:14.378000Z","created_at":"2024-08-20T15:28:14.378000Z"},{"_id":"66c4b60ea5570c2d15033448","body":"> please share strace log and igc library versions\r\n\r\nIGC meaning Intel Graphics Compiler https:\/\/github.com\/intel\/intel-graphics-compiler \r\nEach of our releases on GitHub has a reference to release of IGC, there should be installed the referenced version ","issue_id":1708607650191,"origin_id":1621097980,"user_origin_id":36925973,"create_time":1688537918,"update_time":1688537918,"id":1724167694382,"updated_at":"2024-08-20T15:28:14.382000Z","created_at":"2024-08-20T15:28:14.382000Z"},{"_id":"66c4b60ea5570c2d15033449","body":"intel-graphics-compiler\r\n1:1.0.13822.6-1.1\r\n\r\nfrom ALHP x86-64-v3 repo","issue_id":1708607650191,"origin_id":1621958738,"user_origin_id":8528033,"create_time":1688569790,"update_time":1688569790,"id":1724167694387,"updated_at":"2024-08-20T15:28:14.386000Z","created_at":"2024-08-20T15:28:14.386000Z"},{"_id":"66c4b60ea5570c2d1503344a","body":"please run\r\n`ldd \/usr\/lib\/libigdfcl.so.1`\r\n`ldd \/usr\/lib\/libigc.so.1`","issue_id":1708607650191,"origin_id":1624910948,"user_origin_id":36925973,"create_time":1688715448,"update_time":1688715448,"id":1724167694390,"updated_at":"2024-08-20T15:28:14.390000Z","created_at":"2024-08-20T15:28:14.390000Z"},{"_id":"66c4b60ea5570c2d1503344b","body":"```\r\nldd \/usr\/lib\/libigdfcl.so.1\r\n\r\nlinux-vdso.so.1 (0x00007ffdd13ef000)\r\nliblldELF.so.15 => \/usr\/lib\/liblldELF.so.15 (0x00007fd98f400000)\r\nlibopencl-clang.so.15 => \/usr\/lib\/libopencl-clang.so.15 (0x00007fd98f303000)\r\nliblldCommon.so.15 => \/usr\/lib\/liblldCommon.so.15 (0x00007fd98f6ce000)\r\nlibLLVM-15.so => \/usr\/lib\/libLLVM-15.so (0x00007fd987800000)\r\nlibstdc++.so.6 => \/usr\/lib\/libstdc++.so.6 (0x00007fd987400000)\r\nlibgcc_s.so.1 => \/usr\/lib\/libgcc_s.so.1 (0x00007fd98f2de000)\r\nlibc.so.6 => \/usr\/lib\/libc.so.6 (0x00007fd987000000)\r\nlibz.so.1 => \/usr\/lib\/libz.so.1 (0x00007fd98f2be000)\r\n\/usr\/lib64\/ld-linux-x86-64.so.2 (0x00007fd98f7ee000)\r\nlibLLVMSPIRVLib.so.15 => \/usr\/lib\/..\/lib\/libLLVMSPIRVLib.so.15 (0x00007fd986c00000)\r\nlibclang-cpp.so.15 => \/usr\/lib\/..\/lib\/libclang-cpp.so.15 (0x00007fd983a00000)\r\nlibffi.so.8 => \/usr\/lib\/libffi.so.8 (0x00007fd98f2b1000)\r\nlibedit.so.0 => \/usr\/lib\/libedit.so.0 (0x00007fd98f269000)\r\nlibzstd.so.1 => \/usr\/lib\/libzstd.so.1 (0x00007fd9876f6000)\r\nlibncursesw.so.6 => \/usr\/lib\/libncursesw.so.6 (0x00007fd98767d000)\r\nlibxml2.so.2 => \/usr\/lib\/libxml2.so.2 (0x00007fd987275000)\r\nlibm.so.6 => \/usr\/lib\/libm.so.6 (0x00007fd98390e000)\r\nliblzma.so.5 => \/usr\/lib\/liblzma.so.5 (0x00007fd987237000)\r\nlibicuuc.so.73 => \/usr\/lib\/libicuuc.so.73 (0x00007fd983600000)\r\nlibicudata.so.73 => \/usr\/lib\/libicudata.so.73 (0x00007fd981600000)\r\n\r\n\r\nldd \/usr\/lib\/libigc.so.1\r\n\r\nlinux-vdso.so.1 (0x00007ffec81be000)\r\nlibSPIRV-Tools.so => \/usr\/lib\/libSPIRV-Tools.so (0x00007fa4d67d8000)\r\nliblldELF.so.15 => \/usr\/lib\/liblldELF.so.15 (0x00007fa4d3e00000)\r\nlibLLVMSPIRVLib.so.15 => \/usr\/lib\/libLLVMSPIRVLib.so.15 (0x00007fa4d3a00000)\r\nliblldCommon.so.15 => \/usr\/lib\/liblldCommon.so.15 (0x00007fa4d41c9000)\r\nlibLLVM-15.so => \/usr\/lib\/libLLVM-15.so (0x00007fa4cbe00000)\r\nlibstdc++.so.6 => \/usr\/lib\/libstdc++.so.6 (0x00007fa4cba00000)\r\nlibm.so.6 => \/usr\/lib\/libm.so.6 (0x00007fa4d40d7000)\r\nlibgcc_s.so.1 => \/usr\/lib\/libgcc_s.so.1 (0x00007fa4d3ddb000)\r\nlibc.so.6 => \/usr\/lib\/libc.so.6 (0x00007fa4cb600000)\r\n\/usr\/lib64\/ld-linux-x86-64.so.2 (0x00007fa4d6984000)\r\nlibz.so.1 => \/usr\/lib\/libz.so.1 (0x00007fa4d67b6000)\r\nlibffi.so.8 => \/usr\/lib\/libffi.so.8 (0x00007fa4d3dce000)\r\nlibedit.so.0 => \/usr\/lib\/libedit.so.0 (0x00007fa4d39ba000)\r\nlibzstd.so.1 => \/usr\/lib\/libzstd.so.1 (0x00007fa4d38b0000)\r\nlibncursesw.so.6 => \/usr\/lib\/libncursesw.so.6 (0x00007fa4cbd87000)\r\nlibxml2.so.2 => \/usr\/lib\/libxml2.so.2 (0x00007fa4cb875000)\r\nliblzma.so.5 => \/usr\/lib\/liblzma.so.5 (0x00007fa4d3d90000)\r\nlibicuuc.so.73 => \/usr\/lib\/libicuuc.so.73 (0x00007fa4cb200000)\r\nlibicudata.so.73 => \/usr\/lib\/libicudata.so.73 (0x00007fa4c9200000)\r\n```","issue_id":1708607650191,"origin_id":1626007078,"user_origin_id":8528033,"create_time":1688760339,"update_time":1688760339,"id":1724167694394,"updated_at":"2024-08-20T15:28:14.394000Z","created_at":"2024-08-20T15:28:14.394000Z"},{"_id":"66c4b60ea5570c2d1503344c","body":"please adjust igc packages to neo packages. You have IGC packages from reference of release WW17, while neo packages from release WW09. \r\nPlease update neo to WW17 release or downgrade IGC to reference of WW09 release (1.0.13463.18)","issue_id":1708607650191,"origin_id":1628568040,"user_origin_id":36925973,"create_time":1688980774,"update_time":1688980784,"id":1724167694398,"updated_at":"2024-08-20T15:28:14.397000Z","created_at":"2024-08-20T15:28:14.397000Z"},{"_id":"66c4b60ea5570c2d1503344d","body":"What are Neo packages? What is WW17?\r\n\r\n\r\n`sudo downgrade intel-graphics-compiler` 1.0.13463.18\r\n\r\n```\r\nclinfo\r\nAbort was called at 37 line in file:\r\n\/usr\/src\/debug\/intel-compute-runtime\/compute-runtime-23.17.26241.22\/shared\/source\/built_ins\/built_ins.cpp\r\nfish: Job 1, 'clinfo' terminated by signal SIGABRT (Abort)\r\n```\r\n\r\n```\r\nldd \/usr\/lib\/libigdfcl.so.1\r\nlinux-vdso.so.1 (0x00007fffe67c9000)\r\nliblldELF.so.15 => \/usr\/lib\/liblldELF.so.15 (0x00007fe3df000000)\r\nlibopencl-clang.so.15 => \/usr\/lib\/libopencl-clang.so.15 (0x00007fe3df304000)\r\nliblldCommon.so.15 => \/usr\/lib\/liblldCommon.so.15 (0x00007fe3df2cd000)\r\nlibLLVM-15.so => \/usr\/lib\/libLLVM-15.so (0x00007fe3d7400000)\r\nlibstdc++.so.6 => \/usr\/lib\/libstdc++.so.6 (0x00007fe3d7000000)\r\nlibgcc_s.so.1 => \/usr\/lib\/libgcc_s.so.1 (0x00007fe3defdb000)\r\nlibc.so.6 => \/usr\/lib\/libc.so.6 (0x00007fe3d6c00000)\r\nlibz.so.1 => \/usr\/lib\/libz.so.1 (0x00007fe3defbb000)\r\n\/usr\/lib64\/ld-linux-x86-64.so.2 (0x00007fe3df4e8000)\r\nlibLLVMSPIRVLib.so.15 => \/usr\/lib\/..\/lib\/libLLVMSPIRVLib.so.15 (0x00007fe3d6800000)\r\nlibclang-cpp.so.15 => \/usr\/lib\/..\/lib\/libclang-cpp.so.15 (0x00007fe3d3600000)\r\nlibffi.so.8 => \/usr\/lib\/libffi.so.8 (0x00007fe3defae000)\r\nlibedit.so.0 => \/usr\/lib\/libedit.so.0 (0x00007fe3def66000)\r\nlibzstd.so.1 => \/usr\/lib\/libzstd.so.1 (0x00007fe3dee5c000)\r\nlibncursesw.so.6 => \/usr\/lib\/libncursesw.so.6 (0x00007fe3d7387000)\r\nlibxml2.so.2 => \/usr\/lib\/libxml2.so.2 (0x00007fe3d6e72000)\r\nlibm.so.6 => \/usr\/lib\/libm.so.6 (0x00007fe3d7295000)\r\nliblzma.so.5 => \/usr\/lib\/liblzma.so.5 (0x00007fe3d6e34000)\r\nlibicuuc.so.73 => \/usr\/lib\/libicuuc.so.73 (0x00007fe3d3200000)\r\nlibicudata.so.73 => \/usr\/lib\/libicudata.so.73 (0x00007fe3d1200000)\r\n\r\n\r\nldd \/usr\/lib\/libigc.so.1\r\nlinux-vdso.so.1 (0x00007fff075f1000)\r\nlibSPIRV-Tools.so => \/usr\/lib\/libSPIRV-Tools.so (0x00007f38ca292000)\r\nliblldELF.so.15 => \/usr\/lib\/liblldELF.so.15 (0x00007f38c9e00000)\r\nlibLLVMSPIRVLib.so.15 => \/usr\/lib\/libLLVMSPIRVLib.so.15 (0x00007f38c9a00000)\r\nliblldCommon.so.15 => \/usr\/lib\/liblldCommon.so.15 (0x00007f38ccace000)\r\nlibLLVM-15.so => \/usr\/lib\/libLLVM-15.so (0x00007f38c1e00000)\r\nlibstdc++.so.6 => \/usr\/lib\/libstdc++.so.6 (0x00007f38c1a00000)\r\nlibm.so.6 => \/usr\/lib\/libm.so.6 (0x00007f38ca1a0000)\r\nlibgcc_s.so.1 => \/usr\/lib\/libgcc_s.so.1 (0x00007f38ccaa7000)\r\nlibc.so.6 => \/usr\/lib\/libc.so.6 (0x00007f38c1600000)\r\n\/usr\/lib64\/ld-linux-x86-64.so.2 (0x00007f38ccb42000)\r\nlibz.so.1 => \/usr\/lib\/libz.so.1 (0x00007f38cca87000)\r\nlibffi.so.8 => \/usr\/lib\/libffi.so.8 (0x00007f38cca7a000)\r\nlibedit.so.0 => \/usr\/lib\/libedit.so.0 (0x00007f38cca34000)\r\nlibzstd.so.1 => \/usr\/lib\/libzstd.so.1 (0x00007f38c98f6000)\r\nlibncursesw.so.6 => \/usr\/lib\/libncursesw.so.6 (0x00007f38ca127000)\r\nlibxml2.so.2 => \/usr\/lib\/libxml2.so.2 (0x00007f38c1872000)\r\nliblzma.so.5 => \/usr\/lib\/liblzma.so.5 (0x00007f38ca0e9000)\r\nlibicuuc.so.73 => \/usr\/lib\/libicuuc.so.73 (0x00007f38c1200000)\r\nlibicudata.so.73 => \/usr\/lib\/libicudata.so.73 (0x00007f38bf200000)\r\n```","issue_id":1708607650191,"origin_id":1632928965,"user_origin_id":8528033,"create_time":1689182790,"update_time":1689182790,"id":1724167694402,"updated_at":"2024-08-20T15:28:14.401000Z","created_at":"2024-08-20T15:28:14.401000Z"},{"_id":"66c4b60ea5570c2d1503344e","body":"I mean it looks like you are mixing packages from two different releases. \r\n\r\nWW09 (work week 9 of 2023 year) release https:\/\/github.com\/intel\/compute-runtime\/releases\/tag\/23.09.25812.14 contains NEO in version 23.09.25812.14 and IGC in version 1.0.13463.18 \r\n\r\nWW17 release https:\/\/github.com\/intel\/compute-runtime\/releases\/tag\/23.17.26241.22 contains NEO in version 23.17.26241.22 and IGC in version 1.0.13822.6\r\n\r\nWe cannot guarantee that NEO in version 23.09.25812.14 works with IGC in version 1.0.13822.6 or NEO in version 23.17.26241.22 works with IGC in version 1.0.13463.18 \r\n\r\nPlease ensure you are using corresponding version of NEO and IGC.\r\nFor other releases please find more details here: https:\/\/github.com\/intel\/compute-runtime\/releases ","issue_id":1708607650191,"origin_id":1633822345,"user_origin_id":36925973,"create_time":1689237876,"update_time":1689237876,"id":1724167694406,"updated_at":"2024-08-20T15:28:14.406000Z","created_at":"2024-08-20T15:28:14.406000Z"},{"_id":"66c4b60ea5570c2d1503344f","body":"What does NEO stand for?\r\n\r\nSo is this a packaging issue from the Linux distribution side? I'm curious why I seem to be the only one having that issue then.","issue_id":1708607650191,"origin_id":1634385186,"user_origin_id":8528033,"create_time":1689259841,"update_time":1689259841,"id":1724167694410,"updated_at":"2024-08-20T15:28:14.409000Z","created_at":"2024-08-20T15:28:14.409000Z"},{"_id":"66c4b60ea5570c2d15033450","body":"NEO seems to stand for `intel-compute-runtime`. Why is it called NEO?\r\n\r\nRan a system update.\r\n\r\nintel-compute-runtime: 23.17.26241.22-1.1\r\nintel-graphics-compiler: 1:1.0.13822.6-1.1\r\n\r\nThat corresponds to the numbers in the release page. Not seeing any issue here.","issue_id":1708607650191,"origin_id":1634413362,"user_origin_id":8528033,"create_time":1689260775,"update_time":1689260775,"id":1724167694413,"updated_at":"2024-08-20T15:28:14.412000Z","created_at":"2024-08-20T15:28:14.412000Z"},{"_id":"66c4b60ea5570c2d15033451","body":"If I uninstall those packages, `clinfo` works, and I can use OpenCL on my NVidia again. Not the ideal solution though.","issue_id":1708607650191,"origin_id":1634459220,"user_origin_id":8528033,"create_time":1689262441,"update_time":1689262441,"id":1724167694415,"updated_at":"2024-08-20T15:28:14.415000Z","created_at":"2024-08-20T15:28:14.415000Z"},{"_id":"66c4b60ea5570c2d15033452","body":"> What does NEO stand for?\r\n\r\nhttps:\/\/github.com\/intel\/compute-runtime#what-is-neo \r\n\r\n> So is this a packaging issue from the Linux distribution side? I'm curious why I seem to be the only one having that issue then.\r\n\r\nour package has a dependency on IGC package and it should be marked as required. Have you installed all packages from distro or you built something from source? \r\n\r\nPlease try below experiments:\r\n1. install below packages and run `clinfo`\r\n a. intel-compute-runtime: 23.09.25812.14-1.1\r\n b. intel-graphics-compiler: 1:1.0.13822.6-1.1\r\n2. install below packages and run `clinfo`\r\n a. intel-compute-runtime: 23.17.26241.22-1.1\r\n b. intel-graphics-compiler: 1:1.0.13463.18-1.1\r\n\r\n","issue_id":1708607650191,"origin_id":1635656073,"user_origin_id":36925973,"create_time":1689330517,"update_time":1689330517,"id":1724167694419,"updated_at":"2024-08-20T15:28:14.418000Z","created_at":"2024-08-20T15:28:14.418000Z"},{"_id":"66c4b60ea5570c2d15033453","body":"In both cases it crashes.\r\n\r\nI'm only installing from distro repos.","issue_id":1708607650191,"origin_id":1636144031,"user_origin_id":8528033,"create_time":1689354643,"update_time":1689354643,"id":1724167694425,"updated_at":"2024-08-20T15:28:14.425000Z","created_at":"2024-08-20T15:28:14.425000Z"},{"_id":"66c4b60ea5570c2d15033454","body":"I have another problem with the laptop, and now I'm starting to think it may be related. There was a overlapping logging screen issue; but if I unplug the TV, I realize the problem is worse than that. The internal display is detected completely wrong.\r\n\r\nInternal display is 1080p 144hz\r\n\r\nOutput of `xrandr`\r\n\r\n```\r\nScreen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767\r\nDP-0 disconnected (normal left inverted right x axis y axis)\r\nDP-1 disconnected (normal left inverted right x axis y axis)\r\nHDMI-0 disconnected (normal left inverted right x axis y axis)\r\neDP-1-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm\r\n15360x8640 15.83 28.85\r\n7680x4320 15.83 59.99 59.99 59.99\r\n5120x2880 59.99 59.99\r\n4096x2304 59.99 59.98\r\n3840x2160 60.00 60.01 59.98 59.97\r\n3200x1800 59.96 59.94\r\n2880x1620 59.96 59.97\r\n2560x1600 59.99 59.97\r\n2560x1440 59.99 59.99 59.96 59.95\r\n2048x1536 60.00\r\n1920x1440 60.00\r\n1856x1392 60.01\r\n1792x1344 60.01\r\n2048x1152 59.99 59.98 59.90 59.91\r\n1920x1200 59.88 59.95\r\n1920x1080 60.01* 59.97 59.96 59.93\r\n1600x1200 60.00\r\n1680x1050 59.95 59.88\r\n1400x1050 59.98\r\n1600x900 59.99 59.94 59.95 59.82\r\n1280x1024 60.02\r\n1400x900 59.96 59.88\r\n1280x960 60.00\r\n1440x810 60.00 59.97\r\n1368x768 59.88 59.85\r\n1280x800 59.99 59.97 59.81 59.91\r\n1280x720 60.00 59.99 59.86 59.74\r\n1024x768 60.04 60.00\r\n960x720 60.00\r\n928x696 60.05\r\n896x672 60.01\r\n1024x576 59.95 59.96 59.90 59.82\r\n960x600 59.93 60.00\r\n960x540 59.96 59.99 59.63 59.82\r\n800x600 60.00 60.32 56.25\r\n840x525 60.01 59.88\r\n864x486 59.92 59.57\r\n700x525 59.98\r\n800x450 59.95 59.82\r\n640x512 60.02\r\n700x450 59.96 59.88\r\n640x480 60.00 59.94\r\n720x405 59.51 58.99\r\n684x384 59.88 59.85\r\n640x400 59.88 59.98\r\n640x360 59.86 59.83 59.84 59.32\r\n512x384 60.00\r\n512x288 60.00 59.92\r\n480x270 59.63 59.82\r\n400x300 60.32 56.34\r\n432x243 59.92 59.57\r\n320x240 60.05\r\n360x202 59.51 59.13\r\n320x180 59.84 59.32\r\nHDMI-1-1 disconnected (normal left inverted right x axis y axis)\r\n```\r\n\r\nIt seems something is totally wrong with the Intel display driver. It's possible that it causes the OpenCL problem too. Anything comes to your mind?","issue_id":1708607650191,"origin_id":1636968050,"user_origin_id":8528033,"create_time":1689476863,"update_time":1689476863,"id":1724167694436,"updated_at":"2024-08-20T15:28:14.435000Z","created_at":"2024-08-20T15:28:14.435000Z"},{"_id":"66c4b60ea5570c2d15033455","body":"> In both cases it crashes.\r\n> \r\n> I'm only installing from distro repos.\r\n\r\ndoes it crash in the same place? \r\nAbort was called at 36 line in file:\r\nshared\/source\/built_ins\/built_ins.cpp\r\n\r\nwhen upgrading\/downgrading igc do you change both libigc and libigdfcl packages ? ","issue_id":1708607650191,"origin_id":1637475839,"user_origin_id":36925973,"create_time":1689576788,"update_time":1689576788,"id":1724167694445,"updated_at":"2024-08-20T15:28:14.445000Z","created_at":"2024-08-20T15:28:14.445000Z"},{"_id":"66c4b60ea5570c2d15033456","body":"> \r\n\r\nthere is no explicit connection between OpenCL and display on Linux. OpenCL issue looks like misconfigured dependencies while the display issue if it is related to Intel device then I would recommend checking i915 ","issue_id":1708607650191,"origin_id":1637479535,"user_origin_id":36925973,"create_time":1689577003,"update_time":1689577003,"id":1724167694452,"updated_at":"2024-08-20T15:28:14.452000Z","created_at":"2024-08-20T15:28:14.452000Z"},{"_id":"66c4b60ea5570c2d15033457","body":"With the other version it crashes at line 37 instead of 36.\r\n\r\nWhat is i915? There is no i915 package installed. AFAIK Intel drivers are managed by the kernel.","issue_id":1708607650191,"origin_id":1638397055,"user_origin_id":8528033,"create_time":1689608386,"update_time":1689608386,"id":1724167694460,"updated_at":"2024-08-20T15:28:14.460000Z","created_at":"2024-08-20T15:28:14.460000Z"},{"_id":"66c4b60ea5570c2d15033458","body":"Removed [ALHP](https:\/\/somegit.dev\/ALHP\/ALHP.GO) packages and it fixed the Intel OpenCL issue.\r\n\r\nThe other display problem remains, so is unrelated.\r\n\r\nThis means it's either an ALHP packaging issue, or a v3 compilation issue.\r\n\r\nIndeed, re-installing ALHP packages and the problem came back. You can reproduce it by installing those v3-compiled packages.","issue_id":1708607650191,"origin_id":1639098044,"user_origin_id":8528033,"create_time":1689640453,"update_time":1689645118,"id":1724167694468,"updated_at":"2024-08-20T15:28:14.468000Z","created_at":"2024-08-20T15:28:14.468000Z"}]

`clinfo` on Linux returns this error ``` Abort was called at 36 line in file: /usr/src/debug/intel-compute-runtime/compute-runtime-23.09.25812.14/shared/source/built_ins/built_ins.cpp fish: Job 1, 'clinfo' terminated by signal SIGABRT (Abort) ``` OS: Garuda Linux (arch-based)...

mysteryx93

Feature request: Add support for using OCLOC compilation cache in repeated AOT compilation passes

[]

OCLOC already supports writing its cache to a user-specified directory but I'm not too sure what this is used for when using AOT compilation (in the JIT case, it's clearer...

mirenradia

Appending a dependency event which is to be signalled from the host causes hangs

[{"_id":"66c4b64fa5570c2d15033481","body":"Driver version 23.17.26241.22\r\ntested on\r\n Intel HD 770\r\nIntel(R) Arc(TM) A380 Graphics","issue_id":1708607650199,"origin_id":1616578960,"user_origin_id":8687809,"create_time":1688293181,"update_time":1688293181,"id":1724167759268,"updated_at":"2024-08-20T15:29:19.268000Z","created_at":"2024-08-20T15:29:19.268000Z"},{"_id":"66c4b64fa5570c2d15033482","body":"@pvelesko,\r\n\r\nI looked into the sample (callback.zip) attached here. It looks like there is programming error because of which code is getting into dead lock hence the hang. I have corrected the code in main.cpp file and test passed with immediate command list as well.\r\n\r\nImmediate command list tries to complete the dispatch immediatly but in the attached sample it has a wait event hence dispatch call waits for event to complete but event signal call has been kept after it hence dispatch never completes which shows as hang. When I moved launch to separate thread test passed. See the code change below\r\n\r\n```\r\n L1 \/\/ Launch kernel on the GPU\r\n L2 std::cout << \"Launching kernel\\n\";\r\n\r\n L3 \/\/ Launching kernel using worker thread\r\n L4 \/\/ In case of immediate command list it is required to be on other thread else it will deadlock \r\n L5 std::thread kernel_launch(kernel_func, cmdList, kernel, &dispatch, Event, 1, &HostSignalEvent);\r\n\r\n L6 \/\/ZE_CHECK(zeCommandListAppendLaunchKernel(cmdList, kernel, &dispatch,\r\n L7 \/\/ Event, 0, nullptr)); \/\/1, &HostSignalEvent));\r\n L8 std::cout << \"Host Signal Blocking Event\\n\";\r\n L9 ZE_CHECK(zeEventHostSignal(HostSignalEvent)); \r\n\r\n L10 auto begin = std::chrono::steady_clock::now();\r\n L11 kernel_launch.join();\r\n```\r\n\r\nL5 where I am launching the kernel in other thread where it will be waiting for event to finish. L9 signals the event which helps kernel_launch to complete.\r\n\r\nLet me know if you have any further questions.\r\n","issue_id":1708607650199,"origin_id":1628309071,"user_origin_id":52556743,"create_time":1688969878,"update_time":1688969878,"id":1724167759274,"updated_at":"2024-08-20T15:29:19.273000Z","created_at":"2024-08-20T15:29:19.273000Z"},{"_id":"66c4b64fa5570c2d15033483","body":"```\r\n cmdQueueDesc.mode = ZE_COMMAND_QUEUE_MODE_ASYNCHRONOUS;\r\n```\r\n\r\n```\r\nenumerator ZE_COMMAND_QUEUE_MODE_ASYNCHRONOUS\r\nDevice execution is scheduled and will complete in future; explicit synchronization object must be used to determine completeness\r\n```\r\n\r\nsubmitting things to an async command queue should not be blocking operations. ","issue_id":1708607650199,"origin_id":1628326947,"user_origin_id":8687809,"create_time":1688970833,"update_time":1688970833,"id":1724167759277,"updated_at":"2024-08-20T15:29:19.277000Z","created_at":"2024-08-20T15:29:19.277000Z"},{"_id":"66c4b64fa5570c2d15033484","body":"https:\/\/spec.oneapi.io\/level-zero\/latest\/core\/PROG.html#low-latency-immediate-command-lists: \"Commands appended into an immediate command list may execute synchronously, by blocking until the command is complete.\"","issue_id":1708607650199,"origin_id":1628691808,"user_origin_id":1652632,"create_time":1688985805,"update_time":1688985805,"id":1724167759281,"updated_at":"2024-08-20T15:29:19.281000Z","created_at":"2024-08-20T15:29:19.281000Z"},{"_id":"66c4b64fa5570c2d15033485","body":"But yep, I'd hope the \"blocking possibility\" doesn't include also waiting for events the command depends on. It'd cause the cumbersome need to have another thread just to construct the queue in case of the kernel command has event dependencies of any kind? Looks like a spec corner case which we can workaround (if needed) with the separate submit thread as suggested by @Sarbojit2019.","issue_id":1708607650199,"origin_id":1628699211,"user_origin_id":1652632,"create_time":1688986114,"update_time":1688986114,"id":1724167759285,"updated_at":"2024-08-20T15:29:19.284000Z","created_at":"2024-08-20T15:29:19.284000Z"},{"_id":"66c4b64fa5570c2d15033486","body":"I assume it's blocking when a sync queue is requested\r\n\r\nOn Mon, Jul 10, 2023 at 13:48 Pekka J\u00e4\u00e4skel\u00e4inen ***@***.***>\r\nwrote:\r\n\r\n> But yep, I'd hope the \"blocking possibility\" doesn't include also waiting\r\n> for events the command depends on. It'd cause the cumbersome need to have\r\n> another thread just to construct the queue in case of the kernel command\r\n> has event dependencies of any kind? Looks like a spec corner case which we\r\n> can workaround (if needed) with the separate submit thread as suggested by\r\n> @Sarbojit2019 <https:\/\/github.com\/Sarbojit2019>.\r\n>\r\n> \u2014\r\n> Reply to this email directly, view it on GitHub\r\n> <https:\/\/github.com\/intel\/compute-runtime\/issues\/658#issuecomment-1628699211>,\r\n> or unsubscribe\r\n> <https:\/\/github.com\/notifications\/unsubscribe-auth\/ACCJBQPMD5XXJRO6FA7CIY3XPPMY3ANCNFSM6AAAAAAZ3LCYW4>\r\n> .\r\n> You are receiving this because you were mentioned.Message ID:\r\n> ***@***.***>\r\n>\r\n","issue_id":1708607650199,"origin_id":1628705440,"user_origin_id":8687809,"create_time":1688986352,"update_time":1688986352,"id":1724167759287,"updated_at":"2024-08-20T15:29:19.286000Z","created_at":"2024-08-20T15:29:19.286000Z"},{"_id":"66c4b64fa5570c2d15033487","body":"I assume that it might execute the command before returning (to achieve lowest possible latency), but not deadlock on an input event dep (based on the manual link I posted).","issue_id":1708607650199,"origin_id":1628708872,"user_origin_id":1652632,"create_time":1688986492,"update_time":1688986492,"id":1724167759289,"updated_at":"2024-08-20T15:29:19.288000Z","created_at":"2024-08-20T15:29:19.288000Z"},{"_id":"66c4b64fa5570c2d15033488","body":"> Looks like a spec corner case\r\n\r\nThe spec is ambiguous in this regard. It would make sense if\r\n\r\n\"Commands appended into an immediate command list may execute synchronously, by blocking until the command is complete.\"\r\n\r\nis true when `ZE_COMMAND_QUEUE_MODE_SYNCHRONOUS` is set:\r\n\r\n\"Device execution always completes immediately on execute; Host thread is blocked using wait on implicit synchronization object\" \r\n\r\n@pjaaskel \r\n\r\n> which we can workaround (if needed) with the separate submit thread as suggested by \r\n\r\nWe can just use regular command lists for callbacks to get around this but I'm seeing hangs in the full application and can't reproduce in a simple reproducer. Furthermore, I'm seeing deadlocks on non-blocking operations such as `zeEventQuery` but I wanted to get clarity on this issue first. ","issue_id":1708607650199,"origin_id":1628726610,"user_origin_id":8687809,"create_time":1688987258,"update_time":1688987258,"id":1724167759291,"updated_at":"2024-08-20T15:29:19.290000Z","created_at":"2024-08-20T15:29:19.290000Z"},{"_id":"66c4b64fa5570c2d15033489","body":"With `ZE_COMMAND_QUEUE_MODE_SYNCHRONOUS` it says _always_ blocks whereas with immediate lists it says _may_ block, which have a major semantics difference. But anyhow, I'd also not expect blocking in the case of event deps here.","issue_id":1708607650199,"origin_id":1628733132,"user_origin_id":1652632,"create_time":1688987528,"update_time":1688987528,"id":1724167759293,"updated_at":"2024-08-20T15:29:19.292000Z","created_at":"2024-08-20T15:29:19.292000Z"},{"_id":"66c4b64fa5570c2d1503348a","body":"and conversely `ZE_COMMAND_QUEUE_MODE_ASYNCHRONOUS` should not be blocking. \r\n \r\n\"enumerator ZE_COMMAND_QUEUE_MODE_ASYNCHRONOUS\r\nDevice execution is scheduled and will complete in future; explicit synchronization object must be used to determine completeness\"\r\n\r\n","issue_id":1708607650199,"origin_id":1628735454,"user_origin_id":8687809,"create_time":1688987628,"update_time":1688987628,"id":1724167759295,"updated_at":"2024-08-20T15:29:19.294000Z","created_at":"2024-08-20T15:29:19.294000Z"},{"_id":"66c4b64fa5570c2d1503348b","body":"Yep, I'd expect \"async usage\" to work in this case even though it might execute the commands in the same thread (sometimes).","issue_id":1708607650199,"origin_id":1628851760,"user_origin_id":1652632,"create_time":1688991730,"update_time":1688991730,"id":1724167759297,"updated_at":"2024-08-20T15:29:19.296000Z","created_at":"2024-08-20T15:29:19.296000Z"},{"_id":"66c4b64fa5570c2d1503348c","body":"hi\r\n\r\nI checked the test and is valid. Test is submitting a kernel for immediate submission in asynchronous way. This means upon returning from appendLaunchKernel, the kernel has been submitted, and then asynchronously will wait for the event, but the host thread calling for appendLaunchKernel shouldn't block.\r\n\r\nBacdtrace on GPU MAX 1550 shows we are stuck on the submission path:\r\n\r\n```cpp\r\n#0 0x00007ffff7b3fcab in sched_yield () at ..\/sysdeps\/unix\/syscall-template.S:120\r\n#1 0x00007ffff6a5a4cc in __gthread_yield () at \/usr\/include\/x86_64-linux-gnu\/c++\/10\/bits\/gthr-default.h:693\r\n#2 std::this_thread::yield () at \/usr\/include\/c++\/10\/thread:379\r\n#3 NEO::WaitUtils::waitFunctionWithPredicate<unsigned long>(unsigned long const volatile*, unsigned long, std::function<bool (unsigned long, unsigned long)>) (predicate=..., expectedValue=1, pollAddress=0xfffffff7fc5000)\r\n at ..\/shared\/source\/utilities\/wait_util.h:33\r\n#4 NEO::WaitUtils::waitFunction (expectedValue=1, pollAddress=0xfffffff7fc5000) at ..\/shared\/source\/utilities\/wait_util.h:38\r\n#5 NEO::CommandStreamReceiver::baseWaitFunction (this=0x55555624d6d0, pollAddress=0xfffffff7fc5000, params=..., taskCountToWait=1) at ..\/shared\/source\/command_stream\/command_stream_receiver.cpp:445\r\n#6 0x00007ffff6762def in L0::CommandListCoreFamilyImmediate<(GFXCORE_FAMILY)3080>::executeCommandListImmediateWithFlushTaskImpl (this=this@entry=0x55555627b5f0, performMigration=<optimized out>, performMigration@entry=true,\r\n hasStallingCmds=hasStallingCmds@entry=true, hasRelaxedOrderingDependencies=hasRelaxedOrderingDependencies@entry=false, cmdQ=<optimized out>) at ..\/level_zero\/core\/source\/cmdlist\/cmdlist_hw_immediate.inl:350\r\n#7 0x00007ffff6762ffa in L0::CommandListCoreFamilyImmediate<(GFXCORE_FAMILY)3080>::executeCommandListImmediateWithFlushTask (this=this@entry=0x55555627b5f0, performMigration=performMigration@entry=true, hasStallingCmds=hasStallingCmds@entry=true,\r\n hasRelaxedOrderingDependencies=hasRelaxedOrderingDependencies@entry=false) at ..\/level_zero\/core\/source\/cmdlist\/cmdlist_hw_immediate.inl:283\r\n#8 0x00007ffff6763077 in L0::CommandListCoreFamilyImmediate<(GFXCORE_FAMILY)3080>::flushImmediate (this=0x55555627b5f0, inputRet=<optimized out>, performMigration=<optimized out>, hasStallingCmds=<optimized out>,\r\n hasRelaxedOrderingDependencies=<optimized out>, hSignalEvent=0x555556284410) at ..\/level_zero\/core\/source\/cmdlist\/cmdlist_hw_immediate.inl:844\r\n#9 0x00007ffff66a61ce in L0::zeCommandListAppendLaunchKernel (hCommandList=<optimized out>, kernelHandle=<optimized out>, launchKernelArgs=<optimized out>, hSignalEvent=<optimized out>, numWaitEvents=<optimized out>, phWaitEvents=<optimized out>)\r\n at ..\/level_zero\/core\/source\/cmdlist\/cmdlist.h:188\r\n#10 0x00007ffff7eea188 in zeCommandListAppendLaunchKernel () from \/usr\/local\/lib\/libze_loader.so.1\r\n#11 0x000055555555c3b8 in main (argc=1, argv=0x7fffffffe288) at \/home\/gta\/bin\/callbacks\/main.cpp:224\r\n```\r\n\r\nThe call to waitFunction seems suspicious. If the list is asynchronous, L0 driver shouldn't be waiting.\r\n\r\nTest passes with EnableFlushTaskSubmission=0, so it seems we have a bug on that path.\r\n\r\n@JablonskiMateusz : Please let me know if an internal tracker has been created for this issue or I can do it.\r\n","issue_id":1708607650199,"origin_id":1629712317,"user_origin_id":8868111,"create_time":1689022210,"update_time":1689022210,"id":1724167759300,"updated_at":"2024-08-20T15:29:19.299000Z","created_at":"2024-08-20T15:29:19.299000Z"},{"_id":"66c4b64fa5570c2d1503348d","body":"@JablonskiMateusz @jandres742 `EnableFlushTaskSubmission=0` does not seem to make any difference. Is this supposed to work on public oneapi releases? ","issue_id":1708607650199,"origin_id":1630202702,"user_origin_id":8687809,"create_time":1689056004,"update_time":1689056004,"id":1724167759303,"updated_at":"2024-08-20T15:29:19.302000Z","created_at":"2024-08-20T15:29:19.302000Z"},{"_id":"66c4b64fa5570c2d1503348e","body":"@pvelesko : that's a debug key, which needs to be set alongside with NEOReadDebugKeys:\r\n\r\n```\r\nexport NEOReadDebugKeys=1\r\nexport EnableFlushTaskSubmission=0\r\n```","issue_id":1708607650199,"origin_id":1630237302,"user_origin_id":8868111,"create_time":1689057732,"update_time":1689057732,"id":1724167759305,"updated_at":"2024-08-20T15:29:19.304000Z","created_at":"2024-08-20T15:29:19.304000Z"},{"_id":"66c4b64fa5570c2d1503348f","body":"Is there any danger in always having these set? @jandres742 ","issue_id":1708607650199,"origin_id":1630319736,"user_origin_id":8687809,"create_time":1689061534,"update_time":1689061534,"id":1724167759307,"updated_at":"2024-08-20T15:29:19.306000Z","created_at":"2024-08-20T15:29:19.306000Z"},{"_id":"66c4b64fa5570c2d15033490","body":"I think the reason is that the kernel has `printf()`. Can you remove it and try it again?","issue_id":1708607650199,"origin_id":1630379364,"user_origin_id":35971311,"create_time":1689063962,"update_time":1689063962,"id":1724167759310,"updated_at":"2024-08-20T15:29:19.309000Z","created_at":"2024-08-20T15:29:19.309000Z"},{"_id":"66c4b64fa5570c2d15033491","body":"> Is there any danger in always having these set? @jandres742\r\n\r\n@pvelesko - Yes. Applications should not set debug keys, as using them is only for development and debug purposes.","issue_id":1708607650199,"origin_id":1630389471,"user_origin_id":35971311,"create_time":1689064384,"update_time":1689064384,"id":1724167759313,"updated_at":"2024-08-20T15:29:19.312000Z","created_at":"2024-08-20T15:29:19.312000Z"},{"_id":"66c4b64fa5570c2d15033492","body":"thanks @zzdanowicz . You are correct. Once the printf is removed from KernelGPU.cl, the test completes:\r\n\r\n```\r\n$ .\/driver\r\nUsing immediate command list\r\nDevice : Intel(R) Data Center GPU Max 1550\r\nType : GPU\r\nVendor ID: 8086\r\n#Queue Groups: 3\r\nGroup X: 1024\r\nGroup Y: 1\r\nLaunching kernel\r\nHost Signal Blocking Event\r\nKernel Event Query: 1298518\r\nGPU Kernel = 104273027 [ns]\r\nSEQ Kernel = 5406017312 [ns]\r\nSpeedup = 51x\r\n\r\nMatrix Multiply validation PASSED\r\n```\r\n\r\n@pvelesko could you confirm on your side? Basically, we added a WA where kernels with printfs are executed in synchronous way to make sure that printfs are printed in order when multiple kernels are submitted to an immediate command list. This is just a temporary WA while we work in a more permanent solution, but as long as there are no printfs, the code won't hang.","issue_id":1708607650199,"origin_id":1631126442,"user_origin_id":8868111,"create_time":1689092639,"update_time":1689092639,"id":1724167759315,"updated_at":"2024-08-20T15:29:19.315000Z","created_at":"2024-08-20T15:29:19.315000Z"},{"_id":"66c4b64fa5570c2d15033493","body":"> @pvelesko could you confirm on your side? \r\n\r\n@jandres742 removing the printf no longer blocks the enqueue. \r\n\r\n> This is just a temporary WA while we work in a more permanent solution, but as long as there are no printfs, the code won't hang\r\n\r\nAny ETA on full solution? \r\n\r\nIn the meantime, \r\n\r\n> Yes. Applications should not set debug keys, as using them is only for development and debug purposes.\r\n\r\nwhat side effects can I expect from using these? ","issue_id":1708607650199,"origin_id":1632882168,"user_origin_id":8687809,"create_time":1689180590,"update_time":1689180590,"id":1724167759318,"updated_at":"2024-08-20T15:29:19.317000Z","created_at":"2024-08-20T15:29:19.317000Z"},{"_id":"66c4b64fa5570c2d15033494","body":"Thanks @pvelesko for confirming. We have an internal PR where we are removing that WA. So ETA for that PR to be merged is 1 week I'd say, and then it should be available in upcoming release, provided we dont find any regressions.\r\n\r\nThe debug keys are only for experimentation, so the suggestion above about using them was just to confirm you were seeing the same behavior as us. However, these debug keys are not fully validated and not recommended for use in productization scripts or releases.\r\n\r\nIn that sense, current disclaimer regarding this would be something like:\r\n\r\n\u201cKnown issue: Kernels with printf submitted to immediate command list are executed synchronously to ensure proper ordering of strings printed. This is to be fixed with long term solution in L0 driver\u201d.\"","issue_id":1708607650199,"origin_id":1632940832,"user_origin_id":8868111,"create_time":1689183374,"update_time":1689183374,"id":1724167759320,"updated_at":"2024-08-20T15:29:19.319000Z","created_at":"2024-08-20T15:29:19.319000Z"},{"_id":"66c4b64fa5570c2d15033495","body":"> what side effects can I expect from using these?\r\n\r\nYou cannot have any quality expectations. Applications may fail, get data errors, crashes or hangs.","issue_id":1708607650199,"origin_id":1632969807,"user_origin_id":35971311,"create_time":1689184477,"update_time":1689184477,"id":1724167759322,"updated_at":"2024-08-20T15:29:19.321000Z","created_at":"2024-08-20T15:29:19.321000Z"}]

I create an event which (in the full application) will be signalled from a different thread. I enqueue a kernel which depends on this event, and when using immediate command...

pvelesko

Abort from device_binary_format/patchtokens_decoder

[{"_id":"66c4b637a5570c2d1503346d","body":"Hi @abagusetty could you attach kernel binary or repro steps? It looks like invalid binary","issue_id":1708607650202,"origin_id":1527690095,"user_origin_id":36925973,"create_time":1682693643,"update_time":1682693643,"id":1724167735980,"updated_at":"2024-08-20T15:28:55.979000Z","created_at":"2024-08-20T15:28:55.979000Z"},{"_id":"66c4b637a5570c2d1503346e","body":"Hi @JablonskiMateusz , I getting same error on our Ubuntu 2024 machine. \r\nI using openvino 2024 and trying to run our model on GPU.\r\n\r\nWe using Neo release version [24.05.28454.6](https:\/\/github.com\/intel\/compute-runtime\/releases\/tag\/24.05.28454.6)\r\nPlease advise how to resolve ?\r\n\r\n\r\n\r\n","issue_id":1708607650202,"origin_id":2042128016,"user_origin_id":36672340,"create_time":1712563956,"update_time":1712563956,"id":1724167735985,"updated_at":"2024-08-20T15:28:55.984000Z","created_at":"2024-08-20T15:28:55.984000Z"}]

I am running a HPC workload with PVC in explicit-scaling mode using SYCL API (via L0 plugin) and was wondering what could possibly have triggered the following error. It was...

abagusetty

Xe KMD doesn't work on Linux

[{"_id":"66c4b66118409968dc0b6166","body":"what is neo driver version there? Support for Xe KMD was added in [23.05.25593.11](https:\/\/github.com\/intel\/compute-runtime\/releases\/tag\/23.05.25593.11) ","issue_id":1708607650207,"origin_id":1525961319,"user_origin_id":36925973,"create_time":1682611530,"update_time":1682611530,"id":1724167777820,"updated_at":"2024-08-20T15:29:37.820000Z","created_at":"2024-08-20T15:29:37.820000Z"},{"_id":"66c4b66118409968dc0b6167","body":"Do I have to build with a special branch? I was wondering why intel-compute-runtime-git was still producing version 22 binaries. I don't even know if I need an all different set of dependencies to get it working.\r\n\r\nEdit: I built the `master` branch, why is that still version 22?","issue_id":1708607650207,"origin_id":1526830972,"user_origin_id":796316,"create_time":1682643469,"update_time":1682643685,"id":1724167777826,"updated_at":"2024-08-20T15:29:37.826000Z","created_at":"2024-08-20T15:29:37.826000Z"},{"_id":"66c4b66118409968dc0b6168","body":"Rebuild against `23.09.25812.15.r0.g2e4d3998e2-1`, still hangs 100% on a core when it attempts to actually execute anything.","issue_id":1708607650207,"origin_id":1526941611,"user_origin_id":796316,"create_time":1682653336,"update_time":1682653336,"id":1724167777831,"updated_at":"2024-08-20T15:29:37.830000Z","created_at":"2024-08-20T15:29:37.830000Z"},{"_id":"66c4b66118409968dc0b6169","body":"have you enabled cmake flag to enable Xe driver support?\r\n`NEO_ENABLE_XE_DRM_DETECTION=1` ","issue_id":1708607650207,"origin_id":1527129449,"user_origin_id":36925973,"create_time":1682667628,"update_time":1682667628,"id":1724167777833,"updated_at":"2024-08-20T15:29:37.832000Z","created_at":"2024-08-20T15:29:37.832000Z"},{"_id":"66c4b66118409968dc0b616a","body":"I have that flag set, otherwise there would not be a device to use. Blender lists my oneAPI devices, but hangs spinning a core when it tries to upload the kernels. It works fine on the i915 driver.","issue_id":1708607650207,"origin_id":1527210694,"user_origin_id":796316,"create_time":1682671801,"update_time":1682671801,"id":1724167777836,"updated_at":"2024-08-20T15:29:37.835000Z","created_at":"2024-08-20T15:29:37.835000Z"},{"_id":"66c4b66118409968dc0b616b","body":"Yeah, and dmesg emits the following every time that happens:\r\n```\r\nMay 07 20:23:56 mrgency kernel: xe 0000:28:00.0: [drm] Engine reset: guc_id=59\r\nMay 07 20:23:56 mrgency kernel: xe 0000:28:00.0: [drm] Timedout job: seqno=4294967169, guc_id=59, flags=0x8\r\n```\r\n\r\nThat's -127 cast to u32, which is the initial DMA fence seqno for the Xe driver right now.\r\n","issue_id":1708607650207,"origin_id":1537737212,"user_origin_id":796316,"create_time":1683521105,"update_time":1683521105,"id":1724167777839,"updated_at":"2024-08-20T15:29:37.839000Z","created_at":"2024-08-20T15:29:37.839000Z"},{"_id":"66c4b66118409968dc0b616c","body":"is the issue still visible?","issue_id":1708607650207,"origin_id":1624919551,"user_origin_id":36925973,"create_time":1688715712,"update_time":1688715712,"id":1724167777841,"updated_at":"2024-08-20T15:29:37.841000Z","created_at":"2024-08-20T15:29:37.841000Z"},{"_id":"66c4b66118409968dc0b616d","body":"@kode54 See following for working Xe KMD setup: https:\/\/github.com\/intel\/compute-runtime\/issues\/696\r\n","issue_id":1708607650207,"origin_id":1969615454,"user_origin_id":4669102,"create_time":1709145895,"update_time":1709145895,"id":1724167777844,"updated_at":"2024-08-20T15:29:37.843000Z","created_at":"2024-08-20T15:29:37.843000Z"},{"_id":"66c4b66118409968dc0b616e","body":"I no longer own an Intel GPU to test with, sorry.","issue_id":1708607650207,"origin_id":1969972360,"user_origin_id":796316,"create_time":1709156687,"update_time":1709156687,"id":1724167777846,"updated_at":"2024-08-20T15:29:37.845000Z","created_at":"2024-08-20T15:29:37.845000Z"},{"_id":"66c4b66118409968dc0b616f","body":"@kode54 In that case, could you close this (I cannot)?","issue_id":1708607650207,"origin_id":1970743574,"user_origin_id":4669102,"create_time":1709199041,"update_time":1709199041,"id":1724167777848,"updated_at":"2024-08-20T15:29:37.847000Z","created_at":"2024-08-20T15:29:37.847000Z"}]

Using the Xe KMD, with an updated xe_drm.h, synced between the latest linux-drm-xe-next kernel and this package, results in OpenCL tasks which cause my A770 LE 16GB to time out,...

kode54

execute sysmon running process unknown

[]

Hi all, I use this tool, but I'm having a issue about executing sysmon() not showing running process. **Just say "unknown". How can I solve this problem?** **One of the...

YMont