[Mesa-dev] [PATCH 6/9] gallium: decrease the size of pipe_box - 24 -> 16 bytes

[Marek Olšák]

On Mon, Apr 3, 2017 at 11:28 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 03.04.2017 um 17:11 schrieb Alex Deucher:
>> On Sun, Apr 2, 2017 at 2:00 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>> From: Marek Olšák <marek.olsak at amd.com>
>>>
>>> Also:
>>>
>>> pipe_transfer: 48 -> 40 bytes.
>>> pipe_blit_info = 176 -> 160 bytes.
>>> ---
>>>  src/gallium/include/pipe/p_state.h | 8 ++++----
>>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/gallium/include/pipe/p_state.h b/src/gallium/include/pipe/p_state.h
>>> index 392bb8b..6a147ef 100644
>>> --- a/src/gallium/include/pipe/p_state.h
>>> +++ b/src/gallium/include/pipe/p_state.h
>>> @@ -472,25 +472,25 @@ struct pipe_image_view
>>>     } u;
>>>  };
>>>
>>>
>>>  /**
>>>   * Subregion of 1D/2D/3D image resource.
>>>   */
>>>  struct pipe_box
>>>  {
>>>     int x;
>>> -   int y;
>>> -   int z;
>>> +   int16_t y;
>>> +   int16_t z;
>>>     int width;
>>> -   int height;
>>> -   int depth;
>>> +   int16_t height;
>>> +   int16_t depth;
>>>  };
>>
>> Not specific to this patch per se, but will this cause any issues in
>> the future as max surface sizes supported by hw increase?  I feel like
>> we'll need to change this back at some point.
> I don't think this can increase easily. With 8 subpixel bits for
> rasterization (which is the standard nowadays) the absolute maximum you
> could theoretically support would be 64k when using float math, and there's
> probably reasons why you don't want to go quite to the aboluste limit.
> That said, with int16 the largest pot size possible would be 16k, which
> indeed is what everybody already supports, not leaving even a factor 2
> increase... So I'm not sure it's really a good idea.

We can always revert it. Until then, it's sufficient.

BTW, the maximum depth is 2K because render targets don't support more
on radeon.

Marek