[Mesa-dev] [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

[Marek Olšák]

On Wed, Jul 26, 2017 at 7:05 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Wed, Jul 26, 2017 at 8:15 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> On 26.07.2017 08:29, Michel Dänzer wrote:
>>>
>>> On 25/07/17 05:28 PM, Nicolai Hähnle wrote:
>>>>
>>>> On 22.07.2017 14:00, Daniel Stone wrote:
>>>>>
>>>>>
>>>>> I don't have any great solution off the top of my head, but I'd be
>>>>> inclined to bundle stride in with placement. TTBOMK (from having
>>>>> looked at radv), buffers shared cross-GPU also need to be allocated
>>>>> from a separate externally-visible memory heap. And at the moment,
>>>>> lacking placement information at allocation time (at least for EGL
>>>>> allocations, via DRIImage), that happens via transparent migration at
>>>>> import time I think. Placement restrictions would probably also
>>>>> involve communicating base address alignment requirements.
>>>>
>>>>
>>>> Stride isn't really in the same category as placement and base address
>>>> alignment, though.
>>>>
>>>> Placement and base address alignment requirements can apply to all
>>>> possible texture layouts, while the concept of stride is specific to
>>>> linear layouts.
>>>
>>>
>>> Also, the starting address of shareable buffers is generally aligned to
>>> at least the CPU page size anyway. Do we know of any cases requiring
>>> higher alignment than that, and if so, which address space does the
>>> requirement apply to?
>>
>>
>> Only tiling modes, as Marek mentioned. We don't do tiling shares across
>> different GPUs right now.
>>
>> Maybe we can do it in the future with gfx9 GPUs. But then the alignment
>> requirements should be known on both sides based on the tiling mode anyway
>> -- if they even apply for non-VRAM textures.
>
> We should be able to do some 1D tiling modes.  That doesn't have any
> per sku alignment dependencies.

Yeah, I think 1D tiling for displayable 32bpp is compatible across all
radeon GPUs newer than R600.

All non-X non-VAR tiling modes on Radeon/GFX9 (Vega, Raven) are the
same on all GFX9 GPUs and might be the same on all future products.
The only catch is that X modes are better optimized for the memory
config, so non-X modes can be slower. I think the non-X modes might
also be compatible with Intel (the first 12 at least), so some
cross-vendor interface might be possible. All GFX9 tiling modes:

SW_LINEAR (256B pitch alignment)
SW_256B_S
SW_256B_D (compatible with older Radeons if bpp == 32)
SW_256B_R (compatible with older Radeons if bpp == 32)
SW_4KB_Z (Z = depth/stencil sample order)
SW_4KB_S (S = standard)
SW_4KB_D (D = displayable)
SW_4KB_R (R = displayable rotated)
SW_64KB_Z
SW_64KB_S
SW_64KB_D
SW_64KB_R
SW_VAR_Z (VAR = tile size depends on memory config)
SW_VAR_S
SW_VAR_D
SW_VAR_R
SW_64KB_Z_T
SW_64KB_S_T
SW_64KB_D_T
SW_64KB_R_T
SW_4KB_Z_X (X = optimized for memory config)
SW_4KB_S_X
SW_4KB_D_X
SW_4KB_R_X
SW_64KB_Z_X
SW_64KB_S_X
SW_64KB_D_X
SW_64KB_R_X
SW_VAR_Z_X
SW_VAR_S_X
SW_VAR_D_X
SW_VAR_R_X

Marek