Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Nicolai Hähnle]

On 27.04.2018 19:23, Marek Olšák wrote:
On Fri, Apr 27, 2018 at 4:14 AM, Nicolai Hähnle > wrote:


Sorry, but I still don't understand the logic of this :/

What we want to check for is that all the DCC bytes of a mip-level
are contiguous, right?

Why does it matter for that whether a level is the last level?

Here's the thought experiment that I can't make sense of: Let's say
that you have format, base level, and number of levels N so that the
last-level condition applies. That is, all levels up to and
including N-2 have dccRamAligned true. Level N-1 has dccRamAligned
false, but the patch as-is will still consider it fast-clearable.


Yes, because the non-contiguous level N-1 DCC range (last level) doesn't 
overlap with any existing level. It's interleaved with level N that 
doesn't exist. So clearing the level N-1 DCC range that might overwrite 
level N DCC range doesn't break anything and so the clear is allowed.


Is it clear now?


Yes. I was thinking that dccFastClearSize is the number of bytes 
belonging to the mip level that have to be cleared, but digging into 
AddrLib it is in fact a span like you describe (which potentially 
contains bytes that *don't* belong to the mip level). So the patch is 
okay as-is.


Reviewed-by: Nicolai Hähnle 



Marek




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Marek Olšák]

On Fri, Apr 27, 2018 at 4:14 AM, Nicolai Hähnle  wrote:

> Sorry, but I still don't understand the logic of this :/
>
> What we want to check for is that all the DCC bytes of a mip-level are
> contiguous, right?
>
> Why does it matter for that whether a level is the last level?
>
> Here's the thought experiment that I can't make sense of: Let's say that
> you have format, base level, and number of levels N so that the last-level
> condition applies. That is, all levels up to and including N-2 have
> dccRamAligned true. Level N-1 has dccRamAligned false, but the patch as-is
> will still consider it fast-clearable.
>

Yes, because the non-contiguous level N-1 DCC range (last level) doesn't
overlap with any existing level. It's interleaved with level N that doesn't
exist. So clearing the level N-1 DCC range that might overwrite level N DCC
range doesn't break anything and so the clear is allowed.

Is it clear now?

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Nicolai Hähnle]

Sorry, but I still don't understand the logic of this :/

What we want to check for is that all the DCC bytes of a mip-level are 
contiguous, right?


Why does it matter for that whether a level is the last level?

Here's the thought experiment that I can't make sense of: Let's say that 
you have format, base level, and number of levels N so that the 
last-level condition applies. That is, all levels up to and including 
N-2 have dccRamAligned true. Level N-1 has dccRamAligned false, but the 
patch as-is will still consider it fast-clearable.


Now you take the same format and base level, but allocate N+1 levels. 
Presumably we now also get levels up to and including N-2 with 
dccRamAligned true, but levels N-1 and N will have dccRamAligned false 
and will be considered not fast-clearable.


Why is level N-1 fast clearable in the first case but not the second? 
That's what doesn't make sense to me. Am I missing something here?


Thanks,
Nicolai


On 27.04.2018 04:13, Marek Olšák wrote:

Ping. Thanks.

On Tue, Apr 24, 2018 at 3:56 PM, Marek Olšák > wrote:


From: Marek Olšák mailto:marek.ol...@amd.com>>

v2: require the previous level to be clearable for determining whether
     the last unaligned level is clearable
---
  src/amd/common/ac_surface.c | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index a23952717e3..487f6c6431b 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -336,36 +336,52 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
                 surf->u.legacy.tiling_index[level] =
AddrSurfInfoOut->tileIndex;

         surf->surf_size = surf_level->offset +
