From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chad Versace Subject: Re: [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled Date: Mon, 18 Jul 2011 14:05:12 -0700 Message-ID: <4E24A008.3010802@chad-versace.us> References: <1310975703-20269-1-git-send-email-chad@chad-versace.us> <1310975703-20269-3-git-send-email-chad@chad-versace.us> <87aacbwpih.fsf@eliezer.anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1801499493==" Return-path: In-Reply-To: <87aacbwpih.fsf@eliezer.anholt.net> 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: Eric Anholt 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) --===============1801499493== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1BA10BA1A73498907EE5E6FE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1BA10BA1A73498907EE5E6FE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/18/2011 08:57 AM, Eric Anholt wrote: > On Mon, 18 Jul 2011 00:55:03 -0700, Chad Versace = wrote: >> diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers= /dri/intel/intel_fbo.c >> index 1669af2..507cc33 100644 >> --- a/src/mesa/drivers/dri/intel/intel_fbo.c >> +++ b/src/mesa/drivers/dri/intel/intel_fbo.c >> @@ -173,6 +173,9 @@ intel_alloc_renderbuffer_storage(struct gl_context= * ctx, struct gl_renderbuffer >> =20 >> if (irb->Base.Format =3D=3D MESA_FORMAT_S8) { >> /* >> + * The stencil buffer is W tiled. However, we request from the = kernel a >> + * non-tiled buffer because the GTT is incapable of W fencing. >> + * >> * The stencil buffer has quirky pitch requirements. From Vol = 2a, >> * 11.5.6.2.1 3DSTATE_STENCIL_BUFFER, field "Surface Pitch": >> * The pitch must be set to 2x the value computed based on w= idth, as >> @@ -180,14 +183,14 @@ intel_alloc_renderbuffer_storage(struct gl_conte= xt * ctx, struct gl_renderbuffer >> * 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 oc= curs. >> */ >> irb->region =3D intel_region_alloc(intel->intelScreen, >> - I915_TILING_Y, >> + I915_TILING_NONE, >> cpp * 2, >> - width, >> - height / 2, >> + ALIGN(width, 64), >> + /* XXX: Maybe align to 128? */ >> + ALIGN(height / 2, 64), >> GL_TRUE); >> if (!irb->region) >> return false; >=20 > This looks like it would fail on a buffer with height =3D 129. Doesn't= > seem like 128 pitch requirement would be needed -- has it been tested? >=20 >> diff --git a/src/mesa/drivers/dri/intel/intel_span.c b/src/mesa/driver= s/dri/intel/intel_span.c >> index 153803f..d306432 100644 >> --- a/src/mesa/drivers/dri/intel/intel_span.c >> +++ b/src/mesa/drivers/dri/intel/intel_span.c >> @@ -131,38 +131,77 @@ intel_set_span_functions(struct intel_context *i= ntel, >> int miny =3D 0; \ >> int maxx =3D rb->Width; \ >> int maxy =3D rb->Height; \ >> - int stride =3D rb->RowStride; \ >> - uint8_t *buf =3D rb->Data; \ >> + \ >> + /* \ >> + * Here we ignore rb->Data and rb->RowStride as set by \ >> + * intelSpanRenderStart. Since intel_offset_S8 decodes the W tile = \ >> + * manually, the region's *real* base address and stride is \ >> + * required. \ >> + */ \ >> + struct intel_renderbuffer *irb =3D intel_renderbuffer(rb); \ >> + uint8_t *buf =3D irb->region->buffer->virtual; \ >> + unsigned stride =3D irb->region->pitch; \ >> + unsigned height =3D 2 * irb->region->height; \ >> + bool flip =3D rb->Name =3D=3D 0; \ >> =20 >> -/* Don't flip y. */ >> #undef Y_FLIP >> -#define Y_FLIP(y) y >> +#define Y_FLIP(y) ((1 - flip) * y + flip * (height - 1 - y)) >=20 > The flip is usually handled by a scale and bias variable, so that Y_FLI= P > is ((y) * scale + bias). I think it'll produce less code, since Y_FLIP= > is used a lot. Good call. Does changing the hunk like this look good to you? + struct intel_renderbuffer *irb =3D intel_renderbuffer(rb); \ + uint8_t *buf =3D irb->region->buffer->virtual; \ + unsigned stride =3D irb->region->pitch; \ + unsigned height =3D 2 * irb->region->height; \ + bool flip =3D rb->Name =3D=3D 0; \ + int y_scale =3D flip ? -1 : 1; \ + int y_bias =3D flip ? (height - 1) : 0; \ -/* Don't flip y. */ #undef Y_FLIP -#define Y_FLIP(y) y +#define Y_FLIP(y) (y_scale * (y) + y_bias) --=20 Chad Versace chad@chad-versace.us --------------enig1BA10BA1A73498907EE5E6FE 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/ iQIcBAEBAgAGBQJOJKAIAAoJEAIvNt057x8imy8P/0QrzB/YyWVCAyvgCGSJNvvm f5VJ5iPXWTS5tTeSfPpOAp0Ujk2cGIlD03X/5+RJrwhKWmOKeFD863bLpRDp4Yvk iR9rYDAdOPDcNjr2UM49xdo7f4Tr1ABddPbXnIR29dHq8/s8gPpJrvoLRY+hlv7i laJqAtRzyXBQuRxP5ydpzyE7x0hP8O9DQJITqw5RfpG5p4QcD/LLoQaPrE4WnWbI lU2JbVrQhj/rPVMrOdoAifQdM3IfYAuFuZkGDIZXkl/cgyORAkf+JEJPH4Ule2mp q2NYHuws6Z7KS5JmK4niXMCtF3q4JUjlqqVK0XW1n4T+1EzCiuAwKQu3S0rzNHA5 bmcjnNQ3Q6otY5O8MlxjSbvBzisSK/hOpxu+DB4UkBh00LEwgxcOLm2FUK34SuOK h3NsUlyD5LuVoUtE2F59IW2fFMjoqVNhmaUu85V28l2SEKlspRsuX2MZHjBXdZ2V Q+YsoyBYaE9iQDisfo8TPYtYgC3ZBVwaTr7TV4weLCygFnoUDX1H4Oh7mgWQbmox r/WJ3yVSHXAKBUoiLsF3gKP2T31DPI6qKEa7BGdDnWWeGDWDNbQkQ2oex8c1HLP5 Fz/kaY8NNcZssvWzmuK8+T4WUg3L9O505kpbSYaNs9kZuAqtteei/B802JbCycQW Pf26YgHiUj+Za+CiNKGP =loXM -----END PGP SIGNATURE----- --------------enig1BA10BA1A73498907EE5E6FE-- --===============1801499493== 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 --===============1801499493==--