[Mesa-dev] [PATCH 3/5] radv: remove some members of radeon surface.
Dave Airlie
airlied at gmail.com
Tue May 2 04:34:15 UTC 2017
On 2 May 2017 at 14:18, Timothy Arceri <tarceri at itsqueeze.com> wrote:
>
>
> On 02/05/17 10:22, Dave Airlie wrote:
>>
>> From: Dave Airlie <airlied at redhat.com>
>>
>> We would be storing this info twice per image, no need to,
>> remove it from the surface struct.
>>
>> Signed-off-by: Dave Airlie <airlied at redhat.com>
>> ---
>> src/amd/vulkan/radv_cmd_buffer.c | 2 +-
>> src/amd/vulkan/radv_image.c | 19 +++----
>> src/amd/vulkan/radv_radeon_winsys.h | 7 +--
>> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c | 60
>> ++++++++++++----------
>> 4 files changed, 40 insertions(+), 48 deletions(-)
>>
>> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
>> b/src/amd/vulkan/radv_cmd_buffer.c
>> index 198c599..d165512 100644
>> --- a/src/amd/vulkan/radv_cmd_buffer.c
>> +++ b/src/amd/vulkan/radv_cmd_buffer.c
>> @@ -966,7 +966,7 @@ static void radv_set_optimal_micro_tile_mode(struct
>> radv_device *device,
>> {
>> struct radv_image *image = att->attachment->image;
>> uint32_t tile_mode_index;
>> - if (image->surface.nsamples <= 1)
>> + if (image->info.samples <= 1)
>> return;
>> if (image->surface.micro_tile_mode != micro_tile_mode) {
>> diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
>> index cd278ed..24f3620 100644
>> --- a/src/amd/vulkan/radv_image.c
>> +++ b/src/amd/vulkan/radv_image.c
>> @@ -67,22 +67,16 @@ radv_init_surface(struct radv_device *device,
>> is_depth = vk_format_has_depth(desc);
>> is_stencil = vk_format_has_stencil(desc);
>> - surface->npix_x = pCreateInfo->extent.width;
>> - surface->npix_y = pCreateInfo->extent.height;
>> - surface->npix_z = pCreateInfo->extent.depth;
>> surface->blk_w = vk_format_get_blockwidth(pCreateInfo->format);
>> surface->blk_h = vk_format_get_blockheight(pCreateInfo->format);
>> surface->blk_d = 1;
>> - surface->array_size = pCreateInfo->arrayLayers;
>> - surface->last_level = pCreateInfo->mipLevels - 1;
>> surface->bpe = vk_format_get_blocksize(pCreateInfo->format);
>> /* align byte per element on dword */
>> if (surface->bpe == 3) {
>> surface->bpe = 4;
>> }
>> - surface->nsamples = pCreateInfo->samples ? pCreateInfo->samples :
>> 1;
>> surface->flags = RADEON_SURF_SET(array_mode, MODE);
>> switch (pCreateInfo->imageType){
>> @@ -467,14 +461,13 @@ radv_image_get_fmask_info(struct radv_device
>> *device,
>> {
>> /* FMASK is allocated like an ordinary texture. */
>> struct radeon_surf fmask = image->surface;
>> -
>> + struct radeon_surf_info info = image->info;
>> memset(out, 0, sizeof(*out));
>> fmask.bo_alignment = 0;
>> fmask.bo_size = 0;
>> - fmask.nsamples = 1;
>> fmask.flags |= RADEON_SURF_FMASK;
>> -
>> + info.samples = 1;
>> /* Force 2D tiling if it wasn't set. This may occur when creating
>> * FMASK for MSAA resolve on R6xx. On R6xx, the single-sample
>> * destination buffer must have an FMASK too. */
>> @@ -495,7 +488,7 @@ radv_image_get_fmask_info(struct radv_device *device,
>> return;
>> }
>> - device->ws->surface_init(device->ws, &fmask);
>> + device->ws->surface_init(device->ws, &info, &fmask);
>> assert(fmask.level[0].mode == RADEON_SURF_MODE_2D);
>> out->slice_tile_max = (fmask.level[0].nblk_x *
>> fmask.level[0].nblk_y) / 64;
>> @@ -553,8 +546,8 @@ radv_image_get_cmask_info(struct radv_device *device,
>> unsigned base_align = num_pipes * pipe_interleave_bytes;
>> - unsigned width = align(image->surface.npix_x, cl_width*8);
>> - unsigned height = align(image->surface.npix_y, cl_height*8);
>> + unsigned width = align(image->info.width, cl_width*8);
>> + unsigned height = align(image->info.height, cl_height*8);
>> unsigned slice_elements = (width * height) / (8*8);
>> /* Each element of CMASK is a nibble. */
>> @@ -656,7 +649,7 @@ radv_image_create(VkDevice _device,
>> radv_init_surface(device, &image->surface, create_info);
>> - device->ws->surface_init(device->ws, &image->surface);
>> + device->ws->surface_init(device->ws, &image->info,
>> &image->surface);
>
>
> Maybe change this to just take image as a param?
We don't want to use vulkan types in the winsys, at least so far we've
avoided it,
I'm not sure if that is a goal we have to care about, we had vague intentions of
sharing some of this code, but it doesn't look like good value.
Dave.
More information about the mesa-dev
mailing list