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

[Chris Wilson]

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.
-Chris