Intel® Graphics Compiler (IGC)

repository·master·Indexed 20 days ago

https://github.com/intel/intel-graphics-compiler

An LLVM-based compiler optimized for OpenCL workloads on Intel graphics hardware, supporting Gen9 through Xe2 architectures. The repository includes the IRBuilderGenerator for automating C++ IR Builder accessor code, and tools for managing IBiF matrix builtins for the Joint/Cooperative Matrix SYCL API.

Tokens
171.9K
Snippets
346
Records
540
Agent score
72%

What's inside Intel Graphics Compiler

  1. Overview of the vISA RA Validation Tool

    master

    The vISA RA (Register Assignment) Validation Tool is a GTReplay tool designed to detect incorrect register assignments in shaders. It works by monitoring the byte values of virtual variables.

    How it works:

    1. It stores the byte values of every virtual variable after each Definition (Def) by inspecting the physical register state.
    2. At every Use, it performs a byte-by-byte comparison between the stored values and the current physical register state.
    3. If a mismatch is found, it reports an error, indicating that a Def to one virtual variable clobbered the values of another due to overlapping live ranges.
  2. What is libclc?

    master

    libclc is an open-source, BSD-licensed implementation of the library requirements for the OpenCL C programming language (as specified by the OpenCL 1.1 Specification). It provides implementations for:

    • Supported Data Types (Explicit Conversions, Reinterpreting Types via as_type() and as_typen())
    • Preprocessor Directives and Macros
    • Built-in Functions
    • Double Precision Floating-Point
    • 64-bit Atomics
    • Writing to 3D image memory objects
    • Half Precision Floating-Point

    It is designed to be used with the Clang compiler's OpenCL frontend and is intended to be portable and extensible, allowing targets to override generic function implementations. Currently, it only supports the PTX target.

  3. Overview of IRBuilderGenerator

    master
    IRBuilderGenerator is a code generation tool that automates the creation of C++ IR Builder accessor code. It works by taking C++ functions annotated with specific Clang annotations (compiled to LLVM bitcode) and transforming them into low-level LLVM IRBuilder calls. This process helps maintain consistency between structure definitions and IR generation, handles address space parameterization, and allows for readable C++ templates to generate complex IR instruction sequences.
  4. Check supported SPIR-V extensions in IGC

    master
    The Intel Graphics Compiler (IGC) supports a wide range of SPIR-V extensions, including both Khronos SPV_EXT_* and Intel-specific SPV_INTEL_* extensions. Support varies significantly depending on the hardware platform (e.g., XE3P+, XE_HPG+, XE_HPC+, DG2, PVC) and whether the feature is considered stable or experimental. When developing shaders, verify that the specific extension and its capabilities are supported by your target hardware before use.
  5. Use Shared Virtual Memory (SVM)

    master

    In the SVM model, the host designates part of its virtual address space to be shared with the kernel. The kernel can directly access these addresses without a surface variable.

    • Use Case: Allows sharing complex data structures containing embedded pointers between CPU and GPU.
    • Access: Performed exclusively via SVM instructions using virtual addresses.
    • Synchronization: Data dependencies between the host and kernel (or between threads) should be resolved using the fence instruction or SVM atomic write operations.
  6. Understanding IBiF Matrix Builtins

    master

    The files in this directory provide builtin implementations for the Joint/Cooperative Matrix SYCL API.

    Important Note: These are internal builtins and are not intended to be used directly from outside the Intel Graphics Compiler (IGC). The JointMatrixFuncsResolutionPass.cpp component is responsible for translating external JointMatrix/CooperativeMatrix API calls into these internal builtins.

    Key components:

    • IBiF_matrix.cl: Contains OpenCL C builtins with hand-coded implementations.
    • IBiF_matrix_generator.cpp: A compile-time generator used to create OpenCL C matrix load and store builtins, replacing older macro-based implementations to handle the combinatorial explosion of possible matrix configurations.
  7. Use NBARRIER for named barrier synchronization

    master

    The NBARRIER opcode (0x60) provides named barrier synchronization for a subgroup of threads within a thread group, enabling general consumer-producer synchronization.

    Synchronization Logic

    • Signal Operation: Notifies other threads that the calling thread has reached the barrier identified by <id>.
    • Wait Operation: Only consumer threads can issue a wait operation. A consumer thread will block until all participating producer and consumer threads have reached the barrier.
    • Participation: All threads participating in a specific phase of barrier <id> must use identical values for <id>, <num_threads> (for baseline), <num_producers>, and <num_consumers>.
    • Reuse: A barrier <id> can be reused once all threads have completed their wait operation.

    Execution Model Requirement

    This instruction may only be used with the thread-group execution model.

    NBARRIER.wait <id>
    
    NBARRIER.signal <id> <num_threads>                             // baseline
    NBARRIER.signal <id> <type> <num_producers> <num_consumers>    // general
  8. How Generic Pointers are Created in LLVM

    master

    Generic address space pointers are generated in LLVM through addrspacecast instructions. This occurs whenever there is an implicit or explicit cast from a named address space to the generic address space.

    In IGC, the generic address space is mapped to addrspace(4). When a kernel passes a specific pointer (e.g., global) to a function expecting a generic pointer, an addrspacecast is inserted to convert the pointer type.

    ; Example: Implicit cast from global (addrspace 1) to generic (addrspace 4)
    %ptr_as_generic = addrspacecast i32* %ptr to i32 addrspace(4)*
    call spir_func void @printElement(i32 addrspace(4)* %ptr_as_generic, i32 0)
  9. Configure 3D_LOAD operand parameters by surface type

    master

    The meaning of the u, v, and r parameters in a 3D_LOAD instruction changes based on the type of surface being accessed:

    Surface Typeuvr
    1D / 1D_ARRAYunnormalized 'x' coordinateunnormalized array indexignored
    2D / 2D_ARRAYunnormalized 'x' coordinateunnormalized 'y' coordinateunnormalized array index
    3Dunnormalized 'x' coordinateunnormalized 'y' coordinateunnormalized 'z' coordinate

    Note: For ld2dms_w (type UD), the parameters follow the order: si, mcsl, mcsh, u, v, r, lod.

  10. Access Memory via Surfaces

    master

    Surface-based access uses linear, 2D, or 3D memory objects created by the host.

    • Binding Table: GEN provides a 256-entry binding table. A vISA surface variable stores the Binding Table Index (BTI).
    • Access: Instructions take a surface variable and positive offsets. The hardware resolves the address using the BTI.
    • Bindless Model: Use the special reserved T252 surface variable. This variable contains the actual graphics memory address of the surface state object, bypassing the binding table.
    • Samplers: Similarly, a 32-entry sampler state binding table is used. The special reserved S31 sampler variable supports bindless sampler operations.