From: Chad Versace <chad@chad-versace.us>
To: Eric Anholt <eric@anholt.net>
Cc: mesa-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
Date: Mon, 18 Jul 2011 14:05:12 -0700 [thread overview]
Message-ID: <4E24A008.3010802@chad-versace.us> (raw)
In-Reply-To: <87aacbwpih.fsf@eliezer.anholt.net>
[-- Attachment #1.1: Type: text/plain, Size: 3922 bytes --]
On 07/18/2011 08:57 AM, Eric Anholt wrote:
> On Mon, 18 Jul 2011 00:55:03 -0700, Chad Versace <chad@chad-versace.us> 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
>>
>> if (irb->Base.Format == 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 width, as
>> @@ -180,14 +183,14 @@ intel_alloc_renderbuffer_storage(struct gl_context * 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 occurs.
>> */
>> irb->region = 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;
>
> This looks like it would fail on a buffer with height = 129. Doesn't
> seem like 128 pitch requirement would be needed -- has it been tested?
>
>> diff --git a/src/mesa/drivers/dri/intel/intel_span.c b/src/mesa/drivers/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 *intel,
>> int miny = 0; \
>> int maxx = rb->Width; \
>> int maxy = rb->Height; \
>> - int stride = rb->RowStride; \
>> - uint8_t *buf = 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 = intel_renderbuffer(rb); \
>> + uint8_t *buf = irb->region->buffer->virtual; \
>> + unsigned stride = irb->region->pitch; \
>> + unsigned height = 2 * irb->region->height; \
>> + bool flip = rb->Name == 0; \
>>
>> -/* Don't flip y. */
>> #undef Y_FLIP
>> -#define Y_FLIP(y) y
>> +#define Y_FLIP(y) ((1 - flip) * y + flip * (height - 1 - y))
>
> The flip is usually handled by a scale and bias variable, so that Y_FLIP
> 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 = intel_renderbuffer(rb); \
+ uint8_t *buf = irb->region->buffer->virtual; \
+ unsigned stride = irb->region->pitch; \
+ unsigned height = 2 * irb->region->height; \
+ bool flip = rb->Name == 0; \
+ int y_scale = flip ? -1 : 1; \
+ int y_bias = 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)
--
Chad Versace
chad@chad-versace.us
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2011-07-18 21:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 7:55 [PATCH] intel: Fix stencil buffer to be W tiled Chad Versace
2011-07-18 7:55 ` [PATCH] dri: Do not tile stencil buffer Chad Versace
2011-07-18 8:15 ` Paul Menzel
2011-07-18 18:45 ` [Mesa-dev] " Ian Romanick
2011-07-18 19:28 ` Chad Versace
2011-07-18 20:58 ` Ian Romanick
2011-07-18 7:55 ` [PATCH] intel: Fix stencil buffer to be W tiled Chad Versace
2011-07-18 8:20 ` Paul Menzel
2011-07-19 20:03 ` [Mesa-dev] " Chad Versace
2011-07-18 15:57 ` Eric Anholt
2011-07-18 21:05 ` Chad Versace [this message]
2011-07-19 0:00 ` [Mesa-dev] " Chad Versace
2011-07-19 15:34 ` Eric Anholt
2011-07-18 18:49 ` Ian Romanick
2011-07-18 20:54 ` [Mesa-dev] " Chad Versace
2011-07-18 21:02 ` Ian Romanick
2011-07-18 21:24 ` Chad Versace
2011-07-18 22:34 ` Ian Romanick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E24A008.3010802@chad-versace.us \
--to=chad@chad-versace.us \
--cc=eric@anholt.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mesa-dev@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox