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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