AddrSurfInfoOut->surfSize;

         /* Clear DCC fields at the beginning. */
         surf_level->dcc_offset = 0;

         /* The previous level's flag tells us if we can use DCC for
this level. */
         if (AddrSurfInfoIn->flags.dccCompatible &&
             (level == 0 || AddrDccOut->subLvlCompressible)) {
+               bool prev_level_clearable = level == 0 ||
+ 
  AddrDccOut->dccRamSizeAligned;

+
                 AddrDccIn->colorSurfSize = AddrSurfInfoOut->surfSize;
                 AddrDccIn->tileMode = AddrSurfInfoOut->tileMode;
                 AddrDccIn->tileInfo = *AddrSurfInfoOut->pTileInfo;
                 AddrDccIn->tileIndex = AddrSurfInfoOut->tileIndex;
                 AddrDccIn->macroModeIndex =
AddrSurfInfoOut->macroModeIndex;

                 ret = AddrComputeDccInfo(addrlib,
                                          AddrDccIn,
                                          AddrDccOut);

                 if (ret == ADDR_OK) {
                         surf_level->dcc_offset = surf->dcc_size;
-                       surf_level->dcc_fast_clear_size =
AddrDccOut->dccFastClearSize;
                         surf->num_dcc_levels = level + 1;
                         surf->dcc_size = surf_level->dcc_offset +
AddrDccOut->dccRamSize;
                         surf->dcc_alignment =
MAX2(surf->dcc_alignment, AddrDccOut->dccRamBaseAlign);
+
+                       /* If the DCC size of a subresource (1 mip
level or 1 slice)
+                        * is not aligned, the DCC memory layout is
not contiguous for
+                        * that subresource, which means we can't
use fast clear.
+                        *
+                        * We only do fast clears for whole mipmap
levels. If we did
+                        * per-slice fast clears, the same
restriction would apply.
+                        * (i.e. only compute the slice size and see
if it's aligned)
+                        */
+                       if (AddrDccOut->dccRamSizeAligned ||
+                           (prev_level_clearable && level ==
config->info.levels - 1))
+                               surf_level->dcc_fast_clear_size =
AddrDccOut->dccFastClearSize;
+                       else
+                               surf_level->dcc_fast_clear_size = 0;
                 }
         }

         /* TC-compatible HTILE. */
         if (!is_stencil &&
             AddrSurfInfoIn->flags.depth &&
             surf_level->mode == RADEON_SURF_MODE_2D &&
             level == 0) {
                 AddrHtileIn->flags.tcCompatible =
AddrSurfInfoIn->flags.tcCompatible;
                 AddrHtileIn->pitch = AddrSurfInfoOut->pitch;
-- 
2.17.0





___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev




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

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Marek Olšák]

Ping. Thanks.

On Tue, Apr 24, 2018 at 3:56 PM, Marek Olšák  wrote:

