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

[Nicolai Hähnle]

On 26.07.2017 19:42, Marek Olšák wrote:
> 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:

Right. It might be worth it to try to use some of these tiling modes to 
make PRIME a bit more efficient in some cases. Non-X modes may be 
non-optimal, but certainly they're better than linear :)

Cheers,
Nicolai


> 
> 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
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.