[Mesa-dev] [PATCH] dri: Do not tile stencil buffer

Chad Versace chad at chad-versace.us
Mon Jul 18 12:28:49 PDT 2011


On 07/18/2011 11:45 AM, Ian Romanick wrote:
> On 07/18/2011 12:55 AM, Chad Versace wrote:
>> Until now, the stencil buffer was allocated as a Y tiled buffer, because
>> in several locations the PRM states that it is. However, it is actually
>> W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part 2, Section
>> 4.5.2.1 W-Major Format:
>>     W-Major Tile Format is used for separate stencil.
> 
>> The GTT is incapable of W fencing, so we allocate the stencil buffer with
>> I915_TILING_NONE and decode the tile's layout in software.
> 
>> This commit mutually depends on the mesa commit:
>>     intel: Fix stencil buffer to be W tiled
>>     Author: Chad Versace <chad at chad-versace.us>
>>     Date:   Mon Jul 18 00:37:45 2011 -0700
> 
>> CC: Eric Anholt <eric at anholt.net>
>> CC: Kenneth Graunke <kenneth at whitecape.org>
>> Signed-off-by: Chad Versace <chad at chad-versace.us>
>> ---
>>  src/intel_dri.c |   16 ++++++++++++----
>>  1 files changed, 12 insertions(+), 4 deletions(-)
> 
>> diff --git a/src/intel_dri.c b/src/intel_dri.c
>> index 5ea7c2c..4652dc7 100644
>> --- a/src/intel_dri.c
>> +++ b/src/intel_dri.c
>> @@ -336,7 +336,6 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int attachment,
>>  			switch (attachment) {
>>  			case DRI2BufferDepth:
>>  			case DRI2BufferDepthStencil:
>> -			case DRI2BufferStencil:
>>  			case DRI2BufferHiz:
>>  				if (SUPPORTS_YTILING(intel)) {
>>  					hint |= INTEL_CREATE_PIXMAP_TILING_Y;
>> @@ -351,6 +350,14 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int attachment,
>>  			case DRI2BufferFrontRight:
>>  				hint |= INTEL_CREATE_PIXMAP_TILING_X;
>>  				break;
>> +			case DRI2BufferStencil:
>> +				/*
>> +				 * The stencil buffer is W tiled. However, we
>> +				 * request from the kernel a non-tiled buffer
>> +				 * because the GTT is incapable of W fencing.
>> +				 */
>> +				hint |= INTEL_CREATE_PIXMAP_TILING_NONE;
>> +				break;
>>  			default:
>>  				free(privates);
>>  				free(buffer);
> 
> Eh... it seems like this will break compatibility with older versions of
> Mesa.  I haven't dug around, but there used to be a hack in DRI2 where a
> client would request a depth buffer and a stencil buffer, but it would
> get the same packed depth-stencil buffer for both.  I guess that might
> all be up in the DRI2 layer and not in the driver...

The 'case DRI2BufferStencil' modified in this hunk was added by me when implementing
separate stencil support. It was never used for this hack.

That hack is implemented by an alternate definition of I830DRI2CreateBuffer() which
is ifdef'd out when DRI2INFOREC_VERSION >= 2. FYI, the line that implements the hack can
be found by grepping xf86-video-intel:src/intel_dri.c for
    } else if (attachments[i] == DRI2BufferStencil && pDepthPixmap) {

> 
>> @@ -368,11 +375,12 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int attachment,
>>  		 * To accomplish this, we resort to the nasty hack of doubling
>>  		 * the drm region's cpp and halving its height.
>>  		 *
>> -		 * If we neglect to double the pitch, then
>> -		 * drm_intel_gem_bo_map_gtt() maps the memory incorrectly.
>> +		 * If we neglect to double the pitch, then render corruption
>> +                 * occurs.
> 
> Mangled whitespace?  Probably mixed tabs and spaces...

Oops. Will fix.

> 
>>  		 */
>>  		if (attachment == DRI2BufferStencil) {
>> -			pixmap_height /= 2;
>> +			pixmap_width = ALIGN(pixmap_width, 64);
>> +			pixmap_height = ALIGN(pixmap_height / 2, 64);
>>  			pixmap_cpp *= 2;
>>  		}


-- 
Chad Versace
chad at chad-versace.us

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110718/ecb787f6/attachment.pgp>


More information about the mesa-dev mailing list