diff options
author | Paul Berry <[email protected]> | 2013-01-24 10:43:38 -0800 |
---|---|---|
committer | Paul Berry <[email protected]> | 2013-01-24 13:17:07 -0800 |
commit | b50c0feb2ccf3a4e1be8133405347ee3b49b05cf (patch) | |
tree | f55a690742aa40111fc8a4bc5bdd9d04ffb6ed9e /src/gallium/targets | |
parent | ac158f8ee78fd5902cfeb8712a72cfa4da7ef6f6 (diff) |
intel: Fix ReadPixels on buffers whose width >= 32kbytes
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.
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Ian Romanick <[email protected]>
Diffstat (limited to 'src/gallium/targets')
0 files changed, 0 insertions, 0 deletions