Re: [Intel-gfx] [PATCH 04/10] i965: setup system routine
On Mon, Jul 18, 2011 at 11:19:17AM -0700, Eric Anholt wrote: > On Sun, 17 Jul 2011 16:25:42 -0700, Ben Widawsky wrote: > > Upload the system routine as part of the invariant state if debugging. > > > > Remove SIP setting if not debugging to make it more friendly for others > > that may be debugging shaders or media kernels. > > > > v2: removed comment per Chris > > This patch doesn't really make sense to me. Nothing good will come of > my driver's buffer execution landing inside someone else's debug kernel, > right? So why should my driver's batchbuffer be leaving their SIP in > place? Yeah you're right. Furthermore, the default value should be 0, which should be all good all around. Initially I was trying to do something fancier here, detecting when the SIP has been changed external to mesa, but I gave up on that. I will remove the condition and always set sip. Ben pgp94JdHwIJWB.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: check intel-agp module only for real intel graphics device
Move intel-agp module dependence check into device probe function
instead of always checking that when loading i915 module, which seems
too chatty on non-intel graphics device.
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/i915_drv.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index eb91e2d..b802eb1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -652,6 +652,11 @@ int i915_reset(struct drm_device *dev, u8 flags)
static int __devinit
i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
+ if (!intel_agp_enabled) {
+ DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
+ return -ENODEV;
+ }
+
/* Only bind to function 0 of the device. Early generations
* used function 1 as a placeholder for multi-head. This causes
* us confusion instead, especially on the systems where both
@@ -813,11 +818,6 @@ static struct pci_driver i915_pci_driver = {
static int __init i915_init(void)
{
- if (!intel_agp_enabled) {
- DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
- return -ENODEV;
- }
-
driver.num_ioctls = i915_max_ioctl;
/*
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dri: Do not tile stencil buffer
On 07/18/2011 05:08 PM, 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 > Date: Mon Jul 18 00:37:45 2011 -0700 > > CC: Eric Anholt > CC: Kenneth Graunke > CC: Ian Romancik > Signed-off-by: Chad Versace > --- > src/intel_dri.c | 16 > 1 files changed, 12 insertions(+), 4 deletions(-) For the series: Acked-by: Kenneth Graunke (I would say Reviewed-by, but I haven't verified the math. That said, I don't think I need to...I've seen how rigorously you investigated this.) Happy to see these go in whenever. We definitely need them in 7.11 and 2.16. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel: Fix stencil buffer to be W tiled
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 fix touches the following portions of code:
- In intel_allocate_renderbuffer_storage(), allocate the stencil
buffer with I915_TILING_NONE.
- In intel_verify_dri2_has_hiz(), verify that the stencil buffer is
not tiled.
- In the stencil buffer's span functions, the tile's layout must be
decoded in software.
This commit mutually depends on the xf86-video-intel commit
dri: Do not tile stencil buffer
Author: Chad Versace
Date: Mon Jul 18 00:38:00 2011 -0700
On Gen6 with separate stencil enabled, fixes the following Piglit tests:
bugs/fdo23670-drawpix_stencil
general/stencil-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-readpixels
spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-copypixels
spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels
spec/EXT_packed_depth_stencil/readpixels-24_8
Note: This is a candidate for the 7.11 branch.
CC: Eric Anholt
CC: Kenneth Graunke
CC: Ian Romancik
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_clear.c |6 ++
src/mesa/drivers/dri/intel/intel_context.c |9 ++-
src/mesa/drivers/dri/intel/intel_fbo.c | 12 ++--
src/mesa/drivers/dri/intel/intel_screen.h |9 ++-
src/mesa/drivers/dri/intel/intel_span.c| 88 +---
5 files changed, 93 insertions(+), 31 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_clear.c
b/src/mesa/drivers/dri/intel/intel_clear.c
index dfca03c..5ab9873 100644
--- a/src/mesa/drivers/dri/intel/intel_clear.c
+++ b/src/mesa/drivers/dri/intel/intel_clear.c
@@ -143,6 +143,12 @@ intelClear(struct gl_context *ctx, GLbitfield mask)
*/
tri_mask |= BUFFER_BIT_STENCIL;
}
+else if (intel->has_separate_stencil &&
+ stencilRegion->tiling == I915_TILING_NONE) {
+ /* The stencil buffer is actually W tiled, which the hardware
+* cannot blit to. */
+ tri_mask |= BUFFER_BIT_STENCIL;
+}
else {
/* clearing all stencil bits, use blitting */
blit_mask |= BUFFER_BIT_STENCIL;
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 2ba1363..fe8be08 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -1439,7 +1439,12 @@ intel_verify_dri2_has_hiz(struct intel_context *intel,
assert(stencil_rb->Base.Format == MESA_FORMAT_S8);
assert(depth_rb && depth_rb->Base.Format == MESA_FORMAT_X8_Z24);
- if (stencil_rb->region->tiling == I915_TILING_Y) {
+ if (stencil_rb->region->tiling == I915_TILING_NONE) {
+/*
+ * The stencil buffer is actually W tiled. The region's tiling is
+ * I915_TILING_NONE, however, because the GTT is incapable of W
+ * fencing.
+ */
intel->intelScreen->dri2_has_hiz = INTEL_DRI2_HAS_HIZ_TRUE;
return;
} else {
@@ -1527,7 +1532,7 @@ intel_verify_dri2_has_hiz(struct intel_context *intel,
* Presently, however, no verification or clean up is necessary, and
* execution should not reach here. If the framebuffer still has a hiz
* region, then we have already set dri2_has_hiz to true after
- * confirming above that the stencil buffer is Y tiled.
+ * confirming above that the stencil buffer is W tiled.
*/
assert(0);
}
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 1669af2..2206391 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
[Intel-gfx] [PATCH] dri: Do not tile stencil buffer
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
Date: Mon Jul 18 00:37:45 2011 -0700
CC: Eric Anholt
CC: Kenneth Graunke
CC: Ian Romancik
Signed-off-by: Chad Versace
---
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 1269422..90abe5f 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -335,7 +335,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;
@@ -350,6 +349,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);
@@ -367,11 +374,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.
*/
if (attachment == DRI2BufferStencil) {
- pixmap_height /= 2;
+ pixmap_width = ALIGN(pixmap_width, 64);
+ pixmap_height = ALIGN((pixmap_height + 1) / 2, 64);
pixmap_cpp *= 2;
}
--
1.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] intel: Fix stencil buffer to be W tiled
Patch 1 v2: - Change buffer height from ALIGN(height / 2, 64) to ALIGN((height + 1) / 2, 64). Patch 2 v2: - Change buffer height from ALIGN(height / 2, 64) to ALIGN((height + 1) / 2, 64). - Change return type of intel_offset_S8 changed to intptr_t. - Improve performance of Y_FLIP. - Remove XXX comment in intel_alloc_renderbuffer_storage. xf86-video-intel dri: Do not tile stencil buffer src/intel_dri.c | 16 mesa intel: Fix stencil buffer to be W tiled src/mesa/drivers/dri/intel/intel_clear.c |6 ++ src/mesa/drivers/dri/intel/intel_context.c |9 ++- src/mesa/drivers/dri/intel/intel_fbo.c | 12 ++-- src/mesa/drivers/dri/intel/intel_screen.h |9 ++- src/mesa/drivers/dri/intel/intel_span.c| 88 +--- 5 files changed, 93 insertions(+), 31 deletions(-) -- 1.7.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
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
>>
>> 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.
Oops. It does fail for height = 129. Accordingly, I've changed this hunk to:
irb->region = intel_region_alloc(intel->intelScreen,
- I915_TILING_Y,
+ I915_TILING_NONE,
cpp * 2,
- width,
- height / 2,
+ ALIGN(width, 64),
+ ALIGN((height + 1)/ 2, 64),
GL_TRUE);
And changed the same line in xf86-video-intel too.
> Doesn't
> seem like 128 pitch requirement would be needed -- has it been tested?
The XXX was left in the patch accidentally. 128-alignment has been tested, and
was
found unnecessary.
--
Chad Versace
c...@chad-versace.us
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix unfenced alignment on pre-G33 hardware
On Tue, 19 Jul 2011 00:48:23 +0200, Paul Menzel wrote: Non-text part: multipart/mixed Non-text part: multipart/signed > Am Montag, den 18.07.2011, 13:31 -0700 schrieb Keith Packard: > I have not been able to test this patch but if it fixes the issue it > should definitely be sent to stable as well since the bug has been there > since at least Linux 2.6.37 [1][2] in a lot distributions. The patch is on drm-intel-fixes in my tree; please test what's there and report back what you find out. That patch is marked with a Cc: to stable, so it will end up in stable kernels eventually. -- keith.pack...@intel.com pgpkYHOqpL8ea.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix unfenced alignment on pre-G33 hardware
Am Montag, den 18.07.2011, 13:31 -0700 schrieb Keith Packard: > On Mon, 18 Jul 2011 17:57:52 +0100, Chris Wilson > wrote: > > > Keith, apologies your missive arrived as I sent the previous patch. This > > uses the inferface you proposed.. > > Thanks! I've reduced the diff a bit more to make it easier to review and > have pushed this patch onto drm-intel-fixes. I'd like to get a bit more > testing before I send it along, but that needs to be soon if we want > this in 3.0. I have not been able to test this patch but if it fixes the issue it should definitely be sent to stable as well since the bug has been there since at least Linux 2.6.37 [1][2] in a lot distributions. Thanks, Paul [1] https://bugzilla.redhat.com/show_bug.cgi?id=704959 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614296 signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 02:24 PM, Chad Versace wrote:
> On 07/18/2011 02:02 PM, Ian Romanick wrote:
>> On 07/18/2011 01:54 PM, Chad Versace wrote:
>>> On 07/18/2011 11:49 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 fix touches the following portions of code:
> - In intel_allocate_renderbuffer_storage(), allocate the stencil
> buffer with I915_TILING_NONE.
> - In intel_verify_dri2_has_hiz(), verify that the stencil buffer is
> not tiled.
> - In the stencil buffer's span functions, the tile's layout must be
> decoded in software.
> This commit mutually depends on the xf86-video-intel commit
> dri: Do not tile stencil buffer
> Author: Chad Versace
> Date: Mon Jul 18 00:38:00 2011 -0700
> On Gen6 with separate stencil enabled, fixes the following Piglit tests:
> bugs/fdo23670-drawpix_stencil
> general/stencil-drawpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-copypixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-readpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-copypixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-readpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-copypixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-drawpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-readpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-copypixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-readpixels
>
> spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-copypixels
>
> spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels
> spec/EXT_packed_depth_stencil/readpixels-24_8
> Note: This is a candidate for the 7.11 branch.
> CC: Eric Anholt
> CC: Kenneth Graunke
> Signed-off-by: Chad Versace
> ---
> src/mesa/drivers/dri/intel/intel_clear.c |6 ++
> src/mesa/drivers/dri/intel/intel_context.c |9 ++-
> src/mesa/drivers/dri/intel/intel_fbo.c | 13 +++--
> src/mesa/drivers/dri/intel/intel_screen.h |9 ++-
> src/mesa/drivers/dri/intel/intel_span.c| 85
>
> 5 files changed, 89 insertions(+), 33 deletions(-)
> diff --git a/src/mesa/drivers/dri/intel/intel_clear.c
> b/src/mesa/drivers/dri/intel/intel_clear.c
> index dfca03c..5ab9873 100644
> --- a/src/mesa/drivers/dri/intel/intel_clear.c
> +++ b/src/mesa/drivers/dri/intel/intel_clear.c
> @@ -143,6 +143,12 @@ intelClear(struct gl_context *ctx, GLbitfield mask)
>*/
> tri_mask |= BUFFER_BIT_STENCIL;
> }
> + else if (intel->has_separate_stencil &&
> +stencilRegion->tiling == I915_TILING_NONE) {
> + /* The stencil buffer is actually W tiled, which the hardware
> + * cannot blit to. */
> + tri_mask |= BUFFER_BIT_STENCIL;
> + }
> else {
> /* clearing all stencil bits, use blitting */
> blit_mask |= BUFFER_BIT_STENCIL;
> diff --git a/src/mesa/drivers/dri/intel/intel_context.c
> b/src/mesa/drivers/dri/intel/intel_context.c
> index 2ba1363..fe8be08 100644
> --- a/src/mesa/drivers/dri/intel/intel_context.c
> +++ b/src/mesa/drivers/dri/intel/intel_context.c
> @@ -1439,7 +1439,12 @@ intel_verify_dri2_has_hiz(struct intel_context
> *intel,
>assert(stencil_rb->Base.Format == MESA_FORMAT_S8);
>assert(depth_rb && depth_rb->Base.Format == MESA_FORMAT_X8_Z24);
> - if (stencil_rb->region->tiling == I915_TILING_Y) {
> + if (stencil_rb->region->tiling == I915_TILING_NONE) {
> + /*
> + * The stencil buffer is actually W tiled. The region's tiling is
> + * I915_TILING_NONE, however, because the GTT is incapable of W
> + * fencing.
> + */
>intel->intelScreen->dri2_has_hiz = INTEL_DRI2_HAS_HIZ_TRUE;
>return;
>} else
Re: [Intel-gfx] [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
On 07/18/2011 02:02 PM, Ian Romanick wrote:
> On 07/18/2011 01:54 PM, Chad Versace wrote:
>> On 07/18/2011 11:49 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 fix touches the following portions of code:
- In intel_allocate_renderbuffer_storage(), allocate the stencil
buffer with I915_TILING_NONE.
- In intel_verify_dri2_has_hiz(), verify that the stencil buffer is
not tiled.
- In the stencil buffer's span functions, the tile's layout must be
decoded in software.
>>>
This commit mutually depends on the xf86-video-intel commit
dri: Do not tile stencil buffer
Author: Chad Versace
Date: Mon Jul 18 00:38:00 2011 -0700
>>>
On Gen6 with separate stencil enabled, fixes the following Piglit tests:
bugs/fdo23670-drawpix_stencil
general/stencil-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-readpixels
spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-copypixels
spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels
spec/EXT_packed_depth_stencil/readpixels-24_8
>>>
Note: This is a candidate for the 7.11 branch.
>>>
CC: Eric Anholt
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_clear.c |6 ++
src/mesa/drivers/dri/intel/intel_context.c |9 ++-
src/mesa/drivers/dri/intel/intel_fbo.c | 13 +++--
src/mesa/drivers/dri/intel/intel_screen.h |9 ++-
src/mesa/drivers/dri/intel/intel_span.c| 85
5 files changed, 89 insertions(+), 33 deletions(-)
>>>
diff --git a/src/mesa/drivers/dri/intel/intel_clear.c
b/src/mesa/drivers/dri/intel/intel_clear.c
index dfca03c..5ab9873 100644
--- a/src/mesa/drivers/dri/intel/intel_clear.c
+++ b/src/mesa/drivers/dri/intel/intel_clear.c
@@ -143,6 +143,12 @@ intelClear(struct gl_context *ctx, GLbitfield mask)
*/
tri_mask |= BUFFER_BIT_STENCIL;
}
+ else if (intel->has_separate_stencil &&
+ stencilRegion->tiling == I915_TILING_NONE) {
+ /* The stencil buffer is actually W tiled, which the hardware
+ * cannot blit to. */
+ tri_mask |= BUFFER_BIT_STENCIL;
+ }
else {
/* clearing all stencil bits, use blitting */
blit_mask |= BUFFER_BIT_STENCIL;
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 2ba1363..fe8be08 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -1439,7 +1439,12 @@ intel_verify_dri2_has_hiz(struct intel_context
*intel,
assert(stencil_rb->Base.Format == MESA_FORMAT_S8);
assert(depth_rb && depth_rb->Base.Format == MESA_FORMAT_X8_Z24);
>>>
- if (stencil_rb->region->tiling == I915_TILING_Y) {
+ if (stencil_rb->region->tiling == I915_TILING_NONE) {
+ /*
+* The stencil buffer is actually W tiled. The region's tiling is
+* I915_TILING_NONE, however, because the GTT is incapable of W
+* fencing.
+*/
intel->intelScreen->dri2_has_hiz = INTEL_DRI2_HAS_HIZ_TRUE;
return;
} else {
@@ -1527,7 +1532,7 @@ intel_verify_dri2_has_hiz(struct intel_context
*intel,
* Presently, however, no verification or clean up is necessary, and
Re: [Intel-gfx] [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
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
>>
>> 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
c...@chad-versace.us
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskto
Re: [Intel-gfx] [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 01:54 PM, Chad Versace wrote:
> On 07/18/2011 11:49 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 fix touches the following portions of code:
>>> - In intel_allocate_renderbuffer_storage(), allocate the stencil
>>> buffer with I915_TILING_NONE.
>>> - In intel_verify_dri2_has_hiz(), verify that the stencil buffer is
>>> not tiled.
>>> - In the stencil buffer's span functions, the tile's layout must be
>>> decoded in software.
>>
>>> This commit mutually depends on the xf86-video-intel commit
>>> dri: Do not tile stencil buffer
>>> Author: Chad Versace
>>> Date: Mon Jul 18 00:38:00 2011 -0700
>>
>>> On Gen6 with separate stencil enabled, fixes the following Piglit tests:
>>> bugs/fdo23670-drawpix_stencil
>>> general/stencil-drawpixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-copypixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-readpixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-copypixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-readpixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-copypixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-drawpixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-readpixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-copypixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels
>>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-readpixels
>>> spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-copypixels
>>> spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels
>>> spec/EXT_packed_depth_stencil/readpixels-24_8
>>
>>> Note: This is a candidate for the 7.11 branch.
>>
>>> CC: Eric Anholt
>>> CC: Kenneth Graunke
>>> Signed-off-by: Chad Versace
>>> ---
>>> src/mesa/drivers/dri/intel/intel_clear.c |6 ++
>>> src/mesa/drivers/dri/intel/intel_context.c |9 ++-
>>> src/mesa/drivers/dri/intel/intel_fbo.c | 13 +++--
>>> src/mesa/drivers/dri/intel/intel_screen.h |9 ++-
>>> src/mesa/drivers/dri/intel/intel_span.c| 85
>>>
>>> 5 files changed, 89 insertions(+), 33 deletions(-)
>>
>>> diff --git a/src/mesa/drivers/dri/intel/intel_clear.c
>>> b/src/mesa/drivers/dri/intel/intel_clear.c
>>> index dfca03c..5ab9873 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_clear.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_clear.c
>>> @@ -143,6 +143,12 @@ intelClear(struct gl_context *ctx, GLbitfield mask)
>>> */
>>> tri_mask |= BUFFER_BIT_STENCIL;
>>> }
>>> +else if (intel->has_separate_stencil &&
>>> + stencilRegion->tiling == I915_TILING_NONE) {
>>> + /* The stencil buffer is actually W tiled, which the hardware
>>> +* cannot blit to. */
>>> + tri_mask |= BUFFER_BIT_STENCIL;
>>> +}
>>> else {
>>> /* clearing all stencil bits, use blitting */
>>> blit_mask |= BUFFER_BIT_STENCIL;
>>> diff --git a/src/mesa/drivers/dri/intel/intel_context.c
>>> b/src/mesa/drivers/dri/intel/intel_context.c
>>> index 2ba1363..fe8be08 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_context.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_context.c
>>> @@ -1439,7 +1439,12 @@ intel_verify_dri2_has_hiz(struct intel_context
>>> *intel,
>>>assert(stencil_rb->Base.Format == MESA_FORMAT_S8);
>>>assert(depth_rb && depth_rb->Base.Format == MESA_FORMAT_X8_Z24);
>>
>>> - if (stencil_rb->region->tiling == I915_TILING_Y) {
>>> + if (stencil_rb->region->tiling == I915_TILING_NONE) {
>>> +/*
>>> + * The stencil buffer is actually W tiled. The region's tiling is
>>> + * I915_TILING_NONE, however, because the GTT is incapable of W
>>> + * fencing.
>>> + */
>>> intel->intelScreen->dri2_has_hiz = INTEL_DRI2_HAS_HIZ_TRUE;
>>> return;
>>>} else {
>>> @@ -1527,7 +1532,7 @@ intel_verify_dri2_has_hiz(struct intel_context *intel,
>>> * Presently, however, no verification or clean up is necessary, and
>>> * execution should not reach here. If the framebuffer still has a
>>> hiz
>>> * regio
Re: [Intel-gfx] [Mesa-dev] [PATCH] dri: Do not tile stencil buffer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 12:28 PM, Chad Versace wrote:
> 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
>>> Date: Mon Jul 18 00:37:45 2011 -0700
>>
>>> CC: Eric Anholt
>>> CC: Kenneth Graunke
>>> Signed-off-by: Chad Versace
>>> ---
>>> 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) {
Ah. That sounds right.
This patch (with the whitespace fix) is
Reviewed-by: Ian Romanick
>>
>>> @@ -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;
>>> }
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4knooACgkQX1gOwKyEAw8mrACdFEbKAyQIntzWec6LVA2ZYYjz
8icAn1Fc+vHRyNeygch2QHnH7Vh9Ilqt
=9yZk
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
On 07/18/2011 11:49 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 fix touches the following portions of code:
>> - In intel_allocate_renderbuffer_storage(), allocate the stencil
>> buffer with I915_TILING_NONE.
>> - In intel_verify_dri2_has_hiz(), verify that the stencil buffer is
>> not tiled.
>> - In the stencil buffer's span functions, the tile's layout must be
>> decoded in software.
>
>> This commit mutually depends on the xf86-video-intel commit
>> dri: Do not tile stencil buffer
>> Author: Chad Versace
>> Date: Mon Jul 18 00:38:00 2011 -0700
>
>> On Gen6 with separate stencil enabled, fixes the following Piglit tests:
>> bugs/fdo23670-drawpix_stencil
>> general/stencil-drawpixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-copypixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-readpixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-copypixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-readpixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-copypixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-drawpixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-readpixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-copypixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels
>> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-readpixels
>> spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-copypixels
>> spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels
>> spec/EXT_packed_depth_stencil/readpixels-24_8
>
>> Note: This is a candidate for the 7.11 branch.
>
>> CC: Eric Anholt
>> CC: Kenneth Graunke
>> Signed-off-by: Chad Versace
>> ---
>> src/mesa/drivers/dri/intel/intel_clear.c |6 ++
>> src/mesa/drivers/dri/intel/intel_context.c |9 ++-
>> src/mesa/drivers/dri/intel/intel_fbo.c | 13 +++--
>> src/mesa/drivers/dri/intel/intel_screen.h |9 ++-
>> src/mesa/drivers/dri/intel/intel_span.c| 85
>>
>> 5 files changed, 89 insertions(+), 33 deletions(-)
>
>> diff --git a/src/mesa/drivers/dri/intel/intel_clear.c
>> b/src/mesa/drivers/dri/intel/intel_clear.c
>> index dfca03c..5ab9873 100644
>> --- a/src/mesa/drivers/dri/intel/intel_clear.c
>> +++ b/src/mesa/drivers/dri/intel/intel_clear.c
>> @@ -143,6 +143,12 @@ intelClear(struct gl_context *ctx, GLbitfield mask)
>> */
>> tri_mask |= BUFFER_BIT_STENCIL;
>> }
>> + else if (intel->has_separate_stencil &&
>> + stencilRegion->tiling == I915_TILING_NONE) {
>> +/* The stencil buffer is actually W tiled, which the hardware
>> + * cannot blit to. */
>> +tri_mask |= BUFFER_BIT_STENCIL;
>> + }
>> else {
>> /* clearing all stencil bits, use blitting */
>> blit_mask |= BUFFER_BIT_STENCIL;
>> diff --git a/src/mesa/drivers/dri/intel/intel_context.c
>> b/src/mesa/drivers/dri/intel/intel_context.c
>> index 2ba1363..fe8be08 100644
>> --- a/src/mesa/drivers/dri/intel/intel_context.c
>> +++ b/src/mesa/drivers/dri/intel/intel_context.c
>> @@ -1439,7 +1439,12 @@ intel_verify_dri2_has_hiz(struct intel_context *intel,
>>assert(stencil_rb->Base.Format == MESA_FORMAT_S8);
>>assert(depth_rb && depth_rb->Base.Format == MESA_FORMAT_X8_Z24);
>
>> - if (stencil_rb->region->tiling == I915_TILING_Y) {
>> + if (stencil_rb->region->tiling == I915_TILING_NONE) {
>> + /*
>> + * The stencil buffer is actually W tiled. The region's tiling is
>> + * I915_TILING_NONE, however, because the GTT is incapable of W
>> + * fencing.
>> + */
>> intel->intelScreen->dri2_has_hiz = INTEL_DRI2_HAS_HIZ_TRUE;
>> return;
>>} else {
>> @@ -1527,7 +1532,7 @@ intel_verify_dri2_has_hiz(struct intel_context *intel,
>> * Presently, however, no verification or clean up is necessary, and
>> * execution should not reach here. If the framebuffer still has a hiz
>> * region, then we have already set dri2_has_hiz to true after
>> - * confirming above that the stencil buffer is Y tiled.
>> + * confirming above that the stencil buffer is
Re: [Intel-gfx] [PATCH] drm/i915: Fix unfenced alignment on pre-G33 hardware
On Mon, 18 Jul 2011 17:57:52 +0100, Chris Wilson wrote: > Keith, apologies your missive arrived as I sent the previous patch. This > uses the inferface you proposed.. Thanks! I've reduced the diff a bit more to make it easier to review and have pushed this patch onto drm-intel-fixes. I'd like to get a bit more testing before I send it along, but that needs to be soon if we want this in 3.0. -- keith.pack...@intel.com pgpk0U6VoxB2b.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH] dri: Do not tile stencil buffer
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
>> Date: Mon Jul 18 00:37:45 2011 -0700
>
>> CC: Eric Anholt
>> CC: Kenneth Graunke
>> Signed-off-by: Chad Versace
>> ---
>> 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
c...@chad-versace.us
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 fix touches the following portions of code:
> - In intel_allocate_renderbuffer_storage(), allocate the stencil
> buffer with I915_TILING_NONE.
> - In intel_verify_dri2_has_hiz(), verify that the stencil buffer is
> not tiled.
> - In the stencil buffer's span functions, the tile's layout must be
> decoded in software.
>
> This commit mutually depends on the xf86-video-intel commit
> dri: Do not tile stencil buffer
> Author: Chad Versace
> Date: Mon Jul 18 00:38:00 2011 -0700
>
> On Gen6 with separate stencil enabled, fixes the following Piglit tests:
> bugs/fdo23670-drawpix_stencil
> general/stencil-drawpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-copypixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-readpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-copypixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-readpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-copypixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-drawpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-readpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-copypixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels
> spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-readpixels
> spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-copypixels
> spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels
> spec/EXT_packed_depth_stencil/readpixels-24_8
>
> Note: This is a candidate for the 7.11 branch.
>
> CC: Eric Anholt
> CC: Kenneth Graunke
> Signed-off-by: Chad Versace
> ---
> src/mesa/drivers/dri/intel/intel_clear.c |6 ++
> src/mesa/drivers/dri/intel/intel_context.c |9 ++-
> src/mesa/drivers/dri/intel/intel_fbo.c | 13 +++--
> src/mesa/drivers/dri/intel/intel_screen.h |9 ++-
> src/mesa/drivers/dri/intel/intel_span.c| 85
>
> 5 files changed, 89 insertions(+), 33 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_clear.c
> b/src/mesa/drivers/dri/intel/intel_clear.c
> index dfca03c..5ab9873 100644
> --- a/src/mesa/drivers/dri/intel/intel_clear.c
> +++ b/src/mesa/drivers/dri/intel/intel_clear.c
> @@ -143,6 +143,12 @@ intelClear(struct gl_context *ctx, GLbitfield mask)
>*/
> tri_mask |= BUFFER_BIT_STENCIL;
> }
> + else if (intel->has_separate_stencil &&
> +stencilRegion->tiling == I915_TILING_NONE) {
> + /* The stencil buffer is actually W tiled, which the hardware
> + * cannot blit to. */
> + tri_mask |= BUFFER_BIT_STENCIL;
> + }
> else {
> /* clearing all stencil bits, use blitting */
> blit_mask |= BUFFER_BIT_STENCIL;
> diff --git a/src/mesa/drivers/dri/intel/intel_context.c
> b/src/mesa/drivers/dri/intel/intel_context.c
> index 2ba1363..fe8be08 100644
> --- a/src/mesa/drivers/dri/intel/intel_context.c
> +++ b/src/mesa/drivers/dri/intel/intel_context.c
> @@ -1439,7 +1439,12 @@ intel_verify_dri2_has_hiz(struct intel_context *intel,
>assert(stencil_rb->Base.Format == MESA_FORMAT_S8);
>assert(depth_rb && depth_rb->Base.Format == MESA_FORMAT_X8_Z24);
>
> - if (stencil_rb->region->tiling == I915_TILING_Y) {
> + if (stencil_rb->region->tiling == I915_TILING_NONE) {
> + /*
> + * The stencil buffer is actually W tiled. The region's tiling is
> + * I915_TILING_NONE, however, because the GTT is incapable of W
> + * fencing.
> + */
>intel->intelScreen->dri2_has_hiz = INTEL_DRI2_HAS_HIZ_TRUE;
>return;
>} else {
> @@ -1527,7 +1532,7 @@ intel_verify_dri2_has_hiz(struct intel_context *intel,
> * Presently, however, no verification or clean up is necessary, and
> * execution should not reach here. If the framebuffer still has a hiz
> * region, then we have already set dri2_has_hiz to true after
> - * confirming above that the stencil buffer is Y tiled.
> + * confirming above that the stencil buffer is W tiled.
> */
>assert(0);
> }
> diff --git a/src/mesa/
Re: [Intel-gfx] [Mesa-dev] [PATCH] dri: Do not tile stencil buffer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
> Date: Mon Jul 18 00:37:45 2011 -0700
>
> CC: Eric Anholt
> CC: Kenneth Graunke
> Signed-off-by: Chad Versace
> ---
> 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...
> @@ -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...
>*/
> if (attachment == DRI2BufferStencil) {
> - pixmap_height /= 2;
> + pixmap_width = ALIGN(pixmap_width, 64);
> + pixmap_height = ALIGN(pixmap_height / 2, 64);
> pixmap_cpp *= 2;
> }
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4kf10ACgkQX1gOwKyEAw9jVACeOfy5BjD4Nb/YN3vyOoR5MOOv
IOAAn20Lh7GAN7KSAkBFs/u5uaHq8/Sm
=ICWC
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/10] i965: setup system routine
On Sun, 17 Jul 2011 16:25:42 -0700, Ben Widawsky wrote: > Upload the system routine as part of the invariant state if debugging. > > Remove SIP setting if not debugging to make it more friendly for others > that may be debugging shaders or media kernels. > > v2: removed comment per Chris This patch doesn't really make sense to me. Nothing good will come of my driver's buffer execution landing inside someone else's debug kernel, right? So why should my driver's batchbuffer be leaving their SIP in place? Of course, if we're landing in a SIP at all from our !brw->wm.debugging batchbuffers, we're screwed if we don't have actual SIP instructions in place, so I guess this doesn't *really* change anything. pgp3njcqZjNSr.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] i965: copy in system routine, reserve extra scratch
On Wed, 13 Jul 2011 13:51:44 -0700, Ben Widawsky wrote:
> The debugger shared memory needs to be a fixed size. Since this is
> scratch memory that is already used by register spilling, add
> appropriate hooks to do the right thing when debugging.
>
> v2: Include the bytes for a known good system routine and upload it into
> the instruction state cache
>
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/Makefile |1 +
> src/mesa/drivers/dri/i965/brw_context.h |6 +
> src/mesa/drivers/dri/i965/brw_state.h|6 +-
> src/mesa/drivers/dri/i965/brw_state_cache.c | 49 +-
> src/mesa/drivers/dri/i965/brw_state_upload.c | 18 +-
> src/mesa/drivers/dri/i965/brw_wm.c | 24 +-
> src/mesa/drivers/dri/i965/brw_wm.h |2 +
> src/mesa/drivers/dri/i965/brw_wm_debug.c | 29 +
> src/mesa/drivers/dri/i965/gen6_wm_sr.c | 31 +
> src/mesa/drivers/dri/i965/gen_wm_sr.g4a |32826
> ++
.g4a is the extension for assembly source, not for a compiled hex dump.
I'd make it a .c file -- seems like you need just a touch more
processing to generate that in place in gen6_wm_sr.c.
> +/**
> + * Upload a debugger to the instruction cache. Currently only 1 debugger at a
> + * time is supported. The debugger will live at the beginning of the state
> bo.
> + */
> +void
> +brw_upload_debugger_cache(struct brw_context *brw,
> + void *system_routine,
> + uint32_t length)
s/length/size/ to be consistent with the rest of the driver.
> +{
> + uint32_t sip_size = 0;
> + struct brw_cache *cache = &brw->cache;
> + /* It is useful to have an offset so we can see if the SIP is != 0 */
> + const uint32_t sip_offset = 64;
> + struct brw_cache_item *item;
> +
> + if (cache->debugger) {
> + cache->persistent_size -= cache->debugger->size;
> + cache->debugger = NULL;
> + brw->wm.sip_offset = 0;
> + }
Why check here? We're only called if cache->debugger, right?
> +
> + if (!cache->persistent_size)
> + sip_size += sip_offset;
We're only called once, so we know if cache->persistent_size, right?
> + sip_size += length;
> +
> + item = CALLOC_STRUCT(brw_cache_item);
> + if (!item)
> + return;
> + item->size = sip_size;
> + item->key = system_routine;
> +
> + brw->wm.sip_offset = cache->persistent_size + sip_offset;
> + drm_intel_bo_subdata(cache->bo, brw->wm.sip_offset, length,
> system_routine);
> +
> + cache->persistent_size += sip_size;
> + cache->debugger = item;
> + brw_upload_item_data(cache, item, system_routine);
> +}
> +
> void
> brw_upload_cache(struct brw_cache *cache,
>enum brw_cache_id cache_id,
> @@ -318,7 +357,7 @@ brw_upload_cache(struct brw_cache *cache,
> }
> static void
> @@ -357,8 +396,9 @@ brw_clear_cache(struct brw_context *brw, struct brw_cache
> *cache)
>
> /* Start putting programs into the start of the BO again, since
> * we'll never find the old results.
> +* Save space at beginning for persistent items.
> */
> - cache->next_offset = 0;
> + cache->next_offset = cache->persistent_size;
>
> /* We need to make sure that the programs get regenerated, since
> * any offsets leftover in brw_context will no longer be valid.
You claim to hold on to persistent_size, but we don't actually copy the
data to a new BO... Oh, my. It looks like I totally broke this
function, by letting later uploads stomp over old programs if the cache
was cleared mid-batchbuffer. Wonder if this is one of the P1 bugs.
> @@ -388,7 +428,10 @@ brw_destroy_cache(struct brw_context *brw, struct
> brw_cache *cache)
>
> brw_clear_cache(brw, cache);
> free(cache->items);
> + if (cache->debugger)
> + free(cache->debugger);
> cache->items = NULL;
> + cache->debugger = NULL;
> cache->size = 0;
> }
You don't need to check non-NULL for free().
> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
> b/src/mesa/drivers/dri/i965/brw_state_upload.c
> index 76ffa0d..cc78f73 100644
> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> @@ -33,9 +33,13 @@
>
> #include "brw_context.h"
> #include "brw_state.h"
> +#include "brw_wm.h"
> #include "intel_batchbuffer.h"
> #include "intel_buffers.h"
>
> +extern char * const gen_wm_debugger;
> +extern const int gen_wm_debugger_size;
> +
> /* This is used to initialize brw->state.atoms[]. We could use this
> * list directly except for a single atom, brw_constant_buffer, which
> * has a .dirty value which changes according to the parameters of the
> @@ -239,8 +243,18 @@ void brw_init_state( struct brw_context *brw )
> {
> const struct brw_tracked_state **atoms;
> int num_atoms;
> -
> - brw_init_caches(brw);
> + uint32_t rsvd_cache_space = 0;
Set-but-unused variable?
> if (brw->intel.gen >= 7) {
>atoms = gen7_atoms;
> diff --git
Re: [Intel-gfx] [PATCH] intel: Fix stencil buffer to be W tiled
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
>
> 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.
pgpvujxxgyynD.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix unfenced alignment on pre-G33 hardware
Align unfenced buffers on older hardware to the power-of-two object size.
The docs suggest that it should be possible to align only to a power-of-two
tile height, but using the already computed fence size is easier and
always correct. We also have to make sure that we unbind misaligned buffers
upon tiling changes.
In order to prevent a repetition of this bug, we change the interface to
the alignment computation routines to force the caller to provide the
requested alignment and size of the GTT binding rather than assume the
current values on the object.
Reported-and-tested-by: Sitosfe Wheeler
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36326
Signed-off-by: Chris Wilson
---
Keith, apologies your missive arrived as I sent the previous patch. This
uses the inferface you proposed..
---
drivers/gpu/drm/i915/i915_drv.h|4 +-
drivers/gpu/drm/i915/i915_gem.c| 75
drivers/gpu/drm/i915/i915_gem_tiling.c |4 +-
3 files changed, 43 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2798d27..b533ab8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1216,7 +1216,9 @@ void i915_gem_free_all_phys_object(struct drm_device
*dev);
void i915_gem_release(struct drm_device *dev, struct drm_file *file);
uint32_t
-i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj);
+i915_gem_get_unfenced_gtt_alignment(struct drm_device *dev,
+ uint32_t size,
+ int tiling_mode);
int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2e0d891..b9d9879 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1374,25 +1374,23 @@ i915_gem_free_mmap_offset(struct drm_i915_gem_object
*obj)
}
static uint32_t
-i915_gem_get_gtt_size(struct drm_i915_gem_object *obj)
+i915_gem_get_gtt_size(struct drm_device *dev, uint32_t size, int tiling_mode)
{
- struct drm_device *dev = obj->base.dev;
- uint32_t size;
+ uint32_t fence_size;
- if (INTEL_INFO(dev)->gen >= 4 ||
- obj->tiling_mode == I915_TILING_NONE)
- return obj->base.size;
+ if (INTEL_INFO(dev)->gen >= 4 || tiling_mode == I915_TILING_NONE)
+ return size;
/* Previous chips need a power-of-two fence region when tiling */
if (INTEL_INFO(dev)->gen == 3)
- size = 1024*1024;
+ fence_size = 1024*1024;
else
- size = 512*1024;
+ fence_size = 512*1024;
- while (size < obj->base.size)
- size <<= 1;
+ while (fence_size < size)
+ fence_size <<= 1;
- return size;
+ return fence_size;
}
/**
@@ -1403,59 +1401,53 @@ i915_gem_get_gtt_size(struct drm_i915_gem_object *obj)
* potential fence register mapping.
*/
static uint32_t
-i915_gem_get_gtt_alignment(struct drm_i915_gem_object *obj)
+i915_gem_get_gtt_alignment(struct drm_device *dev,
+ uint32_t size,
+ int tiling_mode)
{
- struct drm_device *dev = obj->base.dev;
-
/*
* Minimum alignment is 4k (GTT page size), but might be greater
* if a fence register is needed for the object.
*/
- if (INTEL_INFO(dev)->gen >= 4 ||
- obj->tiling_mode == I915_TILING_NONE)
+ if (INTEL_INFO(dev)->gen >= 4 || tiling_mode == I915_TILING_NONE)
return 4096;
/*
* Previous chips need to be aligned to the size of the smallest
* fence register that can contain the object.
*/
- return i915_gem_get_gtt_size(obj);
+ return i915_gem_get_gtt_size(dev, size, tiling_mode);
}
/**
* i915_gem_get_unfenced_gtt_alignment - return required GTT alignment for an
* unfenced object
- * @obj: object to check
+ * @dev: the device
+ * @size: size of the object
+ * @tiling_mode: tiling mode of the object
*
* Return the required GTT alignment for an object, only taking into account
* unfenced tiled surface requirements.
*/
uint32_t
-i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj)
+i915_gem_get_unfenced_gtt_alignment(struct drm_device *dev,
+ uint32_t size,
+ int tiling_mode)
{
- struct drm_device *dev = obj->base.dev;
- int tile_height;
+ if (tiling_mode == I915_TILING_NONE)
+ return 4096;
/*
* Minimum alignment is 4k (GTT page size) for sane hw.
*/
- if (INTEL_INFO(dev)->gen >= 4 || IS_G33(dev) ||
- obj->tiling_mode == I915_TILING_NONE)
+ i
[Intel-gfx] [PATCH] drm/i915: Fix unfenced alignment on pre-G33 hardware
Align unfenced buffers on older hardware to the power-of-two object size.
The docs suggest that it should be possible to align only to a power-of-two
tile height, but using the already computed fence size is easier and
always correct. We also have to make sure that we unbind misaligned buffers
upon tiling changes.
Reported-and-tested-by: Sitosfe Wheeler
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36326
Signed-off-by: Chris Wilson
---
Updated to pass tiling_mode to all the gtt size/alignment functions for
consistency and to prevent any more lurking bugs.
---
drivers/gpu/drm/i915/i915_drv.h|3 +-
drivers/gpu/drm/i915/i915_gem.c| 47 +++-
drivers/gpu/drm/i915/i915_gem_tiling.c |3 +-
3 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2798d27..a9492d9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1216,7 +1216,8 @@ void i915_gem_free_all_phys_object(struct drm_device
*dev);
void i915_gem_release(struct drm_device *dev, struct drm_file *file);
uint32_t
-i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj);
+i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj,
+ int tiling_mode);
int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2e0d891..4c4f6c3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1374,13 +1374,14 @@ i915_gem_free_mmap_offset(struct drm_i915_gem_object
*obj)
}
static uint32_t
-i915_gem_get_gtt_size(struct drm_i915_gem_object *obj)
+i915_gem_get_gtt_size(struct drm_i915_gem_object *obj,
+ int tiling_mode)
{
struct drm_device *dev = obj->base.dev;
uint32_t size;
if (INTEL_INFO(dev)->gen >= 4 ||
- obj->tiling_mode == I915_TILING_NONE)
+ tiling_mode == I915_TILING_NONE)
return obj->base.size;
/* Previous chips need a power-of-two fence region when tiling */
@@ -1403,7 +1404,8 @@ i915_gem_get_gtt_size(struct drm_i915_gem_object *obj)
* potential fence register mapping.
*/
static uint32_t
-i915_gem_get_gtt_alignment(struct drm_i915_gem_object *obj)
+i915_gem_get_gtt_alignment(struct drm_i915_gem_object *obj,
+ int tiling_mode)
{
struct drm_device *dev = obj->base.dev;
@@ -1411,51 +1413,45 @@ i915_gem_get_gtt_alignment(struct drm_i915_gem_object
*obj)
* Minimum alignment is 4k (GTT page size), but might be greater
* if a fence register is needed for the object.
*/
- if (INTEL_INFO(dev)->gen >= 4 ||
- obj->tiling_mode == I915_TILING_NONE)
+ if (INTEL_INFO(dev)->gen >= 4 || tiling_mode == I915_TILING_NONE)
return 4096;
/*
* Previous chips need to be aligned to the size of the smallest
* fence register that can contain the object.
*/
- return i915_gem_get_gtt_size(obj);
+ return i915_gem_get_gtt_size(obj, tiling_mode);
}
/**
* i915_gem_get_unfenced_gtt_alignment - return required GTT alignment for an
* unfenced object
* @obj: object to check
+ * @tiling_mode: tiling mode of the object
*
* Return the required GTT alignment for an object, only taking into account
* unfenced tiled surface requirements.
*/
uint32_t
-i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj)
+i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj,
+ int tiling_mode)
{
struct drm_device *dev = obj->base.dev;
- int tile_height;
+
+ if (tiling_mode == I915_TILING_NONE)
+ return 4096;
/*
* Minimum alignment is 4k (GTT page size) for sane hw.
*/
- if (INTEL_INFO(dev)->gen >= 4 || IS_G33(dev) ||
- obj->tiling_mode == I915_TILING_NONE)
+ if (INTEL_INFO(dev)->gen >= 4 || IS_G33(dev))
return 4096;
- /*
-* Older chips need unfenced tiled buffers to be aligned to the left
-* edge of an even tile row (where tile rows are counted as if the bo is
-* placed in a fenced gtt region).
+ /* Previous hardware however needs to be aligned to a power-of-two
+* tile height. The simplest method for determining this is to reuse
+* the power-of-tile object size.
*/
- if (IS_GEN2(dev))
- tile_height = 16;
- else if (obj->tiling_mode == I915_TILING_Y &&
HAS_128_BYTE_Y_TILING(dev))
- tile_height = 32;
- else
- tile_height = 8;
-
- return tile_height * obj->stride * 2;
+ return i915_gem_get_gt
Re: [Intel-gfx] [PATCH] drm/i915: Fix unfenced alignment on pre-G33 hardware
On Mon, 18 Jul 2011 09:17:16 -0700, Keith Packard wrote: Non-text part: multipart/signed > On Sat, 9 Jul 2011 09:31:25 +0100, Chris Wilson > wrote: > > > uint32_t > > -i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj) > > +i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj, > > + int tiling_mode) > ... > > + return i915_gem_get_gtt_size(obj); > > I think you want to pass the new tiling mode to this function rather > than using the object's existing tiling mode. Seems like most of the > issues could easily be explained by using the stale value when trying to > change tiling modes. Actually, given that the only thing you need from the object is the size, it would be better to just create functions which take just the size and tiling mode and computes the gtt size required to map that. Like: i915_gem_get_unfenced_gtt_alignment(struct drm_device *dev, size_t size, unsigned tiling_mode) i915_gem_get_gtt_size(struct drm_device *dev, size_t size, unsigned tiling_mode) Then you can be sure you're using the correct tiling mode in all of the computations. -- keith.pack...@intel.com pgpstNvpTpcU8.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix unfenced alignment on pre-G33 hardware
On Mon, 18 Jul 2011 09:17:16 -0700, Keith Packard wrote: Non-text part: multipart/signed > On Sat, 9 Jul 2011 09:31:25 +0100, Chris Wilson > wrote: > > > uint32_t > > -i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj) > > +i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj, > > + int tiling_mode) > ... > > + return i915_gem_get_gtt_size(obj); > > I think you want to pass the new tiling mode to this function rather > than using the object's existing tiling mode. Seems like most of the > issues could easily be explained by using the stale value when trying to > change tiling modes. So help me, I made that change at one time as Daniel pointed that out. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix unfenced alignment on pre-G33 hardware
On Sat, 9 Jul 2011 09:31:25 +0100, Chris Wilson wrote: > uint32_t > -i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj) > +i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj, > + int tiling_mode) ... > + return i915_gem_get_gtt_size(obj); I think you want to pass the new tiling mode to this function rather than using the object's existing tiling mode. Seems like most of the issues could easily be explained by using the stale value when trying to change tiling modes. -- keith.pack...@intel.com pgpMXA1jc6oeg.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix unfenced alignment on pre-G33 hardware
It sucks a bit to see the relaxed fencing idea go down the toilet for pre-g33, but bleh, hw sometimes just hates us. Cc: sta...@kernel.org Reviewed-by: Daniel Vetter -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [HDMI AUDIO] How I can disable null packets?
Hello, My problem is TV doesn't receive audio through jack 3.5, because my video card send null packets by hdmi output. Here this part of intel_audio_dump: SDVOC HDMI encoding1 SDVOC SDVO encoding0 SDVOC null packets1 SDVOC audio enabled1 I solved this problem in old packages (2.9.1) by intel_audio binary in reg_dumper folder. This binary do: if 0 /* disable HDMI audio bits */ dump_reg(SDVOC,"Digital Display Port B Control Register"); dword &= ~SDVO_AUDIO_ENABLE; dword &= ~SDVO_NULL_PACKETS_DURING_VSYNC; OUTREG(SDVOC, dword); endif Now this binary doesn't work — it do nothing. How I can disable null packets in new package (2:2.14.0-4ubuntu7.1)? Thanks. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Fix stencil buffer to be W tiled
Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace: […] > 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; > \ There are alignment/white space issues above. > + unsigned stride = irb->region->pitch; \ > + unsigned height = 2 * irb->region->height; > \ > + bool flip = rb->Name == 0; > \ […] Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dri: Do not tile stencil buffer
Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace:
> 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
> Date: Mon Jul 18 00:37:45 2011 -0700
>
> CC: Eric Anholt
> CC: Kenneth Graunke
> Signed-off-by: Chad Versace
> ---
> 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);
> @@ -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.
The alignment does not seem to match.
>*/
> if (attachment == DRI2BufferStencil) {
> - pixmap_height /= 2;
> + pixmap_width = ALIGN(pixmap_width, 64);
> + pixmap_height = ALIGN(pixmap_height / 2, 64);
> pixmap_cpp *= 2;
> }
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel: Fix stencil buffer to be W tiled
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 fix touches the following portions of code:
- In intel_allocate_renderbuffer_storage(), allocate the stencil
buffer with I915_TILING_NONE.
- In intel_verify_dri2_has_hiz(), verify that the stencil buffer is
not tiled.
- In the stencil buffer's span functions, the tile's layout must be
decoded in software.
This commit mutually depends on the xf86-video-intel commit
dri: Do not tile stencil buffer
Author: Chad Versace
Date: Mon Jul 18 00:38:00 2011 -0700
On Gen6 with separate stencil enabled, fixes the following Piglit tests:
bugs/fdo23670-drawpix_stencil
general/stencil-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-readpixels
spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-copypixels
spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels
spec/EXT_packed_depth_stencil/readpixels-24_8
Note: This is a candidate for the 7.11 branch.
CC: Eric Anholt
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_clear.c |6 ++
src/mesa/drivers/dri/intel/intel_context.c |9 ++-
src/mesa/drivers/dri/intel/intel_fbo.c | 13 +++--
src/mesa/drivers/dri/intel/intel_screen.h |9 ++-
src/mesa/drivers/dri/intel/intel_span.c| 85
5 files changed, 89 insertions(+), 33 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_clear.c
b/src/mesa/drivers/dri/intel/intel_clear.c
index dfca03c..5ab9873 100644
--- a/src/mesa/drivers/dri/intel/intel_clear.c
+++ b/src/mesa/drivers/dri/intel/intel_clear.c
@@ -143,6 +143,12 @@ intelClear(struct gl_context *ctx, GLbitfield mask)
*/
tri_mask |= BUFFER_BIT_STENCIL;
}
+else if (intel->has_separate_stencil &&
+ stencilRegion->tiling == I915_TILING_NONE) {
+ /* The stencil buffer is actually W tiled, which the hardware
+* cannot blit to. */
+ tri_mask |= BUFFER_BIT_STENCIL;
+}
else {
/* clearing all stencil bits, use blitting */
blit_mask |= BUFFER_BIT_STENCIL;
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 2ba1363..fe8be08 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -1439,7 +1439,12 @@ intel_verify_dri2_has_hiz(struct intel_context *intel,
assert(stencil_rb->Base.Format == MESA_FORMAT_S8);
assert(depth_rb && depth_rb->Base.Format == MESA_FORMAT_X8_Z24);
- if (stencil_rb->region->tiling == I915_TILING_Y) {
+ if (stencil_rb->region->tiling == I915_TILING_NONE) {
+/*
+ * The stencil buffer is actually W tiled. The region's tiling is
+ * I915_TILING_NONE, however, because the GTT is incapable of W
+ * fencing.
+ */
intel->intelScreen->dri2_has_hiz = INTEL_DRI2_HAS_HIZ_TRUE;
return;
} else {
@@ -1527,7 +1532,7 @@ intel_verify_dri2_has_hiz(struct intel_context *intel,
* Presently, however, no verification or clean up is necessary, and
* execution should not reach here. If the framebuffer still has a hiz
* region, then we have already set dri2_has_hiz to true after
- * confirming above that the stencil buffer is Y tiled.
+ * confirming above that the stencil buffer is W tiled.
*/
assert(0);
}
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
[Intel-gfx] [PATCH] dri: Do not tile stencil buffer
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
Date: Mon Jul 18 00:37:45 2011 -0700
CC: Eric Anholt
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
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);
@@ -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.
*/
if (attachment == DRI2BufferStencil) {
- pixmap_height /= 2;
+ pixmap_width = ALIGN(pixmap_width, 64);
+ pixmap_height = ALIGN(pixmap_height / 2, 64);
pixmap_cpp *= 2;
}
--
1.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel: Fix stencil buffer to be W tiled
Chad Versace (2): xf86-video-intel dri: Do not tile stencil buffer src/intel_dri.c | 16 mesa intel: Fix stencil buffer to be W tiled src/mesa/drivers/dri/intel/intel_clear.c |6 ++ src/mesa/drivers/dri/intel/intel_context.c |9 ++- src/mesa/drivers/dri/intel/intel_fbo.c | 13 +++-- src/mesa/drivers/dri/intel/intel_screen.h |9 ++- src/mesa/drivers/dri/intel/intel_span.c| 85 5 files changed, 89 insertions(+), 33 deletions(-) -- 1.7.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
