[Mesa-dev] [PATCH] [RFC] i965/blit: bump some limits to 64k

[Nanley Chery]

On Thu, Jun 14, 2018 at 07:50:54PM +0100, Chris Wilson wrote:
> Quoting Nanley Chery (2018-06-14 19:46:09)
> > On Thu, Jun 14, 2018 at 10:01:18AM -0700, Nanley Chery wrote:
> > > On Thu, Jun 14, 2018 at 04:18:30PM +0300, Martin Peres wrote:
> > > > This fixes screenshots using 8k+ wide display setups in modesetting.
> > > > 
> > > > Chris Wilson even recommended the changes in intel_mipmap_tree.c
> > > > should read 131072 instead of 65535, but I for sure got confused by
> > > > his explanation.
> > > > 
> > > > In any case, I would like to use this RFC patch as a forum to discuss
> > > > why the fallback path is broken[1], and as to what should be the
> > > > limits for HW-accelerated blits now that we got rid of the blitter
> > > > usage on recent platforms.
> > > > 
> > > 
> > > Hi,
> > > 
> > > My understanding is that the fallback path is broken because we silently
> > > ignore miptree_create_for_bo's request for a tiled miptree. This results
> > > in some parts of mesa treating the surface as tiled and other parts of
> > > treating the surface as linear.
> > > 
> > > I couldn't come up with a piglit test for this when I was working on a
> > > fix. Please let me know if you can think of any.
> > > 
> > > I think what the limits should be depends on which mesa branch you're
> > > working off of.
> > > 
> > > * On the master branch of mesa, which has some commits which reduce the
> > >   dependence on the BLT engine, we can remove these limits by using BLORP.
> > >   As much as I can tell, BLORP can handle images as wide as the surface
> > >   pitch limit in the RENDER_SURFACE_STATE packet will allow.
> > > 
> > >   I sent out a series [a] a couple weeks ago that removes the limits
> > >   imposed by the hardware blitter.
> > > 
> > > * On the stable branch however, we can modify some incorrect code to set
> > >   the correct BLT limits (as Chris has suggested). The BLT engine's pitch
> > >   field is a signed 16bit integer, whose unit changes depending on the
> > >   tiling of the surface. For linear surfaces, it's in units of bytes and
> > >   for non-linear surfaces, it's in units of dwords. This translates to
> > >   2^15-1 bytes or (2^15-1) * 4 bytes respectively.
> > >   
> > >   I made a branch [b] which does this already, but I think my rebasing +
> > >   testing strategy for stable branches on the CI might be incorrect.
> > 
> > I just rebased this branch onto master and tested it on the CI.
> > Everything passes except for SNB. I get 1 GPU hang and two test
> > failures:
> > * failure-gpu-hang-otc-gfxtest-snbgt1-01-snbm64.compile.error
> > * KHR-GL33.shaders.uniform_block.random.all_shared_buffer.3.snbm64
> > * dEQP-EGL.functional.color_clears.multi_context.gles3.rgba8888_pbuffer.snbm64
> 
> What are the command lines? Assuming piglit, which the last one doesn't
> appear to be, I can try, see what happens, and see if I can be of
> assistance.

I'm not sure how to run these tests with piglit... Also, when running
the last test by itself, I don't get a GPU hang. I'm assuming an unknown
test is causing others to fail. The CI does say the hanging test is
GTF-GL33.gtf21.GL.build.dvec4_frag, but I'm not sure how to run it to
confirm it.

-Nanley

> -Chris