[Mesa-dev] [PATCH 01/12] i965/rbc: Allow integer formats as advertised in isl_format.c
Jason Ekstrand
jason at jlekstrand.net
Fri Sep 2 14:59:15 UTC 2016
On Sep 2, 2016 3:07 AM, "Pohjolainen, Topi" <topi.pohjolainen at gmail.com>
wrote:
>
> On Fri, Sep 02, 2016 at 08:34:27AM +0300, Pohjolainen, Topi wrote:
> > On Thu, Sep 01, 2016 at 02:33:48PM -0700, Jason Ekstrand wrote:
> > > On Wed, Aug 31, 2016 at 8:17 AM, Topi Pohjolainen
> > > <[1]topi.pohjolainen at intel.com> wrote:
> > >
> > > From: Topi Pohjolainen <[2]topi.pohjolainen at gmail.com>
> > > Blorp consults brw_is_color_fast_clear_compatible() to see if any
> > > restrictions apply for fast clear in addition to the capablities
> > > advertised in isl_format.c::format_info[]. On Gen8+ integer
formats
> > > are backlisted for plain old fast clear but there is no reason
why
> > > lossless compression shouldn't be supported. In fact, lossless
> > > compression of integer formats is already supported for normal
> > > render paths.
> > > This patch prepares for dropping the delayed allocating of the
mcs
> > > buffer for lossless compression. Until now the skip of fast clear
> > > also prevented the mcs being allocated and hence the lossless
> > > compression being effectively turned off for integer formats.
> > > Once the mcs buffer is allocated beforehand, the assertion
addressed
> > > here would start triggering.
> > > Signed-off-by: Topi Pohjolainen <[3]topi.pohjolainen at intel.com>
> > > ---
> > > src/mesa/drivers/dri/i965/brw_blorp.c | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> > > b/src/mesa/drivers/dri/i965/brw_blorp.c
> > > index c902f2e..7e257e9 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > > @@ -761,8 +761,12 @@ do_single_blorp_clear(struct brw_context
*brw,
> > > struct gl_framebuffer *fb,
> > > /* Compressed buffers can be cleared also using normal
> > > rep-clear. In
> > > * such case they bahave such as if they were drawn
using
> > > normal 3D
> > > * render pipeline, and we simply mark the mcs as
dirty.
> > > + *
> > > + * Fast clear of integer formats is not supported on
> > > Gen8+. See
> > > + * brw_is_color_fast_clear_compatible(). This, however,
> > > doesn't
> > > + * prevent lossless compression on Gen9+.
> > > */
> > > - assert(partial_clear);
> > > + assert(partial_clear || _mesa_is_format_integer_color(
> > > format));
> > >
> > > How about assert(isl_format_supports_lossless_compression())?
> >
> > Instead of _mesa_is_format_integer_color()? Sounds good to me.
>
> Well, I suppose we could just drop the assert? This is in a conditional
> block:
Yeah, really the code that's protected by the assert has nothing to do with
fast clears. Instead, it's just "you rendered into a compressed render
target with compression, flag it as unresolved". We probably need similar
code in brw_blorp_blit_miptrees of we don't have it already.
> if (intel_miptree_is_lossless_compressed(brw, irb->mt)) {
> /* Compressed buffers can be cleared also using normal
rep-clear. In
> * such case they bahave such as if they were drawn using normal
3D
> * render pipeline, and we simply mark the mcs as dirty.
> *
> * Fast clear of integer formats is not supported on Gen8+. See
> * brw_is_color_fast_clear_compatible(). This, however, doesn't
> * prevent lossless compression on Gen9+.
> */
> assert(partial_clear || _mesa_is_format_integer_color(format));
>
> >
> > >
> > > irb->mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_
> > > UNRESOLVED;
> > > }
> > > }
> > > --
> > > 2.5.5
> > > _______________________________________________
> > > mesa-dev mailing list
> > > [4]mesa-dev at lists.freedesktop.org
> > > [5]https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > >
> > > References
> > >
> > > 1. mailto:topi.pohjolainen at intel.com
> > > 2. mailto:topi.pohjolainen at gmail.com
> > > 3. mailto:topi.pohjolainen at intel.com
> > > 4. mailto:mesa-dev at lists.freedesktop.org
> > > 5. https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160902/af852205/attachment.html>
More information about the mesa-dev
mailing list