[Mesa-dev] [PATCH 1/2] blorp: Don't try to use R32_UNORM for R24_UNORM_X8_TYPELESS rendering.

[Jason Ekstrand]

On August 10, 2018 13:25:04 Kenneth Graunke <kenneth at whitecape.org> wrote:

> On Friday, August 10, 2018 8:34:12 AM PDT Jason Ekstrand wrote:
>> On August 10, 2018 03:19:18 Kenneth Graunke <kenneth at whitecape.org> wrote:
>>
>>> The hardware doesn't support rendering to R24_UNORM_X8_TYPELESS, so
>>> Jason decided to fake it with a bit of shader math and R32_UNORM RTs.
>>>
>>> The only problem is that R32_UNORM isn't renderable either...so we've
>>> just traded one bad format for another.
>>>
>>> This patch makes us use R32_UINT instead.
>>> ---
>>> src/intel/blorp/blorp_blit.c | 11 ++++++-----
>>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
>>> index c85ec8543a9..7b49f9afa35 100644
>>> --- a/src/intel/blorp/blorp_blit.c
>>> +++ b/src/intel/blorp/blorp_blit.c
>>> @@ -984,14 +984,15 @@ convert_color(struct nir_builder *b, nir_ssa_def *color,
>>> nir_ssa_def *value;
>>>
>>> if (key->dst_format == ISL_FORMAT_R24_UNORM_X8_TYPELESS) {
>>> -      /* The destination image is bound as R32_UNORM but the data needs to be
>>> +      /* The destination image is bound as R32_UINT but the data needs to be
>>> * in R24_UNORM_X8_TYPELESS.  The bottom 24 are the actual data and the
>>> * top 8 need to be zero.  We can accomplish this by simply multiplying
>>> * by a factor to scale things down.
>>> */
>>> -      float factor = (float)((1 << 24) - 1) / (float)UINT32_MAX;
>>> -      value = nir_fmul(b, nir_fsat(b, nir_channel(b, color, 0)),
>>> -                          nir_imm_float(b, factor));
>>> +      unsigned factor = (1 << 24) - 1;
>>> +      value = nir_fsat(b, nir_channel(b, color, 0));
>>> +      value = nir_fmul(b, value, nir_imm_float(b, factor));
>>> +      value = nir_iand(b, nir_f2i32(b, value), nir_imm_int(b, factor));
>>
>> Do we really need the and?
>
> Probably not - without it, we'll just leave garbage in the X8 bits
> instead of zeroing them.  But that's probably fine, unless it affects
> HiZ compression somehow?  I was mostly borrowing from u_format_zs.c
> code to do this without thinking too hard.

That would only matter of mul(sat(x), factor) produces something outside 
the range [0, factor+1). I really don't think it's doing anything useful.

--Jason