On Mon, Apr 3, 2017 at 11:28 PM, Roland Scheidegger <[email protected]> wrote: > Am 03.04.2017 um 17:11 schrieb Alex Deucher: >> On Sun, Apr 2, 2017 at 2:00 PM, Marek Olšák <[email protected]> wrote: >>> From: Marek Olšák <[email protected]> >>> >>> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
