[Mesa-dev] [PATCH] intel: Fix ReadPixels on buffers whose width >= 32kbytes

[Paul Berry]

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 <alexdeucher at gmail.com> wrote:

> On Thu, Jan 24, 2013 at 2:10 PM, Paul Berry <stereotype441 at 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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130124/17b2c392/attachment.html>