Skip to content
  • José María Casanova Crespo's avatar
    isl/i965/fs: SSBO/UBO buffers need size padding if not multiple of 32-bit · 67d7dd59
    José María Casanova Crespo authored and Faith Ekstrand's avatar Faith Ekstrand committed
    
    
    The surfaces that backup the GPU buffers have a boundary check that
    considers that access to partial dwords are considered out-of-bounds.
    For example, buffers with 1,3 16-bit elements has size 2 or 6 and the
    last two bytes would always be read as 0 or its writting ignored.
    
    The introduction of 16-bit types implies that we need to align the size
    to 4-bytew multiples so that partial dwords could be read/written.
    Adding an inconditional +2 size to buffers not being multiple of 2
    solves this issue for the general cases of UBO or SSBO.
    
    But, when unsized arrays of 16-bit elements are used it is not possible
    to know if the size was padded or not. To solve this issue the
    implementation calculates the needed size of the buffer surfaces,
    as suggested by Jason:
    
    surface_size = isl_align(buffer_size, 4) +
                   (isl_align(buffer_size, 4) - buffer_size)
    
    So when we calculate backwards the buffer_size in the backend we
    update the resinfo return value with:
    
    buffer_size = (surface_size & ~3) - (surface_size & 3)
    
    It is also exposed this buffer requirements when robust buffer access
    is enabled so these buffer sizes recommend being multiple of 4.
    
    v2: (Jason Ekstrand)
        Move padding logic fron anv to isl_surface_state.
        Move calculus of original size from spirv to driver backend.
    v3: (Jason Ekstrand)
        Rename some variables and use a similar expresion when calculating.
        padding than when obtaining the original buffer size.
        Avoid use of unnecesary component call at brw_fs_nir.
    v4: (Jason Ekstrand)
        Complete comment with buffer size calculus explanation in brw_fs_nir.
    
    Reviewed-by: default avatarJason Ekstrand <jason@jlekstrand.net>
    67d7dd59