[Mesa3d-dev] [PATCH] Fix Viewport in _mesa_meta_GenerateMipmap
Hi list,
the first of these two patches fixes _mesa_meta_GenerateMipmap to update
the viewport and projection matrix after changing the destination mipmap
level. Before, pixels would get clipped to the boundaries of the
original DrawBuffer, which may be smaller than the second mipmap level.
The second patch just pulls projection matrix and vertex array setup out
of the main loop.
The other way to fix this i can think of is to disable clipping to
viewport. I could not figure out if that is even possible.
Tested with swrast and i965.
Regards,
Pierre
From 493e1fe00e902723c0b20cc75d83fbbca107b90e Mon Sep 17 00:00:00 2001
From: Pierre Willenbrock pie...@pirsoft.de
Date: Wed, 6 Jan 2010 22:37:18 +0100
Subject: [PATCH 1/2] Setup viewport and Projection Matrix in _mesa_meta_GenerateMipmap
This fixes mipmap levels being clipped to the last viewport.
Signed-off-by: Pierre Willenbrock pie...@pirsoft.de
---
src/mesa/drivers/common/meta.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index c4dbfa6..51dd5e0 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -2430,7 +2430,7 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
texObj-Name,
dstLevel);
}
-
+
_mesa_DrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
/* sanity check */
@@ -2440,6 +2440,15 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
break;
}
+ /* setup viewport and matching projection matrix */
+ _mesa_set_viewport(ctx, 0, 0,
+ ctx-DrawBuffer-Width, ctx-DrawBuffer-Height);
+ _mesa_MatrixMode(GL_PROJECTION);
+ _mesa_LoadIdentity();
+ _mesa_Ortho(0.0F, ctx-DrawBuffer-Width,
+ 0.0F, ctx-DrawBuffer-Height,
+ -1.0F, 1.0F);
+
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
}
--
1.6.6.rc4
From 258f82377d39888040d297fe11b0c17d1a0a55c4 Mon Sep 17 00:00:00 2001
From: Pierre Willenbrock pie...@pirsoft.de
Date: Wed, 6 Jan 2010 22:37:32 +0100
Subject: [PATCH 2/2] Move destination vertex/projection setup out of _mesa_meta_GenerateMipmap
Signed-off-by: Pierre Willenbrock pie...@pirsoft.de
---
src/mesa/drivers/common/meta.c | 44 ---
1 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 51dd5e0..25234d9 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -2321,6 +2321,28 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
_mesa_set_enable(ctx, target, GL_TRUE);
+ /* setup vertex positions */
+ {
+ verts[0].x = 0.0F;
+ verts[0].y = 0.0F;
+ verts[1].x = 1.0F;
+ verts[1].y = 0.0F;
+ verts[2].x = 1.0F;
+ verts[2].y = 1.0F;
+ verts[3].x = 0.0F;
+ verts[3].y = 1.0F;
+
+ /* upload new vertex data */
+ _mesa_BufferSubDataARB(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
+ }
+
+ /* setup projection matrix */
+ _mesa_MatrixMode(GL_PROJECTION);
+ _mesa_LoadIdentity();
+ _mesa_Ortho(0.0F, 1.0F,
+ 0.0F, 1.0F,
+ -1.0F, 1.0F);
+
/* texture is already locked, unlock now */
_mesa_unlock_texture(ctx, texObj);
@@ -2387,21 +2409,6 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
}
}
- /* setup vertex positions */
- {
- verts[0].x = 0.0F;
- verts[0].y = 0.0F;
- verts[1].x = (GLfloat) dstWidth;
- verts[1].y = 0.0F;
- verts[2].x = (GLfloat) dstWidth;
- verts[2].y = (GLfloat) dstHeight;
- verts[3].x = 0.0F;
- verts[3].y = (GLfloat) dstHeight;
-
- /* upload new vertex data */
- _mesa_BufferSubDataARB(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
- }
-
/* limit sampling to src level */
_mesa_TexParameteri(target, GL_TEXTURE_BASE_LEVEL, srcLevel);
_mesa_TexParameteri(target, GL_TEXTURE_MAX_LEVEL, srcLevel);
@@ -2440,14 +2447,9 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
break;
}
- /* setup viewport and matching projection matrix */
+ /* setup viewport */
_mesa_set_viewport(ctx, 0, 0,
ctx-DrawBuffer-Width, ctx-DrawBuffer-Height);
- _mesa_MatrixMode(GL_PROJECTION);
- _mesa_LoadIdentity();
- _mesa_Ortho(0.0F, ctx-DrawBuffer-Width,
- 0.0F, ctx-DrawBuffer-Height,
- -1.0F, 1.0F);
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
}
--
1.6.6.rc4
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http
Re: [Mesa3d-dev] [PATCH 0/6]
Ian Romanick schrieb: Pierre Willenbrock wrote: [...] Additionally, in mesa, src/mesa/drivers/dri/intel/intel_tex_image.c, intelSetTexBuffer2, color_rb[0](the front buffer) is accessed without is_front_buffer_rendering being set to true, so RGBA visuals don't work when doing opengl compositing. This is what mesa-tex_image-front-buffer.patch is about? I'm not sure I completely follow. Could you elaborate? Not all of mesa-tex_image-front-buffer.patch. I don't know if the initialisation of is_front_buffer_rendering is needed, it seems to work without. In intelSetTexBuffer2 there is this sequence: intel_update_renderbuffers(pDRICtx, dPriv); rb = intel_fb-color_rb[0]; /* If the region isn't set, then intel_update_renderbuffers was unable * to get the buffers for the drawable. */ if (rb-region == NULL) return; So, it expects intel_update_renderbuffers to fill the intel_fb-color_rb[0]-region of the dPriv. This only happens, if is_front_buffer_rendering is true(or if there is no back buffer). Maybe something more complex is needed, forcing is_front_buffer_rendering to true was the easiest way to get the region allocated. Finally, i noticed that when forcing mesa to use DRI2GetBuffers, the front buffer is requested without considering is_front_buffer_rendering. In that case i get the kwin renders to real front buffer problem. This also happens in the DRI2GetBuffersWithFormat-path, when using the condition from the DRI2GetBuffers-path. That's intentional and required. With the DRI2GetBuffers path you have to request all of the attachments that might ever be used up-front. If a second DRI2GetBuffers call is made and the size of the drawable hasn't changed, it will just return the same set of buffers. That is, it won't add the newly requested buffer at all. Ah, okay. I just wanted to point out that there is still some problem with applications getting the real front buffer, and that this depends on when exactly the front buffer is requested. [...] -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6]
Ian Romanick schrieb: Pierre Willenbrock wrote: Ian Romanick schrieb: Pierre Willenbrock wrote: Additionally, in mesa, src/mesa/drivers/dri/intel/intel_tex_image.c, intelSetTexBuffer2, color_rb[0](the front buffer) is accessed without is_front_buffer_rendering being set to true, so RGBA visuals don't work when doing opengl compositing. This is what mesa-tex_image-front-buffer.patch is about? I'm not sure I completely follow. Could you elaborate? Not all of mesa-tex_image-front-buffer.patch. I don't know if the initialisation of is_front_buffer_rendering is needed, it seems to work without. In intelSetTexBuffer2 there is this sequence: intel_update_renderbuffers(pDRICtx, dPriv); rb = intel_fb-color_rb[0]; /* If the region isn't set, then intel_update_renderbuffers was unable * to get the buffers for the drawable. */ if (rb-region == NULL) return; So, it expects intel_update_renderbuffers to fill the intel_fb-color_rb[0]-region of the dPriv. This only happens, if is_front_buffer_rendering is true(or if there is no back buffer). Maybe something more complex is needed, forcing is_front_buffer_rendering to true was the easiest way to get the region allocated. Okay, I see what's going on. This is the pixmap case. We handle this case differently on the server, so I think we just need to handle it even more differently. Right now the client only asks for the front-buffer when it's going to do front-buffer rendering. However, the server always creates the real front-buffer so that CopyRegion and friends will work. It only does this when the drawable is a window. I was under the impression that only windows had back-buffers. Is this a pixmap with a back-buffer? If so, try the attached xserver patch. I haven't tested it, but I think it should fix this problem. The patch works. I _think_ those are windows, not pixmaps. Windows with RGB visual did work, only windows with RGBA visuals did not show up. But i don't know exactly which visual is chosen(xwininfo only shows the visual class and depth), so maybe the RGB ones did not have a back buffer, but the RGBA ones did. Those windows are rendered through composite extension and texture-from-pixmap, so they may well be pixmaps posing as windows, or something. I have no idea how that works. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6]
Ian Romanick schrieb:
This patch set hits 4 repositories. Woo-hoo!
The old DRI2GetBuffers protocol is replaced with DRI2GetBuffersWithFormat.
This protocol adds a per-buffer format value. This is a magic value that is
opaque outside the driver. The Intel driver simply sends the bits-per-pixel.
Drivers with other requirements to make the correct allocation can send other
data in the field.
The new function also behaves somewhat differently. DRI2GetBuffers would
create the requested set of buffers and destroy all previously existing
buffers. DRI2GetBuffersWithFormat creates the requested set of buffers, but
it only destroys existing buffers on attachments in the requested set.
Futher, it only allocates (or destroys) buffers if the size or format have
changed. This allows a client to initially request { DRI2BufferBackLeft,
DRI2BufferDepth }, and later request { DRI2BufferBackLeft,
DRI2BufferFrontLeft,
DRI2BufferDepth } without ill effect.
Since the buffer allocation is done piece-wise, it is difficult to implement
the combined depth / stencil buffers. Taking a note from
GL_ARB_framebuffer_object, I added a new DRI2BufferDepthStencil attachment.
I have tested the following combinations with the listed result:
* New libGL, old 3D driver, old X server, old 2D driver - works just as
previously
* New libGL, new 3D driver, old X server, old 2D driver - works just as
previously
* New libGL, new 3D driver, new X server, old 2D driver - DRI2 fails to
initialize, uses the software rasterizer
* New libGL, new 3D driver, old X server, new 2D driver - DRI2 fails to
initialize, uses the software rasterizer
* New libGL, new 3D driver, new X server, new 2D driver - Works the way
we really want it to! Front-buffer rendering works, but the fake front-
buffer is only allocated when it's needed. JUST LIKE MAGIC!
The combination that is not tested is the old libGL / 3D driver with
everything
else new. This should work. The idea is that if the the 2D driver receives
format=0 in CreateBuffer, it should make the same allocation that
CreateBuffers
would have made for the attachment.
Looks like xf86-video-intel does not treat allocations with format=0 the
same with your patches. I need an extra (format !=
0)?format:pDraw-depth in xf86-video-intel to get kwin to work with a
mesa forced to use DRI2GetBuffers.
Additionally, in mesa, src/mesa/drivers/dri/intel/intel_tex_image.c,
intelSetTexBuffer2, color_rb[0](the front buffer) is accessed without
is_front_buffer_rendering being set to true, so RGBA visuals don't work
when doing opengl compositing.
Finally, i noticed that when forcing mesa to use DRI2GetBuffers, the
front buffer is requested without considering is_front_buffer_rendering.
In that case i get the kwin renders to real front buffer problem. This
also happens in the DRI2GetBuffersWithFormat-path, when using the
condition from the DRI2GetBuffers-path.
Completely unrelated to this(and your patchset): i think __glXDisp_WaitX
in xserver should call glxc-drawPriv-waitX instead of
glxc-drawPriv-waitGL.
Thanks for making opengl compositing using kwin work again on i965. I
attached patches for all of these problems, except for the differing
handling of is_front_buffer_rendering in intel_update_renderbuffers.
Regards,
Pierre
commit 180da48d70f1fbb5db2ed69cfb5dcb715d48633e
Author: Pierre Willenbrock pie...@pirsoft.de
Date: Sat Apr 25 22:35:40 2009 +0200
Set is_front_buffer_rendering to GL_TRUE before touching color_rb[0]
diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c
index eb224a8..ebf7177 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -739,6 +739,8 @@ intelInitContext(struct intel_context *intel,
*/
intel-no_hw = getenv(INTEL_NO_HW) != NULL;
+ intel-is_front_buffer_rendering = GL_FALSE;
+
return GL_TRUE;
}
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c b/src/mesa/drivers/dri/intel/intel_tex_image.c
index 1f192da..f1ccaf2 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_image.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
@@ -747,6 +747,8 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
if (!intelObj)
return;
+ intel-is_front_buffer_rendering = GL_TRUE;
+
intel_update_renderbuffers(pDRICtx, dPriv);
rb = intel_fb-color_rb[0];
commit b7070a39203cdc51d58dbaf10e3c817f31c6d4f9
Author: Pierre Willenbrock pie...@pirsoft.de
Date: Sat Apr 25 22:58:20 2009 +0200
format == 0 means use default in I830DRI2CreateBuffer
diff --git a/src/i830_dri.c b/src/i830_dri.c
index 4ab09c9..70b76ae 100644
--- a/src/i830_dri.c
+++ b/src/i830_dri.c
@@ -1677,7 +1677,7 @@ I830DRI2CreateBuffer(DrawablePtr pDraw, unsigned int attachment,
pPixmap = (*pScreen-CreatePixmap)(pScreen,
pDraw-width,
pDraw-height,
- format,
+ (format != 0)?format:pDraw
