[Mesa-dev] [PATCH 00/14] RadeonSI: SDMA texture copy rewrite

[Marek Olšák]

On Thu, May 5, 2016 at 5:57 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Wed, May 4, 2016 at 7:43 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> Hi,
>>
>> This patch series completely rewrites texture copying with SDMA for CIK & VI. It only uses the "partial" copy packets, which makes it a lot simpler (one packet per layered/3D copy). Most of the complexity is in handling hw limitations, but luckily the SDMA path can be used in the majority of cases.
>>
>> On top of that, the DMA IB support is improved thanks to extensive testing and benchmarking.
>>
>> This is only enabled on VI for now. It can be enabled on CIK after enough testing is done.
>>
>> There is one more hardware limitation that can cause VM faults with T2L copies and needs a workaround. The exact workaround is still under discussion, but I think this is good enough for review already.
>>
>> On Tonga, it beats the 3D engine in texture upload performance by 0-80%. On APUs, the performance is mixed or slightly worse. The reason may be that the 3D engine uses less bandwidth thanks to DCC.
>>
>> The fact that SDMA can't do DCC compression can be detrimental to texturing performance on VI. The impact hasn't been measured yet.
>>
>> Texture uploads still use 2 copies (user memory -> linear, linear -> tiled). Merging those 2 copies into 1 is not done in this series.
>>
>> Please review and opinions on the DCC issue are welcome,
>
> Have you looked at using SDMA for buffer clears as well?

In general, I don't think SDMA is a good match for any buffer-related
operations if a GFX IB flush is required.

The only area where it might make sense to use SDMA is the initial
HTILE/DCC/CMASK fill when new textures are being created and there is
no dependency on the GFX IB.

We already use SDMA for all pipelined buffer uploads. I don't know if
that is helping us or hurting us. Probably the latter since CP DMA can
copy through (and thus preload) TC L2, while SDMA can't.

Marek