From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chad Versace Subject: Re: [Mesa-dev] [PATCH] dri: Do not tile stencil buffer Date: Mon, 18 Jul 2011 12:28:49 -0700 Message-ID: <4E248971.90805@chad-versace.us> References: <1310975703-20269-1-git-send-email-chad@chad-versace.us> <1310975703-20269-2-git-send-email-chad@chad-versace.us> <4E247F5D.3060106@freedesktop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1848823413==" Return-path: In-Reply-To: <4E247F5D.3060106@freedesktop.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Ian Romanick Cc: mesa-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1848823413== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B62ED230EAF9D4304BC5F9A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B62ED230EAF9D4304BC5F9A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, becau= se >> in several locations the PRM states that it is. However, it is actuall= y >> 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. >=20 >> The GTT is incapable of W fencing, so we allocate the stencil buffer w= ith >> I915_TILING_NONE and decode the tile's layout in software. >=20 >> This commit mutually depends on the mesa commit: >> intel: Fix stencil buffer to be W tiled >> Author: Chad Versace >> Date: Mon Jul 18 00:37:45 2011 -0700 >=20 >> CC: Eric Anholt >> CC: Kenneth Graunke >> Signed-off-by: Chad Versace >> --- >> src/intel_dri.c | 16 ++++++++++++---- >> 1 files changed, 12 insertions(+), 4 deletions(-) >=20 >> 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, unsigne= d int attachment, >> switch (attachment) { >> case DRI2BufferDepth: >> case DRI2BufferDepthStencil: >> - case DRI2BufferStencil: >> case DRI2BufferHiz: >> if (SUPPORTS_YTILING(intel)) { >> hint |=3D INTEL_CREATE_PIXMAP_TILING_Y; >> @@ -351,6 +350,14 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsign= ed int attachment, >> case DRI2BufferFrontRight: >> hint |=3D 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 |=3D INTEL_CREATE_PIXMAP_TILING_NONE; >> + break; >> default: >> free(privates); >> free(buffer); >=20 > Eh... it seems like this will break compatibility with older versions o= f > 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 i= mplementing separate stencil support. It was never used for this hack. That hack is implemented by an alternate definition of I830DRI2CreateBuff= er() which is ifdef'd out when DRI2INFOREC_VERSION >=3D 2. FYI, the line that implem= ents the hack can be found by grepping xf86-video-intel:src/intel_dri.c for } else if (attachments[i] =3D=3D DRI2BufferStencil && pDepthPixmap) {= >=20 >> @@ -368,11 +375,12 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsig= ned 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. >=20 > Mangled whitespace? Probably mixed tabs and spaces... Oops. Will fix. >=20 >> */ >> if (attachment =3D=3D DRI2BufferStencil) { >> - pixmap_height /=3D 2; >> + pixmap_width =3D ALIGN(pixmap_width, 64); >> + pixmap_height =3D ALIGN(pixmap_height / 2, 64); >> pixmap_cpp *=3D 2; >> } --=20 Chad Versace chad@chad-versace.us --------------enig3B62ED230EAF9D4304BC5F9A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOJIlxAAoJEAIvNt057x8iuiAP/RojK2tzHggr2M5vI/NLFei+ Cyk4xF9IcZCg+yH9R6RRnJa2jEn1bUF1RxBRLzPho80XwVzV8V3pntGfQmGGUe2x joRiBaPsbMYJzJZgNwYHQ4X21rDJycFIk5cftyscSF+3/pw7kNalUPcEhqfiOEVG iNViKI7y7j9jKeEczyeLgpIczpnu/ysbRgMqIL89h1Jkb0qmp1m738YLvrwP3+eF ZlLzSwfUxTf0XzJmicnknFzL5sn1XvJVFrX1p6tnxKqC06N/Q+h3Sr4ksjbNPC9o wrqSPH7F+BXucnInjcRHRbUBzF9gdvipuw11/oOQL9wvCVgmSR5Xp5/jvlwvY24j 7UxRJ+YARvqgXFS2hcwdGMRSnuLP+vqKx8FDjSIeF8Rw4ZcnXCOK5qbWEbf7XvXE G7RBHfYpt3ALuitLKCbUeianx4mqnblwggyfF8qrIGz+opzxY2i5o7nMMonTMtlo 3gYksvd78hZHWNkz59crpuYdq2V4drhv1nMSTKrnDgG3EV5bHixfO1Lo9HOFkR/E np7/FP40nEVYHZv4PW1mteeh+00UesEcZYUM8jvWnDWQyOCV6uWveRYKIKgO1RGU /81kDiiy3ZxklBqbUFHTQZIvgqgIWXb7/grZb7MFvlhN1sF1AiLCJ/uE59kt6JuX UJkEZ7m3Mpzy38iPtPWI =MbDf -----END PGP SIGNATURE----- --------------enig3B62ED230EAF9D4304BC5F9A-- --===============1848823413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1848823413==--