> From: Marek Olšák 
>
> v2: require the previous level to be clearable for determining whether
> the last unaligned level is clearable
> ---
>  src/amd/common/ac_surface.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index a23952717e3..487f6c6431b 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -336,36 +336,52 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
> surf->u.legacy.tiling_index[level] =
> AddrSurfInfoOut->tileIndex;
>
> surf->surf_size = surf_level->offset + AddrSurfInfoOut->surfSize;
>
> /* Clear DCC fields at the beginning. */
> surf_level->dcc_offset = 0;
>
> /* The previous level's flag tells us if we can use DCC for this
> level. */
> if (AddrSurfInfoIn->flags.dccCompatible &&
> (level == 0 || AddrDccOut->subLvlCompressible)) {
> +   bool prev_level_clearable = level == 0 ||
> +   AddrDccOut->dccRamSizeAligned;
> +
> AddrDccIn->colorSurfSize = AddrSurfInfoOut->surfSize;
> AddrDccIn->tileMode = AddrSurfInfoOut->tileMode;
> AddrDccIn->tileInfo = *AddrSurfInfoOut->pTileInfo;
> AddrDccIn->tileIndex = AddrSurfInfoOut->tileIndex;
> AddrDccIn->macroModeIndex = AddrSurfInfoOut->
> macroModeIndex;
>
> ret = AddrComputeDccInfo(addrlib,
>  AddrDccIn,
>  AddrDccOut);
>
> if (ret == ADDR_OK) {
> surf_level->dcc_offset = surf->dcc_size;
> -   surf_level->dcc_fast_clear_size =
> AddrDccOut->dccFastClearSize;
> surf->num_dcc_levels = level + 1;
> surf->dcc_size = surf_level->dcc_offset +
> AddrDccOut->dccRamSize;
> surf->dcc_alignment = MAX2(surf->dcc_alignment,
> AddrDccOut->dccRamBaseAlign);
> +
> +   /* If the DCC size of a subresource (1 mip level
> or 1 slice)
> +* is not aligned, the DCC memory layout is not
> contiguous for
> +* that subresource, which means we can't use fast
> clear.
> +*
> +* We only do fast clears for whole mipmap levels.
> If we did
> +* per-slice fast clears, the same restriction
> would apply.
> +* (i.e. only compute the slice size and see if
> it's aligned)
> +*/
> +   if (AddrDccOut->dccRamSizeAligned ||
> +   (prev_level_clearable && level ==
> config->info.levels - 1))
> +   surf_level->dcc_fast_clear_size =
> AddrDccOut->dccFastClearSize;
> +   else
> +   surf_level->dcc_fast_clear_size = 0;
> }
> }
>
> /* TC-compatible HTILE. */
> if (!is_stencil &&
> AddrSurfInfoIn->flags.depth &&
> surf_level->mode == RADEON_SURF_MODE_2D &&
> level == 0) {
> AddrHtileIn->flags.tcCompatible = AddrSurfInfoIn->flags.
> tcCompatible;
> AddrHtileIn->pitch = AddrSurfInfoOut->pitch;
> --
> 2.17.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Marek Olšák]

From: Marek Olšák 

v2: require the previous level to be clearable for determining whether
the last unaligned level is clearable
---
 src/amd/common/ac_surface.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index a23952717e3..487f6c6431b 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -336,36 +336,52 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
surf->u.legacy.tiling_index[level] = AddrSurfInfoOut->tileIndex;
 
surf->surf_size = surf_level->offset + AddrSurfInfoOut->surfSize;
 
/* Clear DCC fields at the beginning. */
surf_level->dcc_offset = 0;
 
/* The previous level's flag tells us if we can use DCC for this level. 
*/
if (AddrSurfInfoIn->flags.dccCompatible &&
(level == 0 || AddrDccOut->subLvlCompressible)) {
+   bool prev_level_clearable = level == 0 ||
+   AddrDccOut->dccRamSizeAligned;
+
AddrDccIn->colorSurfSize = AddrSurfInfoOut->surfSize;
AddrDccIn->tileMode = AddrSurfInfoOut->tileMode;
AddrDccIn->tileInfo = *AddrSurfInfoOut->pTileInfo;
AddrDccIn->tileIndex = AddrSurfInfoOut->tileIndex;
AddrDccIn->macroModeIndex = AddrSurfInfoOut->macroModeIndex;
 
ret = AddrComputeDccInfo(addrlib,
 AddrDccIn,
 AddrDccOut);
 
if (ret == ADDR_OK) {
surf_level->dcc_offset = surf->dcc_size;
-   surf_level->dcc_fast_clear_size = 
AddrDccOut->dccFastClearSize;
surf->num_dcc_levels = level + 1;
surf->dcc_size = surf_level->dcc_offset + 
AddrDccOut->dccRamSize;
surf->dcc_alignment = MAX2(surf->dcc_alignment, 
AddrDccOut->dccRamBaseAlign);
+
+   /* If the DCC size of a subresource (1 mip level or 1 
slice)
+* is not aligned, the DCC memory layout is not 
contiguous for
+* that subresource, which means we can't use fast 
clear.
+*
+* We only do fast clears for whole mipmap levels. If 
we did
+* per-slice fast clears, the same restriction would 
apply.
+* (i.e. only compute the slice size and see if it's 
aligned)
+*/
+   if (AddrDccOut->dccRamSizeAligned ||
+   (prev_level_clearable && level == 
config->info.levels - 1))
+   surf_level->dcc_fast_clear_size = 
AddrDccOut->dccFastClearSize;
+   else
+   surf_level->dcc_fast_clear_size = 0;
}
}
 
/* TC-compatible HTILE. */
if (!is_stencil &&
AddrSurfInfoIn->flags.depth &&
surf_level->mode == RADEON_SURF_MODE_2D &&
level == 0) {
AddrHtileIn->flags.tcCompatible = 
AddrSurfInfoIn->flags.tcCompatible;
AddrHtileIn->pitch = AddrSurfInfoOut->pitch;
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Nicolai Hähnle]

On 18.04.2018 21:53, Marek Olšák wrote:
On Wed, Apr 18, 2018 at 5:54 AM, Nicolai Hähnle > wrote:


On 17.04.2018 02:41, Marek Olšák wrote:

From: Marek Olšák mailto:marek.ol...@amd.com>>

---
   src/amd/common/ac_surface.c | 14 +-
   1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_surface.c
b/src/amd/common/ac_surface.c
index 7558dd91e34..c209b209da2 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -344,24 +344,36 @@ static int gfx6_compute_level(ADDR_HANDLE
addrlib,
                 AddrDccIn->tileInfo = *AddrSurfInfoOut->pTileInfo;
                 AddrDccIn->tileIndex = AddrSurfInfoOut->tileIndex;
                 AddrDccIn->macroModeIndex =
AddrSurfInfoOut->macroModeIndex;
                 ret = AddrComputeDccInfo(addrlib,
                                          AddrDccIn,
                                          AddrDccOut);
                 if (ret == ADDR_OK) {
                         surf_level->dcc_offset = surf->dcc_size;
-                       surf_level->dcc_fast_clear_size =
AddrDccOut->dccFastClearSize;
                         surf->num_dcc_levels = level + 1;
                         surf->dcc_size = surf_level->dcc_offset
+ AddrDccOut->dccRamSize;
                         surf->dcc_alignment =
MAX2(surf->dcc_alignment, AddrDccOut->dccRamBaseAlign);
+
+                       /* If the DCC size of a subresource (1
mip level or 1 slice)
+                        * is not aligned, the DCC memory layout
is not contiguous for
+                        * that subresource, which means we
can't use fast clear.
+                        *
+                        * We only do fast clears for whole
mipmap levels. If we did
+                        * per-slice fast clears, the same
restriction would apply.
+                        * (i.e. only compute the slice size and
see if it's aligned)
+                        */
+                       if (level == config->info.levels - 1 ||
AddrDccOut->dccRamSizeAligned)


Are you sure that the last level is always okay? It seems possible
that the last and second-to-last level end up interleaved due to
swizzling.

The catch is that you'd probably only ever notice this with a
truncated mip-tree.


This condition was copied from amdvlk. I guess that if the 
second-to-last level is unaligned, the last level would also be unaligned.


Agreed, but does that make it any better? If the last level is N, and 
both levels N and N-1 are unaligned, then this code will disable fast 
clear on level N-1 and enable it on level N. That seems wrong to me.



We never use fast clear for non-zero level. For now, we only have to 
make sure that level 0 is contiguous.


Okay, but that might change in the future.

Cheers,
Nicolai




Marek




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Marek Olšák]

On Wed, Apr 18, 2018, 8:01 PM Bas Nieuwenhuizen 
wrote:

> On Wed, Apr 18, 2018 at 2:11 PM, Marek Olšák  wrote:
> > On Wed, Apr 18, 2018 at 4:44 PM, Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl>
> > wrote:
> >>
> >> IIRC if level N is unaligned then num_dcc_levels <= N+1, so level N+1
> >> is not DCC compressed?
> >
> >
> > There is a difference between being aligned (contiguous really) and being
> > compressible. Small mip levels might be unaligned but may still
> > compressible. Non-contiguous can mean that DCC of multiple mip levels is
> > interleaved in memory. It can't be cleared with memset trivially, but it
> can
> > still be compressed.
>
> Hw-wise probably, but if level N is not aligned addrlib will set
> subLvlCompressible to false[1], and hence the next level will not be
> DCC compressed[2]?
>

Even if a level is not compressible (by CB), TC still reads DCC and does
decompression. So it's necessary that the last compressed level doesn't do
fast clear if it's not contiguous. If you remove CB out of the picture, you
can probably compress the whole miptree.

Marek


> [1]
> https://cgit.freedesktop.org/mesa/mesa/tree/src/amd/addrlib/r800/ciaddrlib.cpp#n268
> [2]
> https://cgit.freedesktop.org/mesa/mesa/tree/src/amd/common/ac_surface.c#n345
>
> >
> > Marek
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Bas Nieuwenhuizen]

