On Wed, Oct 21, 2020 at 6:09 PM Harry Wentland <harry.wentland@xxxxxxx> wrote:
>
> Even though log(0) is technically undefined our code assumes that
> log_2(0) is 0. This mirrors the current behavior of our log_2
> implementation on non-Linux platforms.
>
> Signed-off-by: Harry Wentland <harry.wentland@xxxxxxx>
> ---
>
> What's num_pkrs value is upstream Mesa providing for CHIP_VANGOGH?
So mesa isn't quite providing a num_pkrs value to the HW as the render
HW doesn't require you to set one, it assumes something.
In practice mesa still uses num_pkrs, which is provided by a readback
of the GB_ADDR_CFG(CONFIG?) register info provided by the kernel. This
can be used for e.g. determining texture coordinates (like we do for
the displayable DCC transform) but otherwise isn't really needed,
since the tile size for texture allocation is not dependent on
num_pkrs.
so outside of displayable DCC I think you'd be able to get far in mesa
with a wrong num_pkrs.
>
> I saw that problem at bringup with an internal Mesa and had this fix
> for it.
>
> Harry
>
> drivers/gpu/drm/amd/display/dc/basics/conversion.h | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/basics/conversion.h b/drivers/gpu/drm/amd/display/dc/basics/conversion.h
> index ade785c4fdc7..da9883ec7b1c 100644
> --- a/drivers/gpu/drm/amd/display/dc/basics/conversion.h
> +++ b/drivers/gpu/drm/amd/display/dc/basics/conversion.h
> @@ -40,7 +40,11 @@ void convert_float_matrix(
>
> static inline unsigned int log_2(unsigned int num)
> {
> - return ilog2(num);
> + /*
> + * Technically log(0) is undefined, but our code is structured
> + * in a way that assumes log(0) = 0
> + */
> + return num ? ilog2(num) : num;
> }
>
> #endif
> --
> 2.28.0
>
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
