On Mon, Jun 18, 2018 at 03:42:13PM -0700, Nanley Chery wrote: > 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. >
I think I figured out how to properly test the series on the CI for the stable branch. Everything looks good, so I'll send it out soon. -Nanley > -Nanley > > > -Chris _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev