diff --git a/.github/workflows/last-reviewed-cron.yml b/.github/workflows/last-reviewed-cron.yml index c78a8a9dbd..b8edcac849 100644 --- a/.github/workflows/last-reviewed-cron.yml +++ b/.github/workflows/last-reviewed-cron.yml @@ -17,6 +17,7 @@ permissions: jobs: sweep: + if: github.repository == 'ArmDeveloperEcosystem/arm-learning-paths' runs-on: ubuntu-latest steps: - name: Move items based on Last Reviewed Date diff --git a/.wordlist.txt b/.wordlist.txt index 85a6e42060..1718a909fc 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -1,5057 +1,5058 @@ +aa +aaa +aaaa +aaaaa +aaaaaaaa +aaaaaaab +aaarch +AAarch +AABB +AABBs +AAPCS +aar +AAR +aarch AArch +abc +abd +Abena +abetlen +abi +ABI +Abook +AbstRaction +abyz +accelerometer +accelerometers +accg +ACCP +Acer +ACfE +acfl +ACfL +aci +acknowledgement +acknowledgements +ACL +acle +ACM +acnt +ACPI +acq +ACR +ActAgent +activations +Acyclic +ada +AdaBoost +ADAC +Adafruit +adamw +adaptively +adb +addHandler +additionOfProduct +AdditionOfProduct +addr +Addr +addSignal +AddSingleton +AddSource +AddThingToThingGroup +adduser +ade +ADK +AdministratorAccess +Adnan +adoc +Adoptium +adrp +advancedweb +advsimd +AdvSIMD +AE +aei +AEM +aemfvp +AEMs +AEMv +AEMvA +AES +AEx +af +afa +AFBC +afc +affine +Affine +afm +AFM +AFRC +aG +AgentDrArm +AgentDrArmComponent +agentic +agentpath +AgentS +AgentsSettings +agg +AggressiveInlining +Agrawal +AGX +AHB +ahUKEwisi +ai +AirQualityIndex AKIAIOSFODNN +aks +AKS +al +Alaaeddine +Alacritty +alarmtimer +Albin +Alexa +Alexandros +AlexNet +algorithmica +alibaba +Alibaba +alibabacloud +AliCloud +ALLE +allinea +Alloc +allocator +Allocator +allocators +allocs +AllowAnyCustom +AllowUSBDebugging +alos +alpineImage +ALSA +AlSinan +Altivec +altra +Altra +Amanfo +amazonaws +amazondynamodb +AmazonECR +amazonq +AmazonRDS +AmazonS +AmazonSNSFullAccess +amba +AMBA +amd +ami AMI -AVH -AddThingToThingGroup +AMIs +amperecomputing +AMQP +ams +AMX +analyse +analytics +Analytics +andc +andnot +AndroidDemo +AndroidManifest +androidml +anf +animateClick +Anonymized +ansible Ansible +Anson +antialiasing +Antonov +AnyCPU +anypoint +AO +AOM +AOR +AoS +aoss +aot +AoT +AOT +AOvVaw +ap +apache +ApacheBench +apb +apc +aperf +APerf +Aphex +api +APIGW +apiKey +APIs +ApiService +apisix +apk +APK +APKs +APL +aplay +AppCompatActivity +AppHost +AppleClang +ApplyMlMovement +applyRotation +AppManager +appOutDir +appPid +AppShell +appsvc +APs +aQsHmumnZykaFxM +ar +arcee +Arcee +Arcee's +ARchive +archlinuxarm +archs +ArchSpecificLibrary +arctitecture +arduino +arecord +arg +ARG +argc +argList +argmax +args +ArgumentList +argv +Arial +Arlo +armclang +ARMCM +ArmCompilerforEmbedded +ArmDeveloperEcosystem +armds ArmDS +armflang +armflorentlebeau +ARMFp +armhalideandroiddemo +ArmHalideAndroidDemo +armie +ArmIE +armiotcosmosdb +armiotstorage +armips +armkeil +armlearningpaths +armlink +armlm +ArmNN +armpl ArmPL -Armv -Aspera -AttachPolicy -AttachRolePolicy +armpytorchmnistinference +ArmPyTorchMNISTInference +ArmRAL +ARMRAL +ARMSC +armsve +armswdev +armtest +armv +Armv +ARMv +ArmvX +arn +Arnaud +ARNs +Arpad +arrayEqual +arrhythmias +artifactory +Artifactory +arw +arxiv +arXiv +Asahi +asc +ASG +ASGI +ASIL +ASIMD +ASLR +asm +AsmSource +asoc +Aspera +aspnet +aspnetapp +AspNetCore +asr +ASR +ASR's +AssetLib +ASTC +astcenc +Astra +asymm +async +asyncio +ata +ATF +ath +Atheros +atlascli +atlassian +atleast +atomicity +atomics +Atomics +ats +AttachPolicy +AttachRolePolicy AttachThingPrincipal +ATtestation +attester +Attester +Attr +AttributeError +Aude +audiogen +aufs +AUP +auth +authenticator +authtoken +Authtoken +autocannon +Autocannon +autocomplete +autoconf +autoconnect +Autoconnect +autodesk +AutoEncoder +autoexit +autofdo +AutoFDO +autogenerated +autoloading +automake +automations +AutoModelForSpeechSeq +AutoProcessor +autoregressive +autoremove +autorun +Autoscale +autoscaling +Autoscheduler +autounattend +Autovec +autovectorizable +autovectorization +Autovectorization +autovectorize +autovectorized +autovectorizing +autoware +Autoware +autowarefoundation +autowiring +averagetemperature +averageTemperature +avh +AVH +Avin +Avnet +Avx +AVX +awk +aws +awscli +awsConnectionInfo +AWSEC +AWSIoTFullAccess +AwsServerlessDynamoDbLambda +AwsServerlessDynamoDbLambdaS +AwsServerlessLambda +AWSthat +axf +axi +AXI +axion +Axion +axios +az +azcosmosdb +azurecr +AzureFunctions +AzureIoT +azurerm +azureuser +AzureWebJobsStorage +ba +backend +backends +backhauls +backoff +backports +backpropagation +backtrace +baeldung +Baichuan +baidu +Bakre +balancer +balena +Balena +balenaCloud +balenaEtcher +BalenaOS +baremetal +Baremetal +bartowski +barycentric +basebackup +baselineDB +BaseViewModel +bashrc +basicPubSub +BasicTests +Basma +BatchNorm +BatchWriteCommand +BatchWriteItem +BattleEnvController +BattleMode +bazel +bazelbuild +bazelrc +bb +Bbook +bc +Bc +bcebos +bced +BCM +Bcmake +bd +BDA +beabd +bechmarking +bedrust +Bedrust +BeginSample +BehaviorParametersComponent +BehaviourName +BehaviourParameters +BehaviourUpdate +belows +benchArrayPush +BenchmarkBubbleSort +benchmarkDB +BenchmarkDotNet +benchmarked +benchmarkHttpResponse +benchmarking +Benchmarking +BenchmarkQuickSort +benchmem +benchstat +Benchstat +benchStringConcat +Benoît +Bernhardsson +BertTokenizer +Beyls +bfloat +Bfloat +BFloat +BGR +Bhusari +binaryOperator +BindingContext +bindir +bindless +Bindless +binrel +binutils +biogo +Bioinformatics +Biquad +BIST +bitbake +BitBake +Bitbucket +bitfield +bitfields +bitmask +bitness +bitrate +bitstream +Bitstream +bitvector +bitvectors +bitwise +Bitwise +bj +blas +BLAS +BLASes +Blazor +BLE +BLERP +bleve +Bleve +blinky Blinky -CLI -CMSIS -CMake -CPUs -CUDA +blockmap +blockMapFile +blp +BLS +blurThresholdImage +BLX +BLXNS +BMC +BMC's +BMCs +BMS +BoatAttack +Bolt +BOLT's +bonza +bool +boolean +booleanConversion +bootloader +bootloaders +BOOTSEL +borycki +Borycki +BossBattle +boto +Botspot +BoundaryConditions +Boundness +BPC +bpf +BPF +bpftool +br +breakpoint +Breakpoint +brendangregg +brian +brianfrankcooper +Broadcom +Brossard +brstack +BSON +bsp +BSP +bstn +BTI +BubbleSort +BuildCommand +buildctl +BuildKit +buildkite +Buildkite +buildmgr +BUILDPLATFORM +BuildProcess +buildroot +buildspec +Buildspec +buildwithmatter +buildx +BuildYourOwnKernel +BurstCompile +BurstNeonCalculationScript +BurstNeonCollisions +bursty +BusFault +busybox +BusyBox +ButtonClearResults +ButtonRunCalculations +buttonStart +buttonStartPreview +buttonStopPreview +buzzerPin +BVH +bvm +BVM +ByteBuffer +bytecode +BytesToBytesMap +bz +Cacheable +CADI +Caffe +CalcThreadProc +callee +Callee +Calligra +Callout +callstack +Callstack +CallStack +calvo +Calvo +CameraBridgeViewBase +cameraPermissionRequestCode +CameraX +CAMs +CanaKit CancelJob +cancelled +CanExecute +CanExecuteChanged +caPath +cardinality +CAS +CascadeClassifier +CASP +cassandra +Cassandra +Cassandra's +casted +catalogue +CatsNDogs +CBL +cblas +Cbook +CBOR +cbuild +cbuildgen +cca +CCA +ccache +CCC +CCG +Cclass +cd +CDE +CDH +CDK +cdn +ce +cea +cebbb +cef +CEF +CEF's +cefcc +Celestia +centos CentOS +centric +Cepstral +CERN +certifi +certifiability +certPath +CFF +CFFT +cfg +CFGM +CFLAGS +CGNAT +cgroup +cgroupfs +Chakroun +changelog +channelwise +Chaodong +Chari +ChartData +chatbot +Chatbot +chatbot's +chatbots +ChatGPT +ChatGPT's +cheatsheet +CheckBox +checkboxes +checkBoxProcessing +checkmark +Checkpointing +checksums +Cheng +ChenYing +childPid +childProcess +chipidea +chiplet +chipset +chmod +Choi +Chowdary +chown +chpasswd +Christophe +chromebooks +chromeos ChromeOS -Corstone -CreateDeployment -CreateIoTResources -CreateJob -CreateKeysAndCertificate -CreatePolicy -CreateRole -CreateRoleAlias -CreateThing -CreateThingGroup -CreateTokenExchangeRole -DAP -DNS -DeleteThingShadow -DeployDevTools -DescribeEndpoint -DescribeJob -DescribeRoleAlias -DescribeThing -DescribeThingGroup -DevOps -EDA -FPGA -FRONTEND -FVP -FVPs -FastModelsPortfolio -FlexLM -FlexNet -Florent -Fortran -FuSa -GFortran -Gb -GetPolicy -GetRole -GetThingShadow -Gitpod -Graviton -Greengrass -GreengrassV -HPC -HPE -HSK -HSKs -Hostname -IAM -IAR -IDEs -IdentityFile -IoT -JSON -KDE -KVM -Keil -Kubectl -Kubernetes -LLS -LLVM -LPCXpresso -LTS -Lebeau -Lenovo -Linaro -Lmod -MDK -MLOps -MPI -MPICH -MPS -MPT -MSBuild -MSVC -MVAPICH -Manjaro -Multipass -NIC -NXP -Neoverse -NoMachine -Nvidia -OpenVSCode -PDH -PGI -PPA -Pareena -PassRole -Portainer -PowerShell -powershell -Pytorch -Quickstart -README -RHEL -RTOS -Ronan -SDK -SDKs -SLES -SSK -SSKs -SVE -Scalable -SoC -SuSE -Synnott -TCP -TXT -Terraform -Thinkpad -TigerVNC -TokenExchangeRole -TokenExchangeRoleAccess -Toolchain -UBL -UpdateJob -UpdateThingShadow -VMs -VNC -VPN -Verma -WSL -aarch -acfl -adb -af -allinea -amd -ansible -anypoint -api -arctitecture -armclang -armflang -armflorentlebeau -armie -arn -aws -bashrc -binrel -buildmgr -catalogue -cbuild -cbuildgen -cd +ChromeOS's +chromiumembedded +chrono +chroot +ci +cicd +CIDR +cifar +CIFAR +CimInstance +Cinemachine +CIPD +circleci +CircleCI +clair +clairctl +ClassName +CLCD cli +CLI +ClickBench +clickhouse +ClickHouse +clientcredential +clientId +cliinstall +clk +cloudflare +Cloudflare +CloudFormation +cloudsdk +CloudWatch +CLR +clusterName +cma cmake +CMake +CMakeFiles +CMakeLists +CMakePresets +cmath cmd +cmdline +cmdLine +CML +cmn +CMN +CMOs +CMP +CMS cmsis +CMSIS +cmsisdsp +cmvp +cn +CNCF +cnf +cni +CNI +CNNs +CNTPS +cntr +cockroachdb +CockroachDB +CoCo +codebase +codebases +CodeBlocks +codebuild +CodeBuild +codec +Codec +codecs +codegen +codelabs +CodeLite +codemia +codeMode +CODENAME +codeproject +Codespaces +codewhisperer +coe +Colima +colin +CollateObservations +CollectObservations +collisioncalc +CollisionCalculationScript +CollisionMovement +ColorAttachment +combinator +combobox +CommandEncoder +commandline +commandlinetools +CommonJS +comparators +CompilerSpecific +compileSdk +Compiling Dictionary... +Compr +ComputationService +computationTime +ComputationTime +computationTimeHistory +ComputeLibrary +COMs +cond conda +conf config +configdb +ConfigGuess +configs +configurability +ConfigurationInfo +Configurator +configureAgent +Congatec +conn +connectaddress +connectedhomeip +const +ConstraintLayout +containerd +containerd's +ContainerGroup +ContentPage +ControllerBase +conv +convolutional +convolve +cooldown +copyAssign +copyConstruct +CopyWord +CoreDebug +corelink +CoreLink +Corellium +coresight +CoreSight +Corestone +coroutine +Coroutine +coroutines corretto +Corriero +CORS +corstone +Corstone +cosf +CosmicNvim +cosmosdb +CosmosDBOutput +counterintuitive +Coursera cp cpackget -crt -csh -ddt -deamon -deliverables -dev -developerguide -devtools -dir -dnf -dui -eabi -env -exe -executables -fi -fortran -frontend -gcc -gcloud -gfortran -github -gitpod -gnueabihf -gnupg -graviton -greengrass -groupinstall -hashicorp -hostid -hostids -hpc -html -http -https -iam -ide -img -init -installtoolsall -io -iot -jdk -json -keil -kubectl -kubernetes -le -libc -linaro -linaroforge -linux -localhost -macOS -md -mdk -microcontroller -microcontrollers -microsoft -middleware -mkdir -modulefiles -mpiexec -mpirun -mulesoft -multipass -multitool -natively -newgrp -nomachine -noninteractive -nx -onlinedocs -openssh -openvscode -pacman -ppa -ppc -pre -printf -profiler -pstools -pulldown -py -readme -relinked -ret -runtime -sdk -socrates -sudo -synonymously -systemd -tabpane -tcsh -terraform -tf -tigervnc -toolchain -toolchains -ubuntu -uname -unmount -userguide -usr -venv -visualstudio -vscode -wget -www -xJf -xfce -xvf -xz -ABI -ADAC -AKS -AMIs -APIs -ARMRAL -ARMv -AUP -AVX -AXI -Abook -Acer -Adafruit -AddSource -Addr -Alacritty -Alibaba -Altra -AmazonRDS -Analytics -Anonymized -ArmDeveloperEcosystem -ArmNN -ArmRAL -ArmvX -Atomics -Autovectorization -Avnet -BCM -BDA -BLAS -BLE -BLS -BLX -BLXNS -BOOTSEL -BSP -BTI -Baremetal -BasicTests -Bbook -Benchmarking -Bitstream -Breakpoint -Broadcom -Buildspec -CAS -CASP -CDE -CFF -CGNAT -CIDR -CIFAR -CLCD -CLR -CMP -CMakeLists -CNTPS +cpio +cpp +cpp's +CPPLibRecommend +CPPLibVersion +cppreference +CPPStdCodes +cprj +cproject CPTR +cpu +cpuhp +cpus +CPUs +CPUx +cpython +CPython +CPython's +CPzfYHdpQ +CQL +cqlsh +CQLSH +crc CRC +createBitmapFromGrayBytes +CreateComponent +CreateDeployment +CreateDevice +createIndex +CreateIoTResources +CreateJob +CreateKeysAndCertificate +CreateMauiApp +CreatePolicy +createResponse +CreateRole +CreateRoleAlias +CreateS +CreateSecret +createSnsTopic +CreateThing +CreateThingGroup +CreateTokenExchangeRole +CreateWorkload +CreatingConnecting CRNN +Croci +cros +crosh +CrossCompile +CrossEntropyLoss +Crostini +crt +crypto +Cryptocell +cryptographic +cryptographically +csd +csh +csharp +cshtml CSI +csn +csolution +csp CSP +csproj CSPs +css +CSSv +cstdint +csv CSV CTC CTL -CUbe -CallStack -Callee -Callout -Callstack -CanaKit -Cbook -ClickBench -ClickHouse -CloudFormation -CloudWatch -Cloudflare -CodeBuild -Codec -Compr -Congatec -CoreSight -CosmicNvim -Coursera -CreatingConnecting +ctools Ctrl +CTX +ctypes +CUbe CubeAI +CubeCLT CubeIDE CubeMX +cuBLAS +cuda +CUDA +cuDNN +cursorTest +CustomData +CustomDataSources +customizable +cv +CvCameraViewListener +CvType +cwd +cx +CXL +cxp +CXX +CXXFLAGS +cyclonedds +cycloneDDS +CycloneDDS +da +dai DAIF +Damo +DAP DAQ +DarkArms +darko DARMRAL -DBOOST -DBUILD +darwin +Das +databinding +datacenter +DataCollatorForSeq +DataContext +datadir +dataflow +DataFrame +Datagram +dataloader +DataLoader +DataPoint +DataPoints +DataReaders +datascience +dataset +Dataset +datasets +datatracker +DataWriters +dawid +Dawid +dawidborycki +dawnwebgpu +DawnWebGPU +daytona +Daytona +DB's +DBAREMETAL +Dbook +DBOOST +DBUILD +dbus DCMAKE +DComponent +DCPerf +DCPS DCROSS +DCT +dddd +ddi +DDR +ddt +DDTHH +de +deadsnakes +Deadsnakes +deallocate +deallocated +deallocations +deamon +dearmor +deasserts +debconf +debian +debootstrap +debounce +debuggability +debuggable +DebugMon +dec +DecisionRequester +DecisionRequesterComponent +declaratively +declspec +decompositions +decrypts +deepseek +DeepSeek +defaultConstruct +DefineOtherArch +defsym +DEIGEN +DeleteThingShadow +deliverables +demangle +demoserver +denoised +Denoiser +Denoises +denoising +denormal +Denormal +denormalized +DEP +deployable +DeployDevTools +deps +DESC +Descamps +DescribeEndpoint +DescribeJob +DescribeRoleAlias +DescribeThing +DescribeThingGroup +DesktopApp +detections +detectMultiScale +DetectNet +dev +devblogs +devcon +DevCon +devel +developerguide +devfreq +devgen +devguide +deviceId +devicelogin +devicem +devkit +devlink +devops +DevOps +devsummit +DevSummit +devtools +DEXECUTORCH +DFP +dg +dgemm +DGGML DHCP +diagnosticDataCollectionDirectorySizeMB +differentiator +differentiators +DigiKey +digilent +Digilent +digitalWrite +Dimensity +DIMMs +DIMPL +DingTalk +dir +DirectX +Disambiguating +disass +DischargeRate +diskio +DispatcherUnhandledException +Disqus +distilbert +DistilBERT +distributables +distro +distro's +distros +DiT +diy +djangoproject +dl DL +dLayer +dll +DLL +DLLAMA +dllexport +dllimport +DLLs +dlrm +DLRM +DLRMv +dm +dma DMA +dmesg +dmg +dmS +Dn +DNDEBUG +dnf +DNN +DNNL +DNQZJ +dns +DNS +doBeep +Dobrescu +DoCharactersPlain +Docker's +dockerd +Dockerfile +Dockerfiles +dockerhub +DockerHub +dockerignore +docstring +DOCUMENTDB +DOF +Doker +DOM +donothing +DONT +DontDestroyOnLoad +DoSetup +dotenv +dotfiles +dotnet +DotNet +dotnettools +dotprod +dotProduct +doumentation +DoWallsBurst +DoWallsNeon +DoWallsPlain +doxygen +dp +dpaa +Dpdsv +dpkg +Dpldsv +Dpls +Dplsv +dpsv +Dpsv +DPUs +DPYTHON DQS +DragonBoard +drcachesim +DRM +Dropbear +dropdown +Drozd DS DSI DSL +Dsouza +dsp DSP DSPs +dst DSTREAM -Dataset -Dbook -DigiKey -Digilent -DockerHub -Dockerfile -Doker -Dpdsv -Dpldsv -Dplsv -Dpsv -ECDSA -ECR -ECS -EKS -EL -ELR -EOIR -EOR -ETM -EVR -EXCTRC -Ebook -Eg -Eijkhout -Epdsv -Epsv -EventRecorder -EventStart -EventStop -FFR -FFmpeg -FIQ -FPMATH +DSU +DTEST +DTFM +DTLB +dtype +du +dui +dumpbin +durations +dwc +DWORD +dx +dxecore +DxeCore +dxp +dy +dygraph +dylib +DynamicCollisionCalculations +DynamicCollisionObject +dynamicCollisions +DynamIQ +dynamodb +dynamoDb +DynamoDBClient +DynamoDBDocumentClient +DynamoDBv +dynamorio +DynamoRIO +dyno +eab +eabi +eastus +EastUS +Ebook +eBPF +EBS +ec +ecdsa +ECDSA +ecosse +ecr +ECR +ecs +ECS +ecurity +ECUs +EDA +EdgeAI +edgeimpulse +EdgeImpulse +EdgeImpulseLinuxRunnerServiceComponent +EdgeImpulseRunnerRuntime +EdgeImpulseRunnerRuntimeInstallerComponent +EdgeImpulseServiceComponent +edk +EDK +edma +edmgr +edu +Edudzi +ee +ef +EFI +eg +Eg +egion +ei +eigen +Eigen +Eigen's +Eijkhout +eiparams +eks +EKS +eksctl +el +EL +elapsedTimer +ElastiCache +electronjs +ELFMAP +Elham +eliemichel +Elo +ELO +ELR +embeddings +eMMC +emmintrin +empy +enableEdgeToEdge +enablement +enableView +encodings +endian +endif +EndpointsApiExplorer +EndSample +entrypoint +ENU +enum +enums +env +envoyproxy +EOF +EOIR +EOR +EPAC +Epdsv +epi +Epsv +EPYC +eq +EQ +Equinix +esbuild +Esc +ESM +esr +et +etag +ETag +etcd +ETDump +eth +ethernet +ethosu +ETHOSU +ETL +etm +ETM +ETRecord +ETW +eu +eula +EV +eval +evb +evcli +Evcli +EVCLI +EventRecorder +EventSet +EventStart +EventStop +EVEX +evice +EVidence +EVK +EVR +EXCTRC +exe +ExecStart +executables +ExecuteNetwork +executionCount +executorch +ExecuTorch +exePath +ExitBootServices +exitCode +expf +explainer +expressjs +extendability +extensibility +extern +extractGrayScaleBytes +Exynos +EZ +ezstd +f'Predicted +facebook +facebookresearch +faceCascade +facedetection +FaceDetection +facto +fadd +failover +FAISS +fallbacks +fanless +fargate Fargate +Fargate's +FastAPI +FastCGI +FastLanguageModel +fastmcp +FastMCP +FastModelsPortfolio +faTjwFA +Favergeon +fb +fbfa Fbook -FreeRTOS -GCP -GDB -GIC -GICv -GKE -GL -GND -GOTO -GPIO -GPIOs -GPUs -GTC -Gbook -Geekbench -GetStarted -GettingStarted -GiB -Godbolt -Goto -GraphQL -HAILUCK -HDL -HPCG -HSST -HVEC -HammerDB -HelloWorld -HyperScan -Hyperscan -IOPS -IOSTANDARD -IPs -IPv -ISA -Imager -Immortalis -Incrementing -IndexReport -InnoDB -Intrinsics -JARs -JTAG -Javascript -Jetson -Jit -Junit -Jupyter -KA -KasmVNC -Khadas -Kitware -LD -LDXR -LEDs -LF -LPC -LPDDR -LPX -LSB -LSE -LSTM -LVCMOS -Lasiuk -Liliya -LinkedIn -LoadBalancer -Lua -Lzbench -MCU -MCUBoot -MCUXpresso -MJ -MJSynth -MLCommons -MLEK -MLPerf -MMX -MNIST -MPIDR -MQTT -MSB -MVE -MX -MXNet -Macrocell -Makefile -Mbed -MicrosoftTeams -Midgard -MobaXterm -MobilenetV -Mysql -Myvm -NEON's -NN -NeoVim -Neovim -Nginx -NoSQL -NonCommercial -Nucleo -NumPy -NvChad -OAuth -OCI -OCRv -OCR's -OLAP -ONEDNN -OTG -Ok -OpenGL -OpenJDK -OpenSSL -OpenShift -OpenVPN -OpenVSCodeServer -OpenWRT -Openocd -Overcommit -PCIe -PCRE -PMU -PRELOAD -PSA -PSTATE -PaddleDetection -PaddleOCR -PaddlePaddle -Pandoc -Pem -PemKey -Perf -Phytec -Pico -Picoprobe -Pinebook -Pinout -PkgConfig -Pmod -PostgerSQL -PostgrSQL -Postgres -Prefetching -Prereqs -ProjectExplorer -PuTTY -QBHOUSE -QEMU -Qemu -RANs -RDP -RGB -RHE -RMW -RO -ROP -RTL -RTOSes -RTX -RW -Ragel -Renesas -Repo -Retarget -RoI -Runtimes -SBC -SBCs -SCP -SCR -SCTLR -SDC -SDRAM -SG -SIMD -SIMDE -SIMDe -SMAX -SMIN -SPE -SPSR -SRAM -SSD -SSDs -STDOUT -STM -STMicroelectronics -STXR -SVTR -SWCLK -SWD -SWDIO -SWO -SWP -SWV -SYS -SaaS -SciPy -Seidl -ShareAlike -SingleStream -SoftwareComponents -Sparkfun -Src -Starlink -Strech -Subnet -SynthText -SysTick -SystemCoreClock -SystemCoreClockUpdate -SystemReady -TCL -TPC -TPROC -TVAL -TVM -TVMC -TargetBoard -TargetOptions -Tbrk -Tcl -TensorFlow -Tera -TestScenario -ThinkPad -TimerValue -Tk -Tkinter -Touchpad -Traca -TraceHalt -TraceRun -TraceSuspend -Tracepoint -Tracepoints -Traefik -Transactional -TrustZone -Tunings -UART -UDP -UGC -ULINK -ULINKplus -ULINKpro -UMAX -UMIN -USART -UlinkPlus -Uncomment -Uncompress -Undecoded -UnlockDiagnosticVMOptions -Unregister -Unselect -UseAESCTRIntrinsics -UserGuide -Utgard -VBAR -VIO -VLAN -VM -VPC -VPNs -VR -VREF -Vectorisation -Vectorscan -Verilog -VideoCore -Vimscript -Vitis -Vivado -Vulkan -WAL -Watchpoint -Watchpoints -Wayland -WebUSB -Wi -Wordpress -XDC -XGmSCVgb -XSA -XServer -XT -Xeon -Xilinx -Xorg -YAML -YCSB -YML -Yocto -ZYNQ -Zach -Zstandard -Zybo -Zynq -aaarch -abc -accelerometer -acknowledgements -acknowledgement -acnt -acq -ade -aei -ai -aks -alibabacloud -altra -amazonaws -ami -amperecomputing -ams -analyse -analytics -apache -apisix -archlinuxarm -argc -argv -armds -armips -armkeil -armlink -armv -asm -asoc -atomics -auth -authenticator -autoconf -automake -autovectorization -avh -awk -axi -az -azurerm -ba -backend -backends -backhauls -backtrace -balancer -basebackup -bazel -bcebos -bd -bechmarking -behaviour -benchmarking -bitfields -bitstream -bj -blas -blinky -boolean -bootloader -breakpoint -brianfrankcooper -buildspec -buildwithmatter -buildx -bursty -bz -centric -cfg -chmod -chromebooks -chroot -cicd -cifar -clair -clairctl -clickhouse -cloudflare -cmvp -codebuild -codec -colour -commandline -comparators -complier -conf -configdb -connectaddress -connectedhomeip -containerd -convolutional -corstone -cpp -cppreference -cpu -crc -crypto -cryptographic -csp -customizable -cwd -dataset -datasets -ddi -de -debuggable -dec -demoserver -devblogs -devicem -devkit -devsummit -dg -digilent -dm -dockerd -dotprod -doxygen -dpsv -dropdown -dst -du -dygraph -eMMC -eastus -ec -ecdsa -ecosse -ecs -eg -egion -eks -emmintrin -empy -encodings -endif -entrypoint -extensibility -ezstd -fadd -failover -fbfa -ffmpeg -filesystem -filesystems -findimage -fiqHandler -fno -fopt -fp -fpga -fputc -funnelling -gcov -gcovr -gdb -geekbench -ghrunner -gic -gitiles -gitlab -gke -godbolt -googleapis -gp -gperftools -gpio -graphql -grey -gz -gzip -hc -homescreen -hostname -hpcg -hugetlbpage -hugo -hyperloglogs -hyperscan -idealo -ifdef -ifndef -imagenet -imsages -incrementing -infoq -ini -inikep -initialised -innodb -inscount -instal -ìnstance -instrace -interruptible -intra -intrinics -intrinsics -ioc -ip -ips -ipynb -jarfile -jasand -jdhao -jpeg -jq -jre -js -jupyter -kafka -kan -kas -kasmtech -ke -keilstudiocloud -kustomization -kustomizations -lang -largefile -ld -ldadd -ldaddal -learningpath -learningpathall -learnings -libblas -libevent -libftdi -libinput -libinscount -libpcap -libtool -libusb -libx -linuxmadesimple -llvm -lopt -losetup -lr -lscpu -lse -lua -lzbench -mA -mPQ -maccdc -mainfest -maintopic -makefile -malloc -martech -matcher -mbed -mc -mcu -mem -memcached -memtier -memtrace -microSD -microbit -minicom -mkv -mlcommons -mlek -mlperf -mlplatform -mmult -mno -mnt -modelling -mongo -mongodb -moutline -mozilla -mpi -mr -msTicks -msec -msse -mstsc -msve -multiarch -mutex -mutexes -mxnet -mysql -mysqld -mysqlonarm -nano -nci -neoverse -neovim -nginx -nk -nmake -nn -nodejs -nopac -noteboook -nproc -nucleo -num -numpy -nvidia -nvim -nxp -objdump -ocr -ok -oneDNN -onnx -onnxruntime -ooffice -openSUSE -openjdk -openmpi -openocd -opensource -operatingsystems -os -osKernelStart -osThreadNew -osdb -ot -overfitting -pArm -pac -paciasp -paddleocr -pathing -pb -pc -pcap -pcre -pcse -pctl -pdf -pem -perceptron -perf -pico -pid -pinouts -png -polsl -postgres -postgresql -postprocess -postprocessing -prefetch -prefetching -preprocessing -prereqs -ps -psacertified -psv -publicIP -pwntools -px -pytorch -qcomm -qemu -qemuarm -qps -qualcomm -quickstart -raspberrypi -raspios -rb -rcpc -readthedocs -recognise -recordcount -redis -refered -refman -repo -reproducibility -resethandler -resizefs -resnet -retaa -retarget -retargeted -retargets -reymont -ropt -rpi -rpios -rsa -rtcTYRc -rtx -sao -sbin -scalability -scalable -scatterloading -scipy -sdeor -sed -selectable -semihosting -serverless -setenv -setuptools -shader -shaders -sharding -silesia -simde -sizeof -skilllevels -sku -skus -softwares -sourceforge -src -sse -sshd -ssl -startinstanceconsole -stateful -stcube -stdout -stm -stmicroelectronics -storedprocs -strcpy -su -subdirectory -submodules -subnet -subnets -subsciption -sudoers -sve -sw -sys -sysctl -systick -targe -tcl -tcp -tensorflow -textfile -tflite -tflow -tfm -tfvars -th -theartofhpc -thundra -tinyML -tmp -toolset -tooltip -totalcompute -touchpad -tracepoints -traefik -trustedfirmware -ttf -ttyACM -tvm -txt -uVision -uart -udemy -uf -ugc -ulink -ulinkPro -ulinkpro -uncheck -uncomment -uncommented -uncommenting -uncompress -unpredicated -unselect -unselecting -upto -url -userspace -vCPU -vCPUs -vcpus -vec -vectorization -vectorize -vectorized -vectorizing -vectorscan -virtualising -vm -vpc -vuln -watchpoint -watchpoints -waveforms -wb -wearables -webpage -webster -whilelo -wm -wordpress -workloada -wsl -xb -xda -xdc -xf -xfvz -xinitrc -xlarge -xml -xrdp -xsession -xunit -yaml -ycsb -yml -yocto -yoctoproject -yor -youtube -zEybNlwd -zenodo -zephyrproject -zlib -zstd -zybo -zynq -dl -cnf -mariadb -dockerhub -pArmtest -URI -unix -lso -ISV -chown -DTEST -DTFM -GNUARM -mps -axf -fvp -ns -armswdev -suboptimal -interoperable -prepended -instantiation -woa -rds -mbranch -bsp -clientcredential -kitware -al -ng -rtos -sha -shasum -simlimit -KiB -Memcache -Memorystore -MiB -Bitbucket -WindowsPerf -wperf -GitLab -vivaldi -nogpgcheck -dearmor -dpkg -gpg -keyrings -qO -utils -asc -fsSLo -gpg -keyring -keyrings -firefox -esr -DRM -woolyss -TVM's -windowsperf -subfolder -CIPD -SmartScreen -edmgr -pdh -Mediatek -Rockchip -Hetzner -Scaleway -DPUs -NICs -fanless -Sobel -simd -OpenCV -mavx -ACfL -Kasper -Mecklenburg -virtualized -el -semihosted -baidu -paddlepaddle -Makefiles -WDK -devcon -devgen -dotnet -WPF -NPU -MACs -unoptimized -ASTC -libGPUInfo -nav -TrustZone -TFLM -VHT -ssk -hsk -ubl -corelink -coresight -ci -immortalis -spe -mali -vht -fszI -youtu -NDK -dotProduct -uint -TextView -TextView's -Spack -MMU -SDDiskTool -ethernet -APK -OrangePI -orangepi -BuildProcess -orangePiOS -shortener -MTE -Dimensity -MediaTek -Ja -MTE -NqKE -abi -mte -ndk -pmZ -rst -hwcaps -softWare -Inspiron -Brossard -textinstall -Gubay -SDKDocs -cliinstall -htm -ral -IG -keygen -trgt -bstn -OCID -oci -githubusercontent -iaas -ipexplorer -STL -PETG -PLA -AGX -DragonBoard -HummingBoard -STL -ENU -FDM -autodesk -dp -Rosewill -Balena -balena -Grafana -OpenBalena -ggcRootPath -hV -iotcore -pubsub -csolution -gcp -msql -jumpserver -AmazonECR -ecr -hs -ln -uvprojx -vcpkg -gb -iex -iwr -useb -armlm -KEMDK -ACfE -Recurse -USERPROFILE -rf -rmdir -Kitware's -ctools -myproject -myuser -mpacbti -IAP -Equinix -IaC -ArmIE -virtualizer -APIGW -TLS -prebuilt -integrations -Spawner -UnityMain -Gaskin -systemmetrics -Autoconnect -CubeCLT -mcux -mcuxpresso -wrk -psql -CFLAGS -CXXFLAGS -LDFLAGS -openssl -Pulumi -pulumi -overcommit -cprj -FFT -LAPACK -libamath -libastring -dsp -tolerations -Tolerations -Bakre -Pranay -EPAC -SIMDEverywhere -Descamps -Frédéric -lefred -VCN -HeatWave -DESC -TIMECREATED -ocid -gbs -ocpus -nic -vnic -OCPUs -ocp -HashiCorp -php -Elham -Harirpoush -snapshotting -maxclients -maxmemory -Pipelining -pipelining -OOM -swappiness -THP -ElastiCache -MemoryDB -AMBA -LinuxPerf -mitigations -Beyls -Kristof -endian -fb -armlearningpaths -visualisation -llsoftsec -llsoftsecbook -libthread -aaaaaaaa -aaaaaaab -xaaaaaaaa -xaaaaaaab -xfffffffff -fffffffff -fffff -xaa -ffe -disass -ldp -ldrb -mov -plt -sp -stp -nexti -gx -adrp -fc -ldr -str -wzr -Phrack -ASLR -DEP -PAPI -papi -edu -icl -utk -wikipedia -EventSet -IPC -TRM -ORing -MSR -libpfm -eBPF -JNI -pmuserenr -MPU -Uma -Ramalingam -topdown -eksctl -sLO -Wl -lpapi -rpath -alibaba -pmu -PJDOC -SDP -Lookaside -TLB -DynamoRIO -drcachesim -dynamorio -mispredicted -lookaside -devel -glibc -procps -PACBTI -gatord -awscli -dns -Borycki -Dawid -rg -pds -WebApp -AllowAnyCustom -Konstantinos -Margaritis -VectorCamp -ASIMD -enum -solaris -Spickett -Allocator -allocator -pseudocode -struct -allocators -tradeoff -tradeoffs -unallocated -deallocate -prepend -initialise -ptr -LLSoftSecBook -nodeSelector -KMDF -DevCon -LXD -RME -CCA -AEM -Kconfig -buildroot -RMM -Bolt -PGO -llvmorg -latencies -algorithmica -colin -gistcomment -jboner -permalink -scott -SDD -Gbps -datacenter -mispredict -roundtrip -facto -DIMMs -cca -rme -JXrNkYysuXw -enablement -xA -xFFFFFFFF -gpc -rl -GPT -GPTBR -GPCCR -GPC -GPTSZ -PGS -VTTBR -xBxxxxxxx -xxxxxxx -JAX -Keras -jax -keras -Deadsnakes -CPython -Leandro -Nunes -Initializers -Optimizers -rebases -optimizers -IMDB -djangoproject -WSGI -Gunicorn -gunicorn -envoyproxy -hugetlbfs -Pprofdata -profdata -profraw -Xing -Zhengjun -CNCF -Lyft -microservices -VwbgFSoy -fargate -hBHf -microservices -ySm -Fargate's -LearningPath -Przemyslaw -Wirkus -pe -Googolplex -PDB -DLL -si -PCbuild -cpython -CPython's -deployable -azurecr -webapp -RBAC -cheatsheet -Sysbench -Liu -AutoFDO -ghi -fdata -dyno -hfsort -relocations -etm -itrace -strobing -autofdo -facebook -unstripped -Pagefind -ARG -ARMCM -ARMSC -AgentDrArm -AgentS -Arpad -AspNetCore -BOLT's -BUILDPLATFORM -BattleEnvController -BattleMode -BenchmarkDotNet -BossBattle -BusFault -Cclass -CollectObservations -ContainerGroup -DFP -DebugMon -DevSummit -Dockerfiles -DotNet -ELO -EastUS -Elo -FLINK -FPU -FixedUpdate -Flink -Gameplay -HandsOn -HardFault -Heirachy -ITM -JVM -JobManager -JobManagers -ListSorting -MLP -MemManage -MlAgents -NETCore -NEXMark -NMI -NPC -NPCRayPerceptionSensor -Nexmark -OnActionRecieved -PDSC -PPO -PendSV -PerformanceHelper -PerformanceTests -ResetScene -ResourceGroup -STDERR -STDIN -SVC -SquareMatrixMultiplication -StringOperations -TTY -TZ -TaskManager -TaskManagers -Tensorboard -TypeScript -UI -UsageFault -WORKDIR -WindowsDesktop -WoA -Ying -Yu -ZZa -aci -alos -appsvc -aspnet -aspnetapp -borycki -brian -codeproject -configureAgent -const -cproject -csharp -cuda -devicelogin -devops -dll -dockerignore -dotnettools -enums -extern -faTjwFA -flink -futher -gitignore -gpus -hyperparameters -hypertype -installazurecliwindowsx -itemName -jobmanager -joysick -localdir -mcr -mlagents -msi -nexmark -nl -npm -ppo -protobuf -pypa -rocksdb -rpc -runtimes -scp -sct -sql -substring -tensorboard -trialCount -vcpu -visualSilicon -wchar -winget -nightlies -dawid -programmatically -checkmark -jpg -peds -MIPI -UHS -TensorRT -Jetson -nv -orin -sdCard -DetectNet -balenaEtcher -underperform -APerf -aperf -jetson -nv -sdCard -Bfloat -bfloat -freecodecamp -codecs -libvpx -gaussian -stdint -cstdint -nd -qtexamplesandtutorials -modularized -performant -affine -Affine -XFormWidget -runAnimation -QElapsedTimer -xform -XFormView -runAnimation -QElapsedTimer -animateClick -runAnimation -QTransform -setMatrix -elapsedTimer -qDebug -QtCreator -QPushButton -addHandler -addSignal -runAnimationButton -DLLs -ctypes -VSTs -vsts -UIs -CMakePresets -PySide -chrono -iostream -namespace -performCalculations -pragma -precompiler -generateRamp -len -msElapsedTime -startValue -generateSignal -getInputSignal -getInputSignalAfterFilter -getSignalLength -inputSignal -inputSignalAfterFilter -initializer -runTruncation -runVectorCalculations -prepareSeries -MainWindowWidget -repos -msdn -HeadlessIoT -IoTController -SensorReading -isActive -TimeStamp -ISensor -HOWTO -libhugetlbfs -hugepages -manpage -sysbench -meminfo -CXX -ELFMAP -HUGETLB -TPS -apk -deallocations -logcat -MTESERR -SEGV -SIGSEGV -GetCurrentReading -TemperatureSensor -lastKnownReading -AddSingleton -EndpointsApiExplorer -SwaggerGen -ControllerBase -temperatureSensor -webapi -webapiproject -FFTs -fft -Linaro's -bytecode -MSC -vectorizable -autovectorizable -autovectorized -autovectorize -vectorizer -Reflowing -callee -inlining -Autovec -GGC -Schmitz -Vectorizers -accg -hpac -se -sem -ssa -umu -wchars -Kitwares -arduino -uv -uvmpw -libhugtlbfs -mcpu -NoLSE -AEMvA -ActAgent -AgentDrArmComponent -AgentsSettings -AppManager -ApplyMlMovement -AttributeError -BaseViewModel -BehaviorParametersComponent -BehaviourName -BehaviourParameters -BindingContext -CEF -CEF's -CanExecute -CanExecuteChanged -Cinemachine -CollateObservations -Compiling Dictionary... -ComputationTime -ContentPage -DComponent -DOM -DataPoint -DataPoints -DecisionRequester -DecisionRequesterComponent -DesktopApp -DirectX -DontDestroyOnLoad -ESM -EZ -FMADD -FontSize -FontWeight -GEMV -GenerateRandomMatrix -ICommand -INotifyPropertyChanged -ISB -JSONPlaceholder -LINQ -ListBox -LongPath -MLAgents -MLPlayerManagerComponent -MLPs -MVVM -MainPage -MainViewModel -MainWindow -MatrixHelper -MatrixMultiplication -MaxStep -MeasurePerformance -Misspelled words: -MlPlayerManager -MobileApp -MonoBehaviour -Multilayer -NextDouble -NuGet -NumberBox -NumberBoxExecutionCount -NumberBoxMatrixSize -NumericUpDown -OnActionReceived -OnLaunched -OnPropertyChanged -PFR -Perceptrons -PlayerInput -PlotResultsCommand -PropertyChanged -RESTful -RayPerceptionSensor -ReadyToPlay -Realtime -RunCalculationsCommand -Running Task: Markdown... -SME -SMSTART -SVCR -SVL -SerializeField -SetProperty -SettingsController -SfChart -SimpleCommand -Syncfusion -TFP -TODO -TableLayoutPanel -TargetType -TensorBoard -TextBlock -Theobald -ThirdPersonCameraMovement -Timestep -Typicode -UWP -UnityEngine -Using aspell to spellcheck Markdown -VfxService -ViewModel -ViewModels -Walkthrough -WinForms -WinUI -WinUIApp -WindowsForms -XAML -XY -XamarinForms -Xn -ZA -ZT -appOutDir -archs -async -axios -bitfield -blockMapFile -blockmap -bool -buttonStart -ce -cef -chromiumembedded -codebase -coe -computationTime -computationTimeHistory -distributables -doumentation -electronjs -executionCount -firstrun -gameplay -halfwords -incentivize -isPlayer -jQuery -jsonplaceholder -labelArchitecture -listBox -listBoxResults -mana -matLeft -matResult -matRight -matmul -microservice -mvvm -netdesktop -nsis -numericUpDownExecutionCount -numericUpDownMatrixSize -oneClick -onwards -perMachine -pypi -raycast -realtime -resizable -scrollable -sindresorhus -timeScale -toolkit's -windowsarm -winforms -winui -xamarin -xaml -advancedweb -buzzerPin -Compiling Dictionary... -cpio -digitalWrite -doBeep -gzipped -hu -initramfs -ino -kvmtool -ledOff -ledOn -ledPin -linenos -linenostart -MicroPython -Misspelled words: -motionPin -motionState -peizo -pir -PIR -pratapkute -println -PWM -RaspberryPi -skillset -supervisord -UARTs -USD -webserver -AEMs -NLP -BFloat -TLP -lookups -AoS -SoA -acle -advsimd -autovectorizing -wavefunctions -Structs -structs -unfused -AAarch -Attr -osThread -osThreadPrivileged -MBL -MML -NPCs -astcenc -lossy -HWCPipe -Framebuffers -RenderDoc -FN -RZ -VVEW -BoatAttack -DarkArms -UnityTechnologies -malideveloper -occlusionculling -openglessdk -paretrace -texturedteapot -Streamline's -apc -huggingface -machinelearning -summarization -RoBERTa -PickerDomain -RayTracing -viewport -unrealengine -LOD -vr -LRU -framebuffer -VSE -reshading -neighbouring -neighbours -performancestudio -AFRC -Khronos -TLAS -swapchain -FMA -variadic -svld -kotlinlang -LinearLayout -armsve -kotlin -runCalculations -bitrate -VkImageCompressionPropertiesEXT -VkImageSubresource -vkGetImageSubresourceLayout -KhronosGroup -adoc -AFBC -VkImage -VkImageCreateInfo -VkImageFormatProperties -VkImageCompressionControlEXT -BPC -Sponza -VK -VkDeviceCreateInfo -vkCreateDevice -vkEnumerateDeviceExtensionProperties -URP -BurstNeonCollisions -SampleScene -AABB -AABBs -autoconnect -PlayerLoop -ScriptRunBehaviourUpdate -MonoBehaviours -BehaviourUpdate -Alloc -GC -BurstNeonCollisions -CollisionCalculationScript -BeginSample -Gfx -WaitForPresent -EndSample -codeMode -Vn -CollisionMovement -ScreenWriteout -numChar -MoveClearFromCharacters -MoveClearFromWalls -RandomMovement -BurstCompile -IJob -dynamicCollisions -ScriptHolder -AOT -AggressiveInlining -Bitwise -BurstNeonCalculationScript -Compiling Dictionary... -DoCharactersPlain -DoSetup -DoWallsBurst -DoWallsNeon -DoWallsPlain -DynamicCollisionCalculations -DynamicCollisionObject -IsNeonSupported -MethodImpl -MethodImplOptions -Misspelled words: -Monobehaviour -NeonAABBObjCollisionDetectionUnrolled -NeonRadiusObjCollisionDetectionUnrolled -NoAlias -Running Task: Markdown... -ScriptHolder -SpawningScript -StaticCollisionCalculations -StaticCollisionObject -StaticCollisionObjects -Using aspell to spellcheck Markdown -VSTR -bitwise -collisioncalc -detections -foreach -inlined -iteratively -occured -spawner -staticObjects -tblindex -vcgeq -vdupq -vld -vmvn -vorrq -vqtbl -vqtbx -wmvn -ALSA -AdditionOfProduct -AppShell -ChatGPT -ChatGPT's -Chatbot -CreateMauiApp -HWCAP -ListView -MTE's -MacCatalyst -MainActivity -MauiApp -MauiProgram -OpenAI -OpenAI's -PRIXPTR -PROT -Picovoice -Picovoice's -PostProcessVolume -SIGINFO -SPI -ShellContent -Sysreport -TCF -Tizen -VectorHelper -addr -aplay -arecord -arg -args -bitmask -csproj -fmt -ftrace -getauxval -gpt -hdr -hwrt -lifecycle -lx -maui -memset -mmap -nFreeing -nProgram -nTrying -picovoice -prctl -randomise -sa -segv -selft -sig -sigaction -sigemptyset -siginfo -signo -subfolders -syscall -tracepoint -typedef -uintptr -un -untagged -untagging -va -vprintf -wich -xfffe -AHB -ALLE -ATF -BuildKit -ButtonClearResults -ButtonRunCalculations -CADI -CFGM -CMN -CMOs -Cacheable -ChartData -DSU -DataContext -DispatcherUnhandledException -EDK -ExecStart -ExitBootServices -FIP -FV -FVMAIN -Ffs -Fv -GCD -GID -GuidedSectionTools -ITLB -InRelease -InitializeComponent -JavaFX -LSU -Logfile -MCP -MainApplication -NVHPC -ObservableCollection -Og -OutDir -PARAM -PARAMS -PERIPHBASE -Pilar -Preconfiguring -Preselect -RAMFW -RdN -SLC -Skinnider -SockDir -Syncfusion's -TCMs -TLBI -TextBoxExecutionCount -TextBoxVectorSize -TriggeredBy -UEFI -UID -UTF -VECTOROPERATIONS -VectorOperations -aa -additionOfProduct -afa -amba -ap -atleast -aufs -autoremove -backports -bced -busybox -cea -cebbb -cgroup -cgroupfs -cmn -cond -css -dbus -debian -debootstrap -declspec -distro -dllexport -dllimport -dmS -edk -eu -eula -fcabcd -fd -fdts -fefff -fffa -fn -generateRandomVector -gerrit -getty -googlesource -hdlcd -hostnames -initscript -iomacro -journalctl -kB -launchpadcontent -libfdt -libmbedtls -libtinyxml -libvirtd -libwrapper -libz -logfile -logind -marshalled -mcp -measureExecutionTime -microarchitectural -mispredictions -needrestart -networkd -ni -peicore -periphbase -pilar -pts -pwsh -pygments -ramdisk -ramfw -rc -rdinfra -rdn -realpath -refdesign -refinfra -romfw -romlib -screenrc -scrits -scrollback -sockname -syncfusion -systemctl -termcap -tfa -tty -uefi -unselected -utmp -vis -vt -wpf -writeback -writebacks -xe -xeu -xy -zfs -zfsutils -zxf -CoreDebug -Cryptocell -GGUF -GenAI -Georgi -Gerganov -LLM -LLMs -STMU -TheBloke -XXS -quant -quantized -quantizing -impactful -symlinks -nlp -eval -datascience -chatbot -Guid -CoreLink -Kinesis -MQQT -PublishRetain -SensorReadings -WeatherEmulator -WeatherStation -WeatherStationEmulator -ats -awsConnectionInfo -basicPubSub -caPath -certPath -clientId -deasserts -deviceId -getRandomValue -isTelemetryActive -keyPath -msDelayTime -randomSensorReadings -rootCertDir -telemetryIntervalHandle -topicSensorReadings -topicTelemetryControl -topicfilter -uzbanvsz -DistilBERT -distilbert -BertTokenizer -tokenized -GEMM -MMLA -pareenaverma -changelog -OtherServices -amazondynamodb -dynamodb -DynamoDBv -cshtml -sampleapp -tagname -dawidborycki -lp -abetlen -ee -pkgx -mprof -rustc -binutils -RPi -GoogleTest -InstallAzureCLIDeb -sL -ExecuTorch -LLaMA -Eigen -Eigen's -eigen -UB -FX -Benoît -Guennebaud -KOffice -ACL -MKL -NCCL -NUMA -Preconfigured -bazelrc -configs -mkl -nogcp -nonccl -numa -SendNotification -SNS -sns -SendNotification -subscribeEmailToTopic -AWSthat -Altivec -AmazonSNSFullAccess -AppleClang -Arnaud -Bcmake -CERN -CMakeFiles -Calligra -Celestia -Chari -CodeBlocks -CodeLite -DEIGEN -DEXECUTORCH -DNDEBUG -DONT -DPYTHON -EQ -GTest -GTestConfig -GTestConfigVersion -GTestTargets -Grandmaison -Groupwise -Hadron -Homebrew -Ieigen -Krita -LDLT -LHC -LLT -LM -LlamaDemo -MSA -MatComp -MeshLab -Meta's -Miniconda -Mul -NxM -PTHREAD -PTQ -ROCm -SMS -SNSClient -SNSFull -SYCL -Sqrt -TTK -TutorialMatrixClass -Unary -VSX -Varun -WikiText -Wikitext -Wno -XNNPACK -Xcode -ZZZZZ -activations -belows -binaryOperator -booleanConversion -ccache -chatbots -copyAssign -copyConstruct -createSnsTopic -decompositions -defaultConstruct -embeddings -executorch -extendability -fillConstruct -functionalAdd -functionalDotProduct -functionalSub -getElement -getNumColumns -getNumElements -getNumRows -getSizeInBytes -getVersion -gmock -googlemock -googletest -gradle -groupsize -groupsizes -groupwise -gtest -hardcoded -homebrew -inPlaceAdd -inPlaceDotProduct -inPlaceSub -initializerListAssign -initializerListConstruct -libeigen -libexec -libgmock -libgtest -linkers -markos -matchers -minimalistic -mjs -moveAssign -moveConstruct -notEqual -params -pkgconfig -pretrained -representable -setElement -sqrt -tiktoken -tokenizer -torchao -typedefs -unary -unaryOperator -uninitializedConstruct -whitepapers -xN -OgMk -vrr -AE -Boundness -CBOR -Gemma -HuggingFace -KLEIDIAI -Kaggle -Kleidi -KleidiAI -KleidiAI's -MPKI -MediaPipe -Starlark -Stech -ThirdAI -ThirdAI's -ThirdAILabs -UniversalDeepTransformer -XLSX -XNNPack -XXXXXXXXXXXXXX -atlassian -cancelled -cdn -chipset -genai -inode -kleidi -kleidiAI -linkstatic -llm -lts -mediapipe -microarchitecture -mispredicts -opencv -pathologies -rpms -sl -strobed -tgz -thirdai -untar -xnn -xnnpack -xzf -MacBook -AdaBoost -AndroidManifest -AppCompatActivity -CNNs -Caffe -CameraBridgeViewBase -CascadeClassifier -CheckBox -CvCameraViewListener -CvType -DNN -FaceDetection -Haar -IOException -ImageView -Imgproc -JavaCameraView -MatOfRect -Multibox -OpenCV's -OpenCVLoader -RGBA -UC -YOLO -buttonStartPreview -buttonStopPreview -cameraPermissionRequestCode -checkBoxProcessing -detectMultiScale -enableEdgeToEdge -enableView -faceCascade -facedetection -filesDir -findViewById -frontalface -getPath -grayFrame -grayscale -haarcascade -initLocal -isOpenCvInitialized -isPreviewActive -loadHaarCascade -onCameraFrame -onCameraViewStarted -onCameraViewStopped -onClickListeners -onCreate -openCV -openCvCameraView -opencvcamera -opencvfacedetection -setCameraPermissionGranted -setContentView -textViewStatus -thresholding -updateControls -AAR -Artifactory -SoCs -TFLite -artifactory -asymm -memTagMode -memtagMode -Adnan -AlSinan -BPF -DCT -DDTHH -DOF -DynamoDBClient -DynamoDBDocumentClient -Exynos -FMLA -FMOPA -FilterExpression -GetAverageTemperature -Helio -LHS -LLM's -LODs -LTO -NVL -OPPO -PBR -POSIX -RHS -ReLU -SMMLA -ScanCommand -Vivo -Xiaomi -YYYY -Yitian -beabd -bpftool -cefcc -cx -cxp -dx -dxp -dynamoDb -explainer -fDCT -formattedTimeThreshold -gendignoux -ie -intructions -kai -kleidiai -libbpf -libelf -microkernel -microkernels -processwatch -qa -qai -qsi -quantizes -requantization -ss -sssZ -timeThreshold -uKernel -ukernels -Axion -Basma -CNI -EVK -Gaabouri -Gayathri -KPI -Narayana -Narayanan -PMUv -Petclinic -Yegna -baeldung -cni -containerd's -ghcr -imx -javase -jmeter -jmx -jtl -jvm -libs -petclinic -signup -ut -warmup -AOM -ARNs -AdministratorAccess -AmazonS -Arial -AwsServerlessDynamoDbLambda -AwsServerlessLambda -BatchWriteCommand -BatchWriteItem -CORS -CommonJS -FHD -GetItem -IoTPage -PutItem -Renderer -Shen -UpdateItem -WebM -WebsiteHosting -flexbox -getAverageTemperature -libaom -writeTemperatures -ACCP -AES -ArmCompilerforEmbedded -JMeter -LocalAppData -Microsystems -ProgramFiles -ThreadStackSize -UseTransparentHugePages -UserProfile -configurability -darwin -dmg -madvise -osKernelInitialize -Alexandros -CopyWord -Lamprineas -Multiversioning -SkipWord -Tallund -VoD -autocomplete -ifunc -ifuncs -lm -memcpy -multiversioning -AwsServerlessDynamoDbLambdaS -BLASes -BVH -Bindless -Calvo -Chowdary -CloudFormation -GDC -GLSL -Helpbox -Lista -LttE -Malhotra -Mandepudi -Nikhil -OPLTK -Rasterization -Ravi -Refractions -Rohr -RunsOn -SSR -Streamlit -TLASes -TorchAO -Torchchat -Vulkan's -Vulkanised -WebsiteBucket -aaaa -barycentric -bindless -bonza -calvo -chatbot's -createResponse -denoising -getAverageTemperatureButton -getAverageTemperatureUrl -jJyHzkWXEfY -lista -param -prismjs -quicktool -rasterization -rasterized -refractions -renderer -skybox -specular -ssr -streamlit -stylesheet -torchchat -tps -uQ -vulkan -vulkanised -writeTemperaturesUrl -IPython -NeuralNetwork -Sigmoid -Softmax -Tanh -backpropagation -diskio +fc +fcabcd +fcb +fd +fdata +fDCT +FDM +fdts +FeaturedContent feedforward -logits -prem -softmax -subclassing -tanh -torchsummary -BatchNorm -CrossEntropyLoss -DataLoader -Dobrescu -ImageNet -MCA -MSE -RThroughput -Rin -SGD -TorchScript -argmax -certifi -dataloader -figsize -hyperparameter -jit -matplotlib -mca -optim -preprocess -preprocessed -pth -pyplot -scheduler's -torchvision -uOps -unsqueeze - -ACR -Abena -Adoptium -Amanfo -Arlo -Fitbit -Milvus -Amanfo -OCTLA -OpenAg -Sysbox -TCK -TOSA -Temurin -Zhang -Zilliz -arrhythmias -ggerganov -milvus -msbuild -nestybox -pte -replug -sam -sysbox -tinyml -tvOS -watchOS -zilliz -ASGI -ComputeLibrary -FastAPI -GTSRB -KubeArchInspect -MLOPs -MiniLM -OpenBLAS -Requantize -UpsideDownCake -Uvicorn -WPA -WindowsPerfGUI -ZGC -Zouaoui -gui -kubearchinspect -mlops -multithreading -preloaded -requantize -ADK -AbstRaction -Alaaeddine -Albin -AliCloud -Astra -Bernhardsson -BitBake -Chakroun -ColorAttachment -CommandEncoder -CustomDataSources -DawnWebGPU -ETL -ETW -GameActivity -Georgios -ISAs -Jetpack -KV -Koki -LearnWebGPU -Mermigkis -Mitsunami -Naga -NativeActivity -OpenGLES -Perfetto -Qwen -RSE -RTP -RenderPassEncoder -RenderPipeline -SECurity -SPIR -SType -StackOverflow -SurfaceView -TextureView -Thelio -Tianyu -TinyOBJLoader -Tmux -WGSL -WPR -WebGL -WebGPU -Xperf -andc -andnot -dylib -eliemichel -epi -intrinsic's -pApp -rtp -samdauwe -shaderCodeDesc -transpilation -usecase -varunchariArm -vbic -vbicq -webgpu -webgpufundamentals -wgpuQueueSubmit -wgpuQueueWriteBuffer -wgpuQueueWriteTexture -wpa -CAMs -CODENAME -COMs -Chaodong -CreateWorkload -Disqus -ExecuteNetwork -FPC -HX -Hejmadi -Himax -Kieran -LHwilBhvNU -LastWriteTime -LiteRT -OV -Seeed -WiseEye -Yolov -blp -dLayer -dawnwebgpu -dmesg -fm -himax -il -juXXgrDDaUdmi -mins -mobilenet -msvc -od -ons -scm -seeedstudio -sscript -tflm -tw -vc -videoio -wiseeye -wlcsp -xB -xmodem -yolov -Dsouza +fefff +fenv +ffe +fffa +fffff +fffffffff +ffmpeg +FFmpeg +FFN +ffplay +FFR +Ffs +fft +FFT +FFT's +FFTs +FFTW +ffx +FFXM +FfxmFsr FGCT -GCT -GCs -GC's -HNso -HeapRegionSize -HugePages -InitiatingHeapOccupancyPercent -JDKs -JVMs -LZMA -Lau -LuaJIT -NGFW -ParallelGCThreads -Preema -Roesch -Sourcefire -TPACKET -Whitepaper -YGCT -axion -callstack -et -gc -grubfile -jstat -mqF -netresec -parallelizing -profileable -profilers -ruleset -snortrules -techmahindra -unreferenced -uptime -wC -ApiService -AppHost -ArmPyTorchMNISTInference -Blazor -CameraX -ComputationService -Coroutine -EOF -EVCLI -EVidence -Evcli -GenerateMatrix -ImageCapture -InputStream -JWT -JetPack -KBS -MediaPipe's -Mongod -Multimodal -NNAPI -NPUs -NetAspire -OpenTelemetry -PIL -PerformIntensiveCalculations -ReactiveX's -ServiceDefaults -SharedFlow -Skopeo -StateFlow -TestOpenCV -TrustedFirmware -Veraison -WeatherForecast -weatherForecast -WebGPU's -Wiredtiger -androidml -ar -armpytorchmnistinference -codelabs -combinator -cooldown -coroutines -cryptographically -datatracker -debounce -decrypts -diagnosticDataCollectionDirectorySizeMB -eab -eth -evcli -googleblog -hanyin -honorSystemUmask -ietf -jsonviewer -keyFile -livestream -lockCodeSegmentsInMemory -matrixResult -matrixSize -maxIncomingConnections -mongod -mongosh -multimodality -multimodel -oplogSizeMB -optimizable -orchestrator -prebuild -preconfigured -relica -replSetName -rfc -serializable -setParameter -skopeo -subclasses -subproject -subproject's -subrepositories -suppressNoTLSPeerCertificateWarning -systemLog -tlsWithholdClientCertificate -unutilized -vLLM -veraison -verifier -vllm -observables -APL -ARchive -AllowUSBDebugging -CalcThreadProc -DWORD -Daytona +FHD +fi +fidel +figsize +filelock +filemap +FilePath +filesDir +filesystem +filesystems +fillConstruct +FilterExpression +findimage +findViewById +fio +Fio +FIP +FIQ +fiqHandler +firefox +firstlogin +firstrun +Fitbit +FixedUpdate +FlameGraph +flamegraphs +FlameGraphs +flatbuffers +FlatBuffers +flexbox +FlexLM +FlexNet +flink +Flink +FLINK +fLO +Florent +fm +FMA +FMAC +FMADD +FMLA +FMMLA +fmopa +FMOPA +fmt +fn +FN +fno +foir +FontSize +FontWeight +fopt +foreach +formattedTimeThreshold +fortran +Fortran +fourier +fp +FPC +fpga +FPGA +fpm +FPM +FPMATH +FPU +fputc +frac +framebuffer +Framebuffers Fraunhofer -HIWORD -IEC -ITU -Kibana -Koleini -LOWORD -LPVOID -Masoud -OpenMP -VVC -VVenC -ViT -WINAPI -Willen -applyRotation -boto -cblas -daytona -dgemm -dotfiles -dumpbin fraunhoferhhi +Frédéric +freecodecamp +FreeRTOS +Friedt +frontalface +frontend +FRONTEND +fsl +FSR +fsSL +fsSLo +fszI +ftrace +FullAccess +FunASR +FunASR's +func +functionalAdd +functionalDotProduct +functionalSub +funnelling +FurthestReflectionCaptureDistance +FuSa +FuseAll +FuseBlurAndThreshold +futher +Fv +FV +FVMAIN +fvp +FVP +FVP's +FVPs +FX +Gaabouri +GameActivity +gameplay +Gameplay +Gaskin +gatord +gaussian +GAxUDSKQEHfyWClAQFnoECA +Gayathri +gb +Gb +Gbit +Gbook +Gbps +gbs +GBuffer +gc +GC +GC's +gcc +GCD +gcloud +gcov +gcovr +gcp +GCP +GCs +GCT +gdb +GDB +GDC +GDM +GDPR +GDScript +ge +geekbench +Geekbench +GEMM +gemma +Gemma +GEMV +genai +GenAI +gendignoux +GenerateMatrix +generateRamp +GenerateRandomMatrix +generateRandomVector +generateSignal +geo +geomean +geomeans +Georgi +Georgios +geospatial +Geremy +Gerganov +Gerganov's +gerrit +Gershon +getauxval +getAverageTemperature +GetAverageTemperature +getAverageTemperatureButton +getAverageTemperatureUrl +GetByteArrayElements +GetCurrentReading +getElement +getInputSignal +getInputSignalAfterFilter +GetItem +getLastError +getmore +getMore +getNumColumns +getNumElements +getNumRows +getPath +getPipelinePermutationFlags +GetPolicy +getRandomValue +GetRole +getSignalLength +getSizeInBytes +GetStarted +getTempBtn +getter +GetThingShadow +GettingStarted +getty +getVersion +gfortran +GFortran +Gfx +ggc +GGC +ggcRootPath +GGDeploy +ggerganov +GGG +ggml +gguf +GGUF gh +ghcr +ghi +ghrunner +Gi +Gian +GiB +gic +GIC +GICv +GID gif +gistcomment +github +githubusercontent +gitignore +gitiles +gitlab +GitLab +gitpod +Gitpod +gke +GKE +GL +GLE +GLES +glibc +glink +GLSL +gmock +GND +GNUARM +gnueabihf +gnupg +godbolt +Godbolt +golang +Golang +GolangInlineAsm +GolangIntrinsic +GolangLinkLibrary +Golang’s +googleapis +googleblog +googlemock +googlesource +googletest +GoogleTest +Googolplex +Gopalakrishnan +GOPATH +GopherLua +Gorman +GOROOT +goroutines +gosort +Goto +GOTO +goweb +gp +gpc +GPC +GPCCR +gperftools +gpg +gpio +GPIO +GPIOs +gpiozero +gpl +gpt +GPT +GPTBR +GPTSZ +gpu +gpus +GPUs +gradle grafana -installable -kibana -pointStride -prometheus -refx -refy -refz -rotMatrix -sbt -scala -spherePoints -startPoint -terrafom -threadCount -threadNum -useAPL -vvenc -workspaces -ETDump -ETRecord -FAISS -IVI -PDFs -Powertrain -SpinTheCubeInGDI -TaaS -cloudsdk +Grafana +Grandmaison +graphql +GraphQL +graviton +Graviton +grayFrame +grayscale +greengrass +Greengrass +Greengrassc +GreengrassV +grey +groupinstall +groupsize +groupsizes +groupwise +Groupwise +gRPC +grubfile +gst +gstreamer +GStreamer +GTC +gtest +GTest +GTestConfig +GTestConfigVersion +GTestTargets +GTK +GTSRB +Gubay +Guennebaud +gui +Guid +GuidedSectionTools +gunicorn +Gunicorn +gupta +gx +gz +gzip +gzipped +Haar +haarcascade +hadoop +Hadron +HAILUCK +halfwords +halide +Halide +Halide's +Halton +HammerDB +handoff +Handoff +handoffs +HandsOn +hanning +Hanning +hanyin +HARA +hardcoded +hardcoding +HardFault +Harirpoush +HasExited +hashicorp +HashiCorp +hashmap +HashMap +Hawksbill +hBHf +hc +hcd +hCpeYsarnnGv +hdd +HDDs +HDL +hdlcd +hdr +HeadlessIoT +HeapRegionSize +HeatWave +Heirachy +Hejmadi +Helio +HelloWorld +HelloworldPublisher +HelloworldSubscriber +Helpbox +Hetzner +hfsort +hh +HHVM +Higham highcpu -proj -sln -uploader -AAPCS -AOvVaw -ASR -AoT -Authtoken -Bc -ConstraintLayout -DIMPL -DNNL -Damo -Disambiguating -FMMLA -FunASR -FunASR's -GAxUDSKQEHfyWClAQFnoECA -ImageOperation -ImageProcessor -Inductor -KleidiCV -ModelScope -NOPASSWD -OSCI -PMUs -PUNC -PWD -Paraformer -PerformanceMetrics -ProfilerActivity -QAQ -RemoteImage -STT -Sobel's -SystemC -VAD -VER -VL -VSIX -ViTFeatureExtractor -ViTForImageClassification -Webhook -YPQ -aG -aQsHmumnZykaFxM -aaa -aaaaa -adduser -afc -ahUKEwisi -alpineImage -asr -authtoken -autoregressive -baremetal -chpasswd -cn -codebases -combobox -compileSdk -csv -da -dai -databinding -deallocated -debconf -debuggability -defsym -demangle -durations -dy -f'Predicted -fcb -fmopa -fsSL +highmem +HIL +himax +Himax +HIPAA +HipHop +HIWORD +HLSL +HMMER +hns +HNso +hoc +homebrew +Homebrew +homescreen +honorSystemUmask +HostCpuDetection +hostid +hostids +hostname +Hostname +hostnames hotspot +hotspots +HOWTO +hpac +hpc +HPC +hpcg +HPCG +HPE +hs +hsk +HSK +HSKs +HSST +htm +html +http +httpbin +httpd +https +HTTPs +httpx +hu +Huai +hugeMethodLimit +hugepages +HugePages +HUGETLB +hugetlbfs +hugetlbpage +huggingface +HuggingFace +hugo +HummingBoard +hV +HVAC +HVEC +HVM +hw +HW +HWC +HWCAP +hwcaps +HWCPipe +hwmon +hwrt +HX +hyperloglogs +hyperparameter +hyperparameters +hyperscalers +hyperscan +Hyperscan +HyperScan +hypertype +iaas +IaC +iam +IAM +IAP +IAR +icl +ICML +icmp +ICommand +ide +idealo +IdentityFile +IDEs idx +ie +IEC +Ieigen +ietf +iex +ifdef +IFFT +ifndef +ifunc +ifuncs +IG +igor iic +IIoT +IIR +IJob +il +ILP +iMac +ImageCapture +imagenet +ImageNet +ImageOperation +ImageParam +ImageProcessor +Imager +ImageStreams +ImageView +IMDB +img +Imgproc +immortalis +Immortalis +impactful impl +ImportError +imsages +IMU +imx +inBytes +incentivize +IncompatibleHeaderFile +incrementing +Incrementing +IndexReport inductor +Inductor +inet inferencing +infoq +ini +inikep +init +initcall +initialise +initialised +InitializeComponent +initializer +initializerListAssign +initializerListConstruct +Initializers +InitiatingHeapOccupancyPercent +initLocal +initramfs +Initrd +initscript +InlineAsm +inlined +inlines +inlining +innodb +InnoDB +ino +inode +INotifyPropertyChanged inout +inPlaceAdd +inPlaceDotProduct +inPlaceSub +inputBuffer +inputSignal +inputSignalAfterFilter +InputStream +InRelease +inria +inscount +Inspiron instain +instal +installable +InstallAzureCLIDeb +installazurecliwindowsx +installtoolsall +ìnstance +instantiation +instrace +instrinsics +instrumentable +insturction +integrations +integrators +interop +interoperable +interruptible intr -kickstart -kleidicv -kleidicvdemo -lcrt -lsemihost -lst -modelscope -modularity -mymodel -nanoTime -nat -ngrok -nostartfiles -opi -paraformer -picolibc -preprocessor -punc -rct -recommender -rtti -semihost -sme -svcntsw -tvb -uninstallation -usermod -usg -vad -ved -ver -vit -wav -za -zh -ACM -APs -ASG -AutoModelForSpeechSeq -AutoProcessor -Avin -Bioinformatics -CDK -Dropbear -DxeCore -EFI -FFTW -HMMER -ILP -IoC -Jython -LCP -Maranget -Minimap -NFS -NVPL -OMP -OSR -OneAPI -OpenRNG -OpenSSH -Phttps -RNG -Runbook -SSM -Shrinkwrap -Shrinkwrap's -TSO -TSan -TSan's -ThreadSanitizer -Toolkits -ULP -ULPs -VSL -Yury -Zarlez -ada -armtest -atomicity -autoscaling -cmath -cuBLAS -cuDNN -distro's -dtype -dxecore -foir -fourier -getter -libm -miniconda -msg -nInferencing -oneAPI -oneapi -openai -pseudorandom -quasirandom -reorderings -rootfs -runbook -safetensors -superset -sysroot -testroot -threadsanitizercppmanual -toolchain's -transpiles -vectorstore -vlen -vv -webhook -xE -Baichuan -Checkpointing -Choi -CustomData -Das -DataCollatorForSeq -DingTalk -FFXM -FSR -FastLanguageModel -FeaturedContent -FfxmFsr -FurthestReflectionCaptureDistance -GBuffer -GLES -HLSL -Halton -JITTERED -JKS -Jitter -KHR -LoFTQ -LoRA -MNN -MSM -MTL -MaliManga -Mip -Mipmap -NDC -PEFT -Parichay -QLoRA -Qianwen -RCAS -RLHF -RelaxedPrecision -RenderTargets -SFT -SFTTrainer -ScreenPercentage -ShaderQualityMode -ShareGPT -Shuheng -TAA -Taobao -TemporalUpscaler -ThirdParty -Tmall -Tokenize -TrainingArguments -UVs -Unsloth -Upscaling -UpscalingRatio -VRAM -XD -Xianyu -Youku -Zhipu -aar -adamw -agentic -antialiasing -arxiv -csn -docstring -ffx -func -getPipelinePermutationFlags -ggml -hoc +intra +intrinics +intrinsic's +intrinsics +Intrinsics +intructions +ints +invalidations +io +ioc +IoC +Iodice +IOException +iomacro +iomap +iommu +iops +IOPS +IOSTANDARD +iostat +iostream +iot +IoT +IoT's +IoTController +iotcore +IoTCore +IoTDatabaee +IoTDatabase +IoTHubInput +iothubowner +iotop +IoTPage +IoTStreamAnalyticsJob +IoTTemperatureAlertFunc +ip +IPC +iperf +iPerf +ipexplorer +ipfrag +ipi +IPMI +ipmitool +ips +IPs +ipv +IPv +ipykernel +ipynb +IPython +irq +IRQs +IRQS +ISA +isActive +ISAs +ISB +IsEncrypted +ISensor +ish +IsNeonSupported +iso +isOpenCvInitialized +isPlayer +isPreviewActive +isTelemetryActive +Istio +ISV +itemName +iteratively +ITLB +ITM +itrace +ITU +IVI +iwr +Ja +Jalisco +jarfile +JARs +jasand +JavaCameraView +JavaFX +JavaJar +JavaPom +javascript +Javascript +javase +JavaServer +JavaSource +jax +JAX +Jayat +jbd +jboner +jbyteArray +jdhao +jdk +JDKs +Jetpack +JetPack +jetson +Jetson +JFR +JIRA +jit +Jit jitter +Jitter jittered +JITTERED jittering -lastestlora -luminance -mipmap -mnn -motionVectorScale -mutators -proc -qwen -raytraced -reactiveness -renderdoc -renderers -sharegpt -sym -tokenization -tokenize -tokenizes -tokenizing -tonemapped -tonemapping -trl -unjittered -unsloth -upscaled -upscalers -upscales -upscaling -vl -webbot -APKs -ASR's -DLRM -DLRMv -DeepSeek -Geremy -MERCHANTABILITY -MoE -NONINFRINGEMENT -NaN -OCPU -OCaml -Ollama -Ollama's -Prefill -Unsloth's -YAMLs -Yiyang -bartowski -bc -checkboxes -deepseek -diy -fenv -gguf -highmem -inria +jJyHzkWXEfY +JKS +jlowin +jmeter +JMeter +jmh +JMH +jmx +JNI +Joana +jobmanager +JobManager +JobManagers +joedog +journalctl +joysick +jpeg +jpg +jq +jQuery +jre +js +json +JSON +jsonplaceholder +JSONPlaceholder +JSONs +jsonviewer +JSP +jstat +JTAG +jtl +Julien +jumpserver +Junit +jupyter +Jupyter +juXXgrDDaUdmi +jvm +JVM +JVMs +jvmti +jwt +JWT +JXrNkYysuXw +Jython +KA +kafka +Kaggle +kai +kan +kas +kasmtech +KasmVNC +Kasper +kata +kB +KBC +kbs +KBS +Kconfig +KCS +KDE +ke +keda +KEDA +kedify +Kedify +Kedify's +Kedify’s +keil +Keil +keilstudiocloud +KEMDK +Ker +keras +Keras +keyFile +keygen +keypair +keyPath +keypress +keyring +keyrings +keyspace +Keyspace +keyspaces +Khadas +KHR +Khronos +KhronosGroup +KiB +kibana +Kibana +kickstart +Kieran +Kinesis +kitware +Kitware +Kitware's +Kitwares +kleidi +Kleidi +kleidiai +kleidiAI +KleidiAI +KLEIDIAI +KleidiAI's +kleidicv +KleidiCV +kleidicvdemo +KMDF +kmem +KOffice +Koki +Koleini +Kompanio +Konstantinos +Kordorwu +kotlin +kotlinlang +KPI +KRaft +krishna +Kristof +Krita +ksm +kts +kubearchinspect +KubeArchInspect +kubectl +Kubectl +kubernetes +Kubernetes +Kuo +kurtosis +kustomization +kustomizations +KV +kvm +KVM +kvmtool +kvssink +kyber +labelArchitecture +Lamprineas +lang +LANs +LAPACK +largefile +Lasiuk +lastestlora +lastKnownReading +LastWriteTime +latencies +Lau +launchpadcontent +LCP +lcrt +ld +LD +ldadd +ldaddal +LDFLAGS +LDLT +ldp +ldr +ldrb +LDXR +le +Leandro +learnable +learningpath +LearningPath +learningpathall +learnings +learnt +LearnWebGPU +Lebeau +ledOff +ledOn +ledPin +LEDs +lefred +len +Lenovo +LF lfs -lora -ollama -opam -perceptrons -personalization -rclone -screenspace -significand -stdbuf -sublicense -tok -truncations -ulp -unmangled -unportable -zeropoint -AO -Autoware -CCC -ECUs -HTTPs -Hawksbill -HelloworldPublisher -HelloworldSubscriber -IMU -Jalisco +lgpio +LHC +LHS +LHwilBhvNU +Liang +libamath +libaom +libastring +libata +libblas +libbpf +libc +libcrypto +libcurl +libeigen +libelf +libevent +libexec +libfdt +libftdi +libgmock +libGPUCounters +libGPUInfo +libGPULayers +libgtest +libhugetlbfs +libhugtlbfs +libinput +libinscount +libm +libmagic +Libmath +libmbedtls +libomp +libpcap +libperf +libpfm +libray +libs +libssl +libstreamline +libtensorflowlite +libthread +libtinyxml +libtool +libusb +libvips +libvirtd +libvpx +libwrapper +libx +libz LiDAR -OTA -OpenAD -OpenADKit -ROS -RViz -Rviz -SDV -SDVs -SOAFEE -SSO -Veraison's -amazonq -autoware -autowarefoundation -casted -certifiability -codewhisperer -cyclonedds -distros -dlrm -musl -openadkit -printenv -qdeveloper -ros -rviz -testbed -ug -vnc -Acyclic -Bedrust -MLPerf's -bedrust -darko -mesaros -multilayer -renderbuffer -rosdep -suboptimally -AMQP -AirQualityIndex -AzureFunctions -AzureIoT -AzureWebJobsStorage -CosmosDBOutput -DOCUMENTDB -IoTDatabaee -IoTDatabase -IoTHubInput -IoTStreamAnalyticsJob -IoTTemperatureAlertFunc -IsEncrypted +lifecycle +Liliya +linaro +Linaro +Linaro's +linaroforge +LinearLayout +linenos +linenostart +LinkedIn +linkers +linkstatic +LINQ +linux +linuxcontainers +linuxmadesimple +LinuxPerf +lista +Lista +listBox +ListBox +listBoxResults +ListSorting +ListView +litert +LiteRT +Liu +LiveHDR +livestream +lkvm +LLaMA +LlamaDemo +LLC +lldb +LLE +llm +LLM +LLM's +llmexport +LLMs +LLS +llsoftsec +llsoftsecbook +LLSoftSecBook +LLT +llvm +LLVM +LLVM's +llvmorg +lm +LM +Lmod +ln +LoadBalancer +loadHaarCascade +loadImageFromAssets +LocalAppData +localdir +localhost +lockCodeSegmentsInMemory +lockd +lockfile +lockfiles +LOD +LODs +lof +LoFTQ +logcat +logfile +Logfile +logind +logits +LongPath +LongToUnsafeRowMap +lookaside +Lookaside +lookups +lopt +lora +LoRA +losetup +lossy +LOWORD +lp +lpapi +LPC +LPCXpresso +LPDDR +LPI +lpprojectubuntuarm +LPVOID +LPX +lr LRS -RUs -SENDGRID -SendGrid -SendGridAPIClient -Servleress -Twilio -armiotcosmosdb -armiotstorage -asyncio -autogenerated -averageTemperature -averagetemperature -azcosmosdb -cardinality -cosmosdb -declaratively -devguide -differentiator -etag -getTempBtn -hotspots -iothubowner -schemas -sdks -sendgrid -soafee -timestamping -transactional -Biquad -CFFT -Christophe -Corriero -EBS -Favergeon -Fio -HDDs -Hanning -IFFT -Microbenchmark -NVMe -Nerdctl -NoiseSuppression -NoiseSuppressionReference -Paladugu -Phalani -PythonWrapper -Rani -RelWithDebInfo -Rescaling -SNR -VisualStudioSetup -WebUI -buildctl -channelwise -checksums -cmsisdsp -fio -frac -hanning -hdd -iops -iostat -iotop +LRU +LSB +lscpu +lse +LSE +lsemihost +lso +lst +LSTM +LSU +lt +LTO +lts +LTS +LttE +lua +Lua +LuaJIT +luminance +LVCMOS +lx +LXC +LXD +Lyft +lzbench +Lzbench +LZMA +mA +MacBook +MACC +MacCatalyst +maccdc +MACCs +machinelearning +MachineSets +macos +macOS +Macrocell +MACs +madvise +MainActivity +MainApplication +mainfest +MainPage +maintopic +MainViewModel +MainWindow +MainWindowWidget +makatia +Makatia +makefile +Makefile +Makefiles +Malhotra +mali +malideveloper +MaliManga +malioc +malloc +mana +Mandepudi +Manjaro +manpage +Maranget +Margaritis +mariadb +MarkdownRenderXHTML +markos +marshalled +martech +Masoud +matcher +matchers +MatComp +matLeft +matmul +MatOfRect +matplotlib +matResult +matRight +MatrixHelper +MatrixMultiplication +matrixResult +matrixSize +maui +MauiApp +MauiProgram +mavx +maxclients +maxIncomingConnections +maxmemory +MaxStep +mbed +Mbed +Mbit +MBL +Mbps +mbranch +mbstring +mc +mca +MCA +mcp +MCP +mcpu +mcr +MCTP +mcu +MCU +MCUBoot +MCUs +mcux +mcuxpresso +MCUXpresso +md +mdio +mdk +MDK +measureExecutionTime +MeasurePerformance +mebibytes +Mecklenburg +mediapipe +MediaPipe +MediaPipe's +Mediatek +MediaTek +MediaWiki +mem +Memcache +memcached +memcg +memcpy +meminfo +MemManage +MemoryDB +Memorystore +memPriv +memset +memtables +memtagMode +memTagMode +memtier +memtrace +MERCHANTABILITY +Mermigkis +mesaros +MeshLab +Meta's +metaprogramming +MethodImpl +MethodImplOptions +MFCC +MHU +MiB +microarchitectural +microarchitecture +microarchitectures microbenchmark +Microbenchmark microbenchmarking -nerdctl -nr -nvme -observability -operationscount -paddings -pidstat -preloads -recordscount -rescaled -rescaling -subnoise -transcoders -transcoding -upi -windowsdeveloper -GDScript -Sanp -WinPerf -benchmarked -donothing -httpx -libGPUCounters -libGPULayers -malioc -mnist -np -pgo -rescale -scikit -shiftVal -urllib -wdk -DB's -FFT's -IoT's -NumPy's -SendGrid's -AEMv -AEx -BusyBox -CTX -FastMCP -HW -LLVM's -LiveHDR -PCI -PSCI -Pixmap -PyPi -Qixiang -REGS -RevC -SMMU -SMP -Strided -TTS -Wix’s -Xu -aemfvp -convolve -deps -dotenv -fastmcp -ipykernel -jlowin -libomp -lockfile -lockfiles +microbit +microcontroller +microcontrollers +microkernel +microkernels +MicroPython +microSD +microservice +microservices +microsoft +MicrosoftTeams +Microsystems +middleware +Midgard +milvus +Milvus +minicom +miniconda +Miniconda +minifies +minikube +MiniLM +minimalistic +Minimap +mins +Mip +MIPI +mipmap +Mipmap +MirrorMaker +misclassification +mispredict +mispredicted +misprediction +mispredictions +mispredicts +MISRA +Misspelled words: +mitigations +Mitsunami +MJ +mjs +MJSynth mk +mkdir +mkl +MKL +mkv +mL +mlagents +MlAgents +MLAgents +mlcommons +MLCommons +mlek +MLEK +MLEmulationLayerForVulkan +mlops +MLOps +MLOPs +MLP +mlperf +MLPerf +MLPerf's +mlplatform +MlPlayerManager +MLPlayerManagerComponent +MLPs +mlr +mM +mmap +mmc +MMIO +MML +MMLA +MMU +mmult +MMX +mnist +MNIST +mnn +MNN +mno +mnt +MobaXterm +MobileApp +mobilenet +MobileNet +MobilenetV +modelling +modelscope +ModelScope +modularity +modularized +modulefiles +MoE +Mohamad +mongo +mongod +Mongod +mongodb +mongosh +mongostat +mongotop +Mongotop +MonoBehavior +MonoBehaviors +MonoBehaviour +MonoBehaviours +Monobehaviour +motionPin +motionState +motionVectorScale +moutline +mov +moveAssign +MoveClearFromCharacters +MoveClearFromWalls +moveConstruct +mozilla +mpacbti +mpi +MPI +MPICH +MPIDR +mpiexec +mpirun +MPix +MPKI +mPQ +mprof +mps +MPS +MPT +MPU +mqF +MQQT +MQTT +mr +mR +MSA +MSB +msbuild +MSBuild +MSC +msDelayTime +msdn +MSE +msec +msElapsedTime +msg +msi +MSM +msql +MSR +msse +msTicks +mstsc +msvc +MSVC +msve +mte +MTE +MTE's +MTESERR +MTL +mtu +Mul +mulesoft +multiarch +Multibox +multicast +multicore +multidisks +multilayer +Multilayer multimodal -ngrok’s -precomputed -pyproject -toml -virtualenv -mebibytes -syscalls -ArchSpecificLibrary -Asahi -AsmSource -AutoEncoder -Avx -BuildCommand -BuildYourOwnKernel -CPPLibRecommend -CPPLibVersion -CPPStdCodes -CompilerSpecific -ConfigGuess -ConfigurationInfo -CrossCompile -DefineOtherArch -Denoises -DiT -Drozd -FlatBuffers -GolangInlineAsm -GolangIntrinsic -GolangLinkLibrary -HostCpuDetection -IncompatibleHeaderFile -InlineAsm -JavaJar -JavaPom -JavaSource -NoEquivalentInlineAsm -NoEquivalentIntrinsic -OldCrt -OpenAnolis -PreprocessorError -PythonInlineAsm -PythonIntrinsic -PythonLinkLibrary -PythonPackage -RustInlineAsm -RustIntrinsic -RustLinkLibrary -SentencePiece -SignedChar -Submodule -TUI -Wix’s -audiogen -bazelbuild -centos -cmdline -deadsnakes -flatbuffers -libmagic -litert -mv -ngrok’s -pagesize -runfinch -spiece -subcommand -subgenre -submodule -subword -techcrunch -transformative -Aude -Gian -Iodice -SmolLM -VME -Vuilliomenet -cpus -fLO -invalidations -libtensorflowlite -macos +Multimodal +multimodality +multimodel +multipass +Multipass multithreaded -Wix's -ngrok's -qs -qu -Mbps -SVMATCH -abd -bitvector -bitvectors -iperf -normals -svcntb -svmatch -tc -Alexa -BLERP -Cepstral -Datagram -Edudzi -GDPR -Gbit -Gershon -HIPAA -HVAC -Kordorwu -MCUs -MFCC -Mbit -PDM -Situnayake -accelerometers -iPerf -libcrypto -libray -libssl -misclassification -retransmission -subquery -uninstrumented -ASIL -AdvSIMD -AnyCPU -BIST -BMS -Benchstat -Bleve -CMS -CPUx -CockroachDB -CycloneDDS -DCPS -DCPerf -DataReaders -DataWriters -Dn -EV -Gi -GopherLua -HARA -HHVM -HIL -HipHop -JIRA -Jayat -Julien -MISRA -MarkdownRenderXHTML -MediaWiki +multithreading +multitool +multiversioning +Multiversioning +musb +musl +mutators +mutex +mutexes +mv +MVAPICH +MVE +mvvm +MVVM +mW +mWh +MX +mxnet +MXNet +mymodel +myproject +MyS +mysql +Mysql +MySql +mysqld +mysqlonarm +mysqlslap +MyStrongPassword +myuser +Myvm +Naga +Najem +namespace +namespaces +Namespaces +NaN +nano +nanoTime +napi +Narayana +Narayanan +nat +NativeActivity +natively +nav +nbc +nbr +NCCL +nci +ncryption +nd +NDC +ndk +NDK +needrestart +neighbouring +neighbours +NEON's +NeonAABBObjCollisionDetectionUnrolled +NeonRadiusObjCollisionDetectionUnrolled +neoverse +Neoverse +Neoverse's +neovim +Neovim +NeoVim +nerdctl +Nerdctl +nestybox NET's +NetAspire +NETCore +netdesktop +NetFn +netfs +netlink +netresec +netstat +Netty +networkd +NeuralNetwork +newgrp +nexmark +Nexmark +NEXMark +NextDouble +nexti +Nfpl +nFreeing +nfs +NFS +ng +NGFW +nginx +Nginx +ngrok +ngrok's +ngrok’s +ni +nic +NIC +NIC's +NICs +nightlies +Nikhil +nInferencing +nk +nl +nlp +NLP +nmake +NMI +nn +NN +NNAPI +NNE +NNERuntimeRDGMLExtensionsForVulkan +NoAlias +nodeAffinity +nodejs +NodeJS +nodeSelector +NoEquivalentInlineAsm +NoEquivalentIntrinsic +nogcp +nogpgcheck +NoiseSuppression +NoiseSuppressionReference +NoLSE +nomachine +NoMachine +nonccl +NonCommercial +NONINFRINGEMENT +noninteractive +nopac +NOPASSWD +nordic +normals +NoRuntime +NoSQL +nostartfiles +noteboook +notEqual +np +NPC +NPCRayPerceptionSensor +NPCs +npm +npmjs +nproc +nProgram +NPU +NPUs +NqKE +nr +ns +nsec NSG -OrchardCMS -OrchardCore -PATHNAME -Polarion -QoS -RSS -Req -SELinux -STS -ThreadPool -VM's -VM’s -autorun -azureuser -bb -benchstat -biogo -bitness -bleve -br -brstack -cockroachdb -cycloneDDS -differentiators -esbuild -etcd -facebookresearch -gRPC -geomean -geomeans -geospatial -hardcoding -igor -interop -ipfrag -ipv -krishna -metaprogramming -minifies -misprediction -multicast -multicore +nsis +NSS +Ntegral +ntegrity +nterface +nTrying +nucleo +Nucleo +NuGet +num +numa +NUMA +NumberBox +NumberBoxExecutionCount +NumberBoxMatrixSize +numChar +NumericUpDown +numericUpDownExecutionCount +numericUpDownMatrixSize +numpy +NumPy +NumPy's +Nunes +nv +nv +NvChad +NVHPC +nvidia +Nvidia +nvim +NVL +NVM +nvme +NVMe +NVPL +nx +NxM +nxp +NXP +OAuth +objdump +observability +ObservableCollection +observables +oc +OCaml +occlusionculling +oci +OCI +ocid +OCID +ocp +OCPU +ocpus +OCPUs +ocr +OCR's +OCRv +OCTLA +od odinlmshen +oe +OEM +OEMs +offlines +Og +OgMk +ok +Ok +OLAP +OldCrt +ollama +Ollama +Ollama's +OMP +Omusilibwa +OnActionReceived +OnActionRecieved +onCameraFrame +onCameraViewStarted +onCameraViewStopped +onClickListeners +onCreate +oneapi +oneAPI +OneAPI +oneClick +oneDNN +ONEDNN +OnLaunched +onlinedocs +onnx +onnxruntime +OnPropertyChanged +ons +onwards +oOer +ooffice +oom +OOM +opam +opcache +Opcache +OpenAD +openadkit +OpenADKit +OpenAg +openai +OpenAI +OpenAI's +OpenAnolis +OpenBalena +OpenBLAS +openbmc +OpenBMC +OpenBMC's +OpenCL +opencv +openCV +OpenCV +OpenCV's +opencvcamera +openCvCameraView +opencvfacedetection +OpenCVLoader +OpenGL +OpenGLES +openglessdk +openjdk +OpenJDK +OpenMP +openmpi +openocd +Openocd +OpenRNG +openshift +OpenShift +OpenShift's +opensource +openssh +OpenSSH +openssl +OpenSSL +openSUSE +OpenTelemetry +OpenVPN +openvscode +OpenVSCode +OpenVSCodeServer +OpenWRT +operatingsystems +operationscount +opi +oplogSizeMB +OPLTK +OPPO +optee +optim optimise +optimizable +optimizers +Optimizers +orangepi +OrangePI +orangePiOS +OrchardCMS orchardcore +OrchardCore +orchestrator +orgId +orin +ORing +ORT +os +OSCI +osdb +osKernelInitialize +osKernelStart +OSR +osThread +osThreadNew +osThreadPrivileged +ot +OTA +OTG +OtherServices +OutDir +outHead +outLine +outputArray +outputBuffer +outputFile ov +OV +overcommit +Overcommit +overfitting +pac +PACBTI +paciasp +pacman +paddings +PaddleDetection +paddleocr +PaddleOCR +paddlepaddle +PaddlePaddle +Pagefind +pagemap +pagesize +Paladugu +Pandoc +papi +PAPI +pApp +paraformer +Paraformer +ParallelGCThreads +parallelization +Parallelization +parallelize +parallelized +parallelizes +parallelizing +param +PARAM +params +PARAMS +paravirtualization +paravirtualized +Paravirtualized +Pareena +pareenaverma +ParentProcessId +paretrace +Parichay +pArm +pArmtest +PassRole +passthrough +PassThru +pathing pathname -psci -retuned -rexec -rmem -roadmap -runnable -taskset -unicast -wrk's -yy -zenoh -AFM -AOR -AWSEC -Agrawal -Arcee -Atheros -ChenYing -Colima -Corellium -Corestone -Croci -DBAREMETAL -Denormal -Docker's -Dpls -ETHOSU -FVP's -Gopalakrishnan -Gorman -HVM -Higham -Huai -ICML -IIR -IIoT -ImageStreams -Joana -Kuo -LANs -Liang -Libmath -MACC -MACCs -MachineSets -MobileNet -OpenShift's -PMLR -PipelineRun -PreserveOriginal -Queryable -Reimport -SPRA -STRINGIFY -Sram -TMS -Tekton -VPs -VSCode -WANs -WR -Waheed -Weidmann -Wikitest -XQuartz -Xiu -ZGVnN -Zenon -afm -aot -arXiv -arcee -armpl -ath -bitbake -bootloaders -cntr -cosf -cpp's -datadir -dddd -denormal -denormalized -edgeimpulse -ethosu -expf -geo -gupta -iMac -instrinsics -ish -keypair -learnable -libcurl -lldb -mL -mM -mR -mlr -nbc -nbr -nodeAffinity -nordic -oc -oe -openshift +PATHNAME +pathologies +pb +PBR +pc +pcap +PCbuild +PCI +PCIe +pcre +PCRE +PCRs pcs +pcse +pctl +PDB +pdf +PDFs +pdh +PDH +PDM +pds +PDSC +pe +peds +PEFT +peicore +peizo +pem +Pem +PemKey +penBmc +PendSV +perceptron +perceptrons +Perceptrons +percpu +perf +Perf +Perfetto +PerformanceHelper +PerformanceMetrics +performancestudio +PerformanceStudio +PerformanceTests +performant +performCalculations +PerformIntensiveCalculations +periphbase +PERIPHBASE +perMachine +permalink +personalization +petclinic +Petclinic +PETG +PFR +PGI +pgo +PGO +PGS +Phalani +phar +php +phpbench +PHPBench +phpinfo +Phrack +Phttps +PHYs +Phytec +PickerDomain +pico +Pico +picolibc +Picoprobe +picovoice +Picovoice +Picovoice's +pid +pidstat +PIL +pilar +Pilar +Pinebook +pinout +Pinout +pinouts +PipelineRun +pipelining +Pipelining +pir +PIR +Pixmap +PJDOC +pkgconfig +PkgConfig +pkgx +PLA +PlayerInput +PlayerLoop +PLDM +PlotResultsCommand +plt +PMLR +Pmod +pmu +PMU +PMUs +pmuserenr +PMUv +pmZ +png +poc +PoC +PoCs podTemplate podTemplate's +pointStride +Polarion +polsl +Portainer +POSIX +PostgerSQL +postgres +Postgres +postgresql +PostgrSQL postinstallation -prepending -prog -queryable -redhat -reimport -shadergraph -sheel -spra -stefanalfbo -subnormals -taskrun -tg -thisunrolling -tokio -topologies -umax -varg -vexp -vgetq -vres -wifi -wlan -wlp -wlx -xquartz -zenohd -Kompanio -Zenoh's -instrumentable -subprocesses -CPzfYHdpQ -iso -Arcee's -commandlinetools +postprocess +postprocessing +PostProcessVolume +powershell +PowerShell +Powertrain +ppa +PPA +ppc ppl -rollout -sdkmanager -Ntegral -OEMs -TKN -VHD -inet -tekton -tektoncd -tkn -verifiably -vhd -AssetLib -PerformanceStudio -VkThread +ppo +PPO +Pprofdata +pragma +Pranay +pratapkute +prctl +pre +preallocation +prebuild +prebuilt precompiled -rollouts -Bhusari -DLLAMA -FlameGraph -FlameGraphs -JSP -KBC -MMIO -Paravirtualized +precompiler +precomputed +precomputing +preconfigured +Preconfigured +Preconfiguring +Preema +prefetch +prefetching +Prefetching +prefill +Prefill +PRELOAD +preloaded +preloads +prem +prepareSeries +prepend +prepended +prepending +preprocess +preprocessed +preprocessing +preprocessor +PreprocessorError +prereqs +Prereqs +Preselect PreserveFramePointer -Servlet -TDISP -VirtIO -WebSocket -agentpath -alarmtimer -aoss -apb -ata -bpf -brendangregg -chipidea -clk -cma -counterintuitive -cpuhp -cros -csd -devfreq -devlink -dma -dpaa -dwc -ecurity -edma -evice -filelock -filemap -flamegraphs -fsl -glink -gpu -hcd -hns -hw -hwmon -icmp -initcall -iomap -iommu -ipi -irq -jbd -jvmti -kmem -ksm -kvm -kyber -libata -libperf -lockd -mdio -memcg -mmc -mtu -musb -napi -ncryption -netfs -netlink -nfs -ntegrity -nterface -oom -optee -pagemap -paravirtualized -percpu +PreserveOriginal +pretrained +printenv +printf printk +println +prismjs +PRIXPTR +proc +procedureS +ProcessID +processwatch +procps +profdata +profileable +profiler +ProfilerActivity +profilers +profraw +prog +ProgramFiles +programmatically +proj +ProjectExplorer +prometheus +PropertyChanged +PROT +protobuf +proxying +Przemyslaw +ps +PSA +psacertified +psci +PSCI +pseudocode +pseudorandom +psql +PSTATE +pstools +psv +pte +pth +PTHREAD +PTQ +ptr +pts +publicIP +PublishRetain +pubsub +pulldown +pulumi +Pulumi +punc +PUNC +PutItem +PuTTY +PWD pwm +PWM +pwntools +pwsh +px +py +pygments +pypa +pypi +PyPi +pyplot +pyproject +PySide +PythonInlineAsm +PythonIntrinsic +PythonLinkLibrary +PythonPackage +PythonWrapper +pytorch +Pytorch +qa +qai +QAQ +QAT +QBHOUSE qcom +qcomm +qcow +QCOW +qDebug +qdeveloper qdisc +QElapsedTimer +qemu +Qemu +QEMU +qemuarm +Qianwen +Qixiang +QLoRA +qO +qos +QoS +qps +QPushButton +qrw +qs +qsi +QtCreator +qtexamplesandtutorials +QTransform +qu +qualcomm +quant +quantized +quantizes +quantizing +quasirandom +queryable +Queryable +QuickSort +quickstart +Quickstart +quicktool +qwen +Qwen +RaceNight +Radoslav +Ragel +ral +Ramalingam +ramdisk +RamFB +ramfw +RAMFW +randomise +RandomMovement +randomSensorReadings +Rani +RANs ras +raspberrypi +RaspberryPi +Raspi +raspios +rasterization +Rasterization +rasterized +Ravi +raycast +RayPerceptionSensor +raytraced +RayTracing +rb +RBAC +rc +RCAS +rclone +rcpc +rct rcu +RDBMS +RDD +RDG +rdinfra +rdn +RdN +RDom +RDP +rds +rdv +RDv +RDV +reactiveness +ReactiveX's +readme +README +readthedocs +ReadyToPlay +realpath +realtime +Realtime +Rebalance +rebases +recommender +recomputation +Recomputation +reconfig +reconversion +recordcount +recordscount +Recurse +Redfish +redhat +redis +refdesign +refered +refetching +refinfra +Reflowing +refman +refractions +Refractions +refx +refy +refz regmap +REGS +reimport +Reimport +RelaxedPrecision +ReleaseByteArrayElements +relica +relinked +relocations +ReLU +RelWithDebInfo +RemainingCapacity +Remmina +RemoteImage +renderbuffer +renderdoc +RenderDoc +RenderDoc's +renderer +Renderer +renderers +RenderPassEncoder +RenderPipeline +RenderTargets +Renesas +reorderings +REPL +replset +replSetName +replug +repo +Repo +repos +representable +reproducibility +req +Req +requantization +requantize +Requantize +rescale +rescaled +rescaling +Rescaling +resethandler +ResetScene +reshading +resizable +resizefs +resnet +ResourceGroup +RESTful +ret +retaa +retarget +Retarget +retargeted +retargets +retransmission +retuned +RevC +rexec +reymont +rf +rfc +rg +RGB +RGBA +RGBRGBRGB +rgerganov rgerganov's +RGGB +RHE +RHEL +RHI +RHIs +RHS +Rin +rl +RLHF +rmdir +rme +RME +rmem +RMM +RMSNorm +RMW +RNG +RO +roadmap +RoBERTa +Rockchip +rocksdb +ROCm +Roesch +Rohr +RoI +rollout +rollouts +romfw +romlib +Ronan +rootCertDir +rootfs +ROP +RoPE +ropt +ros +ROS +rosdep +Rosewill +RoT +rotMatrix rotocol +Roubalik +roundtrip +rpath +rpc rpcgss +rpi +RPi +rpios rpmh +rpms +RRR +rsa +RSE rseq +RSS +rst rtc +rtcTYRc +RThroughput +RTL +rtos +RTOS +RTOSes +rtp +RTP +rtti +rtx +RTX +Rui +Ruifeng +ruleset +runAnimation +runAnimationButton +runbook +Runbook +runCalculations +RunCalculationsCommand +runfinch +runnable +Running Task: Markdown... +RunsOn +runtime +runtimes +Runtimes +runTruncation +runVectorCalculations +RUs +rustc +RustInlineAsm +RustIntrinsic +RustLinkLibrary +rviz +Rviz +RViz +rvps +RVPS +RW +RZ +sa +SaaS +safetensors +SAI +sam +samdauwe +sampleapp +SampleScene +sandboxed +Sandboxed +Sanp +sao +SAXPY +SBC +SBCs +sbin +sbt +scala +scalability +scalable +Scalable +ScaledObject +scaler +Scaler +scalers +Scaleway +ScanCommand +scatterloading sched +scheduler's +schemas +Schmitz +scikit +scipy +SciPy +scm scmi +scott +scp +SCP +SCR +ScreenPercentage +screenrc +screenspace +ScreenWriteout +ScriptHolder +ScriptRunBehaviourUpdate +scrits +scrollable +scrollback scsi -skb -smbus -smp -spi -spmi -sunrpc -swiotlb -tegra -thp -tlb -udp -ufs -untrusted -uring -virtio -vmalloc -vmscan -workqueue -xdp -xhci -JFR -conv -servlet -tv -gpiozero -lgpio -TinyLlama -Superscalar -automations -gemma -tinyllama -pinout -Makatia -Omusilibwa -EdgeAI -Raspi -abyz -fidel -javascript -makatia -uk -STDDEV -Stdev -BytesToBytesMap -HashMap -LongToUnsafeRowMap -Stdev -UnsafeRow -UnsafeRowhash -agg -arrayEqual -codegen -hashmap -hugeMethodLimit -ints -kurtosis -stddev -wholestage -RDD -TEEs -paravirtualization -WholeStageCodegen -Wholestage -zshrc -hadoop -CBL -DataFrame -exitCode -Gerganov's -Radoslav -rgerganov -NSS -spatio -upsampling -UE -VGF -NNE -RDG -Configurator -RHI -RHIs -NNERuntimeRDGMLExtensionsForVulkan -Unreal's -ORT -MLEmulationLayerForVulkan -RenderDoc's -vgf -dataflow -Sandboxed -sandboxed -Termina -LXC -Crostini -ChromeOS's -crosh -Sommelier -chromeos -linuxcontainers -XPS -NIC’s -offlines -passthrough -SLOs -Ker -Rui -SmartNICs +sct +SCTLR +SDC +sdCard +sdCard +SDD +SDDiskTool +sdeor +sdk +SDK +SDKDocs +sdkmanager +sdks +SDKs +SDP +SDRAM +SDV +SDVs +se +SecretsManagerReadWrite +SECurity +sed +Seeed +seeedstudio +segv +SEGV +Seidl +Seige +selectable selectedalt -UIalt -lpprojectubuntuarm -RDV -chiplet -BMC -upstreams -rdv -Initrd -handoff -ACPI -PCRs -MHU -Handoff -userland -CXL -DDR -PHYs -UCIe -handoffs -CCG -CML -Codespaces -Cheng -GDM -LPI -nsec +selft +SELinux +sem +semihost +semihosted +semihosting +sendgrid +SendGrid +SENDGRID +SendGrid's +SendGridAPIClient +SendNotification +SensorReading +SensorReadings +SentencePiece +serializable +SerializeField +serverless +ServiceDefaults +Servleress +servlet +Servlet +servlets +SetByteArrayRegion +setCameraPermissionGranted +setContentView +setElement +setenv +setMatrix +setParameter +SetProperty +SettingsController +setuptools +SfChart +SFT +SFTTrainer +SG +SGD +sha +shader +shaderCodeDesc +shadergraph +ShaderQualityMode +shaders +sharding +ShareAlike +SharedFlow +sharegpt +ShareGPT +shasum +sheel +ShellContent +Shen +shiftVal shortcode -BSON -joedog -Seige -Antonov -jwt -kbs -Nfpl -ZjnAMjLk -hCpeYsarnnGv -kbs -rvps -xcbTMTBX -CDH -RVPS -Attester -attester -ATtestation -CoCo -procedureS -NIC’s -httpbin -proxying -OpenBMC -PoC -PoCs -evb -ipmitool -openbmc -poc -IPMI -integrators -KCS -PLDM -MCTP -Redfish -hyperscalers -BMCs -OEM -NetFn -RDv -CSSv -penBmc -BMC's +shortener +Shrinkwrap +Shrinkwrap's +Shuheng +si +sig +sigaction +sigemptyset +siginfo +SIGINFO +Sigmoid +SignedChar +significand +signo +signup +SIGSEGV +silesia +simd +SIMD +simde +SIMDe +SIMDE +SIMDEverywhere +simlimit +SimpleCommand +sindresorhus +SingleStream +Situnayake +sizeof +skb +skilllevels +skillset +Skinnider +SkipWord +skopeo +Skopeo +sku +skus +skybox +sl +sL +SLC +sleeptime +SLES +sln +sLO +SLOs +sm +SmartNICs +SmartScreen +SMAX +smbus +sme +SME +SMIN +SMMLA +SMMU +SmolLM +smp +SMP +SMS +SMSTART +snapshotting +snortrules +SNR +sns +SNS +SNSClient +SNSFull +SoA +soafee +SOAFEE +Sobel +Sobel's +SoC socat -ZooKeeper -IRQs -IRQS -Friedt -namespaces -atlascli -benchmarkDB -cursorTest -replset -testCollection -Namespaces -mongotop -Mongotop -baselineDB -ef -netstat -tulnp -mongostat -arw -conn -getmore -qrw -vsize -conn -WiredTiger -GLE -getLastError -createIndex -getMore -getmore -RoT -lkvm -JMH -jmh -UseG -Xmx -Xms -JavaServer -servlets -RMSNorm -RoPE -FFN -ukernel -libstreamline -prefill -OpenCL +SockDir +sockname +socrates +SoCs +softmax +Softmax +softWare +SoftwareComponents +softwares +SoL +solaris +Sommelier +Sor +Sourcefire +sourceforge +sp +Spack +Sparkfun +spatio +spawner +Spawner +SpawningScript +spe +SPE +specular +spherePoints +spi +SPI +Spickett +spiece +SpinTheCubeInGDI +SPIR +spmi +Sponza +spra +SPRA +sprintf +SPSR +sql +sqrt +Sqrt +SquareMatrixMultiplication +squeezenet +SqueezeNet +Sram +SRAM +src +Src +ss +ssa +sscript +SSD +SSDs +sse +sshd +ssk +SSK +SSKs +ssl +SSM +SSO +ssr +SSR +sssZ +SSTables +StackOverflow +Starlark +Starlink +startinstanceconsole +startPoint +startValue +StateFlow +stateful +StatefulSets +StaticCollisionCalculations +StaticCollisionObject +StaticCollisionObjects +staticObjects +stcube +stdbuf +stddev +STDDEV +STDERR +stdev +Stdev +STDIN +stdint +stdout +STDOUT +Stech +stefanalfbo +STL +stm +STM +stmicroelectronics +STMicroelectronics +STMU +storedprocs +stp +str +strcpy +Streamline's +streamlit +Streamlit +Strech +Strided +STRINGIFY +StringOperations +strobed +strobing +struct +structs +Structs +STS +STT +STXR +stylesheet +SType +su +subclasses +subclassing +subcommand +subdirectory +subfolder +subfolders +subgenre +subgraph subgraphs -threadpool -worksize -Zhilong -Denoiser -RGGB -denoised -YGGV -Mohamad -Najem -kata +sublicense +submodule +Submodule +submodules +subnet +Subnet +subnets +subnoise +subnormals +suboptimal +suboptimally +subprocesses +subproject +subproject's +subquery +subrepositories +subsciption +subscribeEmailToTopic +substring +subword +sudo +sudoers +summarization +sunrpc +Superscalar +superset +supervisord +suppressNoTLSPeerCertificateWarning +SurfaceView +SuSE +SVC +svcntb +svcntsw +SVCR +sve +SVE svl +SVL +svld +svmatch +SVMATCH +SVTR svzero -anf -DynamIQ -Zena -learnt -lof -BalenaOS -balenaCloud -MX -ARMFp -AndroidDemo -ApacheBench -ArmHalideAndroidDemo -Autoscheduler -BGR -BVM -BenchmarkBubbleSort -BenchmarkQuickSort -Botspot -BoundaryConditions -BubbleSort -ByteBuffer -DGGML -DNQZJ -DTLB -EPYC -ETag -EVEX -Esc -FuseAll -FuseBlurAndThreshold -GGG -GOPATH -GOROOT -GTK -GetByteArrayElements -Golang -Golang’s -HWC -Halide -Halide’s -ImageParam -Istio -KEDA -Kedify -Kedify’s -LLC -LLE -MPix -NIC’s -Netty -NoRuntime -OpenBMC’s -Parallelization -QCOW -QuickSort -RDom -RGBRGBRGB -RRR -RamFB -Recomputation -ReleaseByteArrayElements -Remmina -Roubalik -SAXPY -ScaledObject -Scaler -SetByteArrayRegion -SoL -Sor +sw +SwaggerGen +swapchain +swappiness +SWCLK +SWD +SWDIO +swiotlb +SWO +SWP +SWV +SYCL +sym +symlinks +syncfusion +Syncfusion +Syncfusion's +Synnott +synonymously +SynthText +sys +SYS +sysbench +Sysbench +sysbox +Sysbox +syscall +syscalls +sysctl Sysoev +Sysreport +sysroot +SystemC +SystemCoreClock +SystemCoreClockUpdate +systemctl +systemd +systemLog +systemmetrics +SystemReady +systick +SysTick +TAA +TaaS +TableLayoutPanel +tabpane +tagname +Tallund +tanh +Tanh +Taobao +targe +TargetBoard +TargetOptions +TargetType +TaskManager +TaskManagers +taskrun +taskset +tblindex +Tbrk +tc +TCF +TCK +tcl +Tcl +TCL +TCMs +tcp +TCP +tcsh +TDISP +techcrunch +techmahindra +TEEs +tegra +tekton +Tekton +tektoncd +telemetryIntervalHandle +temperatureSensor +TemperatureSensor +TemporalUpscaler +Temurin +tensorboard +Tensorboard +TensorBoard +tensorflow +TensorFlow +TensorRT +Tera +termcap +Termina +terrafom +terraform +Terraform +TERUpdate +testbed +testCollection +TestOpenCV +testroot +TestScenario +testsh +TextBlock +TextBoxExecutionCount +TextBoxVectorSize +textfile +textinstall +texturedteapot +TextureView +TextView +TextView's +textViewStatus +tf +tfa +tflite +TFLite +tflm +TFLM +tflow +tfm +TFP +tfvars +tg +tgz +th +theartofhpc +TheBloke +Thelio +Theobald +Thinkpad +ThinkPad +thirdai +ThirdAI +ThirdAI's +ThirdAILabs +ThirdParty +ThirdPersonCameraMovement +thisunrolling +thp +THP +threadCount +threadNum +threadpool +ThreadPool +ThreadSanitizer +threadsanitizercppmanual +ThreadStackSize +thresholded +thresholding +thundra +Tianyu +TIdentify +tigervnc +TigerVNC +tiktoken +TIMECREATED +TimerValue +timeScale +TimeStamp +timestamping +Timestep +timeThreshold +tinyllama +TinyLlama +tinyml +tinyML +TinyOBJLoader TinyRPS +Tizen +Tk +Tkinter +tkn +TKN +TLAS +TLASes +tlb +TLB +TLBI +TLP +TLS +tlsWithholdClientCertificate +Tmall +tmp +TMS +Tmux +TODO +tok +TokenExchange +TokenExchangeRole +TokenExchangeRoleAccess +tokenization +tokenize +Tokenize +tokenized +tokenizer +tokenizes +tokenizing +tokio +tolerations +Tolerations +toml +tonemapped +tonemapping +toolchain +Toolchain +toolchain's +toolchains +toolkit's +Toolkits +toolset +tooltip +topdown +topicfilter +topicSensorReadings +topicTelemetryControl +topologies +torchao +TorchAO +torchchat +Torchchat +TorchScript +torchsummary +torchvision +TOSA +totalcompute +touchpad +Touchpad +TPACKET +TPC +TPROC +tps +TPS +Traca +TraceHalt +tracepoint +Tracepoint +tracepoints +Tracepoints +TraceRun +TraceSuspend +tradeoff +tradeoffs +traefik +Traefik +TrainingArguments +transactional +Transactional +transcoders +transcoding +transformative +transpilation +transpiles +trgt +trialCount +Trie +TriggeredBy +trl +TRM +truncations +trustedfirmware +TrustedFirmware +TrustZone +TSan +TSan's +TSO +ttf +TTK +TTS +tty +TTY +ttyACM +TUI +tulnp +Tunings +TutorialMatrixClass +tv +TVAL +tvb +tvm +TVM +TVM's +TVMC +tvOS +tw +Twilio +txt +TXT +typedef +typedefs +TypeScript +Typicode +TZ +uart +UART +UARTs +UB +ubl +UBL +ubuntu +UC +UCIe +UCS +udemy +udp +UDP +UE +uefi +UEFI +uf +ufs UFW +ug +ugc +UGC +UHS +UI +UIalt +UID +uint +uintptr +UIs +uk +ukernel +uKernel +ukernels +ulink +ULINK +UlinkPlus +ULINKplus +ulinkpro +ulinkPro +ULINKpro +ulp +ULP +ULPs +Uma +umax +UMAX +UMIN +umu +un +unallocated +uname +unary +Unary +unaryOperator +uncheck +uncomment +Uncomment +uncommented +uncommenting +uncompress +Uncompress +Undecoded +underperform +underperformed +underperforms +unfused +unicast +uninitializedConstruct +uninstallation +uninstrumented +UnityEngine +UnityMain +UnityTechnologies +UniversalDeepTransformer +unix +unjittered +UnlockDiagnosticVMOptions +unmangled +unmount +unoptimized +unportable +unpredicated +Unreal's +unrealengine +unreferenced +Unregister +UnsafeRow +UnsafeRowhash +unselect +Unselect +unselected +unselecting +unsloth +Unsloth +Unsloth's +unsqueeze +unstripped +untagged +untagging +untar +untrusted +unutilized +unvectorized +uop +uops +uOps +updateControls +UpdateItem +UpdateJob +UpdateThingShadow +upi +uploader +UploadToS +upsampling +upscaled +upscalers +upscales +upscaling +Upscaling +UpscalingRatio +UpsideDownCake +upstreams +uptime +upto +uQ +URI +uring +url +urllib +URP +UsageFault +USART +USD +UseAESCTRIntrinsics +useAPL +useb +usecase +UseG +userguide +UserGuide +userland +usermod +UserProfile +USERPROFILE +userspace +UseTransparentHugePages +usg +Using aspell to spellcheck Markdown +usr +ut +utf +UTF +Utgard +utils +utk +utmp +uuid +UUID +uv +Uvicorn +uVision +uvmpw +uvprojx +UVs +UWP +uzbanvsz +va +vad +VAD +varg +variadic +Varun +varunchariArm +VBAR +vbic +vbicq +vc +vcgeq +VCN +vcpkg +vcpu +vCPU +vcpus +vCPUs +vdupq +vec +VectorCamp +VectorHelper +Vectorisation +vectorizable +vectorization +vectorize +vectorized +vectorizer +Vectorizers +vectorizing +VectorOperations +VECTOROPERATIONS +vectorscan +Vectorscan +vectorstore +ved +venv +ver +VER +veraison +Veraison +Veraison's +verifiably +verifier +Verilog +Verma +vesion +vexp +VfxService +vgetq +vgf +VGF +vhd +VHD +vht +VHT +VideoCore +videoio +ViewModel +ViewModels +viewport +Vimscript +VIO +vips +virtio +VirtIO +virtualenv +virtualising +virtualized +virtualizer +VirtualService +vis +visualisation +visualSilicon +visualstudio +VisualStudioSetup +vit +ViT +ViTFeatureExtractor +ViTForImageClassification +Vitis +Vivado +vivaldi +Vivo +VK +vkCreateDevice +VkDeviceCreateInfo +vkEnumerateDeviceExtensionProperties +vkGetImageSubresourceLayout +VkImage +VkImageCompressionControlEXT +VkImageCompressionPropertiesEXT +VkImageCreateInfo +VkImageFormatProperties +VkImageSubresource +VkThread +vl +VL VLA +VLAN +vld +vlen +vllm +vLLM +vm +VM +VM's +vmalloc +VME +VMs +VM’s +vmscan +vmvn +Vn +vnc +VNC +vnic +VoD +vorrq +vpc +VPC +VPN +VPNs +vprintf +VPs +vqtbl +vqtbx +vr +VR +VRAM +VREF +vres +vrr +vscode +VSCode +VSE +VSIX +vsize +VSL +VSTR +vsts +VSTs +VSX +vt VTOR -VirtualService +VTTBR +Vuilliomenet +vulkan +Vulkan +Vulkan's +vulkanised +Vulkanised +vuln +vv +VVC +vvenc +VVenC +VVEW +VwbgFSoy +Waheed +WaitForPresent +WAL +walkthrough +Walkthrough +WANs +warmup +warmups +watchOS +watchpoint +Watchpoint +watchpoints +Watchpoints +wav +waveforms +wavefunctions +Wayland +wb +wC +wchar +wchars +wdk +WDK +wearables +WeatherEmulator +weatherForecast +WeatherForecast +WeatherStation +WeatherStationEmulator +webapi +webapiproject +webapp +WebApp +webbot +WebGL +webgpu +WebGPU +WebGPU's +webgpufundamentals +webhook +Webhook +WebM +webpage +webserver +WebsiteBucket +WebsiteHosting +WebSocket +webster +WebUI +WebUSB +Weidmann +wget +wgpuQueueSubmit +wgpuQueueWriteBuffer +wgpuQueueWriteTexture +WGSL +whilelo +Whitepaper +whitepapers +wholestage +Wholestage +WholeStageCodegen +Wi +wich +wifi +wikipedia +Wikitest +Wikitext +WikiText +Willen +WINAPI +windowsarm +WindowsDesktop +windowsdeveloper +WindowsForms WindowsOnArm +windowsperf +WindowsPerf +WindowsPerfGUI +winforms +WinForms +winget +WinPerf +winui +WinUI +WinUIApp +Wiredtiger +WiredTiger +Wirkus +wiseeye +WiseEye +Wix's +Wix’s +Wl +wlan +wlcsp +wlp +wlx +wm +wmvn +Wno +woa +WoA +woolyss +wordpress +Wordpress +WORKDIR +workloada +workqueue +worksize +workspaces +wpa +WPA +wperf +wpf +WPF +WPR +WR +writeback +writebacks +writeTemperatures +writeTemperaturesUrl +wrk +wrk's +WSGI +wsl +WSL +www +wwwrun +wzr +xA +xaa +xaaaaaaaa +xaaaaaaab +xamarin +XamarinForms +xaml +XAML +xb +xB +xBxxxxxxx +xcbTMTBX +Xcode +XD +xda +xdc +XDC +xdebug +Xdebug +xdp +xe +xE +Xeon +xeu +xf +xfce +xfffe +xFFFFFFFF +xfffffffff +xform +XFormView +XFormWidget +xfvz +XGmSCVgb +xhci +Xianyu +Xiaomi +Xilinx +Xing +xinitrc +Xiu +xJf +xlarge +XLSX +xml XMM +xmodem +Xms +Xmx +xN +Xn +xnn +xnnpack +XNNPack +XNNPACK +xo +Xorg +Xperf +XPS +xquartz +XQuartz +xrdp +XSA +XServer +xsession +XT +Xu +xunit +xvf +XXS +xxxxxxx +XXXXXXXXXXXXXX +xy +XY +xz +xzf +yaml +YAML +YAMLs +ycsb +YCSB +Yegna +YGCT +YGGV +yi +Ying +Yitian +Yiyang +yml +YML YMM +yocto +Yocto +yoctoproject +YOLO +yolov +Yolov +yor +Youku +youtu +youtube +YPQ +ySm +Yu +Yury YUV -ZMM +yy +YYYY +za +ZA +Zach +Zarlez Zbynek -adaptively -allocs -apiKey -armhalideandroiddemo -autounattend -autowiring -benchmarkHttpResponse -benchmem -blurThresholdImage -bvm -clusterName -coroutine -createBitmapFromGrayBytes -cv -extractGrayScaleBytes -fallbacks -firstlogin -golang -gosort -goweb -halide -httpd -inBytes -inlines -inputBuffer -insturction -jbyteArray -keda -kedify -keypress -kts -llmexport -loadImageFromAssets -microarchitectures -minikube -oOer -orgId -outputArray -outputBuffer -parallelization -parallelize -parallelized -parallelizes -preallocation -precomputing -qcow -recomputation -reconfig -reconversion -refetching -req -scaler -scalers -sprintf -stdev -thresholded -underperformed -underperforms -unvectorized -uop -walkthrough -warmups -xo -yi -AMX -AlexNet -FMAC -MySql -MyStrongPassword -RDBMS -SqueezeNet -TIdentify -goroutines -mysqlslap -squeezenet -Aphex -Autoscale -Halide’s -KRaft -Kedify's -Kedify’s -MirrorMaker -NIC’s -Neoverse's -OpenBMC’s -Rebalance -StatefulSets -codemia -multidisks -testsh -uops -subgraph -ArgumentList -Autocannon -Buildkite -CimInstance -ClassName -DischargeRate -FPM -FastCGI -FilePath -Halide’s -HasExited -ImportError -NIC’s -NVM -NodeJS -Opcache -OpenBMC’s -PHPBench -ParentProcessId -PassThru -ProcessID -QAT -REPL -RaceNight -RemainingCapacity -Ruifeng -Xdebug -appPid -argList -autocannon -autoexit -autoloading -benchArrayPush -benchStringConcat -buildkite -childPid -childProcess -cmdLine -eq -exePath -ffplay -fpm -gpl -hh -mW -mWh -mbstring -memPriv -npmjs -opcache -outHead -outLine -outputFile -phar -phpbench -phpinfo -utf -vesion -wwwrun -xdebug +Zena +zenodo +zenoh +Zenoh's +zenohd +Zenon +zephyrproject +zeropoint +zEybNlwd +zfs +zfsutils +ZGC +ZGVnN +zh +Zhang +Zhengjun +Zhilong +Zhipu +zilliz +Zilliz +ZjnAMjLk +zlib +ZMM zoneIdentifier +ZooKeeper +Zouaoui +zshrc +Zstandard +zstd +ZT +zxf +zybo +Zybo +zynq +Zynq +ZYNQ zypper -keyspace -Keyspace -CQL -cqlsh -keyspaces -CQLSH -SAI -SSTables -Trie -UCS -memtables -cassandra -Cassandra's -Cassandra -CircleCI +ZZa +ZZZZZ \ No newline at end of file diff --git a/content/learning-paths/cross-platform/function-multiversioning/_index.md b/content/learning-paths/cross-platform/function-multiversioning/_index.md index f0b76e2cde..1a7a7f995a 100644 --- a/content/learning-paths/cross-platform/function-multiversioning/_index.md +++ b/content/learning-paths/cross-platform/function-multiversioning/_index.md @@ -17,7 +17,7 @@ prerequisites: - Familiarity with indirect functions (ifuncs). - Basic knowledge of loop vectorization. - Familiarity with Arm assembly. - - A LLVM 20 compiler with runtime library support or GCC 14. + - A LLVM 20 compiler with runtime library support or GCC 16. author: Alexandros Lamprineas diff --git a/content/learning-paths/cross-platform/function-multiversioning/examples2.md b/content/learning-paths/cross-platform/function-multiversioning/examples2.md index 2ed806dec5..6059461000 100644 --- a/content/learning-paths/cross-platform/function-multiversioning/examples2.md +++ b/content/learning-paths/cross-platform/function-multiversioning/examples2.md @@ -141,10 +141,6 @@ To compile with GCC, use: g++ -march=armv8-a -O3 dotprod.c ``` -{{% notice Note %}} -Note that `gcc-14` does not yet support `target_version` when using the c-frontend. You can use `g++-14` instead. -{{% /notice %}} - To run the application: ```console diff --git a/content/learning-paths/cross-platform/function-multiversioning/examples3.md b/content/learning-paths/cross-platform/function-multiversioning/examples3.md index acd8cf13b8..0fb098b54c 100644 --- a/content/learning-paths/cross-platform/function-multiversioning/examples3.md +++ b/content/learning-paths/cross-platform/function-multiversioning/examples3.md @@ -86,10 +86,6 @@ To compile with GCC, run: g++ -march=armv8-a -O3 skip-word.c ``` -{{% notice Note %}} -Note that `gcc++-14` does not support "mops" as a function multiversioning feature, so to compile this example with gcc remove the `target_clones` from CopyWord. -{{% /notice %}} - To run the application: ```console diff --git a/content/learning-paths/cross-platform/function-multiversioning/implementation-details.md b/content/learning-paths/cross-platform/function-multiversioning/implementation-details.md index 2dcfb0b460..924670cca8 100644 --- a/content/learning-paths/cross-platform/function-multiversioning/implementation-details.md +++ b/content/learning-paths/cross-platform/function-multiversioning/implementation-details.md @@ -64,11 +64,9 @@ f.resolver: The immediate value `#12582912` in this assembly is used to construct a bitmask for materializing the runtime detection of `rcpc3`. {{% /notice %}} -#### Differences between GCC 14 and LLVM 20 implementations +#### Differences between GCC 16 and LLVM 20 implementations -- The attribute `target_version` in GCC is only supported for C++, not for C. - The set of features as indicated by the [mapping table](https://arm-software.github.io/acle/main/acle.html#mapping) differs in support between the two compilers. -- LLVM supports mixing `target_version` with `target_clones` whereas GCC does not yet support this. #### Resolver emission with LLVM diff --git a/content/learning-paths/cross-platform/multiplying-matrices-with-sme2/2-check-your-environment.md b/content/learning-paths/cross-platform/multiplying-matrices-with-sme2/2-check-your-environment.md index 5c8a6e3f19..0d1e438649 100644 --- a/content/learning-paths/cross-platform/multiplying-matrices-with-sme2/2-check-your-environment.md +++ b/content/learning-paths/cross-platform/multiplying-matrices-with-sme2/2-check-your-environment.md @@ -197,7 +197,7 @@ defined in ``misc.c``. The ``sme2_check`` program then displays whether SVE, SME and SME2 are supported at line 24. The checking of SVE, SME and SME2 is done differently depending on -``BAREMETAL``. This platform specific behaviour is abstracted by the +``BAREMETAL``. This platform specific behavior is abstracted by the ``display_cpu_features()``: - In baremetal mode, our program has access to system registers and can inspect system registers for SME2 support. The program will print the SVE field of the ``ID_AA64PFR0_EL1`` system register and the SME field of the ``ID_AA64PFR1_EL1`` system register. - In non baremetal mode, on an Apple platform the program needs to use a higher diff --git a/content/learning-paths/cross-platform/simd-on-rust/simd-on-rust-part2.md b/content/learning-paths/cross-platform/simd-on-rust/simd-on-rust-part2.md index 35662773c2..e6771f3a0d 100644 --- a/content/learning-paths/cross-platform/simd-on-rust/simd-on-rust-part2.md +++ b/content/learning-paths/cross-platform/simd-on-rust/simd-on-rust-part2.md @@ -281,7 +281,7 @@ This seems counter-intuitive but the reason is that, unlike C, Rust treats the i Like functions, inlining them is not always guaranteed. If it is possible to inline the intrinsic, code generation and performance would be almost as that with C. If it is not possible, you might find that the same code in Rust performs worse than in C. -Because of this, you have to look carefully at the disassembly generated from your SIMD Rust code. So, how can you fix this behaviour and get the expected generated code? +Because of this, you have to look carefully at the disassembly generated from your SIMD Rust code. So, how can you fix this behavior and get the expected generated code? As you have seen, Rust has a very particular way to enable target features. In this case, you have to remember to add that `dotprod` is the required target feature. Make this change in the function `sad_vec_asimd` as shown below: diff --git a/content/learning-paths/embedded-and-microcontrollers/_index.md b/content/learning-paths/embedded-and-microcontrollers/_index.md index 694dc9cd6d..175ba5cb29 100644 --- a/content/learning-paths/embedded-and-microcontrollers/_index.md +++ b/content/learning-paths/embedded-and-microcontrollers/_index.md @@ -11,7 +11,7 @@ maintopic: true operatingsystems_filter: - Android: 1 - Baremetal: 30 -- Linux: 30 +- Linux: 31 - macOS: 7 - RTOS: 9 - Windows: 4 @@ -20,7 +20,7 @@ subjects_filter: - Containers and Virtualization: 6 - Embedded Linux: 4 - Libraries: 3 -- ML: 16 +- ML: 17 - Performance and Architecture: 21 - RTOS Fundamentals: 4 - Security: 2 @@ -50,8 +50,8 @@ tools_software_languages_filter: - DetectNet: 1 - Docker: 10 - DSTREAM: 2 -- Edge AI: 2 -- Edge Impulse: 1 +- Edge AI: 3 +- Edge Impulse: 2 - ExecuTorch: 4 - FastAPI: 1 - FPGA: 1 diff --git a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/_index.md b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/_index.md index 1bc986ec80..78e20ee0af 100644 --- a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/_index.md +++ b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/_index.md @@ -1,5 +1,5 @@ --- -title: Deploy Edge AI models scalably using Edge Impulse and AWS IoT Greengrass +title: Deploy Edge AI models using Edge Impulse and AWS IoT Greengrass draft: true cascade: @@ -7,13 +7,13 @@ cascade: minutes_to_complete: 120 -who_is_this_for: This learning path is for Edge AI and embedded engineers who need to scalably deploy crafted ML for the Edge to thousands of edge devices. +who_is_this_for: This learning path is for Edge AI and embedded engineers who need to deploy crafted ML for the Edge to thousands of edge devices. learning_objectives: - Basic understanding of Edge Impulses Edge ML Solution - Basic hardware setup for Edge AI ML development with Edge Impulse - Install AWS IoT Greengrass onto the edge device - - Configure the edge device with the custom integration between Edge Implulse and AWS IoT Greengrass + - Configure the edge device with the custom integration between Edge Impulse and AWS IoT Greengrass prerequisites: - An [Edge Impulse Studio](https://studio.edgeimpulse.com/signup) account (workshop will walk through this). diff --git a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/edgeimpulseprojectbuild.md b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/edgeimpulseprojectbuild.md index 856cea5d4b..9e5582253b 100644 --- a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/edgeimpulseprojectbuild.md +++ b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/edgeimpulseprojectbuild.md @@ -70,7 +70,7 @@ Key in this is the "Impulse". On the left side of the dashboard, our "Impulse" ![Edge Impulse](./images/EI_Project_2.png) -Clicking on "Object Detection" on the left, you will see some detail on the model that has been utlized in our Impulse: +Clicking on "Object Detection" on the left, you will see some detail on the model that has been utilized in our Impulse: ![Edge Impulse](./images/EI_Project_3.png) diff --git a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/greengrassinstallation.md b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/greengrassinstallation.md index 87e42301c7..a5d2136569 100644 --- a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/greengrassinstallation.md +++ b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/greengrassinstallation.md @@ -22,7 +22,7 @@ Prior to installing AWS IoT Greengrass, we need to create a set of AWS credentia > export AWS_ACCESS_KEY_ID= > export AWS_SECRET_ACCESS_KEY= -If you are using your personal AWS account and do not have the credentails created, you will need to create them. If you already have them, please skip the next step and proceed to step 3) below. +If you are using your personal AWS account and do not have the credentials created, you will need to create them. If you already have them, please skip the next step and proceed to step 3) below. #### 1a. Creating Access Credentials (personal AWS Accounts) diff --git a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/hardware/hardwaresetupec2.md b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/hardware/hardwaresetupec2.md index 7dece6c720..f8aed88de1 100644 --- a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/hardware/hardwaresetupec2.md +++ b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/hardware/hardwaresetupec2.md @@ -33,7 +33,7 @@ Press "Add security group rule" and lets allow port tcp/4912: Lets also give the EC2 instance a bit more disk space. Please change the "8" to "28" here: -![Increase Diskspace](../images/EC2_Setup_5.png) +![Increase disk space](../images/EC2_Setup_5.png) Finally, press "Launch instance". You should see your EC2 instance getting created: diff --git a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/running.md b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/running.md index 9fb6ad386b..f96c63338b 100644 --- a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/running.md +++ b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/running.md @@ -20,7 +20,7 @@ So, for example, if my public ip address of my edge device is "1.1.1.1", my url http://1.1.1.1:4912 -You should now see both the imput (video either from file or from your edge devices attached camera) as well as inference results and inference times. There are two output scenarios depending on whether your edge device has a camera or does not have a camera... read below! +You should now see both the input (video either from file or from your edge devices attached camera) as well as inference results and inference times. There are two output scenarios depending on whether your edge device has a camera or does not have a camera... read below! ### Option 1: Edge devices with cameras @@ -60,7 +60,7 @@ Additionally, you will see, model metrics being published periodically: ![Model Metrics](./images/EI_Model_Metrics.png) -#### Issuing a command and examing the command result +#### Issuing a command and examining the command result The integration provides a set of commands (see the [Summary](8_Summary.md) for details on the commands). One command, in particular, restarts the Edge Impulse "Runner" service. @@ -102,7 +102,7 @@ and you should see your inferencing resuming. You should also see more inference >**_NOTE:_** >For those who have edge devices WITHOUT cameras, your runner will read is input image video and report inferences until the video ends. Once ended, the "Runner" will simply wait for you to issue the above "restart" command to replay the video file. The restart command will cause the Runner to restart and it will once again, play the video file. -Cool! Congradulations! You have completed this workshop!! +Cool! Congratulations! You have completed this workshop!! #### Supplemental notes Below are a few additional notes regarding the component deployment, log files, launch times for some devices: diff --git a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/summary.md b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/summary.md index 171be46fdc..e48415dbbb 100644 --- a/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/summary.md +++ b/content/learning-paths/embedded-and-microcontrollers/edge_impulse_greengrass/summary.md @@ -8,7 +8,7 @@ layout: learningpathall ## Summary -Congradulations! You have completed this workshop! Please select "Next" below to read a bit about cleaning up your AWS environment in order to minimize costs/etc (AWS workshop attendees: this will happen automatically for you) +Congratulations! You have completed this workshop! Please select "Next" below to read a bit about cleaning up your AWS environment in order to minimize costs/etc (AWS workshop attendees: this will happen automatically for you) ### For More Information diff --git a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/build_nn.md b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/build_nn.md index 72390b8268..8296e75c8d 100644 --- a/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/build_nn.md +++ b/content/learning-paths/embedded-and-microcontrollers/img_nn_stcube/build_nn.md @@ -120,7 +120,7 @@ y_test shape: (10000, 10) ## Create the Model -You are going to create a small convolutional neural network for image classification. The image size of CIFAR10 is 32 by 32, and the number of colour channels is 3. So, the input shape of the first convolution layer is (32, 32, 3). Since the number of classes is 10, so the last dense layer should have 10 units. +You are going to create a small convolutional neural network for image classification. The image size of CIFAR10 is 32 by 32, and the number of color channels is 3. So, the input shape of the first convolution layer is (32, 32, 3). Since the number of classes is 10, so the last dense layer should have 10 units. Here is an image illustrating the network architecture. Note that only convolution and dense layers are illustrated in this image. diff --git a/content/learning-paths/laptops-and-desktops/memory-tagged-dynamic-memory-allocator/how-to-4.md b/content/learning-paths/laptops-and-desktops/memory-tagged-dynamic-memory-allocator/how-to-4.md index a2800aa274..b73652ad87 100644 --- a/content/learning-paths/laptops-and-desktops/memory-tagged-dynamic-memory-allocator/how-to-4.md +++ b/content/learning-paths/laptops-and-desktops/memory-tagged-dynamic-memory-allocator/how-to-4.md @@ -218,11 +218,11 @@ If you are attempting to free memory using an incorrectly tagged pointer, this is invalid. This applies whether it actually points to an allocated range or to free space. Letting either happen could corrupt the internal structures of the heap. -## Undefined Malloc And Free Behaviour +## Undefined Malloc And Free Behavior The C standard library defines `free` as expecting to be given a pointer that is exactly the same as that which was produced by `malloc`. Therefore, it is -undefined behaviour to pass a modified pointer to free, for example, as a pointer to +undefined behavior to pass a modified pointer to free, for example, as a pointer to the middle of an allocation rather than the start. This doesn't mean that an implementation can't accept a modified pointer. It @@ -234,7 +234,7 @@ points to the same allocation. Our memory tagging allocator is stricter than that. Despite the pointer's logical tag not changing where it points to, the allocator will not allow you to use a pointer with an incorrect tag. -Looking at the examples above, you can see why the ranges of behaviour allowed by +Looking at the examples above, you can see why the ranges of behavior allowed by the standard (or rather, left undefined) can be useful for different use cases. If you wanted to make our allocator less strict, you could disable tag checking. diff --git a/content/learning-paths/laptops-and-desktops/windowsperf-vs-extension/spe-feature.md b/content/learning-paths/laptops-and-desktops/windowsperf-vs-extension/spe-feature.md index af5e4fdd46..f7a50845d0 100644 --- a/content/learning-paths/laptops-and-desktops/windowsperf-vs-extension/spe-feature.md +++ b/content/learning-paths/laptops-and-desktops/windowsperf-vs-extension/spe-feature.md @@ -19,7 +19,7 @@ This section requires hardware that supports the SPE specification to function p The Arm Statistical Profiling Extension (SPE) is an architectural feature designed for enhanced instruction execution profiling within Arm CPUs. This feature has been available since the introduction of the Neoverse N1 CPU platform in 2019, along with performance monitor units (PMUs) generally available in Arm CPUs. -The SPE is an optional feature in ARMv8.2 hardware that allows CPU instructions to be sampled and associated with the source code location where that instruction occured. +The SPE is an optional feature in ARMv8.2 hardware that allows CPU instructions to be sampled and associated with the source code location where that instruction occurred. Some of the key methodologies that can be applied for performance analysis using SPE-profiled data are as follows: diff --git a/content/learning-paths/mobile-graphics-and-gaming/android_halide/android.md b/content/learning-paths/mobile-graphics-and-gaming/android_halide/android.md index 3bb359a6fa..58ba9f918b 100644 --- a/content/learning-paths/mobile-graphics-and-gaming/android_halide/android.md +++ b/content/learning-paths/mobile-graphics-and-gaming/android_halide/android.md @@ -18,7 +18,7 @@ Kotlin, now the preferred programming language for Android development, combines ## Benefits of using Halide on mobile Integrating Halide into Android applications brings several key advantages: 1. Performance. Halide enables significant acceleration of complex image processing algorithms, often surpassing the speed of traditional Java or Kotlin implementations by leveraging optimized code generation. By generating highly optimized native code tailored for ARM CPUs or GPUs, Halide can dramatically increase frame rates and responsiveness, essential for real-time or interactive applications. -2. Efficiency. On mobile devices, resource efficiency translates directly to improved battery life and reduced thermal output. Halide’s scheduling strategies (such as operation fusion, tiling, parallelization, and vectorization) minimize unnecessary memory transfers, CPU usage, and GPU overhead. This optimization substantially reduces overall power consumption, extending battery life and enhancing the user experience by preventing overheating. +2. Efficiency. On mobile devices, resource efficiency translates directly to improved battery life and reduced thermal output. Halide's scheduling strategies (such as operation fusion, tiling, parallelization, and vectorization) minimize unnecessary memory transfers, CPU usage, and GPU overhead. This optimization substantially reduces overall power consumption, extending battery life and enhancing the user experience by preventing overheating. 3. Portability. Halide abstracts hardware-specific details, allowing developers to write a single high-level pipeline that easily targets different processor architectures and hardware configurations. Pipelines can seamlessly run on various ARM-based CPUs and GPUs commonly found in Android smartphones and tablets, enabling developers to support a wide range of devices with minimal platform-specific modifications. 4. Custom Algorithm Integration. Halide allows developers to easily integrate their bespoke image-processing algorithms that may not be readily available or optimized in common libraries, providing full flexibility and control over application-specific performance and functionality. @@ -28,7 +28,7 @@ In short, Halide delivers high-performance image processing without sacrificing While Android presents abundant opportunities for developers, the mobile development ecosystem brings its own set of challenges, especially for performance-intensive applications: 1. Limited Hardware Resources. Unlike desktop or server environments, mobile devices have significant constraints on processing power, memory capacity, and battery life. Developers must optimize software meticulously to deliver smooth performance while carefully managing hardware resource consumption. Leveraging tools like Halide allows developers to overcome these constraints by optimizing computational workloads, making resource-intensive tasks feasible on constrained hardware. 2. Cross-Compilation Complexities. Developing native code for Android requires handling multiple hardware architectures (such as armv8-a, ARM64, and sometimes x86/x86_64). Cross-compilation introduces complexities due to different instruction sets, CPU features, and performance characteristics. Managing this complexity involves careful use of the Android NDK, understanding toolchains, and correctly configuring build systems (e.g., Gradle, CMake). Halide helps mitigate these issues by abstracting away many platform-specific optimizations, automatically generating code optimized for target architectures. -3. Image-Format Conversions (Bitmap ↔ Halide Buffer). Android typically handles images through the Bitmap class or similar platform-specific constructs, whereas Halide expects image data to be in raw, contiguous buffer formats. Developers must bridge the gap between Android-specific image representations (Bitmaps, YUV images from camera APIs, etc.) and Halide’s native buffer format. Proper management of these conversions—including considerations for pixel formats, stride alignment, and memory copying overhead—can significantly impact performance and correctness, necessitating careful design and efficient implementation of buffer-handling routines. +3. Image-Format Conversions (Bitmap ↔ Halide Buffer). Android typically handles images through the Bitmap class or similar platform-specific constructs, whereas Halide expects image data to be in raw, contiguous buffer formats. Developers must bridge the gap between Android-specific image representations (Bitmaps, YUV images from camera APIs, etc.) and Halide's native buffer format. Proper management of these conversions—including considerations for pixel formats, stride alignment, and memory copying overhead—can significantly impact performance and correctness, necessitating careful design and efficient implementation of buffer-handling routines. ## Project requirements Before integrating Halide into your Android application, ensure you have the necessary tools and libraries. @@ -409,11 +409,11 @@ Through this JNI bridge, Kotlin can invoke high-performance native code. You can ![img9](Figures/09.png) ![img10](Figures/10.png) -In the above code we created a new jbyteArray and copying the data explicitly, which can result in an additional overhead. To optimize performance by avoiding unnecessary memory copies, you can directly wrap Halide’s buffer in a Java-accessible ByteBuffer like so +In the above code we created a new jbyteArray and copying the data explicitly, which can result in an additional overhead. To optimize performance by avoiding unnecessary memory copies, you can directly wrap Halide's buffer in a Java-accessible ByteBuffer like so ```java // Instead of allocating a new jbyteArray, create a direct ByteBuffer from Halide's buffer data. jobject outputBuffer = env->NewDirectByteBuffer(output.data(), width * height); ``` ## Summary -In this lesson, we’ve successfully integrated a Halide image-processing pipeline into an Android application using Kotlin. We started by setting up an Android project configured for native development with the Android NDK, employing Kotlin as the primary language. We then integrated Halide-generated static libraries and demonstrated their usage through Java Native Interface (JNI), bridging Kotlin and native code. This equips developers with the skills needed to harness Halide’s capabilities for building sophisticated, performant mobile applications on Android. \ No newline at end of file +In this lesson, we’ve successfully integrated a Halide image-processing pipeline into an Android application using Kotlin. We started by setting up an Android project configured for native development with the Android NDK, employing Kotlin as the primary language. We then integrated Halide-generated static libraries and demonstrated their usage through Java Native Interface (JNI), bridging Kotlin and native code. This equips developers with the skills needed to harness Halide's capabilities for building sophisticated, performant mobile applications on Android. \ No newline at end of file diff --git a/content/learning-paths/mobile-graphics-and-gaming/android_halide/aot-and-cross-compilation.md b/content/learning-paths/mobile-graphics-and-gaming/android_halide/aot-and-cross-compilation.md index 4c8ebe0796..f4003f1f51 100644 --- a/content/learning-paths/mobile-graphics-and-gaming/android_halide/aot-and-cross-compilation.md +++ b/content/learning-paths/mobile-graphics-and-gaming/android_halide/aot-and-cross-compilation.md @@ -8,7 +8,7 @@ layout: "learningpathall" --- ## Ahead-of-time and cross-compilation -One of Halide’s standout features is the ability to compile image processing pipelines ahead-of-time (AOT), enabling developers to generate optimized binary code on their host machines rather than compiling directly on target devices. This AOT compilation process allows developers to create highly efficient libraries that run effectively across diverse hardware without incurring the runtime overhead associated with just-in-time (JIT) compilation. +One of Halide's standout features is the ability to compile image processing pipelines ahead-of-time (AOT), enabling developers to generate optimized binary code on their host machines rather than compiling directly on target devices. This AOT compilation process allows developers to create highly efficient libraries that run effectively across diverse hardware without incurring the runtime overhead associated with just-in-time (JIT) compilation. Halide also supports robust cross-compilation capabilities. Cross-compilation means using the host version of Halide, typically running on a desktop Linux or macOS system—to target different architectures, such as ARM for Android devices. Developers can thus optimize Halide pipelines on their host machine, produce libraries specifically optimized for Android, and integrate them seamlessly into Android applications. The generated pipeline code includes essential optimizations and can embed minimal runtime support, further reducing workload on the target device and ensuring responsiveness and efficiency. @@ -16,7 +16,7 @@ Halide also supports robust cross-compilation capabilities. Cross-compilation me In this section, we leverage the host version of Halide to perform AOT compilation of an image processing pipeline via cross-compilation. The resulting pipeline library is specifically tailored to Android devices (targeting, for instance, arm64-v8a ABI), while the compilation itself occurs entirely on the host system. This approach significantly accelerates development by eliminating the need to build Halide or perform JIT compilation on Android devices. It also guarantees that the resulting binaries are optimized for the intended hardware, streamlining the deployment of high-performance image processing applications on mobile platforms. ## Prepare Pipeline for Android -The procedure implemented in the following code demonstrates how Halide’s AOT compilation and cross-compilation features can be utilized to create an optimized image processing pipeline for Android. We will run Halide on our host machine (in this example, macOS) to generate a static library containing the pipeline function, which will later be invoked from an Android device. Below is a step-by-step explanation of this process. +The procedure implemented in the following code demonstrates how Halide's AOT compilation and cross-compilation features can be utilized to create an optimized image processing pipeline for Android. We will run Halide on our host machine (in this example, macOS) to generate a static library containing the pipeline function, which will later be invoked from an Android device. Below is a step-by-step explanation of this process. Create a new file named blur-android.cpp with the following contents: @@ -85,7 +85,7 @@ int main(int argc, char** argv) { } ``` -In the original implementation constants 128, 255, and 0 were implicitly treated as integers. Here, the threshold value (128) and output values (255, 0) are explicitly cast to uint8_t. This approach removes ambiguity and clearly specifies the types used, ensuring compatibility and clarity. Both approaches result in identical functionality, but explicitly casting helps emphasize the type correctness and may avoid subtle issues during cross-compilation or in certain environments. +In the original implementation constants 128, 255, and 0 were implicitly treated as integers. Here, the threshold value (128) and output values (255, 0) are explicitly cast to uint8_t. This approach removes ambiguity and clearly specifies the types used, ensuring compatibility and clarity. Both approaches result in identical functionality, but explicitly casting helps emphasize the type correctness and may avoid subtle issues during cross-compilation or in certain environments. Additionally, explicit uint8_t casts help avoid implicit promotion to 32-bit integers (and the corresponding narrowings back to 8-bit) in the generated code, reducing redundant cast operations and potential vector widen/narrow overhead—especially on ARM/NEON The program takes at least one command-line argument, the output base name used to generate the files (e.g., “blur_threshold_android”). Here, the target architecture is explicitly set within the code to Android ARM64: @@ -105,8 +105,12 @@ target.set_feature(Target::NoRuntime, false); ``` Notes: -* NoRuntime — When set to true, Halide excludes its runtime from the generated code, and you must link the runtime manually during the linking step. When set to false, the Halide runtime is included in the generated library, which simplifies deployment. -* ARMFp16 — Enables the use of ARM hardware support for half-precision (16-bit) floating-point operations, which can provide faster execution when reduced precision is acceptable. +1. NoRuntime — When set to true, Halide excludes its runtime from the generated code, and you must link the runtime manually during the linking step. When set to false, the Halide runtime is included in the generated library, which simplifies deployment. +2. ARMFp16 — Enables the use of ARM hardware support for half-precision (16-bit) floating-point operations, which can provide faster execution when reduced precision is acceptable. +3. Why the runtime choice matters - If your app links several AOT-compiled pipelines, ensure there is exactly one Halide runtime at link time: +* Strategy A (cleanest): build all pipelines with NoRuntime ON and link a single standalone Halide runtime once (matching the union of features you need, e.g., Vulkan/OpenCL/Metal or ARM options). +* Strategy B: embed the runtime in exactly one pipeline (leave NoRuntime OFF only there); compile all other pipelines with NoRuntime ON. +* Mixing more than one runtime can cause duplicate symbols and split global state (e.g., error handlers, device interfaces). We declare spatial variables (x, y) and an ImageParam named “input” representing the input image data. We use boundary clamping (clamp) to safely handle edge pixels. Then, we apply a 3x3 blur with a reduction domain (RDom). The accumulated sum is divided by 9 (the number of pixels in the neighborhood), producing an average blurred image. Lastly, thresholding is applied, producing a binary output: pixels above a certain brightness threshold (128) become white (255), while others become black (0). @@ -118,7 +122,7 @@ This strategy can simplify debugging by clearly isolating computational steps an By clearly separating algorithm logic from scheduling, developers can easily test and compare different scheduling strategies,such as compute_inline, compute_root, compute_at, and more, without modifying their fundamental algorithmic code. This separation significantly accelerates iterative optimization and debugging processes, ultimately yielding better-performing code with minimal overhead. -We invoke Halide’s AOT compilation function compile_to_static_library, which generates a static library (.a) containing the optimized pipeline and a corresponding header file (.h). +We invoke Halide's AOT compilation function compile_to_static_library, which generates a static library (.a) containing the optimized pipeline and a corresponding header file (.h). ```cpp thresholded.compile_to_static_library( @@ -130,7 +134,7 @@ thresholded.compile_to_static_library( ``` This will produce: -* A static library (blur_threshold_android.a) containing the compiled pipeline. This static library also includes Halide’s runtime functions tailored specifically for the targeted architecture (arm-64-android). Thus, no separate Halide runtime needs to be provided on the Android device when linking against this library. +* A static library (blur_threshold_android.a) containing the compiled pipeline. This static library also includes Halide's runtime functions tailored specifically for the targeted architecture (arm-64-android). Thus, no separate Halide runtime needs to be provided on the Android device when linking against this library. * A header file (blur_threshold_android.h) declaring the pipeline function for use in other C++/JNI code. These generated files are then ready to integrate directly into an Android project via JNI, allowing efficient execution of the optimized pipeline on Android devices. The integration process is covered in the next section. @@ -159,4 +163,4 @@ This will produce two files: We will integrate these files into our Android project in the following section. ## Summary -In this section, we’ve explored Halide’s powerful ahead-of-time (AOT) and cross-compilation capabilities, preparing an optimized image processing pipeline tailored specifically for Android devices. By using the host-based Halide compiler, we’ve generated a static library optimized for ARM64 Android architecture, incorporating safe boundary conditions, neighborhood-based blurring, and thresholding operations. This streamlined process allows seamless integration of highly optimized native code into Android applications, ensuring both development efficiency and runtime performance on mobile platforms. \ No newline at end of file +In this section, we’ve explored Halide's powerful ahead-of-time (AOT) and cross-compilation capabilities, preparing an optimized image processing pipeline tailored specifically for Android devices. By using the host-based Halide compiler, we’ve generated a static library optimized for ARM64 Android architecture, incorporating safe boundary conditions, neighborhood-based blurring, and thresholding operations. This streamlined process allows seamless integration of highly optimized native code into Android applications, ensuring both development efficiency and runtime performance on mobile platforms. \ No newline at end of file diff --git a/content/learning-paths/mobile-graphics-and-gaming/android_halide/fusion.md b/content/learning-paths/mobile-graphics-and-gaming/android_halide/fusion.md index 6ce0249adf..f10442403f 100644 --- a/content/learning-paths/mobile-graphics-and-gaming/android_halide/fusion.md +++ b/content/learning-paths/mobile-graphics-and-gaming/android_halide/fusion.md @@ -10,7 +10,7 @@ layout: "learningpathall" ## Objective In the previous section, you explored parallelization and tiling. Here, you will focus on operator fusion (inlining) in Halide i.e., letting producers be computed directly inside their consumers—versus materializing intermediates with compute_root() or compute_at(). You will learn when fusion reduces memory traffic and when materializing saves recomputation (e.g., for large stencils or multi-use intermediates). You will inspect loop nests with print_loop_nest(), switch among schedules (fuse-all, fuse-blur-only, materialize, tile-and-materialize-per-tile) in a live camera pipeline, and measure the impact (ms/FPS/MPix/s). -This section does not cover loop fusion (the fuse directive). You will focus on operator fusion, which is Halide’s default behavior. +This section does not cover loop fusion (the fuse directive). You will focus on operator fusion, which is Halide's default behavior. ## Code To demonstrate how fusion in Halide works create a new file `camera-capture-fusion.cpp`, and modify it as follows. This code uses a live camera pipeline (BGR → gray → 3×3 blur → threshold), adds a few schedule variants to toggle operator fusion vs. materialization, and print ms / FPS / MPix/s. So you can see the impact immediately. @@ -42,7 +42,7 @@ static const char* schedule_name(Schedule s) { case Schedule::FuseBlurAndThreshold: return "FuseBlurAndThreshold"; case Schedule::FuseAll: return "FuseAll"; case Schedule::Tile: return "Tile"; - default: return "Unknown"; + default: return "Unknown"; } } @@ -174,10 +174,10 @@ int main(int argc, char** argv) { if (!frame.isContinuous()) frame = frame.clone(); // Wrap interleaved frame - auto in_rt = Runtime::Buffer::make_interleaved( - frame.data, frame.cols, frame.rows, /*channels*/3); - Buffer<> in_fe(*in_rt.raw_buffer()); - input.set(in_fe); + Halide::Buffer inputBuf = Runtime::Buffer::make_interleaved( + frame.data, frame.cols, frame.rows, frame.channels()); + + input.set(inputBuf); // Time the Halide realize() only auto t0 = std::chrono::high_resolution_clock::now(); @@ -232,32 +232,6 @@ int main(int argc, char** argv) { return 0; } ``` -You will begin by pulling in the right set of headers. Right after the includes you define an enumeration, Schedule, which lists the four different scheduling strategies you want to experiment with. These represent the “modes” you will toggle between while the program is running: a simple materialized version, a fused blur-plus-threshold, a fully fused pipeline, and a tiled variant. - -Finally, to make the output more readable, you add a small helper function, `schedule_name`. It converts each enum value into a human-friendly label so that when the program prints logs or overlays statistics, you can immediately see which schedule is active. -```cpp -#include "Halide.h" -#include -#include -#include -#include -#include -#include -#include - -using namespace Halide; -using namespace cv; -using namespace std; - -enum class Schedule : int { - Simple = 0, - FuseBlurAndThreshold = 1, - FuseAll = 2, - Tile = 3, -}; - -static const char* schedule_name(Schedule s) { ... } -``` The main part of this program is the `make_pipeline` function. It defines the camera processing pipeline in Halide and applies different scheduling choices depending on which mode we select. @@ -282,33 +256,6 @@ Next comes the gray conversion. As in previous section, you will use Rec.601 wei You will then add a threshold stage. Pixels above 128 become white, and all others black, producing a binary image. Finally, define an output Func that wraps the thresholded result and call compute_root() on it so that it will be realized explicitly when you run the pipeline. -```cpp - // (c) BGR → gray (Rec.601, float weights) - Func gray("gray"); - gray(x, y) = cast(0.114f * inputClamped(x, y, 0) - + 0.587f * inputClamped(x, y, 1) - + 0.299f * inputClamped(x, y, 2)); - - // (d) 3×3 binomial blur, unrolled in host code (no RDom needed) - Func blur("blur"); - const uint16_t k[3][3] = {{1,2,1},{2,4,2},{1,2,1}}; - Expr blurSum = cast(0); - for (int j = 0; j < 3; ++j) - for (int i = 0; i < 3; ++i) - blurSum = blurSum + cast(gray(x + i - 1, y + j - 1)) * k[j][i]; - blur(x, y) = cast(blurSum / 16); - - // (e) Threshold to binary - Func thresholded("thresholded"); - Expr T = cast(128); - thresholded(x, y) = select(blur(x, y) > T, cast(255), cast(0)); - - // (f) Final output and default root - Func output("output"); - output(x, y) = thresholded(x, y); - output.compute_root(); -``` - Now comes the interesting part: the scheduling choices. Depending on the Schedule enum passed in, you instruct Halide to either fuse everything (the default), materialize some intermediates, or even tile the output. * Simple: Here you will explicitly compute and store both gray and blur across the whole frame with compute_root(). This makes them easy to reuse or parallelize, but requires extra memory traffic. * FuseBlurAndThreshold: You compute gray once as a planar buffer, but leave blur and thresholded fused into output. This often works well when the input is interleaved, because subsequent stages read from a planar gray. @@ -470,13 +417,13 @@ Comparing the numbers: By toggling schedules live, you can see and measure how operator fusion and materialization change both the loop structure and the throughput: * Fusion is the default in Halide and eliminates temporary storage, but may cause recomputation for spatial filters. -* Materializing selected stages with compute_root() or compute_at() can reduce recomputation, enable vectorization and parallelization, and sometimes yield much higher throughput. +* Materializing selected stages with compute_root() or compute_at() can reduce recomputation and improve locality. It can also make vectorization and parallelization easier or more effective, but they are not strictly required by materialization and can be applied independently. For best performance, consider these choices together and measure on your target. * Tile-level materialization (compute_at) provides a hybrid - fusing within tiles while keeping intermediates small and cache-resident. This demo makes these trade-offs concrete: the loop nest diagrams explain the structure, and the live FPS/MPix/s stats show the real performance impact. ## What “fusion” means in Halide -One of Halide’s defining features is that, by default, it performs operator fusion, also called inlining. This means that if a stage produces some intermediate values, those values aren’t stored in a separate buffer and then re-read later—instead, the stage is computed directly inside the consumer’s loop. In other words, unless you tell Halide otherwise, every producer Func is fused into the next stage that uses it. +One of Halide's defining features is that, by default, it performs operator fusion, also called inlining. This means that if a stage produces some intermediate values, those values aren’t stored in a separate buffer and then re-read later—instead, the stage is computed directly inside the consumer’s loop. In other words, unless you tell Halide otherwise, every producer Func is fused into the next stage that uses it. Why is this important? Fusion reduces memory traffic, because Halide doesn’t need to write intermediates out to RAM and read them back again. On CPUs, where memory bandwidth is often the bottleneck, this can be a major performance win. Fusion also improves cache locality, since values are computed exactly where they are needed and the working set stays small. The trade-off, however, is that fusion can cause recomputation: if a consumer uses a neighborhood (like a blur that reads 3×3 or 9×9 pixels), the fused producer may be recalculated multiple times for overlapping regions. Whether fusion is faster depends on the balance between compute cost and memory traffic. @@ -509,7 +456,7 @@ Our pipeline is: BGR input → gray → 3×3 blur → thresholded → output. De By toggling between these modes in the live demo, you can see how the loop nests and throughput numbers change, which makes the abstract idea of fusion much more concrete. ## When to use operator fusion -Fusion is Halide’s default and usually the right place to start. It’s especially effective for: +Fusion is Halide's default and usually the right place to start. It’s especially effective for: * Element-wise chains, where each pixel is transformed independently: examples include intensity scaling or offset, gamma correction, channel mixing, color-space conversions, and logical masking. * Cheap post-ops after spatial filters: @@ -528,4 +475,4 @@ Fusion isn’t always best. You’ll want to materialize an intermediate (comput The fastest way to check whether fusion helps is to measure it. Our demo prints timing and throughput per frame, but Halide also includes a built-in profiler that reports per-stage runtimes. To learn how to enable and interpret the profiler, see the official [Halide profiling tutorial](https://halide-lang.org/tutorials/tutorial_lesson_21_auto_scheduler_generate.html#profiling). ## Summary -In this section, you have learned about operator fusion in Halide—a powerful technique for reducing memory bandwidth and improving computational efficiency. You explored why fusion matters, looked at scenarios where it is most effective, and saw how Halide’s scheduling constructs such as compute_root() and compute_at() let us control whether stages are fused or materialized. By experimenting with different schedules, including fusing the Gaussian blur and thresholding stages, we observed how fusion can significantly improve the performance of a real-time image processing pipeline +In this section, you have learned about operator fusion in Halide—a powerful technique for reducing memory bandwidth and improving computational efficiency. You explored why fusion matters, looked at scenarios where it is most effective, and saw how Halide's scheduling constructs such as compute_root() and compute_at() let us control whether stages are fused or materialized. By experimenting with different schedules, including fusing the Gaussian blur and thresholding stages, we observed how fusion can significantly improve the performance of a real-time image processing pipeline diff --git a/content/learning-paths/mobile-graphics-and-gaming/android_halide/intro.md b/content/learning-paths/mobile-graphics-and-gaming/android_halide/intro.md index 892004c17c..3883ee0e7c 100644 --- a/content/learning-paths/mobile-graphics-and-gaming/android_halide/intro.md +++ b/content/learning-paths/mobile-graphics-and-gaming/android_halide/intro.md @@ -12,7 +12,7 @@ Halide is a powerful, open-source programming language specifically designed to A key advantage of Halide lies in its innovative programming model. By clearly distinguishing between algorithmic logic and scheduling decisions—such as parallelism, vectorization, memory management, and hardware-specific optimizations, developers can first focus on ensuring the correctness of their algorithms. Performance tuning can then be handled independently, significantly accelerating development cycles. This approach often yields performance that matches or even surpasses manually optimized code. As a result, Halide has seen widespread adoption across industry and academia, powering image processing systems at organizations such as Google, Adobe, and Facebook, and enabling advanced computational photography features used by millions daily. -In this learning path, you will explore Halide’s foundational concepts, set up your development environment, and create your first functional Halide application. By the end, you will understand what makes Halide uniquely suited to efficient image processing, particularly on mobile and Arm-based hardware, and be ready to build your own optimized pipelines. +In this learning path, you will explore Halide's foundational concepts, set up your development environment, and create your first functional Halide application. By the end, you will understand what makes Halide uniquely suited to efficient image processing, particularly on mobile and Arm-based hardware, and be ready to build your own optimized pipelines. For broader or more general use cases, please refer to the official Halide documentation and tutorials available at [halide-lang.org](https://halide-lang.org). @@ -20,7 +20,7 @@ The example code for this Learning Path is available in two repositories [here]( ## Key concepts in Halide ### Separation of algorithm and schedule -At the core of Halide’s design philosophy is the principle of clearly separating algorithms from schedules. Traditional image-processing programming tightly couples algorithmic logic with execution strategy, complicating optimization and portability. In contrast, Halide explicitly distinguishes these two components: +At the core of Halide's design philosophy is the principle of clearly separating algorithms from schedules. Traditional image-processing programming tightly couples algorithmic logic with execution strategy, complicating optimization and portability. In contrast, Halide explicitly distinguishes these two components: * Algorithm: Defines what computations are performed—for example, image filters, pixel transformations, or other mathematical operations on image data. * Schedule: Specifies how and where these computations are executed, addressing critical details such as parallel execution, memory usage, caching strategies, and hardware-specific optimizations. @@ -154,7 +154,7 @@ int main() { } ``` -This program demonstrates how to combine Halide’s image processing capabilities with OpenCV’s image I/O and display functionality. It begins by loading an image from disk using OpenCV, specifically reading from a static file named `img.png` (here you use a Cameraman image). Since OpenCV loads images in BGR format by default, the code immediately converts the image to RGB format so that it is compatible with Halide’s expectations. +This program demonstrates how to combine Halide's image processing capabilities with OpenCV’s image I/O and display functionality. It begins by loading an image from disk using OpenCV, specifically reading from a static file named `img.png` (here you use a Cameraman image). Since OpenCV loads images in BGR format by default, the code immediately converts the image to RGB format so that it is compatible with Halide's expectations. Once the image is loaded and converted, the program wraps the raw image data into a Halide buffer, capturing the image’s dimensions (width, height, and color channels). Next, the Halide pipeline is defined through a function named invert, which specifies the computations to perform on each pixel—in this case, subtracting the original pixel value from 255 to invert the colors. The pipeline definition alone does not perform any actual computation; it only describes what computations should occur and how to schedule them. @@ -188,7 +188,7 @@ Buffer inputBuffer = Buffer::make_interleaved( 2. Planar Layout (RRR...GGG...BBB...): * Preferred by certain image-processing routines or hardware accelerators (e.g., some GPU kernels or certain ML frameworks). -* Achieved naturally by Halide’s default loop ordering (x, y, c). +* Achieved naturally by Halide's default loop ordering (x, y, c). It is essential to select loop ordering based on your specific data format requirements and integration scenario. Halide provides full flexibility, allowing you to explicitly reorder loops to match the desired memory layout efficiently. @@ -231,7 +231,7 @@ You will see two windows displaying the original and inverted images: ![img2](Figures/02.png) ## Summary -In this section, you have learned Halide’s foundational concepts, explored the benefits of separating algorithms and schedules, set up your development environment, and created your first functional Halide application integrated with OpenCV. +In this section, you have learned Halide's foundational concepts, explored the benefits of separating algorithms and schedules, set up your development environment, and created your first functional Halide application integrated with OpenCV. While the example introduces the core concepts of Halide pipelines (such as defining computations symbolically and realizing them), it does not yet showcase the substantial benefits of explicitly separating algorithm definition from scheduling strategies. diff --git a/content/learning-paths/mobile-graphics-and-gaming/android_halide/processing-workflow.md b/content/learning-paths/mobile-graphics-and-gaming/android_halide/processing-workflow.md index a06d206841..9536a75bfc 100644 --- a/content/learning-paths/mobile-graphics-and-gaming/android_halide/processing-workflow.md +++ b/content/learning-paths/mobile-graphics-and-gaming/android_halide/processing-workflow.md @@ -8,197 +8,189 @@ layout: "learningpathall" --- ## Objective -In this section, you will build a real-time camera processing pipeline using Halide. First, you capture video frames from a webcam using OpenCV, then implement a Gaussian (binomial) blur to smooth the captured images, followed by thresholding to create a clear binary output highlighting prominent image features. After establishing this pipeline, you will measure performance and then explore Halide’s scheduling options—parallelization and tiling—to understand when they help and when they don’t. +In this section, you will build a real-time camera processing pipeline using Halide. First, you capture video frames from a webcam using OpenCV, then implement a Gaussian (binomial) blur to smooth the captured images, followed by thresholding to create a clear binary output highlighting prominent image features. After establishing this pipeline, you will measure performance and then explore Halide's scheduling options—parallelization and tiling—to understand when they help and when they don’t. ## Gaussian blur and thresholding Create a new `camera-capture.cpp` file and modify it as follows: ```cpp #include "Halide.h" -#include "HalideRuntime.h" // for Runtime::Buffer make_interleaved #include #include #include #include #include +using namespace Halide; using namespace cv; using namespace std; -// Clamp coordinate within [0, maxCoord - 1]. -static inline Halide::Expr clampCoord(Halide::Expr coord, int maxCoord) { - return Halide::clamp(coord, 0, maxCoord - 1); -} - int main() { // Open the default camera. VideoCapture cap(0); if (!cap.isOpened()) { - cerr << "Error: Unable to open camera." << endl; + cerr << "Error: Unable to open camera.\n"; + return -1; + } + + // Grab one frame to determine dimensions and channels + Mat frame; + cap >> frame; + if (frame.empty()) { + cerr << "Error: empty first frame.\n"; return -1; } + // Ensure BGR 3-channel layout + if (frame.channels() == 4) + cvtColor(frame, frame, COLOR_BGRA2BGR); + else if (frame.channels() == 1) + cvtColor(frame, frame, COLOR_GRAY2BGR); + if (!frame.isContinuous()) + frame = frame.clone(); + + const int width = frame.cols; + const int height = frame.rows; + const int ch = frame.channels(); + + // Input + ImageParam input(UInt(8), 3, "input"); + input.dim(0).set_stride(ch); // interleaved: x stride = channels + input.dim(2).set_stride(1); + input.dim(2).set_bounds(0, 3); + + // Clamp borders + Func inputClamped = BoundaryConditions::repeat_edge(input); + + // Grayscale conversion (Rec.601 weights) + Var x("x"), y("y"); + Func gray("gray"); + gray(x, y) = cast(0.114f * inputClamped(x, y, 0) + + 0.587f * inputClamped(x, y, 1) + + 0.299f * inputClamped(x, y, 2)); + + // 3×3 binomial blur + Func blur("blur"); + const uint16_t k[3][3] = {{1,2,1},{2,4,2},{1,2,1}}; + Expr sum = cast(0); + for (int j = 0; j < 3; ++j) + for (int i = 0; i < 3; ++i) + sum += cast(gray(x + i - 1, y + j - 1)) * k[j][i]; + blur(x, y) = cast(sum / 16); + + // Threshold fused with blur + Func output("output"); + Expr T = cast(128); + output(x, y) = select(blur(x, y) > T, cast(255), cast(0)); + + // Allocate output buffer once + Buffer outBuf(width, height); + + // JIT compile once outside the loop + Pipeline pipe(output); + pipe.compile_jit(); + + namedWindow("Processing Workflow", WINDOW_NORMAL); + while (true) { - // Capture frame (typically interleaved BGR). - Mat frame; cap >> frame; - if (frame.empty()) { - cerr << "Error: Received empty frame." << endl; - break; - } - if (!frame.isContinuous()) frame = frame.clone(); - - const int width = frame.cols; - const int height = frame.rows; - const int channels = frame.channels(); // 3 (BGR) or 4 (BGRA) - - // Wrap the interleaved OpenCV frame for Halide. - auto in_rt = Halide::Runtime::Buffer::make_interleaved( - frame.data, width, height, channels); - Halide::Buffer<> inputBuffer(*in_rt.raw_buffer()); // front-end view - - // Define ImageParam (x, y, c) and declare interleaved layout. - Halide::ImageParam input(Halide::UInt(8), 3, "input"); - input.set(inputBuffer); - input.dim(0).set_stride(channels); // x-stride = C (interleaved) - input.dim(2).set_stride(1); // c-stride = 1 (adjacent bytes) - input.dim(2).set_bounds(0, channels); - - // Spatial vars. - Halide::Var x("x"), y("y"); - - // Grayscale in Halide - Halide::Func gray("gray"); - Halide::Expr r16 = Halide::cast(input(x, y, 2)); - Halide::Expr g16 = Halide::cast(input(x, y, 1)); - Halide::Expr b16 = Halide::cast(input(x, y, 0)); - - // Integer approx: Y ≈ (77*R + 150*G + 29*B) >> 8 - gray(x, y) = Halide::cast((77 * r16 + 150 * g16 + 29 * b16) >> 8); - - // 3×3 binomial kernel (sum = 16). - int kernel_vals[3][3] = { - {1, 2, 1}, - {2, 4, 2}, - {1, 2, 1} - }; - Halide::Buffer kernelBuf(&kernel_vals[0][0], 3, 3); - - // Blur via reduction over a 3×3 neighborhood. - Halide::RDom r(0, 3, 0, 3); - Halide::Func blur("blur"); - - // Use int16_t for safe multiply-and-accumulate with 8-bit input. - Halide::Expr val = - Halide::cast( - gray(clampCoord(x + r.x - 1, width), - clampCoord(y + r.y - 1, height)) - ) * Halide::cast(kernelBuf(r.x, r.y)); - - blur(x, y) = Halide::cast(Halide::sum(val) / 16); - - // Thresholding. - Halide::Func thresholded("thresholded"); - thresholded(x, y) = Halide::cast( - Halide::select(blur(x, y) > 128, 255, 0) - ); - - // Realize and display. - Halide::Buffer outputBuffer; + if (frame.empty()) break; + if (frame.channels() == 4) + cvtColor(frame, frame, COLOR_BGRA2BGR); + else if (frame.channels() == 1) + cvtColor(frame, frame, COLOR_GRAY2BGR); + if (!frame.isContinuous()) + frame = frame.clone(); + + // Use Halide::Buffer::make_interleaved directly + Buffer inputBuf = + Buffer::make_interleaved(frame.data, frame.cols, frame.rows, frame.channels()); + + input.set(inputBuf); + try { - outputBuffer = thresholded.realize({ width, height }); - } catch (const std::exception &e) { - cerr << "Halide pipeline error: " << e.what() << endl; + pipe.realize(outBuf); + } catch (const Halide::RuntimeError& e) { + cerr << "Halide runtime error: " << e.what() << "\n"; + break; + } catch (const std::exception& e) { + cerr << "std::exception: " << e.what() << "\n"; break; } - Mat blurredThresholded(height, width, CV_8UC1, outputBuffer.data()); - imshow("Processed Image", blurredThresholded); - - // ~33 FPS; exit on any key. - if (waitKey(30) >= 0) break; + // Display + Mat view(height, width, CV_8UC1, outBuf.data()); + imshow("Processing Workflow", view); + if (waitKey(1) >= 0) break; } - cap.release(); destroyAllWindows(); return 0; } ``` -This code demonstrates a real-time image processing pipeline using Halide and OpenCV. The default camera is accessed, continuously capturing color video frames in an interleaved BGR format. The images are then converted to the grayscale directly inside the Halide pipeline. A Halide function gray(x, y) computes the luminance from the red, green, and blue channels using an integer approximation of the Rec.601 formula: +The camera delivers interleaved BGR frames. Inside Halide, we convert to grayscale (Rec.601), apply a 3×3 binomial blur (sum/16 with 16-bit accumulation), then threshold to produce a binary image. We compile once (outside the capture loop) and realize per frame for real-time processing. + +A 3×3 filter needs neighbors (x±1, y±1). At the image edges, some taps would fall outside the valid region. Rather than scattering manual clamps across expressions, we wrap the input once: ```cpp -Halide::Expr r16 = Halide::cast(input(x, y, 2)); -Halide::Expr g16 = Halide::cast(input(x, y, 1)); -Halide::Expr b16 = Halide::cast(input(x, y, 0)); -gray(x, y) = Halide::cast((77 * r16 + 150 * g16 + 29 * b16) >> 8); +// Wrap the input so out-of-bounds reads replicate the nearest edge pixel. +Func inputClamped = BoundaryConditions::repeat_edge(input); ``` -The pipeline then applies a Gaussian blur using a 3×3 kernel explicitly defined in a Halide buffer: -``` -int kernel_vals[3][3] = { - {1, 2, 1}, - {2, 4, 2}, - {1, 2, 1} -}; -Halide::Buffer kernelBuf(&kernel_vals[0][0], 3, 3); -``` +Any out-of-bounds access replicates the nearest edge pixel. This makes the boundary policy obvious, keeps expressions clean, and ensures all downstream stages behave consistently at the edges. -Why this kernel? -* It provides effective smoothing while remaining computationally lightweight. -* The weights approximate a Gaussian distribution, which reduces noise but preserves edges better than a box filter. -* This is mathematically a binomial filter, a standard and efficient approximation of Gaussian blurring. +Grayscale conversion happens inside Halide using Rec.601 weights. We read B, G, R from the interleaved input and compute luminance: -The Gaussian blur is computed using a Halide reduction domain (RDom), which iterates over the 3×3 neighborhood around each pixel. To handle boundaries, pixel coordinates are manually clamped to valid ranges. Intermediate products use 16-bit arithmetic to safely accumulate pixel values before normalization: ```cpp -Halide::Expr val = - Halide::cast( - gray(clampCoord(x + r.x - 1, width), - clampCoord(y + r.y - 1, height)) - ) * Halide::cast(kernelBuf(r.x, r.y)); - -blur(x, y) = Halide::cast(Halide::sum(val) / 16); +// Grayscale (Rec.601) +Var x("x"), y("y"); +Func gray("gray"); +gray(x, y) = cast(0.114f * inputClamped(x, y, 0) + // B + 0.587f * inputClamped(x, y, 1) + // G + 0.299f * inputClamped(x, y, 2)); // R ``` -After the blur stage, the pipeline applies a thresholding operation to highlight prominent features. Thresholding converts the blurred grayscale image into a binary image: pixels with intensity greater than 128 become white (255), while all others become black (0). This is expressed in Halide as: -```cpp -Halide::Func thresholded("thresholded"); -thresholded(x, y) = Halide::cast( - Halide::select(blur(x, y) > 128, 255, 0) -); -``` - -This simple but effective step emphasizes strong edges and regions of high contrast, often used as a building block in segmentation and feature extraction pipelines +Next, the pipeline applies a Gaussian-approximate (binomial) blur using a fixed 3×3 kernel. For this learning path, we implement it with small loops and 16-bit accumulation for safety: -Finally, the result is realized by Halide into a buffer and directly wrapped into an OpenCV matrix (cv::Mat) without extra copying: ```cpp -Halide::Buffer outputBuffer = thresholded.realize({width, height}); -Mat blurredThresholded(height, width, CV_8UC1, outputBuffer.data()); -imshow("Processed Image", blurredThresholded); +Func blur("blur"); +const uint16_t k[3][3] = {{1,2,1},{2,4,2},{1,2,1}}; // sum = 16 +Expr sum = cast(0); +for (int j = 0; j < 3; ++j) + for (int i = 0; i < 3; ++i) + sum += cast(gray(x + i - 1, y + j - 1)) * k[j][i]; +blur(x, y) = cast(sum / 16); ``` -The main loop continues capturing frames, running the Halide pipeline, and displaying the processed output in real-time until a key is pressed. This demonstrates how Halide integrates with OpenCV to build efficient, interactive image processing applications. +Why this kernel? +* It provides effective smoothing while remaining computationally lightweight. +* The weights approximate a Gaussian distribution, which reduces noise but preserves edges better than a box filter. +* This is mathematically a binomial filter, a standard and efficient approximation of Gaussian blurring. -In the examples above, pixel coordinates are manually clamped with a helper function: +After the blur, the pipeline applies thresholding to produce a binary image. We explicitly cast constants to uint8_t to remove ambiguity and avoid redundant widen/narrow operations in generated code: ```cpp -gray(clampCoord(x + r.x - 1, width), - clampCoord(y + r.y - 1, height)) +Func output("output"); + Expr T = cast(128); + output(x, y) = select(blur(x, y) > T, cast(255), cast(0)); ``` -This ensures that when the reduction domain r extends beyond the image borders (for example, at the left or top edge), the coordinates are clipped into the valid range [0, width-1] and [0, height-1]. Manual clamping is explicit and easy to understand, but it scatters boundary-handling logic across the pipeline. +This simple but effective step emphasizes strong edges and regions of high contrast, often used as a building block in segmentation and feature extraction pipelines -Halide provides an alternative through boundary condition functions, which wrap an existing Func and define its behavior outside the valid region. For the Gaussian blur, you can clamp the grayscale function instead of the raw input, producing a new function that automatically handles out-of-bounds coordinates: +Finally, the result is realized by Halide and displayed via OpenCV. The pipeline is built once (outside the capture loop) and then realized each frame: ```cpp -// Clamp the grayscale function instead of raw input -Halide::Func grayClamped = Halide::BoundaryConditions::repeat_edge(gray); - -// Use grayClamped inside the blur definition -Halide::Expr val = - Halide::cast(grayClamped(x + (r.x - 1), y + (r.y - 1))) * - Halide::cast(kernelBuf(r.x, r.y)); +// Build the pipeline once (outside the capture loop) +Buffer outBuf(width, height); +Pipeline pipe(output); +pipe.compile_jit(); + +// Per frame +pipe.realize(outBuf); +Mat view(height, width, CV_8UC1, outBuf.data()); +imshow("Processing Workflow", view); ``` -In practice, both manual clamping and BoundaryConditions produce the same visual results. But for maintainability and performance tuning, using BoundaryConditions::repeat_edge (or another suitable policy) can be the preferred approach in production Halide pipelines. +The main loop continues capturing frames, running the Halide pipeline, and displaying the processed output in real time until a key is pressed. This illustrates how Halide integrates cleanly with OpenCV to build efficient, interactive image-processing applications. ## Compilation instructions Compile the program as follows (replace /path/to/halide accordingly): @@ -227,207 +219,146 @@ Let’s first lock in a measurable baseline before we start changing the schedul Create `camera-capture-perf-measurement.cpp` with the following code: ```cpp #include "Halide.h" -#include "HalideRuntime.h" #include #include #include #include #include -#include -#include +#include +#include +using namespace Halide; using namespace cv; using namespace std; -// Clamp coordinate within [0, maxCoord - 1]. -static inline Halide::Expr clampCoord(Halide::Expr coord, int maxCoord) { - return Halide::clamp(coord, 0, maxCoord - 1); -} - int main() { // Open the default camera. VideoCapture cap(0); if (!cap.isOpened()) { - cerr << "Error: Unable to open camera." << endl; + cerr << "Error: Unable to open camera.\n"; return -1; } - bool warmed_up = false; // skip/report first-frame JIT separately + // Grab one frame to determine dimensions and channels + Mat frame; + cap >> frame; + if (frame.empty()) { + cerr << "Error: empty first frame.\n"; + return -1; + } - while (true) { - // Capture frame. - Mat frame; + // Ensure BGR 3-channel layout + if (frame.channels() == 4) cvtColor(frame, frame, COLOR_BGRA2BGR); + else if (frame.channels() == 1) cvtColor(frame, frame, COLOR_GRAY2BGR); + if (!frame.isContinuous()) frame = frame.clone(); + + const int width = frame.cols; + const int height = frame.rows; + const int ch = frame.channels(); + + // Build the pipeline once (outside the capture loop) + ImageParam input(UInt(8), 3, "input"); + input.dim(0).set_stride(ch); // interleaved: x stride = channels + input.dim(2).set_stride(1); + input.dim(2).set_bounds(0, 3); + + // Clamp borders + Func inputClamped = BoundaryConditions::repeat_edge(input); + + // Grayscale conversion (Rec.601 weights) + Var x("x"), y("y"); + Func gray("gray"); + gray(x, y) = cast(0.114f * inputClamped(x, y, 0) + + 0.587f * inputClamped(x, y, 1) + + 0.299f * inputClamped(x, y, 2)); + + // 3×3 binomial blur + Func blur("blur"); + const uint16_t k[3][3] = {{1,2,1},{2,4,2},{1,2,1}}; + Expr sum = cast(0); + for (int j = 0; j < 3; ++j) + for (int i = 0; i < 3; ++i) + sum += cast(gray(x + i - 1, y + j - 1)) * k[j][i]; + blur(x, y) = cast(sum / 16); + + // Threshold (binary) + Func output("output"); + Expr T = cast(128); + output(x, y) = select(blur(x, y) > T, cast(255), cast(0)); + + // Baseline schedule: materialize gray; fuse blur+threshold into output + gray.compute_root(); + + // Allocate output buffer once & JIT once + Buffer outBuf(width, height); + Pipeline pipe(output); + pipe.compile_jit(); + + namedWindow("Processing Workflow", WINDOW_NORMAL); + + bool warmed_up = false; + for (;;) { cap >> frame; - if (frame.empty()) { - cerr << "Error: Received empty frame." << endl; - break; - } - if (!frame.isContinuous()) { - frame = frame.clone(); - } - - int width = frame.cols; - int height = frame.rows; - int channels = frame.channels(); // typically 3 (BGR) or 4 (BGRA) - - // Wrap the interleaved BGR[BGR...] frame for Halide - auto in_rt = Halide::Runtime::Buffer::make_interleaved( - frame.data, width, height, channels); - Halide::Buffer<> inputBuffer(*in_rt.raw_buffer()); // front-end Buffer view - - // Define ImageParam for color input (x, y, c). - Halide::ImageParam input(Halide::UInt(8), 3, "input"); - input.set(inputBuffer); - - const int C = frame.channels(); // 3 (BGR) or 4 (BGRA) - input.dim(0).set_stride(C); // x stride = channels (interleaved) - input.dim(2).set_stride(1); // c stride = 1 (adjacent bytes) - input.dim(2).set_bounds(0, C); // c in [0, C) - - // Define variables representing image coordinates. - Halide::Var x("x"), y("y"); - - // Grayscale in Halide (BGR order; ignore alpha if present) - Halide::Func gray("gray"); - Halide::Expr r16 = Halide::cast(input(x, y, 2)); - Halide::Expr g16 = Halide::cast(input(x, y, 1)); - Halide::Expr b16 = Halide::cast(input(x, y, 0)); - - // Integer approx: Y ≈ (77*R + 150*G + 29*B) >> 8 - gray(x, y) = Halide::cast((77 * r16 + 150 * g16 + 29 * b16) >> 8); - - // Kernel layout: [1 2 1; 2 4 2; 1 2 1], sum = 16. - int kernel_vals[3][3] = { - {1, 2, 1}, - {2, 4, 2}, - {1, 2, 1} - }; - Halide::Buffer kernelBuf(&kernel_vals[0][0], 3, 3); - - Halide::RDom r(0, 3, 0, 3); - Halide::Func blur("blur"); - - Halide::Expr val = - Halide::cast( gray(clampCoord(x + r.x - 1, width), - clampCoord(y + r.y - 1, height)) ) * - Halide::cast( kernelBuf(r.x, r.y) ); - - blur(x, y) = Halide::cast(Halide::sum(val) / 16); - - // Thresholding stage - Halide::Func thresholded("thresholded"); - thresholded(x, y) = Halide::cast( - Halide::select(blur(x, y) > 128, 255, 0) - ); - - // Performance timing around realize() only - Halide::Buffer outputBuffer; - auto t0 = std::chrono::high_resolution_clock::now(); - - try { - outputBuffer = thresholded.realize({ width, height }); - } catch (const std::exception &e) { - cerr << "Halide pipeline error: " << e.what() << endl; - break; - } - - auto t1 = std::chrono::high_resolution_clock::now(); - double ms = std::chrono::duration(t1 - t0).count(); - - // First frame includes JIT; mark it so you know why it's slower - double fps = (ms > 0.0) ? 1000.0 / ms : 0.0; - double mpixps = (ms > 0.0) ? (double(width) * double(height)) / (ms * 1000.0) : 0.0; - - std::cout << std::fixed << std::setprecision(2) - << (warmed_up ? "" : "[warm-up] ") - << "Halide realize: " << ms << " ms | " - << fps << " FPS | " - << mpixps << " MPix/s" << endl; - + if (frame.empty()) break; + if (frame.channels() == 4) cvtColor(frame, frame, COLOR_BGRA2BGR); + else if (frame.channels() == 1) cvtColor(frame, frame, COLOR_GRAY2BGR); + if (!frame.isContinuous()) frame = frame.clone(); + + // Use Halide::Buffer::make_interleaved directly + Buffer inputBuf = + Buffer::make_interleaved(frame.data, frame.cols, frame.rows, frame.channels()); + input.set(inputBuf); + + // Performance timing strictly around realize() + auto t0 = chrono::high_resolution_clock::now(); + pipe.realize(outBuf); + auto t1 = chrono::high_resolution_clock::now(); + + double ms = chrono::duration(t1 - t0).count(); + double fps = ms > 0.0 ? 1000.0 / ms : 0.0; + double mpixps = ms > 0.0 ? (double(width) * double(height)) / (ms * 1000.0) : 0.0; + + cout << fixed << setprecision(2) + << (warmed_up ? "" : "[warm-up] ") + << "realize: " << ms << " ms | " + << fps << " FPS | " + << mpixps << " MPix/s\r" << flush; warmed_up = true; - // Wrap output in OpenCV Mat and display. - Mat blurredThresholded(height, width, CV_8UC1, outputBuffer.data()); - imshow("Processed Image", blurredThresholded); - - // Wait for 30 ms (~33 FPS). Exit if any key is pressed. - if (waitKey(30) >= 0) { - break; - } + // Display + Mat view(height, width, CV_8UC1, outBuf.data()); + imshow("Processing Workflow", view); + if (waitKey(1) >= 0) break; } - std::cout << std::endl; - cap.release(); + cout << "\n"; destroyAllWindows(); return 0; } ``` * The console prints ms, FPS, and MPix/s per frame, measured strictly around realize() (camera capture and UI are excluded). -* The very first line is labeled [warm-up] because it includes Halide’s JIT compilation. You can ignore it when comparing schedules. +* The first frame is labeled [warm-up] because it includes Halide's JIT compilation. You can ignore it when comparing schedules. * MPix/s = (width*height)/seconds is a good resolution-agnostic metric to compare schedule variants. Build and run the application. Here is the sample output: ```console % ./camera-capture-perf-measurement -[warm-up] Halide realize: 327.13 ms | 3.06 FPS | 6.34 MPix/s -Halide realize: 77.32 ms | 12.93 FPS | 26.82 MPix/s -Halide realize: 82.86 ms | 12.07 FPS | 25.03 MPix/s -Halide realize: 83.59 ms | 11.96 FPS | 24.81 MPix/s -Halide realize: 79.20 ms | 12.63 FPS | 26.18 MPix/s -Halide realize: 78.97 ms | 12.66 FPS | 26.26 MPix/s -Halide realize: 80.37 ms | 12.44 FPS | 25.80 MPix/s -Halide realize: 79.60 ms | 12.56 FPS | 26.05 MPix/s -Halide realize: 80.52 ms | 12.42 FPS | 25.75 MPix/s -Halide realize: 80.22 ms | 12.47 FPS | 25.85 MPix/s -Halide realize: 80.91 ms | 12.36 FPS | 25.63 MPix/s -Halide realize: 79.90 ms | 12.51 FPS | 25.95 MPix/s -Halide realize: 79.49 ms | 12.58 FPS | 26.09 MPix/s -Halide realize: 79.78 ms | 12.53 FPS | 25.99 MPix/s -Halide realize: 80.74 ms | 12.38 FPS | 25.68 MPix/s -Halide realize: 80.88 ms | 12.36 FPS | 25.64 MPix/s -Halide realize: 81.07 ms | 12.34 FPS | 25.58 MPix/s -Halide realize: 79.98 ms | 12.50 FPS | 25.93 MPix/s -Halide realize: 79.73 ms | 12.54 FPS | 26.01 MPix/s -Halide realize: 80.24 ms | 12.46 FPS | 25.84 MPix/s -Halide realize: 80.99 ms | 12.35 FPS | 25.60 MPix/s -Halide realize: 80.70 ms | 12.39 FPS | 25.69 MPix/s -Halide realize: 81.24 ms | 12.31 FPS | 25.52 MPix/s -Halide realize: 79.77 ms | 12.54 FPS | 26.00 MPix/s -Halide realize: 79.81 ms | 12.53 FPS | 25.98 MPix/s -Halide realize: 80.13 ms | 12.48 FPS | 25.88 MPix/s -Halide realize: 80.12 ms | 12.48 FPS | 25.88 MPix/s -Halide realize: 80.45 ms | 12.43 FPS | 25.78 MPix/s -Halide realize: 77.72 ms | 12.87 FPS | 26.68 MPix/s -Halide realize: 80.54 ms | 12.42 FPS | 25.74 MPix/s -Halide realize: 80.44 ms | 12.43 FPS | 25.78 MPix/s -Halide realize: 79.47 ms | 12.58 FPS | 26.09 MPix/s -Halide realize: 79.68 ms | 12.55 FPS | 26.02 MPix/s -Halide realize: 79.79 ms | 12.53 FPS | 25.99 MPix/s -Halide realize: 79.86 ms | 12.52 FPS | 25.97 MPix/s -Halide realize: 80.52 ms | 12.42 FPS | 25.75 MPix/s -Halide realize: 79.47 ms | 12.58 FPS | 26.09 MPix/s -Halide realize: 82.55 ms | 12.11 FPS | 25.12 MPix/s -Halide realize: 78.59 ms | 12.72 FPS | 26.38 MPix/s -Halide realize: 79.98 ms | 12.50 FPS | 25.93 MPix/s -Halide realize: 79.06 ms | 12.65 FPS | 26.23 MPix/s -Halide realize: 80.54 ms | 12.42 FPS | 25.75 MPix/s -Halide realize: 79.19 ms | 12.63 FPS | 26.19 MPix/s -Halide realize: 80.70 ms | 12.39 FPS | 25.70 MPix/s +realize: 4.84 ms | 206.53 FPS | 428.25 MPix/s ``` -This gives an average FPS of 12.48, and average throughput of 25.88 MPix/s. Now you can start measuring potential improvements from scheduling. +This gives an FPS of 206.53, and average throughput of 428.25 MPix/s. Now you can start measuring potential improvements from scheduling. ### Parallelization -Parallelization lets Halide run independent pieces of work at the same time on multiple CPU cores. For image pipelines, rows (or tiles of rows) are naturally parallel: each can be processed independently once producer data is available. By distributing work across cores, we reduce wall-clock time—crucial for real-time video. +Parallelization lets Halide run independent pieces of work at the same time on multiple CPU cores. In image pipelines, rows (or row tiles) are naturally parallel once producer data is available. By distributing work across cores, we reduce wall-clock time—crucial for real-time video. -With the baseline measured, you will apply a minimal schedule that parallelizes the blur reduction across rows while keeping the threshold stage at root. This avoids tricky interactions between a parallel consumer and an unscheduled reduction (a common source of internal errors). +With the baseline measured, apply a minimal schedule that parallelizes the blur reduction across rows while keeping the final stage explicit at root. This avoids tricky interactions between a parallel consumer and an unscheduled reduction. -Add these lines right after the threshold definition (and before any realize()): +Add these lines after defining output(x, y) (and before any realize()): ```cpp blur.compute_root().parallel(y); // parallelize reduction across scanlines -thresholded.compute_root(); // cheap pixel-wise stage at root +output.compute_root(); // cheap pixel-wise stage at root ``` This does two important things: @@ -437,58 +368,10 @@ This does two important things: Now rebuild and run the application again. The results should look like: ```output % ./camera-capture-perf-measurement -[warm-up] Halide realize: 312.66 ms | 3.20 FPS | 6.63 MPix/s -Halide realize: 84.86 ms | 11.78 FPS | 24.44 MPix/s -Halide realize: 88.53 ms | 11.30 FPS | 23.42 MPix/s -Halide realize: 85.46 ms | 11.70 FPS | 24.26 MPix/s -Halide realize: 83.12 ms | 12.03 FPS | 24.95 MPix/s -Halide realize: 88.70 ms | 11.27 FPS | 23.38 MPix/s -Halide realize: 87.58 ms | 11.42 FPS | 23.68 MPix/s -Halide realize: 83.38 ms | 11.99 FPS | 24.87 MPix/s -Halide realize: 81.65 ms | 12.25 FPS | 25.39 MPix/s -Halide realize: 84.88 ms | 11.78 FPS | 24.43 MPix/s -Halide realize: 84.40 ms | 11.85 FPS | 24.57 MPix/s -Halide realize: 85.30 ms | 11.72 FPS | 24.31 MPix/s -Halide realize: 83.15 ms | 12.03 FPS | 24.94 MPix/s -Halide realize: 85.69 ms | 11.67 FPS | 24.20 MPix/s -Halide realize: 83.39 ms | 11.99 FPS | 24.87 MPix/s - -% g++ -std=c++17 camera-capture-perf-measurement.cpp -o camera-capture-perf-measurement \ - -I/Users/db/Repos/Halide-19.0.0-arm-64-osx/include -L/Users/db/Repos/Halide-19.0.0-arm-64-osx/lib -lHalide \ - $(pkg-config --cflags --libs opencv4) -lpthread -ldl \ - -Wl,-rpath,/Users/db/Repos/Halide-19.0.0-arm-64-osx -% ./camera-capture-perf-measurement -[warm-up] Halide realize: 300.76 ms | 3.32 FPS | 6.89 MPix/s -Halide realize: 64.23 ms | 15.57 FPS | 32.29 MPix/s -Halide realize: 64.68 ms | 15.46 FPS | 32.06 MPix/s -Halide realize: 71.92 ms | 13.90 FPS | 28.83 MPix/s -Halide realize: 63.78 ms | 15.68 FPS | 32.51 MPix/s -Halide realize: 67.95 ms | 14.72 FPS | 30.52 MPix/s -Halide realize: 67.31 ms | 14.86 FPS | 30.81 MPix/s -Halide realize: 67.90 ms | 14.73 FPS | 30.54 MPix/s -Halide realize: 68.81 ms | 14.53 FPS | 30.14 MPix/s -Halide realize: 68.57 ms | 14.58 FPS | 30.24 MPix/s -Halide realize: 66.83 ms | 14.96 FPS | 31.03 MPix/s -Halide realize: 68.04 ms | 14.70 FPS | 30.47 MPix/s -Halide realize: 67.72 ms | 14.77 FPS | 30.62 MPix/s -Halide realize: 68.79 ms | 14.54 FPS | 30.14 MPix/s -Halide realize: 67.56 ms | 14.80 FPS | 30.69 MPix/s -Halide realize: 67.65 ms | 14.78 FPS | 30.65 MPix/s -Halide realize: 67.81 ms | 14.75 FPS | 30.58 MPix/s -Halide realize: 67.81 ms | 14.75 FPS | 30.58 MPix/s -Halide realize: 68.03 ms | 14.70 FPS | 30.48 MPix/s -Halide realize: 67.44 ms | 14.83 FPS | 30.75 MPix/s -Halide realize: 70.11 ms | 14.26 FPS | 29.58 MPix/s -Halide realize: 66.23 ms | 15.10 FPS | 31.31 MPix/s -Halide realize: 67.96 ms | 14.72 FPS | 30.51 MPix/s -Halide realize: 68.00 ms | 14.71 FPS | 30.49 MPix/s -Halide realize: 67.98 ms | 14.71 FPS | 30.50 MPix/s -Halide realize: 67.56 ms | 14.80 FPS | 30.69 MPix/s -Halide realize: 68.53 ms | 14.59 FPS | 30.26 MPix/s -Halide realize: 67.06 ms | 14.91 FPS | 30.92 MPix/s +realize: 3.80 ms | 263.07 FPS | 545.49 MPix/s ``` -This gives, on average FPS: 14.79, and throughput of 30.67 MPix/s, leading to ~+18.5% improvement vs baseline. +That’s ≈20% faster than baseline. ### Tiling Tiling is a scheduling technique that divides computations into smaller, cache-friendly blocks or tiles. This approach significantly enhances data locality, reduces memory bandwidth usage, and leverages CPU caches more efficiently. While tiling can also use parallel execution, its primary advantage comes from optimizing intermediate data storage. @@ -509,20 +392,20 @@ Before using this, remove any earlier compute_root().parallel(y) schedule for bl Halide::Var xo("xo"), yo("yo"), xi("xi"), yi("yi"); // Tile & parallelize the consumer; vectorize inner x on planar output. -thresholded +output .tile(x, y, xo, yo, xi, yi, 128, 64) .vectorize(xi, 16) .parallel(yo); // Compute blur inside each tile and vectorize its inner x. blur - .compute_at(thresholded, xo) + .compute_at(output, xo) .vectorize(x, 16); // Cache RGB→gray per tile (reads interleaved input → keep unvectorized). gray - .compute_at(thresholded, xo) - .store_at(thresholded, xo); + .compute_at(output, xo) + .store_at(output, xo); ``` In this scheduling: @@ -531,9 +414,12 @@ In this scheduling: * gray.compute_at(...).store_at(...) materializes a tile-local planar buffer for the grayscale intermediate so blur can reuse it within the tile. * Vectorization is applied only to planar stages (blur, thresholded), gray stays unvectorized because it reads interleaved input (x-stride = channels). -Recompile your application as before, then run. On our machine, this version ran at ~7.6 FPS (~15.76 MPix/s, ~139 ms/frame), slower than baseline (~12.48 FPS) and the parallelization-only schedule (~14.79 FPS). The 3×3 blur is very small (low arithmetic intensity), the extra writes/reads of a tile-local buffer add overhead, and the interleaved source still limits how efficiently the gray producer can be read/vectorized. +Recompile your application as before, then run. What we observed on our machine: +```output +realize: 2.36 ms | 423.10 FPS | 877.34 MPix/s +``` -This pattern shines when the cached intermediate is expensive and reused a lot (bigger kernels, multi-use intermediates, or separable/multi-stage pipelines). For a tiny 3×3 on CPU, the benefit often doesn’t amortize. +This was the fastest variant here—caching a planar grayscale per tile enabled efficient reuse and vectorized blur reads. ### Tiling for parallelization (without explicit intermediate storage) Tiling can also be used just to partition work across cores, without caching intermediates. This keeps the schedule simple: you split the output into tiles, parallelize across tiles, and vectorize along unit-stride x. Producers are computed inside each tile to keep the working set small, but don’t materialize extra tile-local buffers: @@ -541,13 +427,13 @@ Tiling can also be used just to partition work across cores, without caching int // Tiling (partitioning only) Halide::Var xo("xo"), yo("yo"), xi("xi"), yi("yi"); -thresholded +output .tile(x, y, xo, yo, xi, yi, 128, 64) // try 128x64; tune per CPU .vectorize(xi, 16) // safe: planar, unit-stride along x .parallel(yo); // run tiles across cores blur - .compute_at(thresholded, xo) // keep work tile-local + .compute_at(output, xo) // keep work tile-local .vectorize(x, 16); // vectorize planar blur ``` @@ -557,7 +443,7 @@ What this does * compute_at(thresholded, xo) evaluates blur per tile (better locality) without forcing extra storage. * Vectorization is applied to planar stages (blur, thresholded). -Recompile your application as before, then run. On our test machine, we got 9.35 FPS (19.40 MPix/s, ~106.93 ms/frame). This is slower than both the baseline and the parallelization-only schedule. The main reasons: +Recompile your application as before, then run. On our test machine, we got 5.56 ms (179.91 FPS, 373.07 MPix/s). This is slower than both the baseline and the parallelization-only schedule. The main reasons: * Recomputation of gray: with a 3×3 blur, each output reuses up to 9 neighbors; leaving gray inlined means RGB→gray is recomputed for each tap. * Interleaved input: gray reads BGR interleaved data (x-stride = channels), limiting unit-stride vectorization efficiency upstream. * Overhead vs. work: a 3×3 blur has low arithmetic intensity; extra tile/task overhead isn’t amortized. @@ -570,8 +456,8 @@ Tiling without caching intermediates mainly helps partition work, but for tiny k blur.compute_root().parallel(y); thresholded.compute_root(); ``` -* Tiling for cache efficiency helps when an expensive intermediate is reused many times per output (e.g., larger kernels, separable/multi-stage pipelines, multiple consumers) and when producers read planar data. Caching gray per tile with a tiny 3×3 kernel over an interleaved source added overhead and ran slower (~8.2 FPS / 17.0 MPix/s). -* Tiling for parallelization (partitioning only) simplifies work distribution and enables vectorization of planar stages, but with low arithmetic intensity (3×3) and an interleaved source it underperformed here (~9.35 FPS / 19.40 MPix/s). +* Tiling for cache efficiency helps when an expensive intermediate is reused many times per output (e.g., larger kernels, separable/multi-stage pipelines, multiple consumers) and when producers read planar data. Caching gray per tile with a tiny 3×3 kernel over an interleaved source added overhead and ran slower. +* Tiling for parallelization (partitioning only) simplifies work distribution and enables vectorization of planar stages, but with low arithmetic intensity (3×3) and an interleaved source it underperformed here. When to choose what: * Start with parallelizing the main reduction at root. @@ -579,7 +465,7 @@ When to choose what: * Keep stages that read interleaved inputs unvectorized; vectorize only planar consumers. ## Summary -In this section, you built a real-time Halide+OpenCV pipeline—grayscale, a 3×3 binomial blur, then thresholding—and instrumented it to measure throughput. The baseline settled around 12.48 FPS (25.88 MPix/s). A small, safe schedule tweak that parallelizes the blur reduction across rows lifted performance to about 14.79 FPS (30.67 MPix/s). In contrast, tiling used only for partitioning landed near 9.35 FPS (19.40 MPix/s), and tiling with a cached per-tile grayscale buffer was slower still at roughly 8.2 FPS (17.0 MPix/s). +In this section, you built a real-time Halide+OpenCV pipeline—grayscale, a 3×3 binomial blur, then thresholding—and instrumented it to measure throughput. The baseline landed at 4.84 ms (206.53 FPS, 428.25 MPix/s). A small, safe schedule tweak that parallelizes the blur reduction across rows improved performance to 3.80 ms (263.07 FPS, 545.49 MPix/s)—about +20%. A tiling schedule used only for partitioning was slower at 5.56 ms (179.91 FPS, 373.07 MPix/s). In contrast, tiling with a cached per-tile grayscale (so the blur reuses a planar intermediate) was the fastest at 2.36 ms (423.10 FPS, 877.34 MPix/s). -The pattern is clear. On CPU, with a small kernel and an interleaved camera source, parallelizing the reduction is the most effective first step. Tiling starts to pay off only when an expensive intermediate is reused enough to amortize the overhead, e.g., after making the blur separable (horizontal+vertical), producing a planar grayscale once per frame with gray.compute_root(), and applying boundary conditions to unlock interior fast paths. From there, tune tile sizes and thread count to squeeze out the remaining headroom. +The pattern is clear. On CPU, with a small kernel and an interleaved camera source, the most reliable first step is to parallelize the main reduction across rows. Tiling pays off when you also cache a reused intermediate (e.g., a planar grayscale) so downstream stages get unit-stride, vectorizable access and better locality. Keep stages that read interleaved inputs unvectorized; vectorize planar consumers. From there, tune tile sizes and thread count for your target. Boundary conditions are handled once with repeat_edge, keeping edge behavior consistent and scheduling clean. diff --git a/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/10-appendix.md b/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/10-appendix.md index 38d46a8d36..e621683354 100644 --- a/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/10-appendix.md +++ b/content/learning-paths/mobile-graphics-and-gaming/using-neon-intrinsics-to-optimize-unity-on-android/10-appendix.md @@ -8,7 +8,7 @@ layout: learningpathall ## The Neon intrinsics we used Here is a breakdown of some of the Neon intrinsics that were used to optimize the AABB collision detection in the function called `NeonAABBObjCollisionDetectionUnrolled`. It can be found at line **718** in _CollisionCalculationScript.cs_. -`NeonAABBObjCollisionDetectionUnrolled` performs the collision detection between the characters and the walls. The outer loop iterates through all of the characters, while the inner loop iterates through the walls. The result is an array of boolean values (**true** denotes a collision has occured) which tells us which characters have collided with which walls. +`NeonAABBObjCollisionDetectionUnrolled` performs the collision detection between the characters and the walls. The outer loop iterates through all of the characters, while the inner loop iterates through the walls. The result is an array of boolean values (**true** denotes a collision has occurred) which tells us which characters have collided with which walls. ### `Unity.Burst.Intrinsics.v64` (loading data into a vector register) ``` diff --git a/content/learning-paths/mobile-graphics-and-gaming/using_unity_machine_learning_agents/06-the-unity-project.md b/content/learning-paths/mobile-graphics-and-gaming/using_unity_machine_learning_agents/06-the-unity-project.md index 96d4fce2a8..6b3683c4cb 100644 --- a/content/learning-paths/mobile-graphics-and-gaming/using_unity_machine_learning_agents/06-the-unity-project.md +++ b/content/learning-paths/mobile-graphics-and-gaming/using_unity_machine_learning_agents/06-the-unity-project.md @@ -114,9 +114,9 @@ _DecisionRequester_ is a component from the ML Agents Toolkit. It controls how o ![DecisionRequesterComponent](images/decision-requester-component.png "Figure 6. The DecisionRequester component on the ML-NPC game object.") -ML Agent components are designed to be run from a _MonoBehaviour_'s _FixedUpdate_ function. +ML Agent components are designed to be run from a _MonoBehavior_'s _FixedUpdate_ function. -_MonoBehaviour_ provides a variety of functions that game objects can use to perform various functions at specific times during a frame. _FixedUpdate_ is called in step with the Unity physics system and is called at a fixed interval (independent of frame rate). The interval rate for _FixedUpdate_ can be changed using Edit->Project Settings->Time->Fixed Timestep. +_MonoBehavior_ provides a variety of functions that game objects can use to perform various functions at specific times during a frame. _FixedUpdate_ is called in step with the Unity physics system and is called at a fixed interval (independent of frame rate). The interval rate for _FixedUpdate_ can be changed using Edit->Project Settings->Time->Fixed Timestep. You shouldn't need to modify this value but it is important to be aware that _FixedUpdate_ can be called multiple times per frame depending on the interval. @@ -132,7 +132,7 @@ _Max Step_ is a property from _Agent_. It determines the maximum number of steps The ML subsystem calls on AgentDrArm implementations of functions such as _CollateObservations(..)_ and _OnActionReceived(..)_. (More on this later.) -#### BehaviourParameters Component +#### Behavior Parameters Component The behavior parameters dictate the size of the neural network. @@ -144,7 +144,7 @@ _Inference Device_ is set to _Default_ and determines which compute device is us There shouldn't be much difference between Burst and CPU in this case, though Unity is moving more and more to the Burst compiler. -The _Behaviour Name_ is important as you will use it again later in the training sections. You will see that "BossBattle" is used in several places. +The _Behavior Name_ is important as you will use it again later in the training sections. You will see that "BossBattle" is used in several places. #### RayPerceptionSensor3D Component diff --git a/content/learning-paths/servers-and-cloud-computing/_index.md b/content/learning-paths/servers-and-cloud-computing/_index.md index 372f4f691c..0c9685d2c2 100644 --- a/content/learning-paths/servers-and-cloud-computing/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/_index.md @@ -8,7 +8,7 @@ key_ip: maintopic: true operatingsystems_filter: - Android: 3 -- Linux: 183 +- Linux: 185 - macOS: 13 - Windows: 14 pinned_modules: @@ -18,9 +18,9 @@ pinned_modules: - providers - migration subjects_filter: -- CI-CD: 8 +- CI-CD: 9 - Containers and Virtualization: 32 -- Databases: 18 +- Databases: 19 - Libraries: 9 - ML: 32 - Performance and Architecture: 72 @@ -36,7 +36,8 @@ tools_software_languages_filter: - AI: 1 - Android Studio: 1 - Ansible: 2 -- apache: 1 +- Apache: 1 +- Apache Cassandra: 1 - Apache Spark: 2 - Apache Tomcat: 2 - ApacheBench: 1 @@ -73,20 +74,24 @@ tools_software_languages_filter: - C#: 2 - C++: 12 - Capstone: 1 +- cassandra-stress: 1 - CCA: 8 +- CircleCI: 1 - Clair: 1 - Clang: 13 - ClickBench: 1 - ClickHouse: 1 - CMake: 1 - conda: 1 +- cqlsh: 1 - Daytona: 1 - Demo: 3 - Django: 1 -- Docker: 24 +- Docker: 25 - Docker Buildx: 1 - Envoy: 3 - ExecuTorch: 1 +- Express: 1 - FAISS: 1 - FlameGraph: 1 - Flink: 1 @@ -116,7 +121,7 @@ tools_software_languages_filter: - Intrinsics: 1 - iPerf3: 1 - ipmitool: 1 -- Java: 4 +- Java: 5 - JAX: 1 - JMH: 1 - Kafka: 2 @@ -148,8 +153,8 @@ tools_software_languages_filter: - Networking: 1 - Nexmark: 1 - NGINX: 4 -- Node.js: 4 -- npm: 1 +- Node.js: 5 +- npm: 2 - Ollama: 1 - ONNX Runtime: 2 - OpenBLAS: 1 @@ -211,7 +216,7 @@ tools_software_languages_filter: weight: 1 cloud_service_providers_filter: - AWS: 17 -- Google Cloud: 21 +- Google Cloud: 23 - Microsoft Azure: 18 - Oracle: 2 --- diff --git a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/_index.md b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/_index.md index dad926e671..4151bde30d 100644 --- a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/_index.md @@ -1,26 +1,22 @@ --- -title: Build multi-architecture Docker images with Buildkite on Google Axion - -draft: true -cascade: - draft: true +title: Create multi-architecture Docker images with Buildkite on Google Axion minutes_to_complete: 40 -who_is_this_for: This is an introductory guide for software developers learning to build and run multi-architecture Docker images with Buildkite on Arm-based Google Cloud C4A virtual machines powered by Google Axion processors. +who_is_this_for: This is an introductory topic for developers who want to build and run multi-architecture Docker images with Buildkite on Arm-based Google Cloud C4A virtual machines (VM) powered by Google Axion processors. learning_objectives: -- Provision an Arm-based virtual machine on Google Cloud running SUSE Linux Enterprise Server or Ubuntu +- Provision an Arm-based VM on Google Cloud running either SUSE Linux Enterprise Server or Ubuntu - Install and configure Docker, Docker Buildx, and the Buildkite agent - Write a Dockerfile to containerize a simple Flask-based Python application - Configure a Buildkite pipeline to build a multi-architecture Docker image and push it to Docker Hub -- Run the application to ensure it works as expected +- Start the application and verify that it runs correctly prerequisites: - - A [Google Cloud Platform (GCP)](https://cloud.google.com/free?utm_source=google&hl=en) account with billing enabled - - Basic knowledge of Linux system administration such as creating users, installing packages, and managing services - - Familiarity with Docker and container concepts - - A GitHub account to host your application repository + - A [Google Cloud Platform (GCP) account](https://cloud.google.com/free?utm_source=google&hl=en) with billing enabled + - Basic Linux system administration skills, including how to create users, install packages, and manage services + - Familiarity with [Docker](https://docs.docker.com/get-started/) and container concepts + - A [GitHub account](https://github.com/join) to host your application repository author: Jason Andrews diff --git a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/background.md b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/background.md index 7d11024ac7..fffc14cb39 100644 --- a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/background.md +++ b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/background.md @@ -1,20 +1,26 @@ --- -title: Get started with Buildkite on Google Axion C4A instances +title: Discover Buildkite on Google Axion C4A instances weight: 2 layout: "learningpathall" --- -## Google Axion C4A instances on Google Cloud +## Get started -Google Axion C4A is a family of Arm-based virtual machines powered by Google's custom Axion CPU, which is built on Arm Neoverse V2 cores. Designed for high performance and energy efficiency, these VMs are well-suited for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications. +This section introduces two core technologies you'll use in this Learning Path: the Buildkite continuous integration and delivery (CI/CD) platform and Google Axion C4A Arm virtual machines (VMs). You'll see how these tools help you build, test, and deploy software efficiently on Arm-based cloud infrastructure. If you want to dive deeper, check out the links to further resources. -The C4A series can provide a cost-efficient alternative to x86 VMs while leveraging the scalability and performance characteristics of the Arm architecture on Google Cloud. +## Buildkite for CI/CD on Arm -To learn more about Google Axion, see the blog [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu). +Buildkite is a flexible and scalable continuous integration and delivery (CI/CD) platform that enables you to run pipelines on your own infrastructure. By deploying Buildkite agents on Google Axion C4A VMs, you can take advantage of Arm's performance and cost efficiency to build, test, and deploy applications, including multi-architecture Docker images. Buildkite integrates seamlessly with version control systems such as GitHub and supports advanced workflows for cloud migration, multi-arch builds, and testing microservices. -## Buildkite for CI/CD on Arm +To get started, review the [Buildkite documentation](https://buildkite.com/docs) for setup instructions, pipeline configuration, and agent management. + +## Google Axion C4A Arm VMs for efficient cloud workloads + +Google Axion C4A is a family of Arm-based virtual machines powered by Google's custom Axion CPU, which is built on Arm Neoverse V2 cores. Designed for high performance and energy efficiency, these VMs are well-suited for modern cloud workloads such as CI/CD pipelines. The C4A series can provide a cost-efficient alternative to x86 VMs while leveraging the scalability and performance characteristics of the Arm architecture on Google Cloud. + +Learn more in this Google blog [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu). -Buildkite is a flexible and scalable continuous integration and delivery (CI/CD) platform that allows you to run pipelines on your own infrastructure. By deploying Buildkite agents on Google Axion C4A VMs, you can take advantage of Arm's performance and cost efficiency to build, test, and deploy applications, including multi-architecture Docker images. +## What's next? -Buildkite integrates seamlessly with version control systems such as GitHub and supports advanced workflows for cloud migration, multi-arch builds, and testing microservices. Learn more in the [Buildkite documentation](https://buildkite.com/docs). +You've now learned about the two main technologies you'll use in this Learning Path. You're ready to start building, testing, and deploying on Arm-based cloud infrastructure with confidence. Keep going, you're making great progress! \ No newline at end of file diff --git a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/buildkite-agent-setup.md b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/buildkite-agent-setup.md index 8fcd583e82..655418eb54 100644 --- a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/buildkite-agent-setup.md +++ b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/buildkite-agent-setup.md @@ -1,30 +1,33 @@ --- -title: Set-up Buildkite +title: Set up and connect Buildkite agent on a Google Axion C4A Arm VM weight: 5 ### FIXED, DO NOT MODIFY layout: learningpathall --- -# Set up a Buildkite agent +## What you'll do in this section -After installing the Buildkite agent binary on a Google Axion C4A Arm VM, you can set up and configure a Buildkite agent and queue. +In this section, you'll configure and connect a Buildkite agent on a Google Axion C4A Arm virtual machine (VM). You'll generate an agent token, set up the agent configuration, create a Buildkite queue, and verify that your agent is online and ready to run CI/CD jobs on Arm infrastructure. -## 1. Create an Agent Token +## Create an agent token Before configuring the agent, you need an agent token from your Buildkite organization. -1. Log in to your Buildkite account (you can login with GitHub), and go to your Organization Settings -2. Click Agents in the left menu -3. Click Create Agent Token -4. Enter a name for your token, such as `buildkite-arm` -5. Click Create Token -6. Copy the token immediately, you won’t be able to see it again after leaving the page. +To create an agent token, follow these steps: -![Buildkite Dashboard alt-text#center](images/agent-token.png "Create Buildkite agent Token") +- Sign in to your Buildkite account. You can use your GitHub credentials if you prefer. +- In the left menu, select **Organization settings**. +- Select **Agents**. +- Select **Create agent token**. +- Enter a descriptive name for the token, such as `buildkite-arm`. +- Select **Create token**. +- Copy the token and store it securely as you won’t be able to view it again after you leave the page. +![Buildkite Dashboard alt-text#center](images/agent-token.png "Create Buildkite agent token") -## 2. Configure Buildkite Agent + +## Configure the Buildkite agent Create the configuration directory and file on your local system with the commands below: @@ -35,10 +38,10 @@ tags="queue=buildkite-queue1" EOF ``` -Replace `YOUR_AGENT_TOKEN` with the token you generated from your Buildkite Agents page. +Replace `YOUR_AGENT_TOKEN` with the token that you generated from your Buildkite Agents page. -{{% notice Note %}} -You find it easier to copy the commands above into a text file named `config-agent.sh` and run the file. +{{% notice Tip %}} +You might find it easier to copy the commands above into a text file named `config-agent.sh` and run the file. ```console bash ./config-agent.sh ``` @@ -63,21 +66,23 @@ token="YOUR-GENERATED-TOKEN-VALUE" tags="queue=buildkite-queue1" ``` -## 3. Create a Queue in Buildkite +## Create a queue in Buildkite Now that your agent is created, you can create a queue. -1. Go to your Buildkite Organization select Queues and then select Create Queue -2. Name the queue, for example `buildkite-queue1` -3. Save the queue +- Go to your Buildkite organization, select **Queues**, and then select **Create queue**. +- Enter a name for the queue, for example `buildkite-queue1`. +- Select **Save** to create the queue. + +This step connects your agent to the correct queue, ensuring jobs are routed to your Arm-based Buildkite agent. {{% notice Note %}} Make sure the queue name matches the `tags` field in the agent configuration. {{% /notice %}} -![Buildkite Dashboard alt-text#center](images/queue.png "Create Buildkite Queue") +![Buildkite Dashboard alt-text#center](images/queue.png "Create the Buildkite queue") -## 4. Verify the agent in the Buildkite UI +## Verify the agent in the Buildkite UI First, start the agent on your local computer: @@ -85,12 +90,13 @@ First, start the agent on your local computer: sudo /root/.buildkite-agent/bin/buildkite-agent start --build-path="/var/lib/buildkite-agent/builds" ``` -Then, confirm it is visible in the Buildkite UI: +Then, confirm the agent is visible in the Buildkite UI, by doing the following: -Go Buildkite and select Agents +- In the Buildkite dashboard, select **Agents** from the left menu. This page lists all registered agents for your organization. +- Look for your new agent in the list and verify that its status is **online** and that it is assigned to the correct queue. Confirm that the agent is online and connected to the queue `buildkite-queue1`. -![Buildkite Dashboard alt-text#center](images/agent.png "Verify Agent") +![Buildkite Dashboard alt-text#center](images/agent.png "Verify the agent") -The Buildkite agent is ready, you can proceed to use Buildkite for building multi-arch images. +Congratulations! Your Buildkite agent is now set up and connected to your queue. You can now start using Buildkite to build multi-architecture images on your Arm-based VM. This setup enables you to run CI/CD pipelines optimized for Arm platforms, and take advantage of the performance and scalability of Arm servers. diff --git a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/installation.md b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/installation.md index 5898eab09d..8e10cfd3c4 100644 --- a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/installation.md +++ b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/installation.md @@ -1,13 +1,13 @@ --- -title: Install Buildkite +title: Install Buildkite on a Google Axion C4A Arm VM weight: 4 ### FIXED, DO NOT MODIFY layout: learningpathall --- -## Install Buildkite on a Google Axion C4A Arm VM -This section guides you through installing the Buildkite agent on a Google Axion C4A Arm VM, enabling it to connect to your Buildkite account and run CI/CD pipelines. +## Get started with installing the Buildkite agent +This section walks you through installing the Buildkite agent on a Google Axion C4A Arm VM, enabling it to connect to your Buildkite account and run the CI/CD pipelines. {{< tabpane code=true >}} {{< tab header="Ubuntu" language="bash">}} @@ -20,19 +20,20 @@ sudo zypper install -y curl unzip {{< /tab >}} {{< /tabpane >}} -### Download and Install Buildkite Agent +## Download and install the Buildkite agent + +Use this one-line command to download and run the Buildkite installer: ```console sudo bash -c "$(curl -sL https://raw.githubusercontent.com/buildkite/agent/main/install.sh)" ``` - -This one-line command downloads and runs the Buildkite installer. - The installer performs the following steps: -- Download the latest version of the agent, for example `v3.109.1` -- Install it into the home directory of the root user at `/root/.buildkite-agent` -- Create a default config file (`buildkite-agent.cfg`) where you’ll later add your agent token +- Downloads the latest version of the agent, for example `v3.109.1` +- Installs the Buildkite agent into the home directory of the root user at `/root/.buildkite-agent` +- Creates a default config file (`buildkite-agent.cfg`) where you’ll later add your agent token + +You should see this output: ```output @@ -66,31 +67,31 @@ For docs, help and support: Happy building! <3 ``` -### Verify installation -This command checks the version of the Buildkite agent and confirms it is installed successfully. +## Verify installation + +Now verify the installation by checking the Buildkite agent version. This confirms that the agent is installed and ready to use: ```console sudo /root/.buildkite-agent/bin/buildkite-agent --version ``` -You should see output similar to: + +The expected output is similar to: ```output buildkite-agent version 3.109.1+10971.5c28e309805a3d748068a3ff7f5c531f51f6f495 ``` {{% notice Note %}} -The Buildkite Agent version 3.43.0 introduces Linux/Arm64 Docker image for the Buildkite Agent, making deployment and installation easier for Linux users on Arm. You can view the [release note](https://github.com/buildkite/agent/releases/tag/v3.43.0). +The Buildkite Agent version 3.43.0 introduces Linux/Arm64 Docker image for the Buildkite Agent, making deployment and installation easier for Linux users on Arm. You can view the [Buildkite agent GitHub release note](https://github.com/buildkite/agent/releases/tag/v3.43.0). -The [Arm Ecosystem Dashboard](https://developer.arm.com/ecosystem-dashboard/) recommends Buildkite Agent version v3.43.0 as the minimum recommended on the Arm platforms. +The [Arm Ecosystem Dashboard](https://developer.arm.com/ecosystem-dashboard/) recommends Buildkite Agent version v3.43.0 or later for Arm platforms. {{% /notice %}} -### Install Docker and Docker Buildx - -Buildkite will use Docker to build and push images. +## Install Docker -First, refresh the package repositories and install the required packages including git, Python3-pip, and Docker: +Buildkite uses Docker to build and push images. -Next, enable and start the Docker service to ensure it runs automatically when your VM starts: +This step ensures Docker is always available for your CI/CD pipelines. {{< tabpane code=true >}} {{< tab header="Ubuntu" language="bash">}} @@ -105,14 +106,6 @@ sudo usermod -aG docker $USER ; newgrp docker {{< /tab >}} {{< /tabpane >}} - -SUSE Linux requires some extra steps to start Docker, you can skip this for Ubuntu: - -```console -sudo systemctl enable docker -sudo systemctl start docker -``` - Verify the Docker installation by checking the version and running a test container: ```console @@ -146,11 +139,16 @@ For more examples and ideas, visit: ## Install Docker Buildx -Docker Buildx is a plugin that allows building multi-architecture images, for example `arm64` and `amd64`. +Docker Buildx is a plugin that allows the building of multi-architecture images, for example `arm64` and `amd64`. +If you're using SUSE Linux, you need to install Docker Buildx manually. On Ubuntu, Docker Buildx is included by default, so you can skip this step. + +For more information or troubleshooting details, see the [Docker Buildx documentation](https://docs.docker.com/build/buildx/). + +## Download Docker Buildx -For SUSE Linux, you need to install Docker Buildx. This is not necessary on Ubuntu. +If you need to download Docker Buildx, follow these steps. -Download the binary and move it to the Docker CLI plugin directory: +Start by downloading the Docker Buildx binary and move it to the Docker CLI plugin directory. This enables advanced multi-architecture builds on your Arm VM: ```console wget https://github.com/docker/buildx/releases/download/v0.26.1/buildx-v0.26.1.linux-arm64 @@ -159,4 +157,26 @@ sudo mkdir -p /usr/libexec/docker/cli-plugins sudo mv buildx-v0.26.1.linux-arm64 /usr/libexec/docker/cli-plugins/docker-buildx ``` -Now that the Buildkite installation is complete, you can set up the Buildkite agent. +After installing, verify that Docker Buildx is available: + +```console +docker buildx version +``` + +The expected output is similar to: + +```output +github.com/docker/buildx v0.26.1 +``` + +If you see the version information, Docker Buildx is installed correctly and ready for use. + +{{% notice Note %}} +If you encounter a "permission denied" error, ensure your user is in the `docker` group and that the plugin file is executable. +{{% /notice %}} + +You can now use Docker Buildx to build and push multi-architecture images, which is especially useful for Arm-based CI/CD pipelines. + +## What you've accomplished + +Great job! You’ve installed Docker, Docker Buildx, and the Buildkite agent on your Arm VM. Next, you’ll set up and connect your Buildkite agent to your account. diff --git a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/instance.md b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/instance.md index dad269729e..ad886ddfc0 100644 --- a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/instance.md +++ b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/instance.md @@ -6,25 +6,34 @@ weight: 3 layout: learningpathall --- -## Overview +## Get started -In this section, you'll learn how to provision a Google Axion C4A Arm virtual machine on Google Cloud Platform (GCP) using the `c4a-standard-4` instance type with 4 vCPUs and 16 GB memory in the Google Cloud Console. +You're about to launch a Google Axion C4A Arm virtual machine on Google Cloud Platform (GCP). This section guides you through each step, from selecting the optimal instance type to configuring your operating system and networking. -## Provision a Google Axion C4A VM in the Google Cloud Console +By the end, you'll have a ready-to-use Arm-based VM, perfect for high-performance workloads and cloud-native development. Specifically, you'll learn how to provision a Google Axion C4A Arm virtual machine on Google Cloud Platform (GCP) using the `c4a-standard-4` instance type with 4 vCPUs and 16 GB memory in the Google Cloud Console. -To create a virtual machine based on the C4A instance type: +## Provision a virtual machine -1. Navigate to the [Google Cloud Console](https://console.cloud.google.com/). -2. Go to Compute Engine > VM Instances and select **Create Instance**. -3. Under **Machine configuration**: - - Populate fields such as **Instance name**, **Region**, and **Zone**. - - Set **Series** to **C4A**. - - Select **c4a-standard-4** for machine type. +To create a virtual machine based on the C4A instance type, follow these steps: +- Open the [Google Cloud Console](https://console.cloud.google.com/). +- In the left navigation pane, select **Compute Engine** > **VM instances**. +- Select **Create instance**. +- In the **Machine configuration** section: + - Enter a value for **Instance name**. + - Select a **Region** and **Zone**. + - For **Series**, select **C4A**. + - For **Machine type**, select **c4a-standard-4**. - ![Create a Google Axion C4A Arm virtual machine in the Google Cloud Console with c4a-standard-4 selected alt-text#center](images/gcp-vm.png "Creating a Google Axion C4A Arm virtual machine in Google Cloud Console") +The following image shows the **Machine configuration** section with the C4A series and c4a-standard-4 machine type selected: -4. Under **OS and Storage**, select **Change**, then choose an Arm64-based OS image. For this Learning Path, use **SUSE Linux Enterprise Server** or **Ubuntu**. Select your preferred version for the operating system. Ensure you choose the Arm version, then select **Select**. -5. Under **Networking**, enable **Allow HTTP traffic**. -6. Select **Create** to launch the instance. + ![Screenshot of the Machine configuration section in Google Cloud Console with C4A series and c4a-standard-4 machine type selected.alt-text #center](images/gcp-vm.png "Creating a Google Axion C4A Arm virtual machine in Google Cloud Console") + +- In the **OS and storage** section, select **Change**. + - In the **Operating system** dialog, choose an Arm64-based image such as **SUSE Linux Enterprise Server** or **Ubuntu**. + - Select your preferred version, making sure you select the Arm architecture. + - Select **Select** to confirm your choice. +- In the **Networking** section, enable the **Allow HTTP traffic** option. +- Select **Create** to launch your instance. + +Once the instance is running, you can connect to it using SSH from the Google Cloud Console or your local terminal. This allows you to configure your environment and begin deploying workloads on your new Arm-based VM. -Once the instance is running, connect using SSH \ No newline at end of file diff --git a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/multiarch_buildkite_pipeline.md b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/multiarch_buildkite_pipeline.md index ebd93c42ac..d7b76feb7e 100644 --- a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/multiarch_buildkite_pipeline.md +++ b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/multiarch_buildkite_pipeline.md @@ -8,11 +8,11 @@ layout: learningpathall ## Create an application -You can now create an application to containerize with Docker. The example below is a simple Flask-based Python application. +Now you'll create a simple application to containerize with Docker. This example uses Flask, a popular Python web framework. -Create a new public GitHub repository where you can create the Dockerfile and the Python file for the application. +The first step is to create a new public GitHub repository. You'll add both the `Dockerfile` and the Python application file to this repository. -### Create a Dockerfile +## Create a Dockerfile In a GitHub repo, add a new file named `Dockerfile` with this content: @@ -30,7 +30,7 @@ EXPOSE 5000 CMD ["python", "app.py"] ``` -### Create a Python application +## Create a Python application In the same repo, add a Python source file named `app.py`: @@ -48,16 +48,13 @@ if __name__ == "__main__": This Python code defines a simple Flask web server that listens on all interfaces (0.0.0.0) at port 5000 and responds with "Hello from Arm-based Buildkite runner!" when the root URL (/) is accessed. -### Add the code to your GitHub repository +## Add your code to the GitHub repository -Before triggering the pipeline, your GitHub repository should have: +Before you trigger the Buildkite pipeline, make sure your GitHub repository contains both the `Dockerfile` and the `app.py` file. The `Dockerfile` defines your multi-architecture container image, and `app.py` is your Python microservice. -- `Dockerfile` (defines your multi-arch image) -- `app.py` (your Python microservice) +You'll need the URL of this repository when you create your Buildkite pipeline in the next steps. -You will need the path to the GitHub repository when you create a Buildkite pipeline below. - -### Add Docker credentials as Buildkite secrets +## Add Docker credentials as Buildkite secrets Make sure to add your Docker credentials as secrets in the Buildkite UI. @@ -65,20 +62,20 @@ Navigate to Buildkite and select Agents and then Secrets and add `DOCKER_USERNAM ![Buildkite Dashboard alt-text#center](images/secrets.png "Set Secrets") -### Create a Buildkite pipeline for multi-arch builds +## Create a Buildkite pipeline for multi-arch builds In Buildkite, define your pipeline using YAML through the UI. Go to the Buildkite Dashboard and select Pipelines and New Pipeline -Fill out the form: +Fill out the form using the following details: - Git Repository: Enter your GitHub repository URL (SSH or HTTPS). - Name: Enter a name for your pipeline. ![Buildkite Dashboard alt-text#center](images/pipeline.png "Create Pipeline") -In the Steps (YAML Steps) section, paste your pipeline YAML. +In the Steps (YAML Steps) section, paste your pipeline YAML: ```yaml steps: @@ -99,10 +96,12 @@ steps: ![Buildkite Dashboard alt-text#center](images/yaml.png "YAML steps") -Click Create Pipeline. +Select **Create pipeline** to save your new pipeline. -Trigger a new build by clicking New Build on your pipeline’s dashboard. +To start your first build, select **New build** on your pipeline dashboard. This action triggers the pipeline and begins the multi-architecture build process. ![Buildkite Dashboard alt-text#center](images/build-p.png "Create Build") -Once your files and pipeline are ready, you can validate that your Buildkite agent is running and ready to execute jobs. +## What you've accomplished + +You've now created a simple Flask application, added a Dockerfile, set up your GitHub repository, and configured a Buildkite pipeline for multi-architecture builds on Arm. You also added Docker credentials as secrets and defined your pipeline steps in YAML. These steps prepare you to build, push, and test containerized applications using Arm-based infrastructure. You're now ready to validate your setup and run your first build! diff --git a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/validation.md b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/validation.md index 10886be473..05041e9809 100644 --- a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/validation.md +++ b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/validation.md @@ -10,9 +10,9 @@ layout: learningpathall Follow the steps below to run your pipeline on an Arm-based Buildkite agent. You will use Docker Buildx to create a multi-architecture image for both `arm64` and `amd64`. -### Ensure the agent is running +## Ensure the agent is running -Before your pipeline can execute, the Buildkite agent must be running and connected to your Buildkite account. To verify the agent status, run the following command on your VM: +Before running your pipeline, make sure the Buildkite agent is active and connected. On your VM, check the agent status with this command: ```console sudo /root/.buildkite-agent/bin/buildkite-agent status @@ -20,32 +20,32 @@ sudo /root/.buildkite-agent/bin/buildkite-agent status This command checks the current state of your Buildkite agent and displays its connection status. When the agent is properly running and connected, you'll see logs indicating "Registered agent" in the output, confirming that the agent is online and ready to receive jobs from Buildkite. The agent continuously listens for new pipeline jobs and executes the steps you've defined in your configuration. -### Trigger the pipeline +## Trigger the pipeline To start your pipeline, navigate to your pipeline in the Buildkite web interface. From your Buildkite dashboard, select the pipeline you created and click the "New Build" button. Choose the branch you want to build from the dropdown menu, then click "Start Build" to begin execution. -![Buildkite Dashboard alt-text#center](images/build-p.png "Trigger the pipeline") +![Screenshot of the Buildkite dashboard showing the "New Build" button highlighted, with the pipeline name and branch selection visible. This interface allows you to trigger a new build and select the branch to build from alt-text#center](images/build-p.png "Trigger the pipeline") When you trigger the pipeline, Buildkite sends the job to your Arm-based agent and begins executing the steps defined in your YAML configuration file. The agent will process each step in sequence, starting with Docker login, followed by creating the Buildx builder, and finally building and pushing your multi-architecture Docker image. -### Monitor the Build +## Monitor the build +You can watch your build logs in real time in the Buildkite dashboard. Each step appears as it runs, so you can track progress and spot any issues quickly. -You can see the logs of your build live in the Buildkite UI. +The main steps you'll see are: -The steps include: -- Docker login -- Buildx builder creation -- Multi-arch Docker image build and push +- Logging in to Docker +- Creating the Buildx builder +- Building and pushing the multi-architecture Docker image -![Buildkite Dashboard alt-text#center](images/log.png "Monitor the build") +![Screenshot of the Buildkite dashboard displaying real-time build logs, showing each pipeline step and its status for monitoring progress alt-text#center](images/log.png "Monitor the build") -### Verify Multi-Arch Image +## Verify multi-arch image After the pipeline completes successfully, you can go to Docker Hub and verify the pushed multi-arch images: -![Docker-Hub alt-text#center](images/multi-arch-image.png "Figure 3: Docker image") +![Screenshot of Docker Hub showing the multi-architecture image for the application repository, confirming both arm64 and amd64 platforms are available alt-text#center](images/multi-arch-image.png "Docker image") -### Run the Flask Application on Arm +## Run the Flask application ```console docker pull /multi-arch-app:latest @@ -54,13 +54,14 @@ docker run --rm -p 80:5000 /multi-arch-app:latest This command runs the Flask application inside a container, exposing it on port 5000 inside the container and mapping it to port 80 on the host machine. -You can now visit the VM’s Public IP to access the Flask application. +You can now visit the VM’s Public IP to access the Flask application: ```console http:// ``` You should see output similar to: +![Screenshot of the Docker Hub web interface showing the multi-architecture image tags for the application repository, confirming successful upload of both arm64 and amd64 alt-text#center](images/browser.png "Verify Docker images") -![Buildkite Dashboard alt-text#center](images/browser.png "Figure 4: Verify Docker Images") +## What you've accomplished -Your pipeline is working, and you have successfully built and ran the Flask application using your Arm-based Buildkite agent. +You've now completed the key steps to run a Buildkite pipeline on an Arm-based Google Axion C4A VM. You verified your agent connection, triggered and monitored a multi-architecture build, and successfully deployed and tested a Flask application in a Docker container. This workflow demonstrates how to use Arm infrastructure for modern CI/CD pipelines and multi-architecture container builds. Great work, you're now ready to apply these skills to your own Arm-based projects! \ No newline at end of file diff --git a/content/learning-paths/servers-and-cloud-computing/dotnet-migration/4-dotnet-versions.md b/content/learning-paths/servers-and-cloud-computing/dotnet-migration/4-dotnet-versions.md index 79254fa8e4..a4c8d3853f 100644 --- a/content/learning-paths/servers-and-cloud-computing/dotnet-migration/4-dotnet-versions.md +++ b/content/learning-paths/servers-and-cloud-computing/dotnet-migration/4-dotnet-versions.md @@ -55,7 +55,7 @@ With .NET 5 Microsoft started the “one .NET” unification. Even though it had Key highlights were: - General-availability of Native AOT publishing for console applications, producing self-contained, very small binaries with fast start-up on Arm64. -- Dynamic PGO (Profile-Guided Optimization) and On-Stack Replacement became the default, letting the JIT optimise the hottest code paths based on real run-time data. +- Dynamic PGO (Profile-Guided Optimization) and On-Stack Replacement became the default, letting the JIT optimize the hottest code paths based on real run-time data. - New Arm64 hardware intrinsics (e.g. SHA-1/SHA-256, AES, CRC-32) exposed through System.Runtime.Intrinsics, enabling high-performance crypto workloads. ## .NET 8 (current LTS – support until November 2026) diff --git a/content/learning-paths/servers-and-cloud-computing/openbmc-rdv3/3_openbmc_simulate.md b/content/learning-paths/servers-and-cloud-computing/openbmc-rdv3/3_openbmc_simulate.md index 19d83590c5..e38eb595d2 100644 --- a/content/learning-paths/servers-and-cloud-computing/openbmc-rdv3/3_openbmc_simulate.md +++ b/content/learning-paths/servers-and-cloud-computing/openbmc-rdv3/3_openbmc_simulate.md @@ -36,7 +36,7 @@ wget https://gitlab.arm.com/server_management/PoCs/fvp-poc/-/raw/2a79ae93560969a ``` Before running the simulation, open the `run.sh` script and locate the line that defines `FVP_KEYWORD`. -This variable determines when the host FVP should be launched by monitoring OpenBMC’s console output. +This variable determines when the host FVP should be launched by monitoring OpenBMC's console output. If not set correctly, the script might hang or fail to start the host simulation. Update the line to: diff --git a/content/learning-paths/servers-and-cloud-computing/sve/sve_basics.md b/content/learning-paths/servers-and-cloud-computing/sve/sve_basics.md index 8196f3af0e..17cf661a79 100644 --- a/content/learning-paths/servers-and-cloud-computing/sve/sve_basics.md +++ b/content/learning-paths/servers-and-cloud-computing/sve/sve_basics.md @@ -82,7 +82,7 @@ Take a look at the example code compiled for SVE (left) and for NEON (right): {{< godbolt width="100%" height="700px" mode="diff" lopt="-O3 -march=armv8-a" ropt="-O3 -march=armv8-a+sve" src="int fun(double * restrict a, double * restrict b, int size)\n{\n for (int i=0; i < size; ++i)\n {\n b[i] += a[i];\n }\n}" >}} -Notice how small the SVE assembly is in comparison to NEON. This is due to the predicate behaviour which avoids generating assembly for remainder loops (scalar operations performed when the iteration domain is not a multiple of the vector length. +Notice how small the SVE assembly is in comparison to NEON. This is due to the predicate behavior which avoids generating assembly for remainder loops (scalar operations performed when the iteration domain is not a multiple of the vector length. Observe what the SVE assembly instructions are doing: diff --git a/content/learning-paths/servers-and-cloud-computing/tune-network-workloads-on-bare-metal/4_local-numa.md b/content/learning-paths/servers-and-cloud-computing/tune-network-workloads-on-bare-metal/4_local-numa.md index ce2fe4b622..7529fa63ff 100644 --- a/content/learning-paths/servers-and-cloud-computing/tune-network-workloads-on-bare-metal/4_local-numa.md +++ b/content/learning-paths/servers-and-cloud-computing/tune-network-workloads-on-bare-metal/4_local-numa.md @@ -46,7 +46,7 @@ Example output (NIC on NUMA node 1): 1 ``` -Allocate the eight reserved cores to the NIC’s NUMA node (the example below keeps CPUs 96–103 online on node 1 and offlines the rest): +Allocate the eight reserved cores to the NIC's NUMA node (the example below keeps CPUs 96–103 online on node 1 and offlines the rest): ```bash for no in {96..103}; do sudo bash -c "echo 1 > /sys/devices/system/cpu/cpu${no}/online"; done @@ -93,7 +93,7 @@ Run `wrk2` on the `x86_64` bare‑metal client to measure throughput and latency ulimit -n 65535 && wrk -c1280 -t128 -R500000 -d60 http://${tomcat_ip}:8080/examples/servlets/servlet/HelloWorldExample ``` -Sample results after placing Tomcat on the NIC’s local NUMA node: +Sample results after placing Tomcat on the NIC's local NUMA node: ```output Thread Stats Avg Stdev Max +/- Stdev diff --git a/content/learning-paths/servers-and-cloud-computing/tune-network-workloads-on-bare-metal/_index.md b/content/learning-paths/servers-and-cloud-computing/tune-network-workloads-on-bare-metal/_index.md index 902cefcd4f..47170a0754 100644 --- a/content/learning-paths/servers-and-cloud-computing/tune-network-workloads-on-bare-metal/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/tune-network-workloads-on-bare-metal/_index.md @@ -9,7 +9,7 @@ learning_objectives: - Set up Apache Tomcat and wrk2 to benchmark HTTP on an Arm Neoverse bare‑metal host - Establish a reproducible baseline baseline (file‑descriptor limits, logging, thread counts, fixed core set) - Tune NIC queue count to match available cores and measure impact - - Improve NUMA locality by placing Tomcat on the NIC’s NUMA node and aligning worker threads with cores + - Improve NUMA locality by placing Tomcat on the NIC's NUMA node and aligning worker threads with cores - Compare IOMMU strict mode and IOMMU passthrough mode, and select the configuration that delivers the best performance for your workload prerequisites: