optimize build of synocli-videodriver

[hgy59]

The build of synocli-videodriver for DSM 7 takes too long

Analysis of the build of synocli-video-driver in #6303:
for DSM 6.2.4 it took 17 Minutes to build the synocli-video-driver package
but for DSM 7.1 it took 3 Hours and 18 Minutes.

Since it takes so long for DSM 7.1, the github build action often times out after 6 hours for any build with ffmpeg7

Further analysis of the build log showed, that the build of cross/intel-graphics-compiler that is built for DSM 7 only, took 2 Hours and 21 Minutes (without the related dependencies).

This brings up the idea to precreate the intel-graphics-compiler and provide it as native/intel-graphics-compiler.

@th0ma7 is this possible?

[th0ma7]

Probably feasible but tricky, and would become a cross/intel-graphics-compiler_prebuilt or similar using install resources probably (and not native). Issue is that intel-compute-runtime also depends on it, so it would probably need to be packaged with it as well if not just because of the total size needed by intel-graphics-compiler unstripped + now the downloaded tar.bz2 which may go beyond the total disk space.

The whole idea of seperating the videodriver was to avoid rebuilding it, and reduce ffmpeg package size and limit storage usage on our web hosting platform ... but what if, idea like that, what about caching the spk/synocli-videodriver within github-action (similar to distrib folder)? it would change only once a year or so (as I have no intention to follow every weekly releases).

[hgy59]

We first should cleanup the artifacts (what is defined in PLIST files) of intel-* modules.

The term "compiler" triggers this, as I suppose it is required at build time only and should no be added to the videodriver spk.
candidates:

• iga64
• GenX_IR (the graphics compiler?)
• ocloc-24.31 (the OpenCL™ Offline Compiler)
• may be more

And there are duplicates in the PLIST files of cross/intel-compute-runtime and cross/intel-graphics-compiler
So it is not obvious what is built by which of those.

[hgy59]

and we could certainly remove cross/igt-gpu-tools (or create a video driver develompent package?)

[th0ma7]

We first should cleanup the artifacts (what is defined in PLIST files) of intel-* modules.

The term "compiler" triggers this, as I suppose it is required at build time only and should no be added to the videodriver spk. candidates:

Well, you need the spirv "compiler" portion of llvm for the driver to function, along with opencl and tools. There may be some reduction with the sample*, but beyond that not much.

• iga64
• GenX_IR (the graphics compiler?)
• ocloc-24.31 (the OpenCL™ Offline Compiler)
• may be more

And there are duplicates in the PLIST files of cross/intel-compute-runtime and cross/intel-graphics-compiler So it is not obvious what is built by which of those.

Good catch, looking at things:

spksrc@spksrc:~/python-wheels/spksrc/cross$ sdiff intel-graphics-compiler/PLIST intel-compute-runtime/PLIST 
bin:bin/clinfo                                                <
bin:bin/cllayerinfo                                           <
bin:bin/GenX_IR                                               <
bin:bin/iga64                                                 <
bin:bin/lld                                                   <
bin:bin/metrics_monitor                                       <
bin:bin/ocloc-24.31                                             bin:bin/ocloc-24.31
bin:bin/sample_decode                                         <
bin:bin/sample_encode                                         <
bin:bin/sample_multi_transcode                                <
bin:bin/sample_vpp                                            <
bin:bin/system_analyzer                                       <
bin:bin/val-surface-sharing                                   <
bin:bin/vpl-inspect                                           <
bin:bin/vpl-import-export                                     <
lnk:lib/libiga64.so                                           <
lnk:lib/libiga64.so.1                                         <
lib:lib/libiga64.so.1.0.1                                     <
lnk:lib/libigc.so                                             <
lnk:lib/libigc.so.1                                           <
lib:lib/libigc.so.1.0.1                                       <
lnk:lib/libigdfcl.so                                          <
lnk:lib/libigdfcl.so.1                                        <
lib:lib/libigdfcl.so.1.0.1                                    <
lib:lib/libocloc.so                                             lib:lib/libocloc.so
lib:lib/libopencl-clang.so.14                                 <
lnk:lib/libze_intel_gpu.so.1                                    lnk:lib/libze_intel_gpu.so.1
lib:lib/libze_intel_gpu.so.1.3.30508                          | lnk:lib/libze_intel_gpu.so.1.3.30508
rsc:lib/igc/NOTICES.txt                                       <
lib:lib/intel-opencl/libigdrcl.so                               lib:lib/intel-opencl/libigdrcl.so
                                                              > rsc:etc/OpenCL/vendors/intel.icd

From the get go, lnk:lib/libze_intel_gpu.so.1.3.30508 should be type lib. And indeed, wonder what goes where... There where multiple attempts to build in-tree using llvm the various components (or not, depending) which may have led to this confusion in these two PLIST.

From a quick search in the sources:

• libze_intel_gpu.so* is from intel-compute-runtime
• ocloc offline compiler also from intel-compute-runtime
• libze* I believe stands for level zero and also from intel-compute-runtime
• libigdrcl* as well, from intel-compute-runtime

Note that the intel-compute-runtime is what defines the intel video driver opencl capabilities so the Khronos generic loader (ocl-icd) knows what to do about it by reading its etc/OpenCL/vendors/intel.icd definition file.

[th0ma7]

But really the question is, can spk/synocli-videodriver be cached to expedite the builds? That would be an enourmous saving on compute time...

EDIT: Actually, caching ffmpeg* as well could have some potential... but the videodrv package is relatively self-contaioned in comparison (i.e. contains less dependencies that can trigger it)