Created attachment 180620 [details] workaround I'm using drm-next (i915kms, Skylake GT2) and Beignet 1.3.0 started to crash unless built with ASan. Looking in src/cl_program.c suggests get_program_global_data() shouldn't be called with OpenCL 1.2 but 2.0 is disabled by default, so something is wrong. https://cgit.freedesktop.org/beignet/commit/?id=295b1cb6d1ac $ clinfo Number of platforms 1 Platform Name Intel Gen OCL Driver Platform Vendor Intel Platform Version OpenCL 1.2 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 Platform Extensions function suffix Intel Segmentation fault Process 90021 stopped * thread #1, stop reason = signal SIGSEGV: invalid address (fault address: 0x20) frame #0: libdrm_intel.so.1`drm_intel_bo_set_softpin_offset(bo=0x0000000000000000, offset=34486951936) at intel_bufmgr.c:266 263 int 264 drm_intel_bo_set_softpin_offset(drm_intel_bo *bo, uint64_t offset) 265 { -> 266 if (bo->bufmgr->bo_set_softpin_offset) 267 return bo->bufmgr->bo_set_softpin_offset(bo, offset); 268 269 return -ENODEV; (lldb) bt * thread #1, stop reason = signal SIGSEGV: invalid address (fault address: 0x20) * frame #0: libdrm_intel.so.1`drm_intel_bo_set_softpin_offset(bo=0x0000000000000000, offset=34486951936) at intel_bufmgr.c:266 frame #1: libcl.so`get_program_global_data(prog=0x000000080126c1c0) at cl_program.c:227 frame #2: libcl.so`cl_program_build(p=0x000000080126c1c0, options="") at cl_program.c:677 frame #3: libcl.so`clBuildProgram(program=0x000000080126c1c0, num_devices=1, device_list=0x00007fffffffe1e0, options="", pfn_notify=0x0000000000000000, user_data=0x0000000000000000) at cl_api.c:835 frame #4: libcl.so`cl_self_test(device=0x000000080168a2a0, atomic_in_l3_flag=SELF_TEST_PASS) at cl_device_id.c:852 frame #5: libcl.so`cl_get_device_ids(platform=0x00000008016863d8, device_type=4294967295, num_entries=0, devices=0x0000000000000000, num_devices=0x0000000801300d10) at cl_device_id.c:907 frame #6: libcl.so`clGetDeviceIDs(platform=0x00000008016863d8, device_type=4294967295, num_entries=0, devices=0x0000000000000000, num_devices=0x0000000801300d10) at cl_api_device_id.c:43 frame #7: libOpenCL.so.1`clGetDeviceIDs(platform=0x00000008016863d8, device_type=4294967295, num_entries=0, devices=0x0000000000000000, num_devices=0x0000000801300d10) at ocl_icd_loader_gen.c:58 frame #8: clinfo`printPlatformInfo(p=0) at clinfo.c:459 frame #9: clinfo`main(argc=1, argv=0x00007fffffffe448) at clinfo.c:2676 frame #10: clinfo`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:72 (lldb) f 1 frame #1: libcl.so`get_program_global_data(prog=0x000000080126c1c0) at cl_program.c:227 224 interp_program_get_global_constant_data(prog->opaque, (char*)p); 225 226 prog->global_data = cl_buffer_alloc_userptr(bufmgr, "program global data", p, alignedSz, 0); -> 227 cl_buffer_set_softpin_offset(prog->global_data, (size_t)p); 228 cl_buffer_set_bo_use_full_range(prog->global_data, 1); 229 230 uint32_t reloc_count = interp_program_get_global_reloc_count(prog->opaque);
Hmm, Beignet 1.3.0 also crashes after building with -DENABLE_OPENCL_20=on. (lldb) r Process 90871 launching Process 90871 launched: '/usr/local/bin/clinfo' (x86_64) 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 Platform Extensions function suffix Intel Process 90871 stopped * thread #1, stop reason = signal SIGSEGV: invalid address (fault address: 0x20) frame #0: libdrm_intel.so.1`drm_intel_bo_set_softpin_offset(bo=0x0000000000000000, offset=34486792192) at intel_bufmgr.c:266 263 int 264 drm_intel_bo_set_softpin_offset(drm_intel_bo *bo, uint64_t offset) 265 { -> 266 if (bo->bufmgr->bo_set_softpin_offset) 267 return bo->bufmgr->bo_set_softpin_offset(bo, offset); 268 269 return -ENODEV; (lldb) bt * thread #1, stop reason = signal SIGSEGV: invalid address (fault address: 0x20) * frame #0: libdrm_intel.so.1`drm_intel_bo_set_softpin_offset(bo=0x0000000000000000, offset=34486792192) at intel_bufmgr.c:266 frame #1: libcl.so`get_program_global_data(prog=0x000000080126c1c0) at cl_program.c:227 frame #2: libcl.so`cl_program_build(p=0x000000080126c1c0, options="") at cl_program.c:678 frame #3: libcl.so`clBuildProgram(program=0x000000080126c1c0, num_devices=1, device_list=0x00007fffffffe1d0, options="", pfn_notify=0x0000000000000000, user_data=0x0000000000000000) at cl_api.c:835 frame #4: libcl.so`cl_self_test(device=0x000000080168af30, atomic_in_l3_flag=SELF_TEST_PASS) at cl_device_id.c:852 frame #5: libcl.so`cl_get_device_ids(platform=0x0000000801687068, device_type=4294967295, num_entries=0, devices=0x0000000000000000, num_devices=0x0000000801300d10) at cl_device_id.c:907 frame #6: libcl.so`clGetDeviceIDs(platform=0x0000000801687068, device_type=4294967295, num_entries=0, devices=0x0000000000000000, num_devices=0x0000000801300d10) at cl_api_device_id.c:43 frame #7: libOpenCL.so.1`clGetDeviceIDs(platform=0x0000000801687068, device_type=4294967295, num_entries=0, devices=0x0000000000000000, num_devices=0x0000000801300d10) at ocl_icd_loader_gen.c:58 frame #8: clinfo`printPlatformInfo(p=0) at clinfo.c:459 frame #9: clinfo`main(argc=1, argv=0x00007fffffffe438) at clinfo.c:2676 frame #10: clinfo`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:72 $ valgrind --track-origins=yes clinfo ==90907== Memcheck, a memory error detector ==90907== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==90907== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==90907== Command: clinfo ==90907== ==90907== Conditional jump or move depends on uninitialised value(s) ==90907== at 0x6C26EEB: drm_intel_bufmgr_gem_init (intel_bufmgr_gem.c:3746) ==90907== by 0x5C47E9C: intel_driver_memman_init (intel_driver.c:129) ==90907== by 0x5C45F73: intel_driver_init (intel_driver.c:172) ==90907== by 0x5C45F09: intel_driver_init_shared (intel_driver.c:302) ==90907== by 0x5C48185: intel_driver_open (intel_driver.c:226) ==90907== by 0x5C47865: intel_get_device_id (intel_driver.c:430) ==90907== by 0x5C47609: intel_setup_callbacks (intel_driver.c:1041) ==90907== by 0x5C3AA10: (anonymous namespace)::OCLDriverCallBackInitializer::OCLDriverCallBackInitializer() (cl_driver.cpp:33) ==90907== by 0x5C3A9EF: __cxx_global_var_init (cl_driver.cpp:38) ==90907== by 0x5C3AA28: _GLOBAL__sub_I_cl_driver.cpp (cl_driver.cpp:0) ==90907== by 0x5C4AE51: __do_global_ctors_aux (in /usr/local/lib/beignet/libcl.so) ==90907== by 0x5C0B74D: ??? (in /usr/local/lib/beignet/libcl.so) ==90907== Uninitialised value was created by a stack allocation ==90907== at 0x6C25140: drm_intel_bufmgr_gem_init (intel_bufmgr_gem.c:3623) ==90907== ==90907== Conditional jump or move depends on uninitialised value(s) ==90907== at 0x6C27056: drm_intel_bufmgr_gem_init (intel_bufmgr_gem.c:3778) ==90907== by 0x5C47E9C: intel_driver_memman_init (intel_driver.c:129) ==90907== by 0x5C45F73: intel_driver_init (intel_driver.c:172) ==90907== by 0x5C45F09: intel_driver_init_shared (intel_driver.c:302) ==90907== by 0x5C48185: intel_driver_open (intel_driver.c:226) ==90907== by 0x5C47865: intel_get_device_id (intel_driver.c:430) ==90907== by 0x5C47609: intel_setup_callbacks (intel_driver.c:1041) ==90907== by 0x5C3AA10: (anonymous namespace)::OCLDriverCallBackInitializer::OCLDriverCallBackInitializer() (cl_driver.cpp:33) ==90907== by 0x5C3A9EF: __cxx_global_var_init (cl_driver.cpp:38) ==90907== by 0x5C3AA28: _GLOBAL__sub_I_cl_driver.cpp (cl_driver.cpp:0) ==90907== by 0x5C4AE51: __do_global_ctors_aux (in /usr/local/lib/beignet/libcl.so) ==90907== by 0x5C0B74D: ??? (in /usr/local/lib/beignet/libcl.so) ==90907== Uninitialised value was created by a stack allocation ==90907== at 0x6C25140: drm_intel_bufmgr_gem_init (intel_bufmgr_gem.c:3623) ==90907== 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 Platform Extensions function suffix Intel ==90907== Conditional jump or move depends on uninitialised value(s) ==90907== at 0x9A0537E: clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x95D7CBA: gbe::buildModuleFromSource(char const*, llvm::Module**, llvm::LLVMContext*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&, unsigned long, char*, unsigned long*, unsigned int) (program.cpp:720) ==90907== by 0x95C0E0B: gbe::programNewFromSource(unsigned int, char const*, unsigned long, char const*, char*, unsigned long*) (program.cpp:1094) ==90907== by 0x5C1DA46: cl_program_build (cl_program.c:625) ==90907== by 0x5C0E631: clBuildProgram (cl_api.c:835) ==90907== by 0x5C31EF3: cl_self_test (cl_device_id.c:852) ==90907== by 0x5C32179: cl_get_device_ids (cl_device_id.c:907) ==90907== by 0x5C11362: clGetDeviceIDs (cl_api_device_id.c:43) ==90907== by 0x4E38044: clGetDeviceIDs (ocl_icd_loader_gen.c:58) ==90907== by 0x402310: printPlatformInfo (clinfo.c:459) ==90907== by 0x40A34A: main (clinfo.c:2676) ==90907== ==90907== Conditional jump or move depends on uninitialised value(s) ==90907== at 0x9A15241: ParseLangArgs(clang::LangOptions&, llvm::opt::ArgList&, clang::InputKind,clang::TargetOptions const&, clang::PreprocessorOptions&, clang::DiagnosticsEngine&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x9A08095: clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x95D7CBA: gbe::buildModuleFromSource(char const*, llvm::Module**, llvm::LLVMContext*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&, unsigned long, char*, unsigned long*, unsigned int) (program.cpp:720) ==90907== by 0x95C0E0B: gbe::programNewFromSource(unsigned int, char const*, unsigned long, char const*, char*, unsigned long*) (program.cpp:1094) ==90907== by 0x5C1DA46: cl_program_build (cl_program.c:625) ==90907== by 0x5C0E631: clBuildProgram (cl_api.c:835) ==90907== by 0x5C31EF3: cl_self_test (cl_device_id.c:852) ==90907== by 0x5C32179: cl_get_device_ids (cl_device_id.c:907) ==90907== by 0x5C11362: clGetDeviceIDs (cl_api_device_id.c:43) ==90907== by 0x4E38044: clGetDeviceIDs (ocl_icd_loader_gen.c:58) ==90907== by 0x402310: printPlatformInfo (clinfo.c:459) ==90907== by 0x40A34A: main (clinfo.c:2676) ==90907== ==90907== Conditional jump or move depends on uninitialised value(s) ==90907== at 0x9A16B6A: ParseLangArgs(clang::LangOptions&, llvm::opt::ArgList&, clang::InputKind,clang::TargetOptions const&, clang::PreprocessorOptions&, clang::DiagnosticsEngine&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x9A08095: clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x95D7CBA: gbe::buildModuleFromSource(char const*, llvm::Module**, llvm::LLVMContext*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&, unsigned long, char*, unsigned long*, unsigned int) (program.cpp:720) ==90907== by 0x95C0E0B: gbe::programNewFromSource(unsigned int, char const*, unsigned long, char const*, char*, unsigned long*) (program.cpp:1094) ==90907== by 0x5C1DA46: cl_program_build (cl_program.c:625) ==90907== by 0x5C0E631: clBuildProgram (cl_api.c:835) ==90907== by 0x5C31EF3: cl_self_test (cl_device_id.c:852) ==90907== by 0x5C32179: cl_get_device_ids (cl_device_id.c:907) ==90907== by 0x5C11362: clGetDeviceIDs (cl_api_device_id.c:43) ==90907== by 0x4E38044: clGetDeviceIDs (ocl_icd_loader_gen.c:58) ==90907== by 0x402310: printPlatformInfo (clinfo.c:459) ==90907== by 0x40A34A: main (clinfo.c:2676) ==90907== vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x38 0xF6 0xC1 0x5D 0xC3 0x31 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F38 vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 ==90907== valgrind: Unrecognised instruction at address 0xa7b77b2. ==90907== at 0xA7B77B2: clang::TargetInfo::getLeastIntTypeByWidth(unsigned int, bool) const (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x9A47EBF: DefineLeastWidthIntType(unsigned int, bool, clang::TargetInfo const&, clang::MacroBuilder&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x9A4508C: InitializePredefinedMacros(clang::TargetInfo const&, clang::LangOptions const&, clang::FrontendOptions const&, clang::MacroBuilder&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x9A41082: clang::InitializePreprocessor(clang::Preprocessor&, clang::PreprocessorOptions const&, clang::PCHContainerReader const&, clang::FrontendOptions const&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x99F06E1: clang::CompilerInstance::createPreprocessor(clang::TranslationUnitKind) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x9A2B856: clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&, clang::FrontendInputFile const&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x99F4034: clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x95D86F9: gbe::buildModuleFromSource(char const*, llvm::Module**, llvm::LLVMContext*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&, unsigned long, char*, unsigned long*, unsigned int) (program.cpp:763) ==90907== by 0x95C0E0B: gbe::programNewFromSource(unsigned int, char const*, unsigned long, char const*, char*, unsigned long*) (program.cpp:1094) ==90907== by 0x5C1DA46: cl_program_build (cl_program.c:625) ==90907== by 0x5C0E631: clBuildProgram (cl_api.c:835) ==90907== by 0x5C31EF3: cl_self_test (cl_device_id.c:852) ==90907== Your program just tried to execute an instruction that Valgrind ==90907== did not recognise. There are two possible reasons for this. ==90907== 1. Your program has a bug and erroneously jumped to a non-code ==90907== location. If you are running Memcheck and you just saw a ==90907== warning about a bad jump, it's probably your program's fault. ==90907== 2. The instruction is legitimate but Valgrind doesn't handle it, ==90907== i.e. it's Valgrind's fault. If you think this is the case or ==90907== you are not sure, please let us know and we'll try to fix it. ==90907== Either way, Valgrind will now raise a SIGILL signal which will ==90907== probably kill your program. ==90907== ==90907== Process terminating with default action of signal 4 (SIGILL): dumping core ==90907== Illegal opcode at address 0xA7B77B2 ==90907== at 0xA7B77B2: clang::TargetInfo::getLeastIntTypeByWidth(unsigned int, bool) const (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x9A47EBF: DefineLeastWidthIntType(unsigned int, bool, clang::TargetInfo const&, clang::MacroBuilder&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x9A4508C: InitializePredefinedMacros(clang::TargetInfo const&, clang::LangOptions const&, clang::FrontendOptions const&, clang::MacroBuilder&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x9A41082: clang::InitializePreprocessor(clang::Preprocessor&, clang::PreprocessorOptions const&, clang::PCHContainerReader const&, clang::FrontendOptions const&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x99F06E1: clang::CompilerInstance::createPreprocessor(clang::TranslationUnitKind) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x9A2B856: clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&, clang::FrontendInputFile const&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x99F4034: clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (in /usr/local/lib/beignet/libgbe.so) ==90907== by 0x95D86F9: gbe::buildModuleFromSource(char const*, llvm::Module**, llvm::LLVMContext*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&, unsigned long, char*, unsigned long*, unsigned int) (program.cpp:763) ==90907== by 0x95C0E0B: gbe::programNewFromSource(unsigned int, char const*, unsigned long, char const*, char*, unsigned long*) (program.cpp:1094) ==90907== by 0x5C1DA46: cl_program_build (cl_program.c:625) ==90907== by 0x5C0E631: clBuildProgram (cl_api.c:835) ==90907== by 0x5C31EF3: cl_self_test (cl_device_id.c:852) ==90907== ==90907== HEAP SUMMARY: ==90907== in use at exit: 1,752,551 bytes in 6,847 blocks ==90907== total heap usage: 7,843 allocs, 996 frees, 2,107,960 bytes allocated ==90907== ==90907== LEAK SUMMARY: ==90907== definitely lost: 416 bytes in 17 blocks ==90907== indirectly lost: 0 bytes in 0 blocks ==90907== possibly lost: 0 bytes in 0 blocks ==90907== still reachable: 1,752,135 bytes in 6,830 blocks ==90907== suppressed: 0 bytes in 0 blocks ==90907== Rerun with --leak-check=full to see details of leaked memory ==90907== ==90907== For counts of detected and suppressed errors, rerun with: -v ==90907== ERROR SUMMARY: 15 errors from 5 contexts (suppressed: 0 from 0) Killed
The update of beignet was only build tested as I have no hardware on which to possibly run it (the box with Intel 'GPU' has laughable OpenGL support, OpenCL is out of the question), so any runtime feedback is appreciated. Is the "workaround" patch actually working? It is not clear if the error in the second post is with or without that patch.
(In reply to Matthew Rezny from comment #2) > Is the "workaround" patch actually working? Yep. OpenCL 1.4 works fine after the patch (barring old bug 213732). OpenCL 2.0 (not exposed yet) still crashes. No other port uses drm_intel_bo_set_softpin(), so it maybe broken. ;) $ clpeak Platform: Intel Gen OCL Driver Device: Intel(R) HD Graphics Skylake Desktop GT2 Driver version : 1.3 (FreeBSD) Compute units : 24 Clock frequency : 1000 MHz Global memory bandwidth (GBPS) float : 32.94 float2 : 30.69 float4 : 32.55 float8 : 33.19 float16 : 30.05 Single-precision compute (GFLOPS) float : 422.00 float2 : 438.56 float4 : 438.05 float8 : 436.98 float16 : 434.43 No double precision support! Skipped Transfer bandwidth (GBPS) enqueueWriteBuffer : 10.01 enqueueReadBuffer : 11.59 enqueueMapBuffer(for read) : 37543.42 memcpy from mapped ptr : 11.69 enqueueUnmap(after write) : 43471.33 memcpy to mapped ptr : 10.96 Kernel launch latency : 29.42 us Nothing to output !
With bug 217771 in scope comment 0 is limited to OPENCL20=off while comment 1 no longer happens.
(In reply to Jan Beich (mail not working) from comment #4) I was going to suggest trying 1.3.1 since it was released today but it appears you are ahead of me. If I understand your last reply correctly, there is no problem and no need for the patch if beignet is built with OpenCL 2.0 support enabled, correct?
Hi, I have seen the patch you sent to beignet mail-list. I could not reproduce the problem, could you provide the llvm version, libdrm version and build options of the Beignet. You can try to post beignet bugs to our Bugzilla https://bugs.freedesktop.org/enter_bug.cgi?product=Beignet Thanks Xiuli
(In reply to Xiuli Pan from comment #6) > I have seen the patch you sent to beignet mail-list. I could not > reproduce the problem, could you provide the llvm version, libdrm > version and build options of the Beignet. LLVM 3.9.1, libdrm 2.4.75, Mesa 13.0.5 and 17.0.1, ocl-icd 2.2.11, Beignet 1.3.0 or 1.3.1 + -DENABLE_OPENCL_20=off (default on i386). Only -DLLVM_CONFIG_EXECUTABLE=/usr/local/bin/llvm-config39 is explicitly passed in lang/beignet port but the framework does more which you can figure out from build logs (head-amd64 is what I'm using). https://svnweb.freebsd.org/ports/head/graphics/libdrm/files/ https://svnweb.freebsd.org/ports/head/graphics/libGL/files/ https://svnweb.freebsd.org/ports/head/lang/beignet/files/ http://beefy6.nyi.freebsd.org/data/latest-per-pkg/beignet/1.3.0/103amd64-default.log http://beefy5.nyi.freebsd.org/data/latest-per-pkg/beignet/1.3.0/103i386-default.log http://beefy9.nyi.freebsd.org/data/latest-per-pkg/beignet/1.3.0/110amd64-default.log http://beefy10.nyi.freebsd.org/data/latest-per-pkg/beignet/1.3.0/110i386-default.log http://beefy11.nyi.freebsd.org/data/latest-per-pkg/beignet/1.3.0/head-i386-default.log (IPv6-only) http://beefy12.nyi.freebsd.org/data/latest-per-pkg/beignet/1.3.0/head-amd64-default.log (IPv6-only) > You can try to post beignet bugs to our Bugzilla > https://bugs.freedesktop.org/enter_bug.cgi?product=Beignet Sure, next time. I wonder if our libdrm package is a bit broken or this is just another case of using unitialized value.
From Segmentation fault's call stack, prog->global_data = cl_buffer_alloc_userptr(bufmgr, "program global data", p, alignedSz, 0); cl_buffer_alloc_userptr return null, then crash in the next line. cl_buffer_set_softpin_offset(prog->global_data, (size_t)p); Does the libdrm's intel_buffer_alloc_userptr work in freebsd? What's the alignedSz's value? Anyway, the workaround patch is ok to me, thanks.
(In reply to Rong Yang from comment #8) > Does the libdrm's intel_buffer_alloc_userptr work in freebsd? Without root - no. I've filed https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/132 > What's the alignedSz's value? (lldb) p alignedSz (size_t) $1 = 4096 > Anyway, the workaround patch is ok to me, thanks. ocl_version is always 120 here (even with root), so get_program_global_data() is never called. Probably a bug.
Same issue here (drm_intel_bo_set_softpin_offset SEGV). FreeBSD 11.0-RELEASE-p10 i7-4790K "Devil's Canyon" (Haswell) with HD 4600 (GT2) libdrm-2.4.80_1,1 llvm39-3.9.1_1 beignet-1.3.1_1 ocl-icd-2.2.11_1 Initially failed with beignet (openCL 2.0) Also fails with beignet (openCL 2.0) + attachment 180620 [details] Also fails with beignet (openCL 1.2) + attachment 180620 [details] Typical failure (always running as root): (gdb) run Starting program: /usr/local/bin/clinfo Number of platforms 1 Platform Name Intel Gen OCL Driver Platform Vendor Intel Platform Version OpenCL 1.2 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 Platform Extensions function suffix Intel [New LWP 101064 of process 32508] Thread 1 received signal SIGSEGV, Segmentation fault. 0x00000008021ef714 in drm_intel_bo_set_softpin_offset (bo=0x0, offset=34466746368) at intel_bufmgr.c:266 266 if (bo->bufmgr->bo_set_softpin_offset) "clpeak" crashes in the same way, with similar backtrace. Volunteering to test. I would appreciate config option for beignet to toggle openCL 2.0 support!
Just adding that I'm NOT using drm-next, which might explain why DRM_IOCTL_I915_GEM_USERPTR returns EINVAL and hence a NULL pointer. However this does mean that it seems there's no working beignet port for me under 11.0-RELEASE? I also tried beignet-1.2.0 which also doesn't work: # LD_PRELOAD=/lib/libthr.so.3 clpeak Platform: Intel Gen OCL Driver Beignet: self-test failed: (3, 7, 5) + (5, 7, 3) returned (3, 7, 5) See README.md or http://www.freedesktop.org/wiki/Software/Beignet/ Beignet: disabling non-working device clCreateContextFromType (-1) Nothing to output ! Am I 'wrong' to expect a working port of beignet for 11.0-RELEASE without having to build "freebsd-desktop-graphics"? Also have I maybe commented on the wrong bug? Would bug 217771 be more appropriate or should I create a new one? Apologies if I have misunderstood!
(In reply to misc-freebsd-bugzilla from comment #11) > Just adding that I'm NOT using drm-next, which might explain why > DRM_IOCTL_I915_GEM_USERPTR returns EINVAL and hence a NULL pointer. Only OpenCL 2.0 requires DRM_IOCTL_I915_GEM_USERPTR. However, if OpenCL 1.2 fails from beignet-1.2.0, beignet-1.3.1 + the patch here or beignet-1.3.1.205 (snapshot) from review D11377 with/without -DENABLE_OPENCL_20=off appended to CMAKE_ARGS then you're probably out of luck.
*** Bug 220464 has been marked as a duplicate of this bug. ***
Comment on attachment 180620 [details] workaround Approved by: portmgr (maintainer timeout, 4+ months)
Reporter is committer, re-assign accordingly, keeping maintainer CC'd
(In reply to Kubilay Kocak from comment #14) There was no maintainer timeout. Maintainer had been waiting for a clear response to comment #5 for 4 months.
Comment on attachment 180620 [details] workaround This patch is not applicable as-is since the port was updated some time ago, nor has it been made clear whether the workaround is still needed after that update.
(In reply to Kubilay Kocak from comment #14) > Approved by: portmgr (maintainer timeout, 4+ months) Actually, the patch qualified for portmgr blanket as soon as it landed upstream. The stalemate is caused by disagreement about QA. For background see https://lists.freebsd.org/pipermail/svn-ports-head/2017-April/144802.html (In reply to Matthew Rezny from comment #17) > This patch is not applicable as-is Ignoring trivial PORTREVISION conflict the other hunk still applies. And patch-level updates rarely change semantics to require re-evaluation of assumptions. > since the port was updated some time ago, Only 1.4.0 (unreleased atm) has the fix. > nor has it been made clear whether the workaround is still needed after that update. Notice comment 11 or https://lists.freebsd.org/pipermail/freebsd-questions/2017-July/277987.html confirm the crash disappeared by either downgrading to 1.2.0 or applying the patch. comment 4 was invalidated by comment 9 but both are so context-heavy, so let's ignore those.
(In reply to Jan Beich from comment #18) > Actually, the patch qualified for portmgr blanket as soon as it landed upstream. Where is it stated there is blanket approval for any upstream commit? Such a thing would be a free for all. > Notice comment 11 Which says OpenCL doesn't work on any version for him? > comment 4 was invalidated by comment 9 but both are so context-heavy, so let's ignore those. Not that those appear in any way related... Anyway, I'm happy to drop this quagmire around a patch if an upstream snapshot is working as D11377 indicates.
Can portmgr@ land the patch here and backport to 2017Q3 (maybe also 2017Q2)? I can't reach an agreement with the maintainer. (In reply to Matthew Rezny from comment #19) > Where is it stated there is blanket approval for any upstream commit? "any" strawman commit doesn't apply. The patch here is both a crash fix + a regression fix + was reviewed. Being "trivial and tested" it satisfies the requirement for "just fix it". https://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-January/000073.html > Which says OpenCL doesn't work on any version for him? How does this invalidate the *disappeared* crash? Let's not mix different issues.
(In reply to Jan Beich from comment #20) > Can portmgr@ land the patch here and backport to 2017Q3 (maybe also 2017Q2)? Nevermind. I'll land review D11377 under maintainer timeout. According to a comment in that review maintainer doesn't seem as opposed to an update that brings newer LLVM support as well. ;\
A commit references this bug: Author: jbeich Date: Fri Oct 6 22:05:14 UTC 2017 New revision: 451413 URL: https://svnweb.freebsd.org/changeset/ports/451413 Log: lang/beignet: update to 1.3.1.52 (Release_v1.3 branch snapshot) Changes: https://github.com/intel/beignet/compare/be0ae74...afd050f6 PR: 217635 218644 Approved by: maintainer timeout (2 months) MFH: 2017Q2 (requires r437953), 2017Q3 (regression fix for r435144) Differential Revision: https://reviews.freebsd.org/D11377 Changes: head/lang/beignet/Makefile head/lang/beignet/distinfo head/lang/beignet/files/patch-src_cl__program.c head/lang/beignet/files/patch-utests_CMakeLists.txt
A commit references this bug: Author: jbeich Date: Mon Nov 27 13:44:27 UTC 2017 New revision: 454953 URL: https://svnweb.freebsd.org/changeset/ports/454953 Log: MFH: r451413 r453205 lang/beignet: update to 1.3.2 Changes: https://01.org/beignet/downloads/beignet-1.3.2-2017-10-26 PR: 217635 218644 Approved by: maintainer timeout (2 months) Approved by: ports-secteam (swills) Differential Revision: https://reviews.freebsd.org/D11377 Changes: _U branches/2017Q4/ branches/2017Q4/lang/beignet/Makefile branches/2017Q4/lang/beignet/distinfo branches/2017Q4/lang/beignet/files/patch-src_cl__program.c branches/2017Q4/lang/beignet/files/patch-utests_CMakeLists.txt