On Tue, Feb 20, 2018 at 11:31:08AM -0800, Jason Ekstrand wrote:
> On Tue, Feb 20, 2018 at 11:26 AM, Jason Ekstrand <ja...@jlekstrand.net>
> wrote:
>
> > On Tue, Feb 20, 2018 at 11:25 AM, Nanley Chery <nanleych...@gmail.com>
> > wrote:
> >
> >> On Fri, Feb 16, 2018 at 09:28:43AM -0800, Jason Ekstrand wrote:
> >> > ---
> >> > src/intel/vulkan/anv_formats.c | 9 +++++++
> >> > src/intel/vulkan/anv_image.c | 53 ++++++++++++++++++++++++++----
> >> ------------
> >> > 2 files changed, 42 insertions(+), 20 deletions(-)
> >> >
> >> > diff --git a/src/intel/vulkan/anv_formats.c
> >> b/src/intel/vulkan/anv_formats.c
> >> > index 9c52ad5..3c17366 100644
> >> > --- a/src/intel/vulkan/anv_formats.c
> >> > +++ b/src/intel/vulkan/anv_formats.c
> >> > @@ -671,9 +671,18 @@ get_wsi_format_modifier_properties_list(const
> >> struct anv_physical_device *physic
> >> > DRM_FORMAT_MOD_LINEAR,
> >> > I915_FORMAT_MOD_X_TILED,
> >> > I915_FORMAT_MOD_Y_TILED,
> >> > + I915_FORMAT_MOD_Y_TILED_CCS,
> >> > };
> >> >
> >> > for (uint32_t i = 0; i < ARRAY_SIZE(modifiers); i++) {
> >> > + const struct isl_drm_modifier_info *mod_info =
> >> > + isl_drm_modifier_get_info(modifiers[i]);
> >> > +
> >> > + if (mod_info->aux_usage == ISL_AUX_USAGE_CCS_E &&
> >> > + !isl_format_supports_ccs_e(&physical_device->info,
> >> > + anv_format->planes[0].isl_for
> >> mat))
> >> > + continue;
> >> > +
> >> > vk_outarray_append(&out, mod_props) {
> >> > mod_props->modifier = modifiers[i];
> >> > if (isl_drm_modifier_has_aux(modifiers[i]))
> >> > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> >> > index a2bae7b..d7c2e55 100644
> >> > --- a/src/intel/vulkan/anv_image.c
> >> > +++ b/src/intel/vulkan/anv_image.c
> >> > @@ -515,6 +515,7 @@ score_drm_format_mod(uint64_t modifier)
> >> > case DRM_FORMAT_MOD_LINEAR: return 1;
> >> > case I915_FORMAT_MOD_X_TILED: return 2;
> >> > case I915_FORMAT_MOD_Y_TILED: return 3;
> >> > + case I915_FORMAT_MOD_Y_TILED_CCS: return 4;
> >> > default: unreachable("bad DRM format modifier");
> >> > }
> >> > }
> >> > @@ -746,8 +747,13 @@ void anv_GetImageSubresourceLayout(
> >> > VkSubresourceLayout* layout)
> >> > {
> >> > ANV_FROM_HANDLE(anv_image, image, _image);
> >> > - const struct anv_surface *surface =
> >> > - get_surface(image, subresource->aspectMask);
> >> > +
> >> > + const struct anv_surface *surface;
> >> > + if (subresource->aspectMask == VK_IMAGE_ASPECT_PLANE_1_BIT_KHR &&
> >> > + isl_drm_modifier_has_aux(image->drm_format_mod))
> >> > + surface = &image->planes[0].aux_surface;
> >> > + else
> >> > + surface = get_surface(image, subresource->aspectMask);
> >> >
> >> > assert(__builtin_popcount(subresource->aspectMask) == 1);
> >> >
> >> > @@ -862,25 +868,20 @@ anv_layout_to_aux_usage(const struct
> >> gen_device_info * const devinfo,
> >> > }
> >> >
> >> >
> >> > - case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR:
> >> > + case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR: {
> >> > assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
> >> >
> >> > - /* On SKL+, the render buffer can be decompressed by the
> >> presentation
> >> > - * engine. Support for this feature has not yet landed in the
> >> wider
> >> > - * ecosystem. TODO: Update this code when support lands.
> >> > - *
> >> > - * From the BDW PRM, Vol 7, Render Target Resolve:
> >> > - *
> >> > - * If the MCS is enabled on a non-multisampled render target,
> >> the
> >> > - * render target must be resolved before being used for other
> >> > - * purposes (display, texture, CPU lock) The clear value from
> >> > - * SURFACE_STATE is written into pixels in the render target
> >> > - * indicated as clear in the MCS.
> >> > - *
> >> > - * Pre-SKL, the render buffer must be resolved before being used
> >> for
> >> > - * presentation. We can infer that the auxiliary buffer is not
> >> used.
> >> > + /* When handing the image off to the presentation engine, we
> >> need to
> >> > + * ensure that things are properly resolved. For images with no
> >> > + * modifier, we assume that they follow the old rules and always
> >> need
> >> > + * a full resolve because the PE doesn't understand any form of
> >> > + * compression. For images with modifiers, we use the aux usage
> >> from
> >> > + * the modifier.
> >> > */
> >> > - return ISL_AUX_USAGE_NONE;
> >> > + const struct isl_drm_modifier_info *mod_info =
> >> > + isl_drm_modifier_get_info(image->drm_format_mod);
> >> > + return mod_info ? mod_info->aux_usage : ISL_AUX_USAGE_NONE;
> >> > + }
> >> >
> >> >
> >> > /* Rendering Layouts */
> >> > @@ -960,8 +961,20 @@ anv_layout_to_fast_clear_type(const struct
> >> gen_device_info * const devinfo,
> >> > case VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL:
> >> > return ANV_FAST_CLEAR_ANY;
> >> >
> >> > - case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR:
> >> > - return ANV_FAST_CLEAR_NONE;
> >> > + case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR: {
> >> > + assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
> >> > +
> >> > + /* When handing the image off to the presentation engine, we
> >> need to
> >> > + * ensure that things are properly resolved. For images with no
> >> > + * modifier, we assume that they follow the old rules and always
> >> need
> >> > + * a full resolve because the PE doesn't understand any form of
> >> > + * compression. For images with modifiers, we use the value
> >> from the
> >> > + * modifier.
> >> > + */
> >> > + const struct isl_drm_modifier_info *mod_info =
> >> > + isl_drm_modifier_get_info(image->drm_format_mod);
> >> > + return mod_info && mod_info->supports_clear_color;
> >>
> >> This should return an enum value, not a boolean, right?=
> >>
> >
> > Yup. Rebase fail. I'll rework and re-send.
> >
>
> It's worth noting that it doesn't actually matter today because we don't
> have any modifiers that support fast-clear. Maybe we should just leave it
> returning NONE?
>
It is also outside the scope of this patch, so I guess so.
-Nanley
>
> > -Nanley
> >>
> >> > + }
> >> >
> >> > default:
> >> > /* If the image has CCS_E enabled all the time then we can use
> >> > --
> >> > 2.5.0.400.gff86faf
> >> >
> >> > _______________________________________________
> >> > mesa-dev mailing list
> >> > mesa-dev@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >>
> >
> >
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