On Wed, Apr 18, 2018 at 2:11 PM, Marek Olšák  wrote:
> On Wed, Apr 18, 2018 at 4:44 PM, Bas Nieuwenhuizen 
> wrote:
>>
>> IIRC if level N is unaligned then num_dcc_levels <= N+1, so level N+1
>> is not DCC compressed?
>
>
> There is a difference between being aligned (contiguous really) and being
> compressible. Small mip levels might be unaligned but may still
> compressible. Non-contiguous can mean that DCC of multiple mip levels is
> interleaved in memory. It can't be cleared with memset trivially, but it can
> still be compressed.

Hw-wise probably, but if level N is not aligned addrlib will set
subLvlCompressible to false[1], and hence the next level will not be
DCC compressed[2]?

[1] 
https://cgit.freedesktop.org/mesa/mesa/tree/src/amd/addrlib/r800/ciaddrlib.cpp#n268
[2] https://cgit.freedesktop.org/mesa/mesa/tree/src/amd/common/ac_surface.c#n345

>
> Marek
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Marek Olšák]

On Wed, Apr 18, 2018 at 4:44 PM, Bas Nieuwenhuizen 
wrote:

> IIRC if level N is unaligned then num_dcc_levels <= N+1, so level N+1
> is not DCC compressed?
>

There is a difference between being aligned (contiguous really) and being
compressible. Small mip levels might be unaligned but may still
compressible. Non-contiguous can mean that DCC of multiple mip levels is
interleaved in memory. It can't be cleared with memset trivially, but it
can still be compressed.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Bas Nieuwenhuizen]

IIRC if level N is unaligned then num_dcc_levels <= N+1, so level N+1
is not DCC compressed?

On Wed, Apr 18, 2018 at 12:53 PM, Marek Olšák  wrote:
> On Wed, Apr 18, 2018 at 5:54 AM, Nicolai Hähnle  wrote:
>>
>> On 17.04.2018 02:41, Marek Olšák wrote:
>>>
>>> From: Marek Olšák 
>>>
>>> ---
>>>   src/amd/common/ac_surface.c | 14 +-
>>>   1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
>>> index 7558dd91e34..c209b209da2 100644
>>> --- a/src/amd/common/ac_surface.c
>>> +++ b/src/amd/common/ac_surface.c
>>> @@ -344,24 +344,36 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
>>> AddrDccIn->tileInfo = *AddrSurfInfoOut->pTileInfo;
>>> AddrDccIn->tileIndex = AddrSurfInfoOut->tileIndex;
>>> AddrDccIn->macroModeIndex =
>>> AddrSurfInfoOut->macroModeIndex;
>>> ret = AddrComputeDccInfo(addrlib,
>>>  AddrDccIn,
>>>  AddrDccOut);
>>> if (ret == ADDR_OK) {
>>> surf_level->dcc_offset = surf->dcc_size;
>>> -   surf_level->dcc_fast_clear_size =
>>> AddrDccOut->dccFastClearSize;
>>> surf->num_dcc_levels = level + 1;
>>> surf->dcc_size = surf_level->dcc_offset +
>>> AddrDccOut->dccRamSize;
>>> surf->dcc_alignment = MAX2(surf->dcc_alignment,
>>> AddrDccOut->dccRamBaseAlign);
>>> +
>>> +   /* If the DCC size of a subresource (1 mip level
>>> or 1 slice)
>>> +* is not aligned, the DCC memory layout is not
>>> contiguous for
>>> +* that subresource, which means we can't use
>>> fast clear.
>>> +*
>>> +* We only do fast clears for whole mipmap
>>> levels. If we did
>>> +* per-slice fast clears, the same restriction
>>> would apply.
>>> +* (i.e. only compute the slice size and see if
>>> it's aligned)
>>> +*/
>>> +   if (level == config->info.levels - 1 ||
>>> AddrDccOut->dccRamSizeAligned)
>>
>>
>> Are you sure that the last level is always okay? It seems possible that
>> the last and second-to-last level end up interleaved due to swizzling.
>>
>> The catch is that you'd probably only ever notice this with a truncated
>> mip-tree.
>
>
> This condition was copied from amdvlk. I guess that if the second-to-last
> level is unaligned, the last level would also be unaligned.
>
> We never use fast clear for non-zero level. For now, we only have to make
> sure that level 0 is contiguous.
>
> Marek
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Marek Olšák]

On Wed, Apr 18, 2018 at 5:54 AM, Nicolai Hähnle  wrote:

> On 17.04.2018 02:41, Marek Olšák wrote:
>
>> From: Marek Olšák 
>>
>> ---
>>   src/amd/common/ac_surface.c | 14 +-
>>   1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
>> index 7558dd91e34..c209b209da2 100644
>> --- a/src/amd/common/ac_surface.c
>> +++ b/src/amd/common/ac_surface.c
>> @@ -344,24 +344,36 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
>> AddrDccIn->tileInfo = *AddrSurfInfoOut->pTileInfo;
>> AddrDccIn->tileIndex = AddrSurfInfoOut->tileIndex;
>> AddrDccIn->macroModeIndex = AddrSurfInfoOut->macroModeInde
>> x;
>> ret = AddrComputeDccInfo(addrlib,
>>  AddrDccIn,
>>  AddrDccOut);
>> if (ret == ADDR_OK) {
>> surf_level->dcc_offset = surf->dcc_size;
>> -   surf_level->dcc_fast_clear_size =
>> AddrDccOut->dccFastClearSize;
>> surf->num_dcc_levels = level + 1;
>> surf->dcc_size = surf_level->dcc_offset +
>> AddrDccOut->dccRamSize;
>> surf->dcc_alignment = MAX2(surf->dcc_alignment,
>> AddrDccOut->dccRamBaseAlign);
>> +
>> +   /* If the DCC size of a subresource (1 mip level
>> or 1 slice)
>> +* is not aligned, the DCC memory layout is not
>> contiguous for
>> +* that subresource, which means we can't use
>> fast clear.
>> +*
>> +* We only do fast clears for whole mipmap
>> levels. If we did
>> +* per-slice fast clears, the same restriction
>> would apply.
>> +* (i.e. only compute the slice size and see if
>> it's aligned)
>> +*/
>> +   if (level == config->info.levels - 1 ||
>> AddrDccOut->dccRamSizeAligned)
>>
>
> Are you sure that the last level is always okay? It seems possible that
> the last and second-to-last level end up interleaved due to swizzling.
>
> The catch is that you'd probably only ever notice this with a truncated
> mip-tree.
>

This condition was copied from amdvlk. I guess that if the second-to-last
level is unaligned, the last level would also be unaligned.

We never use fast clear for non-zero level. For now, we only have to make
sure that level 0 is contiguous.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Nicolai Hähnle]

On 17.04.2018 02:41, Marek Olšák wrote:

From: Marek Olšák 

---
  src/amd/common/ac_surface.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 7558dd91e34..c209b209da2 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -344,24 +344,36 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
AddrDccIn->tileInfo = *AddrSurfInfoOut->pTileInfo;
AddrDccIn->tileIndex = AddrSurfInfoOut->tileIndex;
AddrDccIn->macroModeIndex = AddrSurfInfoOut->macroModeIndex;
  
  		ret = AddrComputeDccInfo(addrlib,

 AddrDccIn,
 AddrDccOut);
  
  		if (ret == ADDR_OK) {

surf_level->dcc_offset = surf->dcc_size;
-   surf_level->dcc_fast_clear_size = 
AddrDccOut->dccFastClearSize;
surf->num_dcc_levels = level + 1;
surf->dcc_size = surf_level->dcc_offset + 
AddrDccOut->dccRamSize;
surf->dcc_alignment = MAX2(surf->dcc_alignment, 
AddrDccOut->dccRamBaseAlign);
+
+   /* If the DCC size of a subresource (1 mip level or 1 
slice)
+* is not aligned, the DCC memory layout is not 
contiguous for
+* that subresource, which means we can't use fast 
clear.
+*
+* We only do fast clears for whole mipmap levels. If 
we did
+* per-slice fast clears, the same restriction would 
apply.
+* (i.e. only compute the slice size and see if it's 
aligned)
+*/
+   if (level == config->info.levels - 1 || 
AddrDccOut->dccRamSizeAligned)


Are you sure that the last level is always okay? It seems possible that 
the last and second-to-last level end up interleaved due to swizzling.


The catch is that you'd probably only ever notice this with a truncated 
mip-tree.


Thanks,
Nicolai



+   surf_level->dcc_fast_clear_size = 
AddrDccOut->dccFastClearSize;
+   else
+   surf_level->dcc_fast_clear_size = 0;
}
}
  
  	/* TC-compatible HTILE. */

if (!is_stencil &&
AddrSurfInfoIn->flags.depth &&
surf_level->mode == RADEON_SURF_MODE_2D &&
level == 0) {
AddrHtileIn->flags.tcCompatible = 
AddrSurfInfoIn->flags.tcCompatible;
AddrHtileIn->pitch = AddrSurfInfoOut->pitch;




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Marek Olšák]

From: Marek Olšák 

---
 src/amd/common/ac_surface.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 7558dd91e34..c209b209da2 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -344,24 +344,36 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
AddrDccIn->tileInfo = *AddrSurfInfoOut->pTileInfo;
AddrDccIn->tileIndex = AddrSurfInfoOut->tileIndex;
AddrDccIn->macroModeIndex = AddrSurfInfoOut->macroModeIndex;
 
ret = AddrComputeDccInfo(addrlib,
 AddrDccIn,
 AddrDccOut);
 
if (ret == ADDR_OK) {
surf_level->dcc_offset = surf->dcc_size;
-   surf_level->dcc_fast_clear_size = 
AddrDccOut->dccFastClearSize;
surf->num_dcc_levels = level + 1;
surf->dcc_size = surf_level->dcc_offset + 
AddrDccOut->dccRamSize;
surf->dcc_alignment = MAX2(surf->dcc_alignment, 
AddrDccOut->dccRamBaseAlign);
+
+   /* If the DCC size of a subresource (1 mip level or 1 
slice)
+* is not aligned, the DCC memory layout is not 
contiguous for
+* that subresource, which means we can't use fast 
clear.
+*
+* We only do fast clears for whole mipmap levels. If 
we did
+* per-slice fast clears, the same restriction would 
apply.
+* (i.e. only compute the slice size and see if it's 
aligned)
+*/
+   if (level == config->info.levels - 1 || 
AddrDccOut->dccRamSizeAligned)
+   surf_level->dcc_fast_clear_size = 
AddrDccOut->dccFastClearSize;
+   else
+   surf_level->dcc_fast_clear_size = 0;
}
}
 
/* TC-compatible HTILE. */
if (!is_stencil &&
AddrSurfInfoIn->flags.depth &&
surf_level->mode == RADEON_SURF_MODE_2D &&
level == 0) {
AddrHtileIn->flags.tcCompatible = 
AddrSurfInfoIn->flags.tcCompatible;
AddrHtileIn->pitch = AddrSurfInfoOut->pitch;
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev