On 24 January 2013 13:59, Eric Anholt wrote:
> Paul Berry writes:
>
> > Yeah, you're right. I was being lazy. How's this:
>
> > * Furthermore, intelEmitCopyBlit (which is called by
> > * intel_miptree_map_blit) uses a signed 16-bit integer to represent
> > buffer
> > * pitch, so it
Paul Berry writes:
> Yeah, you're right. I was being lazy. How's this:
> * 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 r
On 01/24/2013 02:10 PM, Paul Berry 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
Paul Berry writes:
> 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 d
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 w
On Thu, Jan 24, 2013 at 2:10 PM, Paul Berry 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
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
