<div dir="ltr">Yeah, you're right. I was being lazy. How's this: /* According to the Ivy Bridge PRM, Vol1 Part4, section 1.2.1.2 (Graphics * Data Size Limitations): * * The BLT engine is capable of transferring very large quantities of * graphics data. Any graphics data read from and written to the * destination is permitted to represent a number of pixels that * occupies up to 65,536 scan lines and up to 32,768 bytes per scan line * at the destination. The maximum number of pixels that may be * represented per scan line’s worth of graphics data depends on the * color depth. * * Furthermore, intelEmitCopyBlit (which is called by * intel_miptree_map_blit) uses a signed 16-bit integer to represent buffer * pitch, so it can only handle buffer pitches < 32k. * * As a result of these two limitations, we can only use * intel_miptree_map_blit() when the region's pitsh is less than 32k. */ </div><div class="gmail_extra"> <div class="gmail_quote">On 24 January 2013 11:22, Alex Deucher <<a href="mailto:alexdeucher@gmail.com" target="_blank">alexdeucher@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Jan 24, 2013 at 2:10 PM, Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> wrote: > When possible, glReadPixels calls are performed using the hardware > blitter. However, according to the Ivy Bridge PRM, Vol1 Part4, > section 1.2.1.2 (Graphics Data Size Limitations): > > The BLT engine is capable of transferring very large quantities of > graphics data. Any graphics data read from and written to the > destination is permitted to represent a number of pixels that > occupies up to 65,536 scan lines and up to 32,768 bytes per scan > line at the destination. The maximum number of pixels that may be > represented per scan line’s worth of graphics data depends on the > color depth. > > With an RGBA32F color buffer (which has 16 bytes per pixel) this > imposes a maximum width of 2048 pixels. > > To make matters worse, if the pitch of the buffer is 32k or greater, > intel_miptree_map_blit's call to intelEmitCopyBlit will overflow > intelEmitCopyBlit's src_pitch and dst_pitch parameters (which are > 16-bit signed integers). > > We can conveniently avoid both problems by avoiding the readpixels > blit path when the miptree's pitch is >= 32k. > > Fixes gles3conform "half_float" tests when the buffer width is greater > than 2048. > --- > src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c > index ce03afa..f2571bd 100644 > --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c > +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c > @@ -1568,7 +1568,8 @@ intel_miptree_map_singlesample(struct intel_context *intel, > } else if (intel->has_llc && > !(mode & GL_MAP_WRITE_BIT) && > !mt->compressed && > - mt->region->tiling == I915_TILING_X) { > + mt->region->tiling == I915_TILING_X && > + mt->region->pitch < 32768) { </div></div>You may want to put a comment here about why you have this pitch check. Alex <div class="im"> > intel_miptree_map_blit(intel, mt, map, level, slice); > } else { > intel_miptree_map_gtt(intel, mt, map, level, slice); > -- > 1.8.1.1 > </div>> _______________________________________________ > mesa-dev mailing list > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote></div> </div>