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.
*/
On 24 January 2013 11:22, Alex Deucher <alexdeuc...@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 2:10 PM, Paul Berry <stereotype...@gmail.com>
> 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) {
>
> You may want to put a comment here about why you have this pitch check.
>
> Alex
>
> > intel_miptree_map_blit(intel, mt, map, level, slice);
> > } else {
> > intel_miptree_map_gtt(intel, mt, map, level, slice);
> > --
> > 1.8.1.1
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
