[Mesa-dev] [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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [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
Re: [Mesa-dev] Mesa (master): configure.ac: don' t build gallium driver libs just to see if there are no errors
On 14/07/2011 02:05, Marek Olšák wrote: > Module: Mesa > Branch: master > Commit: 02c8ee202f5a159659a027deae4721ff05cd1530 > URL: > http://cgit.freedesktop.org/mesa/mesa/commit/?id=02c8ee202f5a159659a027deae4721ff05cd1530 > > Author: Marek Olšák > Date: Mon Jun 27 08:02:31 2011 +0200 > > configure.ac: don't build gallium driver libs just to see if there are no > errors [snip] > diff --git a/configure.ac b/configure.ac > index a586f0a..c3047d6 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -769,7 +769,7 @@ GLU_DIRS="sgi" > GALLIUM_DIRS="auxiliary drivers state_trackers" > GALLIUM_TARGET_DIRS="" > GALLIUM_WINSYS_DIRS="sw" > -GALLIUM_DRIVERS_DIRS="softpipe failover galahad trace rbug noop identity" > +GALLIUM_DRIVERS_DIRS="failover galahad trace rbug noop identity" > GALLIUM_STATE_TRACKERS_DIRS="" [snip] > xswrast) > if test "x$HAVE_ST_DRI" = xyes; then > +GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS softpipe" > +if test "x$MESA_LLVM" = x1; then > +GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS llvmpipe" > +fi > GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS dri-swrast" > fi > if test "x$HAVE_ST_VDPAU" = xyes; then It looks like this changes (in the case where swrast is the only driver selected) from always building softpipe to only building if the dri state tracker is selected. Since, this change, building with ./configure --with-driver=xlib --with-gallium-drivers=swrast fails, see [1] > mklib: Making CYGWIN shared library: cygGL-1.dll > Creating library file: libGL-1.dll.a > xlib.o: In function `sw_screen_create_named': > /opt/jhbuild/git/mesa/mesa/src/gallium/targets/libgl-xlib/../../../../src/gallium/auxiliary/target-helpers/inline_sw_helper.h:44: > undefined reference to `_softpipe_create_screen' inline_sw_helper.h conditionalizes the code which references softpipe on the GALLIUM_SOFTPIPE define, but that is always set in src/gallium/targets/libgl-xlib/Makefile without any reference to the configuration. I'd appreciate some guidance as to the correct way to fix this :-) [1] http://tinderbox.freedesktop.org/builds/2011-07-17-0004/logs/libGL/#build ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 Release Candidate 1 tarball issue
On 07/17/2011 03:50 PM, Marty Jack wrote: Another problem in the RC1 tarballs appears to be src/mesa/depend. This contains a pile of references to /usr/lib/gcc/x86_64-redhat-linux/4.6.0/include and will fail if you are not on that system. With that removed I am able to build the RC1 tarballs, but that doesn't mean there isn't something else wrong in the parts that I didn't build. The depend files included in the tarball should be empty files. Looks like one of the recent changes to the top-level Makefile lost the 'tarballs' dependency on 'rm_depend'. I'll see if I can fix this later. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx->Driver.Map/UnmapTextureImage() hooks
On 07/15/2011 02:59 PM, Pekka Paalanen wrote: On Fri, 15 Jul 2011 12:22:41 -0600 Brian Paul wrote: On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paul wrote: The map-texture-image-v4 branch that I just pushed implements this change. It really cleaned things up for the better and will lead to a few more follow-on improvements. There's no obvious regressions with swrast or the gallium drivers. I updated the intel driver code and tested i915 and it seems OK too, but I didn't do a full piglit run on it. I also updated the legacy r600 driver in case anyone cares but didn't do any testing of it. I didn't update any of the other legacy DRI drivers. Would anyone object if we simply stop building mach64, r128, unichrome, sis, etc? I'd be happy to remove those drivers altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. Sounds good to me. I think we'd only keep the swrast, intel and maybe r300/r600 drivers. Opinions? Um, don't kill nouveau_vieux, please. Does the old nouveau driver support some GPUs that the gallium nv50/nvc0 drivers don't support? If we want to keep the older driver someone will need to volunteer to update the code to support the new driver hooks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: st_copy_texsubimage: clip source size to rb size
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39286
---
src/mesa/state_tracker/st_cb_texture.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 6907cfc..63cd142 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1490,6 +1490,14 @@ st_copy_texsubimage(struct gl_context *ctx,
destY = 0;
}
+ if (srcX + width > strb->Base.Width) {
+ width = strb->Base.Width - srcX;
+ }
+
+ if (srcY + height > strb->Base.Height) {
+ height = strb->Base.Height - srcY;
+ }
+
if (width < 0 || height < 0)
return;
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: st_copy_texsubimage: clip source size to rb size
On Mon, Jul 18, 2011 at 8:11 AM, Vadim Girlin wrote:
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39286
> ---
> src/mesa/state_tracker/st_cb_texture.c | 8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.c
> index 6907cfc..63cd142 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -1490,6 +1490,14 @@ st_copy_texsubimage(struct gl_context *ctx,
> destY = 0;
> }
>
> + if (srcX + width > strb->Base.Width) {
> + width = strb->Base.Width - srcX;
> + }
> +
> + if (srcY + height > strb->Base.Height) {
> + height = strb->Base.Height - srcY;
> + }
> +
> if (width < 0 || height < 0)
> return;
Clipping for glCopyTexSubImage() should be done by
_mesa_clip_copytexsubimage() (in image.c, called from teximage.c).
Maybe you could do a bit of debugging to see why that's not doing the
job.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39338] New: Mesa: LLVM dependency mishmash
https://bugs.freedesktop.org/show_bug.cgi?id=39338 Summary: Mesa: LLVM dependency mishmash Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: blocker Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: johannesoberm...@gmx.de LLVM >= 135219 (git: 1abf2cb) required: http://cgit.freedesktop.org/mesa/mesa/commit/?id=9228bfb37519e4a03183ec89e82a80f39addeeeb LLVM < 134829 (git: 1afcace) and 134839 (git: 7c72c92) required: $ grep -r -n "LLVMAddTypeName" ./ ./src/gallium/drivers/llvmpipe/lp_jit.c:116: LLVMAddTypeName(gallivm->module, "texture", texture_type); ./src/gallium/drivers/llvmpipe/lp_jit.c:158: LLVMAddTypeName(gallivm->module, "context", context_type); ./src/gallium/auxiliary/draw/draw_llvm.c:287: LLVMAddTypeName(gallivm->module, struct_name, vertex_header); ./src/gallium/auxiliary/draw/draw_llvm.c:303: LLVMAddTypeName(gallivm->module, "texture", texture_type); ./src/gallium/auxiliary/draw/draw_llvm.c:306: LLVMAddTypeName(gallivm->module, "draw_jit_context", context_type); ./src/gallium/auxiliary/draw/draw_llvm.c:310: LLVMAddTypeName(gallivm->module, "buffer", buffer_type); ./src/gallium/auxiliary/draw/draw_llvm.c:314: LLVMAddTypeName(gallivm->module, "pipe_vertex_buffer", vb_type); Additional hint: LLVM < 135245 (git: ef58218) required: grep -r -n "LLVMInvalidateStructLayout" ./ ./src/gallium/drivers/llvmpipe/lp_jit.c:74: LLVMInvalidateStructLayout(gallivm->target, texture_type); ./src/gallium/drivers/llvmpipe/lp_jit.c:135: LLVMInvalidateStructLayout(gallivm->target, context_type); ./src/gallium/auxiliary/draw/draw_llvm.c:129: LLVMInvalidateStructLayout(gallivm->target, texture_type); ./src/gallium/auxiliary/draw/draw_llvm.c:196: LLVMInvalidateStructLayout(gallivm->target, context_type); ./src/gallium/auxiliary/draw/draw_llvm.c:231: LLVMInvalidateStructLayout(gallivm->target, vb_type); ./src/gallium/auxiliary/draw/draw_llvm.c:264: LLVMInvalidateStructLayout(gallivm->target, vertex_header); -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix the texture format in st_context_teximage
Commit 1a339b6c71ebab6e1a64f05b2e133022d3bbcd15 made st_ChooseTextureFormat map GL_RGBA with type GL_UNSIGNED_BYTE to PIPE_FORMAT_A8B8G8R8_UNORM. The image format for ARGB pixmaps is PIPE_FORMAT_B8G8R8A8_UNORM however. This mismatch caused the texture to be recreated in st_finalize_texture. NOTE: This is a candidate for the 7.11 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39209 Signed-off-by: Fredrik Höglund --- src/mesa/state_tracker/st_manager.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/state_tracker/st_manager.c b/src/mesa/state_tracker/st_manager.c index 7bd82aa..d5228d3 100644 --- a/src/mesa/state_tracker/st_manager.c +++ b/src/mesa/state_tracker/st_manager.c @@ -587,7 +587,7 @@ st_context_teximage(struct st_context_iface *stctxi, internalFormat = GL_RGB; texFormat = st_ChooseTextureFormat(ctx, internalFormat, - GL_RGBA, GL_UNSIGNED_BYTE); + GL_BGRA, GL_UNSIGNED_BYTE); _mesa_init_teximage_fields(ctx, target, texImage, tex->width0, tex->height0, 1, 0, -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: st_copy_texsubimage: clip source size to rb size
On Mon, 2011-07-18 at 08:34 -0600, Brian Paul wrote:
> On Mon, Jul 18, 2011 at 8:11 AM, Vadim Girlin wrote:
> > Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39286
> > ---
> > src/mesa/state_tracker/st_cb_texture.c |8
> > 1 files changed, 8 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/mesa/state_tracker/st_cb_texture.c
> > b/src/mesa/state_tracker/st_cb_texture.c
> > index 6907cfc..63cd142 100644
> > --- a/src/mesa/state_tracker/st_cb_texture.c
> > +++ b/src/mesa/state_tracker/st_cb_texture.c
> > @@ -1490,6 +1490,14 @@ st_copy_texsubimage(struct gl_context *ctx,
> > destY = 0;
> >}
> >
> > + if (srcX + width > strb->Base.Width) {
> > + width = strb->Base.Width - srcX;
> > + }
> > +
> > + if (srcY + height > strb->Base.Height) {
> > + height = strb->Base.Height - srcY;
> > + }
> > +
> >if (width < 0 || height < 0)
> > return;
>
> Clipping for glCopyTexSubImage() should be done by
> _mesa_clip_copytexsubimage() (in image.c, called from teximage.c).
> Maybe you could do a bit of debugging to see why that's not doing the
> job.
>
Yes, I have some doubts too, especially now when I've seen the comment
before the st_copy_texsubimage definition, which explicitly states the
region should be clipped already. AFAICS _mesa_clip_copytexsubimage is
called only from copytexsubimage, but st_copy_texsubimage is called from
copyteximage (without sub) too, that's why no clipping occurs. I'm not
sure now where and how is better to fix it then, because my knowledge of
this code is still not very good. On the other hand, st_copy_texsubimage
already contains some clipping code, that's why I've added the checks in
this function. How should I fix this correctly?
Vadim.
> -Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().
We can't do try-map + create + map + dereference internally in a
driver. Creating a new buffer and replacing a pointer to the old one
may lead to the following issue. If a buffer pointer is replaced, it
doesn't necessarily update all the states the buffer is set in in all
existing contexts. Such states and contexts would still use the old
buffer and wouldn't see the change until the old buffer is unbound.
I think the only correct way to implement the DISCARD flags in drivers
is through a temporary (staging) resource and doing an on-gpu copy to
the original one (i.e. what we do for texture transfers in rX00g).
Marek
On Mon, Jul 18, 2011 at 2:09 AM, Jose Fonseca wrote:
> PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE was added recently, and is the preferred
> interface, because:
> - it can give better performance when the kernel memory manager supports; it
> requires less kernel roundtrips than try-map + create + map + dereference.
> - it also allows the drivers to do more fancy implementations when kernel
> doesn't, e.g., keep a round robin of buffers, to avoid consst, which can be
> freed when memory is low
>
> Preferably, all drivers should implement PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE
> -- they can simply internally do the try-map + create + map + dereference if
> there's no way pass that flag to the kernel map ioctl.
>
> If there are strong reasons to not support
> PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE in certain drivers, then a new PIPE CAP
> should be added, so that drivers that do support don't limited to the lowest
> common denominator.
>
> Note that this can happen in other places as well:
> - glBufferData
> - glTexImage of single level textures.
>
> Jose
>
>
>
> - Original Message -
>> Alternatively, individual drivers could actually implement
>> PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE. As far as I can tell only svga
>> currently implements that, and st_bufferobj_map_range() seems to be
>> the main
>> user. I wonder if in general PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE is
>> something
>> that should just be handled by the state trackers.
>>
>> As for the actual implementation, we could also try a map with
>> PIPE_TRANSFER_DONTBLOCK first, and avoid invalidating
>> _NEW_BUFFER_OBJECT in
>> some cases. I'm not sure if that's worth it without doing more
>> benchmarking
>> though, since in the typical case GL_MAP_INVALIDATE_BUFFER_BIT will
>> probably
>> imply that the buffer is in use.
>>
>> Signed-off-by: Henri Verbeet
>> ---
>> src/mesa/state_tracker/st_cb_bufferobjects.c | 15 +++
>> 1 files changed, 15 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c
>> b/src/mesa/state_tracker/st_cb_bufferobjects.c
>> index 7374bb0..7aa859e 100644
>> --- a/src/mesa/state_tracker/st_cb_bufferobjects.c
>> +++ b/src/mesa/state_tracker/st_cb_bufferobjects.c
>> @@ -332,6 +332,21 @@ st_bufferobj_map_range(struct gl_context *ctx,
>> GLenum target,
>> obj->Pointer = &st_bufferobj_zero_length;
>> }
>> else {
>> + if (flags & PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE) {
>> + struct pipe_resource *buffer;
>> +
>> + buffer = pipe_buffer_create(pipe->screen,
>> + st_obj->buffer->bind,
>> + st_obj->buffer->usage,
>> + st_obj->buffer->width0);
>> + if (buffer) {
>> + st_invalidate_state(ctx, _NEW_BUFFER_OBJECT);
>> + pipe_resource_reference(&st_obj->buffer, NULL);
>> + st_obj->buffer = buffer;
>> + flags &= ~PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE;
>> + }
>> + }
>> +
>> obj->Pointer = pipe_buffer_map_range(pipe,
>> st_obj->buffer,
>> offset, length,
>> --
>> 1.7.2.5
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39338] Mesa: LLVM dependency mishmash
https://bugs.freedesktop.org/show_bug.cgi?id=39338 --- Comment #1 from Droste 2011-07-18 10:10:50 PDT --- Created an attachment (id=49256) View: https://bugs.freedesktop.org/attachment.cgi?id=49256 Review: https://bugs.freedesktop.org/review?bug=39338&attachment=49256 Build fix with llvm 3.0svn This patch should fix the build errors -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] intel: Use the GLSL-based meta clear when available.
Improves glxgears performance 19.6% +/- 7.3% (second fps printout.
n=5).
---
src/mesa/drivers/dri/intel/intel_clear.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_clear.c
b/src/mesa/drivers/dri/intel/intel_clear.c
index dfca03c..35a9948 100644
--- a/src/mesa/drivers/dri/intel/intel_clear.c
+++ b/src/mesa/drivers/dri/intel/intel_clear.c
@@ -182,7 +182,10 @@ intelClear(struct gl_context *ctx, GLbitfield mask)
if (tri_mask) {
debug_mask("tri", tri_mask);
- _mesa_meta_Clear(&intel->ctx, tri_mask);
+ if (ctx->Extensions.ARB_fragment_shader)
+_mesa_meta_glsl_Clear(&intel->ctx, tri_mask);
+ else
+_mesa_meta_Clear(&intel->ctx, tri_mask);
}
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [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.
pgpvFjRi4OnoC.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] meta: Add a GLSL-based _mesa_meta_Clear() variant.
This cuts out a large portion of the overhead of glClear() from
resetting the texenv state and recomputing the fixed function
programs. It also means less use of fixed function internally in our
GLES2 drivers, which is rather bogus.
---
src/mesa/drivers/common/meta.c | 166
src/mesa/drivers/common/meta.h |3 +
2 files changed, 169 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 0e58aec..09d7186 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -62,6 +62,7 @@
#include "main/teximage.h"
#include "main/texparam.h"
#include "main/texstate.h"
+#include "main/uniforms.h"
#include "main/varray.h"
#include "main/viewport.h"
#include "program/program.h"
@@ -235,6 +236,8 @@ struct clear_state
{
GLuint ArrayObj;
GLuint VBO;
+ GLuint ShaderProg;
+ GLint ColorLocation;
};
@@ -1589,6 +1592,169 @@ _mesa_meta_Clear(struct gl_context *ctx, GLbitfield
buffers)
_mesa_meta_end(ctx);
}
+static void
+meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear)
+{
+ const char *vs_source =
+ "attribute vec4 position;\n"
+ "void main()\n"
+ "{\n"
+ " gl_Position = position;\n"
+ "}\n";
+ const char *fs_source =
+ "uniform vec4 color;\n"
+ "void main()\n"
+ "{\n"
+ " gl_FragColor = color;\n"
+ "}\n";
+ GLuint vs, fs;
+
+ if (clear->ArrayObj != 0)
+ return;
+
+ /* create vertex array object */
+ _mesa_GenVertexArrays(1, &clear->ArrayObj);
+ _mesa_BindVertexArray(clear->ArrayObj);
+
+ /* create vertex array buffer */
+ _mesa_GenBuffersARB(1, &clear->VBO);
+ _mesa_BindBufferARB(GL_ARRAY_BUFFER_ARB, clear->VBO);
+
+ /* setup vertex arrays */
+ _mesa_VertexAttribPointerARB(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float),
+ (void *)0);
+ _mesa_EnableVertexAttribArrayARB(0);
+
+ vs = _mesa_CreateShaderObjectARB(GL_VERTEX_SHADER);
+ _mesa_ShaderSourceARB(vs, 1, &vs_source, NULL);
+ _mesa_CompileShaderARB(vs);
+
+ fs = _mesa_CreateShaderObjectARB(GL_FRAGMENT_SHADER);
+ _mesa_ShaderSourceARB(fs, 1, &fs_source, NULL);
+ _mesa_CompileShaderARB(fs);
+
+ clear->ShaderProg = _mesa_CreateProgramObjectARB();
+ _mesa_AttachShader(clear->ShaderProg, fs);
+ _mesa_AttachShader(clear->ShaderProg, vs);
+ _mesa_BindAttribLocationARB(clear->ShaderProg, 0, "position");
+ _mesa_LinkProgramARB(clear->ShaderProg);
+
+ _mesa_DeleteShader(fs);
+ _mesa_DeleteShader(vs);
+
+ clear->ColorLocation = _mesa_GetUniformLocationARB(clear->ShaderProg,
+ "color");
+}
+
+/**
+ * Meta implementation of ctx->Driver.Clear() in terms of polygon rendering.
+ */
+void
+_mesa_meta_glsl_Clear(struct gl_context *ctx, GLbitfield buffers)
+{
+ struct clear_state *clear = &ctx->Meta->Clear;
+ /* save all state but scissor, pixel pack/unpack */
+ GLbitfield metaSave = (META_ALL -
+ META_SCISSOR -
+ META_PIXEL_STORE -
+ META_CONDITIONAL_RENDER);
+ const GLuint stencilMax = (1 << ctx->DrawBuffer->Visual.stencilBits) - 1;
+ struct gl_framebuffer *fb = ctx->DrawBuffer;
+ const float x0 = ((float)fb->_Xmin / fb->Width) * 2.0 - 1.0;
+ const float y0 = ((float)fb->_Ymin / fb->Height) * 2.0 - 1.0;
+ const float x1 = ((float)fb->_Xmax / fb->Width) * 2.0 - 1.0;
+ const float y1 = ((float)fb->_Ymax / fb->Height) * 2.0 - 1.0;
+ const float z = -invert_z(ctx->Depth.Clear);
+ struct vertex {
+ GLfloat x, y, z;
+ } verts[4];
+
+ metaSave = (META_ALPHA_TEST |
+ META_BLEND |
+ META_DEPTH_TEST |
+ META_RASTERIZATION |
+ META_SHADER |
+ META_STENCIL_TEST |
+ META_VERTEX |
+ META_VIEWPORT |
+ META_CLAMP_FRAGMENT_COLOR);
+
+ if (!(buffers & BUFFER_BITS_COLOR)) {
+ /* We'll use colormask to disable color writes. Otherwise,
+ * respect color mask
+ */
+ metaSave |= META_COLOR_MASK;
+ }
+
+ _mesa_meta_begin(ctx, metaSave);
+
+ meta_glsl_clear_init(ctx, clear);
+
+ _mesa_UseProgramObjectARB(clear->ShaderProg);
+ _mesa_Uniform4fvARB(clear->ColorLocation, 1,
+ ctx->Color.ClearColorUnclamped);
+
+ _mesa_BindVertexArray(clear->ArrayObj);
+ _mesa_BindBufferARB(GL_ARRAY_BUFFER_ARB, clear->VBO);
+
+ /* GL_COLOR_BUFFER_BIT */
+ if (buffers & BUFFER_BITS_COLOR) {
+ /* leave colormask, glDrawBuffer state as-is */
+
+ /* Clears never have the color clamped. */
+ _mesa_ClampColorARB(GL_CLAMP_FRAGMENT_COLOR, GL_FALSE);
+ }
+ else {
+ ASSERT(metaSave & META_COLOR_MASK);
+ _mesa_ColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);
+ }
+
+ /* GL_DEPTH_BUFFER_BIT */
+ if (buffers & BUFFER_BIT_DEPTH) {
+ _mesa_set_enable(ctx, GL_DEPTH_TEST, GL_TRUE);
Re: [Mesa-dev] RFC: ctx->Driver.Map/UnmapTextureImage() hooks
The classic nouveau driver supports nv04, nv1x, nv2x IIRC. I'm definitely not the right person for the job, but I'll look at it if nobody else can. ~ C. On Mon, Jul 18, 2011 at 7:09 AM, Brian Paul wrote: > On 07/15/2011 02:59 PM, Pekka Paalanen wrote: >> >> On Fri, 15 Jul 2011 12:22:41 -0600 >> Brian Paul wrote: >> >>> On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paul wrote: > > > The map-texture-image-v4 branch that I just pushed implements > this change. It really cleaned things up for the better and > will lead to a few more follow-on improvements. > > There's no obvious regressions with swrast or the gallium > drivers. I updated the intel driver code and tested i915 and > it seems OK too, but I didn't do a full piglit run on it. I > also updated the legacy r600 driver in case anyone cares but > didn't do any testing of it. > > I didn't update any of the other legacy DRI drivers. Would > anyone object if we simply stop building mach64, r128, > unichrome, sis, etc? I'd be happy to remove those drivers > altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. >>> >>> Sounds good to me. I think we'd only keep the swrast, intel and >>> maybe r300/r600 drivers. Opinions? >> >> Um, don't kill nouveau_vieux, please. > > Does the old nouveau driver support some GPUs that the gallium nv50/nvc0 > drivers don't support? > > If we want to keep the older driver someone will need to volunteer to update > the code to support the new driver hooks. > > -Brian > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [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: [Mesa-dev] [PATCH 08/12] i915: Remove i965 paths from i915_update_drawbuffer() and i830's too.
On Wed, 13 Jul 2011 16:17:51 -0700, Chad Versace wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/12/2011 03:22 PM, Eric Anholt wrote: > > --- > > src/mesa/drivers/dri/i915/i830_vtbl.c | 46 > > +++- > > src/mesa/drivers/dri/i915/i915_vtbl.c | 47 > > +++-- > > 2 files changed, 20 insertions(+), 73 deletions(-) > > > > diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c > > b/src/mesa/drivers/dri/i915/i830_vtbl.c > > index 7dba135..2a97c6f 100644 > > --- a/src/mesa/drivers/dri/i915/i830_vtbl.c > > +++ b/src/mesa/drivers/dri/i915/i830_vtbl.c > > @@ -825,12 +825,7 @@ i830_update_draw_buffer(struct intel_context *intel) > > Here you should add this delta. Sweet. I thought about this delta at one point, then decided I wasn't sure enough to do it up front. Thanks for the review! pgpTC3QGMQ9dO.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [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. pgpNaSyARW7aM.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: fix timer query on gen6+
On Mon, 18 Jul 2011 09:19:32 +0800, "Zou, Nanhai" wrote:
> >>-Original Message-
> >>From: Eric Anholt [mailto:e...@anholt.net]
> >>Sent: 2011年7月17日 8:08
> >>To: Zou, Nanhai; mesa-dev@lists.freedesktop.org
> >>Subject: Re: [Mesa-dev] [PATCH] i965: fix timer query on gen6+
> >>
> >>On Fri, 15 Jul 2011 18:07:51 +0800, Zou Nan hai
> >>wrote:
> >>> on gen6+, PIPE_CONTROL reported timestamp counter is a
> >>> 64 bits value, toggles every 80 ns
> >>
> >>> @@ -58,7 +58,10 @@ brw_queryobj_get_results(struct brw_query_object
> >>> *query)
> >>> drm_intel_bo_map(query->bo, GL_FALSE);
> >>> results = query->bo->virtual;
> >>> if (query->Base.Target == GL_TIME_ELAPSED_EXT) {
> >>> - query->Base.Result += 1000 * ((results[1] >> 32) - (results[0] >>
> >>32));
> >>> + if (gen >= 6)
> >>> + query->Base.Result += 80 * (results[1] - results[0]);
> >>> + else
> >>> + query->Base.Result += 1000 * ((results[1] >> 32) - (results[0]
> >>> >>
> >>32));
> >>
> >>You've mangled the whitespace here. Also, bits 32:63 appear to be
> >>reserved and should be ignored.
>
> I can't find that information in bspec. Bspec says it is a 64 bit value.
Oh, wait, it's MBZ. Sorry. From the Sandybridge PRM, Vol1 Part3, page 73:
"63:36 Reserved Project: All Format: MBZ
35:0 Timestamp Value Project:All Format: U32
This register toggles every 80 ns of time."
pgpBoXk2VIqKA.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().
Hi, On Monday, July 18, 2011 18:28:26 Marek Olšák wrote: > We can't do try-map + create + map + dereference internally in a > driver. Creating a new buffer and replacing a pointer to the old one > may lead to the following issue. If a buffer pointer is replaced, it > doesn't necessarily update all the states the buffer is set in in all > existing contexts. Such states and contexts would still use the old > buffer and wouldn't see the change until the old buffer is unbound. Sadly yes. > I think the only correct way to implement the DISCARD flags in drivers > is through a temporary (staging) resource and doing an on-gpu copy to > the original one (i.e. what we do for texture transfers in rX00g). Which is a bit heavyweight I think. At least for the PIPE_DISCARD_WHOLE_RESOURCE case. The main use case I think of is buffer object streaming with possibly *huge* buffer object data. You would do map/unmap pairs with the unsyncronized flag . Once your buffer has filled up, you need to detach from the old one, just leaving the old one around until it is no longer used. An extra copy should not be required for this case. I hoped to find some time to implement something with atomic generation counts. So having a atomic buffer object change counter in some struct that is shared across contexts and one counter in each context that is used to revalidate the buffer objects for this case. We got something similar than that, for revalidating render buffers with ac8fdbc1c723afb19eeaba5457ba78d0bf33b8d4. I am not exactly sure if I miss something, and I did not find the time to try out myself. But may be this thought helps avoiding may be needless copying? For the PIPE_DISCARD_RESOURCE flag, that operates only on a subset of the buffer objects data, the staging buffer object might be the way to go. Greetings Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Bump: glsl: revised unit tests for lower_jumps.cpp
This is a re-send of the unit tests for lower_jumps.cpp which I sent to the mailing list on July 8. I haven't received any comments yet, and since this is a rewrite of some patches that proved controversial, I'd appreciate some comments as to whether the issues from my previous submission have been adequately addressed. The concerns from the previous patch series (which was sent to the list on July 5) were, as I understood them, mainly about the maintainability and readability of the tests in the form the were in (a Python script which used a lot of auxiliary functions to build up the IR test vectors on the fly). To address these concerns, I've changed the tests into simple bash scripts. The input IR, and the expected output, are now visible in the source files in their standard S-expression form. I believe the patches as they stand now address all the concerns that were brought up. If I don't hear anything by Friday July 22, I'll assume that there aren't any concerns remaining and go ahead and push the patches. Thanks, Paul [PATCH 1/4] mesa: Add an ifndef guard around the definition of the INLINE macro [PATCH 2/4] glsl: Move initialize_context() to glsl_parser_extras.cpp so it can be re-used. [PATCH 3/4] glsl: Create a standalone executable for testing optimization passes. [PATCH 4/4] glsl: Add unit tests for lower_jumps.cpp ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] mesa: Add an ifndef guard around the definition of the INLINE macro
Several headers redundantly define the INLINE macro. Adding this
guard prevents the compiler from complaining about macro redefinition.
---
src/mesa/main/compiler.h | 42 ++
1 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 743841b..d736fdf 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -139,26 +139,28 @@ extern "C" {
/**
* Function inlining
*/
-#if defined(__GNUC__)
-# define INLINE __inline__
-#elif defined(__MSC__)
-# define INLINE __inline
-#elif defined(_MSC_VER)
-# define INLINE __inline
-#elif defined(__ICL)
-# define INLINE __inline
-#elif defined(__INTEL_COMPILER)
-# define INLINE inline
-#elif defined(__WATCOMC__) && (__WATCOMC__ >= 1100)
-# define INLINE __inline
-#elif defined(__SUNPRO_C) && defined(__C99FEATURES__)
-# define INLINE inline
-# define __inline inline
-# define __inline__ inline
-#elif (__STDC_VERSION__ >= 199901L) /* C99 */
-# define INLINE inline
-#else
-# define INLINE
+#ifndef INLINE
+# if defined(__GNUC__)
+#define INLINE __inline__
+# elif defined(__MSC__)
+#define INLINE __inline
+# elif defined(_MSC_VER)
+#define INLINE __inline
+# elif defined(__ICL)
+#define INLINE __inline
+# elif defined(__INTEL_COMPILER)
+#define INLINE inline
+# elif defined(__WATCOMC__) && (__WATCOMC__ >= 1100)
+#define INLINE __inline
+# elif defined(__SUNPRO_C) && defined(__C99FEATURES__)
+#define INLINE inline
+#define __inline inline
+#define __inline__ inline
+# elif (__STDC_VERSION__ >= 199901L) /* C99 */
+#define INLINE inline
+# else
+#define INLINE
+# endif
#endif
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] glsl: Move initialize_context() to glsl_parser_extras.cpp so it can be re-used.
This function is used by main.cpp to initialize a context to a default
configuration for use in compiling builtins. Moved the bulk of it to
glsl_parser_extras.cpp so that it can be re-used in testing.
---
src/glsl/glsl_parser_extras.cpp | 33 +
src/glsl/glsl_parser_extras.h | 11 +++
src/glsl/main.cpp | 25 +
3 files changed, 45 insertions(+), 24 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index cc78137..936dbcc 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -926,6 +926,39 @@ do_common_optimization(exec_list *ir, bool linked,
unsigned max_unroll_iteration
return progress;
}
+void initialize_context_to_defaults(struct gl_context *ctx, gl_api api)
+{
+ memset(ctx, 0, sizeof(*ctx));
+
+ ctx->API = api;
+
+ ctx->Extensions.ARB_ES2_compatibility = GL_TRUE;
+ ctx->Extensions.ARB_draw_buffers = GL_TRUE;
+ ctx->Extensions.ARB_draw_instanced = GL_TRUE;
+ ctx->Extensions.ARB_fragment_coord_conventions = GL_TRUE;
+ ctx->Extensions.EXT_texture_array = GL_TRUE;
+ ctx->Extensions.NV_texture_rectangle = GL_TRUE;
+ ctx->Extensions.EXT_texture3D = GL_TRUE;
+
+ ctx->Const.GLSLVersion = 120;
+
+ /* 1.10 minimums. */
+ ctx->Const.MaxLights = 8;
+ ctx->Const.MaxClipPlanes = 6;
+ ctx->Const.MaxTextureUnits = 2;
+ ctx->Const.MaxTextureCoordUnits = 2;
+ ctx->Const.VertexProgram.MaxAttribs = 16;
+
+ ctx->Const.VertexProgram.MaxUniformComponents = 512;
+ ctx->Const.MaxVarying = 8;
+ ctx->Const.MaxVertexTextureImageUnits = 0;
+ ctx->Const.MaxCombinedTextureImageUnits = 2;
+ ctx->Const.MaxTextureImageUnits = 2;
+ ctx->Const.FragmentProgram.MaxUniformComponents = 64;
+
+ ctx->Const.MaxDrawBuffers = 2;
+}
+
extern "C" {
/**
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 2f4d3cb..3f88abd 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -33,6 +33,7 @@
#include
#include "glsl_symbol_table.h"
+#include "main/mtypes.h"
enum _mesa_glsl_parser_targets {
vertex_shader,
@@ -258,6 +259,16 @@ extern bool _mesa_glsl_process_extension(const char *name,
YYLTYPE *name_locp,
extern const char *
_mesa_glsl_shader_target_name(enum _mesa_glsl_parser_targets target);
+/**
+ * Initialize the given gl_context structure to a reasonable set of
+ * defaults representing the minimum capabilities required by the
+ * OpenGL spec.
+ *
+ * This is used when compiling builtin functions and in testing, when
+ * we don't have a connection to an actual driver.
+ */
+void initialize_context_to_defaults(struct gl_context *ctx, gl_api api);
+
#endif /* __cplusplus */
diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp
index 7952bb1..4cfcf0c 100644
--- a/src/glsl/main.cpp
+++ b/src/glsl/main.cpp
@@ -66,43 +66,20 @@ _mesa_new_shader(struct gl_context *ctx, GLuint name,
GLenum type)
static void
initialize_context(struct gl_context *ctx, gl_api api)
{
- memset(ctx, 0, sizeof(*ctx));
-
- ctx->API = api;
-
- ctx->Extensions.ARB_ES2_compatibility = GL_TRUE;
- ctx->Extensions.ARB_draw_buffers = GL_TRUE;
- ctx->Extensions.ARB_draw_instanced = GL_TRUE;
- ctx->Extensions.ARB_fragment_coord_conventions = GL_TRUE;
- ctx->Extensions.EXT_texture_array = GL_TRUE;
- ctx->Extensions.NV_texture_rectangle = GL_TRUE;
- ctx->Extensions.EXT_texture3D = GL_TRUE;
+ initialize_context_to_defaults(ctx, api);
/* GLSL 1.30 isn't fully supported, but we need to advertise 1.30 so that
* the built-in functions for 1.30 can be built.
*/
ctx->Const.GLSLVersion = 130;
- /* 1.10 minimums. */
- ctx->Const.MaxLights = 8;
ctx->Const.MaxClipPlanes = 8;
- ctx->Const.MaxTextureUnits = 2;
/* More than the 1.10 minimum to appease parser tests taken from
* apps that (hopefully) already checked the number of coords.
*/
ctx->Const.MaxTextureCoordUnits = 4;
- ctx->Const.VertexProgram.MaxAttribs = 16;
- ctx->Const.VertexProgram.MaxUniformComponents = 512;
- ctx->Const.MaxVarying = 8;
- ctx->Const.MaxVertexTextureImageUnits = 0;
- ctx->Const.MaxCombinedTextureImageUnits = 2;
- ctx->Const.MaxTextureImageUnits = 2;
- ctx->Const.FragmentProgram.MaxUniformComponents = 64;
-
- ctx->Const.MaxDrawBuffers = 2;
-
ctx->Driver.NewShader = _mesa_new_shader;
}
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] glsl: Create a standalone executable for testing optimization passes.
This patch adds a new build artifact, glsl_test, which can be used for testing optimization passes in isolation. I'm hoping that we will be able to add other useful standalone tests to this executable in the future. Accordingly, it is built in a modular fashion: the main() function uses its first argument to determine which test function to invoke, removes that argument from argv[], and then calls that function to interpret the rest of the command line arguments and perform the test. Currently the only test function is "optpass", which tests optimization passes. --- src/glsl/.gitignore |1 + src/glsl/Makefile | 23 +++- src/glsl/test.cpp | 78 src/glsl/test_optpass.cpp | 289 + src/glsl/test_optpass.h | 30 + 5 files changed, 418 insertions(+), 3 deletions(-) create mode 100644 src/glsl/test.cpp create mode 100644 src/glsl/test_optpass.cpp create mode 100644 src/glsl/test_optpass.h diff --git a/src/glsl/.gitignore b/src/glsl/.gitignore index dfbd572..d26839a 100644 --- a/src/glsl/.gitignore +++ b/src/glsl/.gitignore @@ -5,3 +5,4 @@ glsl_parser.h glsl_parser.output builtin_function.cpp builtin_compiler +glsl_test diff --git a/src/glsl/Makefile b/src/glsl/Makefile index e0776c1..f574e27 100644 --- a/src/glsl/Makefile +++ b/src/glsl/Makefile @@ -88,7 +88,7 @@ CXX_SOURCES = \ LIBS = \ $(TOP)/src/glsl/libglsl.a -APPS = glsl_compiler glcpp/glcpp +APPS = glsl_compiler glsl_test glcpp/glcpp GLSL2_C_SOURCES = \ ../mesa/program/hash_table.c \ @@ -100,6 +100,18 @@ GLSL2_OBJECTS = \ $(GLSL2_C_SOURCES:.c=.o) \ $(GLSL2_CXX_SOURCES:.cpp=.o) +TEST_C_SOURCES = \ + ../mesa/program/hash_table.c \ + ../mesa/program/symbol_table.c + +TEST_CXX_SOURCES = \ + test.cpp \ + test_optpass.cpp + +TEST_OBJECTS = \ + $(TEST_C_SOURCES:.c=.o) \ + $(TEST_CXX_SOURCES:.cpp=.o) + ### Basic defines ### DEFINES += \ @@ -128,7 +140,9 @@ ALL_SOURCES = \ $(C_SOURCES) \ $(CXX_SOURCES) \ $(GLSL2_CXX_SOURCES) \ - $(GLSL2_C_SOURCES) + $(GLSL2_C_SOURCES) \ + $(TEST_CXX_SOURCES) \ + $(TEST_C_SOURCES) # TARGETS # @@ -150,7 +164,7 @@ depend: $(ALL_SOURCES) Makefile # Remove .o and backup files clean: clean-dricore - rm -f $(GLCPP_OBJECTS) $(GLSL2_OBJECTS) $(OBJECTS) lib$(LIBNAME).a depend depend.bak builtin_function.cpp builtin_function.o builtin_stubs.o builtin_compiler + rm -f $(GLCPP_OBJECTS) $(GLSL2_OBJECTS) $(TEST_OBJECTS) $(OBJECTS) lib$(LIBNAME).a depend depend.bak builtin_function.cpp builtin_function.o builtin_stubs.o builtin_compiler -rm -f $(APPS) clean-dricore: @@ -173,6 +187,9 @@ install-dricore: default glsl_compiler: $(GLSL2_OBJECTS) libglsl.a builtin_stubs.o $(APP_CXX) $(INCLUDES) $(CFLAGS) $(LDFLAGS) $(GLSL2_OBJECTS) builtin_stubs.o $(LIBS) -o $@ +glsl_test: $(TEST_OBJECTS) libglsl.a builtin_stubs.o + $(APP_CXX) $(INCLUDES) $(CFLAGS) $(LDFLAGS) $(TEST_OBJECTS) builtin_stubs.o $(LIBS) -o $@ + glcpp: glcpp/glcpp glcpp/glcpp: $(GLCPP_OBJECTS) $(APP_CC) $(INCLUDES) $(CFLAGS) $(LDFLAGS) $(GLCPP_OBJECTS) -o $@ diff --git a/src/glsl/test.cpp b/src/glsl/test.cpp new file mode 100644 index 000..b1ff92e --- /dev/null +++ b/src/glsl/test.cpp @@ -0,0 +1,78 @@ +/* + * Copyright © 2011 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ + +/** + * \file test.cpp + * + * Standalone tests for the GLSL compiler. + * + * This file provides a standalone executable which can be used to + * test components of the GLSL. + * + * Each test is a function with the same signature as main(). The + * main function interprets its first argument as the name of the test + * to run, strips out that argument, and then calls the test function. + */ + +#include +#include +#include + +#
Re: [Mesa-dev] [PATCH 1/2] glx: Avoid calling __glXInitialize() in driReleaseDrawables().
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/17/2011 04:41 PM, Henri Verbeet wrote:
> This fixes a regression introduced by commit
> a26121f37530619610a78a5fbe5ef87e44047fda (fd.o bug #39219).
>
> Since the __glXInitialize() call should be unnecessary anyway, this is
> probably a nicer fix for the original problem too.
>
> NOTE: This is a candidate for the 7.10 and 7.11 branches.
>
> Signed-off-by: Henri Verbeet
Reviewed-by: Ian Romanick
If this made things work on the reporter's machine, you should add a
Tested-by too.
> ---
> src/glx/dri_common.c |2 +-
> src/glx/glxext.c | 11 +++
> 2 files changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
> index bac0c9e..e7dba5a 100644
> --- a/src/glx/dri_common.c
> +++ b/src/glx/dri_common.c
> @@ -388,7 +388,7 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable
> glxDrawable)
> _X_HIDDEN void
> driReleaseDrawables(struct glx_context *gc)
> {
> - struct glx_display *const priv = __glXInitialize(gc->psc->dpy);
> + const struct glx_display *priv = gc->psc->display;
> __GLXDRIdrawable *pdraw;
>
> if (priv == NULL)
> diff --git a/src/glx/glxext.c b/src/glx/glxext.c
> index 8704c48..8254544 100644
> --- a/src/glx/glxext.c
> +++ b/src/glx/glxext.c
> @@ -260,24 +260,19 @@ glx_display_free(struct glx_display *priv)
> static int
> __glXCloseDisplay(Display * dpy, XExtCodes * codes)
> {
> - struct glx_display *priv, **prev, *next;
> + struct glx_display *priv, **prev;
>
> _XLockMutex(_Xglobal_lock);
> prev = &glx_displays;
> for (priv = glx_displays; priv; prev = &priv->next, priv = priv->next) {
>if (priv->dpy == dpy) {
> + *prev = priv->next;
>break;
>}
> }
> + _XUnlockMutex(_Xglobal_lock);
>
> - /* Only remove the display from the list after it's destroyed. The cleanup
> -* code (e.g. driReleaseDrawables()) ends up calling __glXInitialize(),
> -* which would create a new glx_display while we're trying to destroy this
> -* one. */
> - next = priv->next;
> glx_display_free(priv);
> - *prev = next;
> - _XUnlockMutex(_Xglobal_lock);
>
> return 1;
> }
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4kfgMACgkQX1gOwKyEAw9O/ACdGgSVIvnuSackV4cQCR2tKnOf
hKMAn39DuCOANrqt8RBl7cEllSDZQJ4b
=KZVd
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [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-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] meta: Add a GLSL-based _mesa_meta_Clear() variant.
On 07/18/2011 10:33 AM, Eric Anholt wrote:
This cuts out a large portion of the overhead of glClear() from
resetting the texenv state and recomputing the fixed function
programs. It also means less use of fixed function internally in our
GLES2 drivers, which is rather bogus.
Looks good. Only minor comments below.
Reviewed-by: Brian Paul
---
src/mesa/drivers/common/meta.c | 166
src/mesa/drivers/common/meta.h |3 +
2 files changed, 169 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 0e58aec..09d7186 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -62,6 +62,7 @@
#include "main/teximage.h"
#include "main/texparam.h"
#include "main/texstate.h"
+#include "main/uniforms.h"
#include "main/varray.h"
#include "main/viewport.h"
#include "program/program.h"
@@ -235,6 +236,8 @@ struct clear_state
{
GLuint ArrayObj;
GLuint VBO;
+ GLuint ShaderProg;
+ GLint ColorLocation;
};
@@ -1589,6 +1592,169 @@ _mesa_meta_Clear(struct gl_context *ctx, GLbitfield
buffers)
_mesa_meta_end(ctx);
}
+static void
+meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear)
+{
+ const char *vs_source =
+ "attribute vec4 position;\n"
+ "void main()\n"
+ "{\n"
+ " gl_Position = position;\n"
+ "}\n";
+ const char *fs_source =
+ "uniform vec4 color;\n"
+ "void main()\n"
+ "{\n"
+ " gl_FragColor = color;\n"
+ "}\n";
+ GLuint vs, fs;
+
/* check if GLSL-clear state already initialized */
+ if (clear->ArrayObj != 0)
+ return;
+
+ /* create vertex array object */
+ _mesa_GenVertexArrays(1,&clear->ArrayObj);
+ _mesa_BindVertexArray(clear->ArrayObj);
+
+ /* create vertex array buffer */
+ _mesa_GenBuffersARB(1,&clear->VBO);
+ _mesa_BindBufferARB(GL_ARRAY_BUFFER_ARB, clear->VBO);
+
+ /* setup vertex arrays */
+ _mesa_VertexAttribPointerARB(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float),
+ (void *)0);
You can pass stride=0 here, and I'd use NULL:
_mesa_VertexAttribPointerARB(0, 3, GL_FLOAT, GL_FALSE, 0, NULL);
+ _mesa_EnableVertexAttribArrayARB(0);
+
+ vs = _mesa_CreateShaderObjectARB(GL_VERTEX_SHADER);
+ _mesa_ShaderSourceARB(vs, 1,&vs_source, NULL);
+ _mesa_CompileShaderARB(vs);
+
+ fs = _mesa_CreateShaderObjectARB(GL_FRAGMENT_SHADER);
+ _mesa_ShaderSourceARB(fs, 1,&fs_source, NULL);
+ _mesa_CompileShaderARB(fs);
+
+ clear->ShaderProg = _mesa_CreateProgramObjectARB();
+ _mesa_AttachShader(clear->ShaderProg, fs);
+ _mesa_AttachShader(clear->ShaderProg, vs);
+ _mesa_BindAttribLocationARB(clear->ShaderProg, 0, "position");
+ _mesa_LinkProgramARB(clear->ShaderProg);
+
+ _mesa_DeleteShader(fs);
+ _mesa_DeleteShader(vs);
I think these deletes could be omitted. It might be confusing to the
casual reader.
+ clear->ColorLocation = _mesa_GetUniformLocationARB(clear->ShaderProg,
+ "color");
+}
+
+/**
+ * Meta implementation of ctx->Driver.Clear() in terms of polygon rendering.
"and GLSL shaders".
+ */
+void
+_mesa_meta_glsl_Clear(struct gl_context *ctx, GLbitfield buffers)
+{
+ struct clear_state *clear =&ctx->Meta->Clear;
+ /* save all state but scissor, pixel pack/unpack */
+ GLbitfield metaSave = (META_ALL -
+ META_SCISSOR -
+ META_PIXEL_STORE -
+ META_CONDITIONAL_RENDER);
+ const GLuint stencilMax = (1<< ctx->DrawBuffer->Visual.stencilBits) - 1;
+ struct gl_framebuffer *fb = ctx->DrawBuffer;
+ const float x0 = ((float)fb->_Xmin / fb->Width) * 2.0 - 1.0;
+ const float y0 = ((float)fb->_Ymin / fb->Height) * 2.0 - 1.0;
+ const float x1 = ((float)fb->_Xmax / fb->Width) * 2.0 - 1.0;
+ const float y1 = ((float)fb->_Ymax / fb->Height) * 2.0 - 1.0;
I'd put 'f' suffixes on those constants to avoid float/double conversions.
+ const float z = -invert_z(ctx->Depth.Clear);
+ struct vertex {
+ GLfloat x, y, z;
+ } verts[4];
+
+ metaSave = (META_ALPHA_TEST |
+ META_BLEND |
+ META_DEPTH_TEST |
+ META_RASTERIZATION |
+ META_SHADER |
+ META_STENCIL_TEST |
+ META_VERTEX |
+ META_VIEWPORT |
+ META_CLAMP_FRAGMENT_COLOR);
+
+ if (!(buffers& BUFFER_BITS_COLOR)) {
+ /* We'll use colormask to disable color writes. Otherwise,
+ * respect color mask
+ */
+ metaSave |= META_COLOR_MASK;
+ }
+
+ _mesa_meta_begin(ctx, metaSave);
+
+ meta_glsl_clear_init(ctx, clear);
+
+ _mesa_UseProgramObjectARB(clear->ShaderProg);
+ _mesa_Uniform4fvARB(clear->ColorLocation, 1,
+ ctx->Color.ClearColorUnclamped);
+
+ _mesa_BindVertexArray(clear->ArrayObj);
+ _mesa_BindBufferARB(GL_ARRAY_BUFFER_ARB, clear->VBO)
Re: [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: [Mesa-dev] [PATCH] glsl: Avoid massive ralloc_strndup overhead in S-Expression parsing.
On 15 July 2011 03:16, Kenneth Graunke wrote:
> When parsing S-Expressions, we need to store nul-terminated strings for
> Symbol nodes. Prior to this patch, we called ralloc_strndup each time
> we constructed a new s_symbol. It turns out that this is obscenely
> expensive.
>
> Instead, copy the whole buffer before parsing and overwrite it to
> contain \0 bytes at the appropriate locations. Since atoms are
> separated by whitespace, (), or ;, we can safely overwrite the character
> after a Symbol. While much of the buffer may be unused, copying the
> whole buffer is simple and guaranteed to provide enough space.
>
> Prior to this, running piglit-run.py -t glsl tests/quick.tests with GLSL
> 1.30 enabled took just over 10 minutes on my machine. Now it takes 5.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/s_expression.cpp | 64
> src/glsl/s_expression.h | 2 +-
> 2 files changed, 47 insertions(+), 19 deletions(-)
>
> Seriously! 50% faster piglit runs! I should've done this ages ago.
>
> diff --git a/src/glsl/s_expression.cpp b/src/glsl/s_expression.cpp
> index a922a50..e704a3b 100644
> --- a/src/glsl/s_expression.cpp
> +++ b/src/glsl/s_expression.cpp
> @@ -25,10 +25,13 @@
> #include
> #include "s_expression.h"
>
> -s_symbol::s_symbol(const char *tmp, size_t n)
> +s_symbol::s_symbol(const char *str, size_t n)
> {
> - this->str = ralloc_strndup (this, tmp, n);
> - assert(this->str != NULL);
> + /* Assume the given string is already nul-terminated and in memory that
> + * will live as long as this node.
> + */
> + assert(str[n] == '\0');
> + this->str = str;
> }
>
> s_list::s_list()
> @@ -36,22 +39,26 @@ s_list::s_list()
> }
>
> static void
> -skip_whitespace(const char *& src)
> +skip_whitespace(const char *&src, char *&symbol_buffer)
> {
> - src += strspn(src, " \v\t\r\n");
> + size_t n = strspn(src, " \v\t\r\n");
> + src += n;
> + symbol_buffer += n;
> /* Also skip Scheme-style comments: semi-colon 'til end of line */
> if (src[0] == ';') {
> - src += strcspn(src, "\n");
> - skip_whitespace(src);
> + n = strcspn(src, "\n");
> + src += n;
> + symbol_buffer += n;
> + skip_whitespace(src, symbol_buffer);
> }
> }
>
> static s_expression *
> -read_atom(void *ctx, const char *& src)
> +read_atom(void *ctx, const char *&src, char *&symbol_buffer)
> {
> s_expression *expr = NULL;
>
> - skip_whitespace(src);
> + skip_whitespace(src, symbol_buffer);
>
> size_t n = strcspn(src, "( \v\t\r\n);");
> if (n == 0)
> @@ -70,44 +77,65 @@ read_atom(void *ctx, const char *& src)
> expr = new(ctx) s_int(i);
> } else {
> // Not a number; return a symbol.
> - expr = new(ctx) s_symbol(src, n);
> + symbol_buffer[n] = '\0';
> + expr = new(ctx) s_symbol(symbol_buffer, n);
> }
>
> src += n;
> + symbol_buffer += n;
>
> return expr;
> }
>
> -s_expression *
> -s_expression::read_expression(void *ctx, const char *&src)
> +static s_expression *
> +__read_expression(void *ctx, const char *&src, char *&symbol_buffer)
> {
> - assert(src != NULL);
> -
> - s_expression *atom = read_atom(ctx, src);
> + s_expression *atom = read_atom(ctx, src, symbol_buffer);
> if (atom != NULL)
> return atom;
>
> - skip_whitespace(src);
> + skip_whitespace(src, symbol_buffer);
> if (src[0] == '(') {
> ++src;
> + ++symbol_buffer;
>
> s_list *list = new(ctx) s_list;
> s_expression *expr;
>
> - while ((expr = read_expression(ctx, src)) != NULL) {
> + while ((expr = __read_expression(ctx, src, symbol_buffer)) != NULL) {
> list->subexpressions.push_tail(expr);
> }
> - skip_whitespace(src);
> + skip_whitespace(src, symbol_buffer);
> if (src[0] != ')') {
> printf("Unclosed expression (check your parenthesis).\n");
> return NULL;
> }
> ++src;
> + ++symbol_buffer;
> return list;
> }
> return NULL;
> }
>
> +s_expression *
> +s_expression::read_expression(void *ctx, const char *&src)
> +{
> + assert(src != NULL);
> +
> + /* When we encounter a Symbol, we need to save a nul-terminated copy of
> + * the string. However, ralloc_strndup'ing every individual Symbol is
> + * extremely expensive. We could avoid this by simply overwriting the
> + * next character (guaranteed to be whitespace, parens, or semicolon) with
> + * a nul-byte. But overwriting non-whitespace would mess up parsing.
> + *
> + * So, just copy the whole buffer ahead of time. Walk both, leaving the
> + * original source string unmodified, and altering the copy to contain the
> + * necessary nul-bytes whenever we encounter a symbol.
> + */
> + char *symbol_buffer = ralloc_strdup(ctx, src);
> + return __read_expression(ctx, src, symbol_buffer);
> +}
> +
> void s_int::print()
> {
> printf("%d", this->val);
> diff --git a/src/glsl/s_expression.h b/
Re: [Mesa-dev] [PATCH 1/4] mesa: Add an ifndef guard around the definition of the INLINE macro
On 07/18/2011 12:37 PM, Paul Berry wrote:
Several headers redundantly define the INLINE macro. Adding this
guard prevents the compiler from complaining about macro redefinition.
Other Mesa headers? Or system headers? Or?
Reviewed-by: Brian Paul
---
src/mesa/main/compiler.h | 42 ++
1 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 743841b..d736fdf 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -139,26 +139,28 @@ extern "C" {
/**
* Function inlining
*/
-#if defined(__GNUC__)
-# define INLINE __inline__
-#elif defined(__MSC__)
-# define INLINE __inline
-#elif defined(_MSC_VER)
-# define INLINE __inline
-#elif defined(__ICL)
-# define INLINE __inline
-#elif defined(__INTEL_COMPILER)
-# define INLINE inline
-#elif defined(__WATCOMC__)&& (__WATCOMC__>= 1100)
-# define INLINE __inline
-#elif defined(__SUNPRO_C)&& defined(__C99FEATURES__)
-# define INLINE inline
-# define __inline inline
-# define __inline__ inline
-#elif (__STDC_VERSION__>= 199901L) /* C99 */
-# define INLINE inline
-#else
-# define INLINE
+#ifndef INLINE
+# if defined(__GNUC__)
+#define INLINE __inline__
+# elif defined(__MSC__)
+#define INLINE __inline
+# elif defined(_MSC_VER)
+#define INLINE __inline
+# elif defined(__ICL)
+#define INLINE __inline
+# elif defined(__INTEL_COMPILER)
+#define INLINE inline
+# elif defined(__WATCOMC__)&& (__WATCOMC__>= 1100)
+#define INLINE __inline
+# elif defined(__SUNPRO_C)&& defined(__C99FEATURES__)
+#define INLINE inline
+#define __inline inline
+#define __inline__ inline
+# elif (__STDC_VERSION__>= 199901L) /* C99 */
+#define INLINE inline
+# else
+#define INLINE
+# endif
#endif
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx->Driver.Map/UnmapTextureImage() hooks
On Mon, 18 Jul 2011 08:09:17 -0600 Brian Paul wrote: > On 07/15/2011 02:59 PM, Pekka Paalanen wrote: > > On Fri, 15 Jul 2011 12:22:41 -0600 > > Brian Paul wrote: > > > >> On 07/15/2011 10:07 AM, Dave Airlie wrote: > >>> On Fri, Jul 15, 2011 at 4:10 AM, Brian > >>> Paul wrote: > > > The map-texture-image-v4 branch that I just pushed implements > this change. It really cleaned things up for the better and > will lead to a few more follow-on improvements. > > There's no obvious regressions with swrast or the gallium > drivers. I updated the intel driver code and tested i915 and > it seems OK too, but I didn't do a full piglit run on it. I > also updated the legacy r600 driver in case anyone cares but > didn't do any testing of it. > > I didn't update any of the other legacy DRI drivers. Would > anyone object if we simply stop building mach64, r128, > unichrome, sis, etc? I'd be happy to remove those drivers > altogether for that matter. > >>> > >>> we could EOL those in 7.11, and if anyone wants to ship them, > >>> they can just build 7.11 for them. > >> > >> Sounds good to me. I think we'd only keep the swrast, intel > >> and maybe r300/r600 drivers. Opinions? > > > > Um, don't kill nouveau_vieux, please. > > Does the old nouveau driver support some GPUs that the gallium > nv50/nvc0 drivers don't support? Yes. Like Corbin said, 'nouveau_vieux' is for NV04-NV2x, while the gallium driver 'nouveau' supports NV30 and later. http://nouveau.freedesktop.org/wiki/MesaDrivers > If we want to keep the older driver someone will need to > volunteer to update the code to support the new driver hooks. Sorry, I cannot promise that. Nouveau_vieux seems to have been missing a maintainer for some time now. Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] meta: Add a GLSL-based _mesa_meta_Clear() variant.
On 07/18/2011 12:47 PM, Brian Paul wrote:
On 07/18/2011 10:33 AM, Eric Anholt wrote:
This cuts out a large portion of the overhead of glClear() from
resetting the texenv state and recomputing the fixed function
programs. It also means less use of fixed function internally in our
GLES2 drivers, which is rather bogus.
Looks good. Only minor comments below.
Reviewed-by: Brian Paul
---
src/mesa/drivers/common/meta.c | 166
src/mesa/drivers/common/meta.h | 3 +
2 files changed, 169 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c
b/src/mesa/drivers/common/meta.c
index 0e58aec..09d7186 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -62,6 +62,7 @@
#include "main/teximage.h"
#include "main/texparam.h"
#include "main/texstate.h"
+#include "main/uniforms.h"
#include "main/varray.h"
#include "main/viewport.h"
#include "program/program.h"
@@ -235,6 +236,8 @@ struct clear_state
{
GLuint ArrayObj;
GLuint VBO;
+ GLuint ShaderProg;
+ GLint ColorLocation;
};
@@ -1589,6 +1592,169 @@ _mesa_meta_Clear(struct gl_context *ctx,
GLbitfield buffers)
_mesa_meta_end(ctx);
}
+static void
+meta_glsl_clear_init(struct gl_context *ctx, struct clear_state
*clear)
+{
+ const char *vs_source =
+ "attribute vec4 position;\n"
+ "void main()\n"
+ "{\n"
+ " gl_Position = position;\n"
+ "}\n";
+ const char *fs_source =
+ "uniform vec4 color;\n"
+ "void main()\n"
+ "{\n"
+ " gl_FragColor = color;\n"
+ "}\n";
+ GLuint vs, fs;
+
/* check if GLSL-clear state already initialized */
+ if (clear->ArrayObj != 0)
+ return;
+
+ /* create vertex array object */
+ _mesa_GenVertexArrays(1,&clear->ArrayObj);
+ _mesa_BindVertexArray(clear->ArrayObj);
+
+ /* create vertex array buffer */
+ _mesa_GenBuffersARB(1,&clear->VBO);
+ _mesa_BindBufferARB(GL_ARRAY_BUFFER_ARB, clear->VBO);
+
+ /* setup vertex arrays */
+ _mesa_VertexAttribPointerARB(0, 3, GL_FLOAT, GL_FALSE, 3 *
sizeof(float),
+ (void *)0);
You can pass stride=0 here, and I'd use NULL:
_mesa_VertexAttribPointerARB(0, 3, GL_FLOAT, GL_FALSE, 0, NULL);
Nevermind the NULL thing. (void*)0 emphasizes it's an offset.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx->Driver.Map/UnmapTextureImage() hooks
On 07/18/2011 01:00 PM, Pekka Paalanen wrote: On Mon, 18 Jul 2011 08:09:17 -0600 Brian Paul wrote: On 07/15/2011 02:59 PM, Pekka Paalanen wrote: On Fri, 15 Jul 2011 12:22:41 -0600 Brian Paul wrote: On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulwrote: The map-texture-image-v4 branch that I just pushed implements this change. It really cleaned things up for the better and will lead to a few more follow-on improvements. There's no obvious regressions with swrast or the gallium drivers. I updated the intel driver code and tested i915 and it seems OK too, but I didn't do a full piglit run on it. I also updated the legacy r600 driver in case anyone cares but didn't do any testing of it. I didn't update any of the other legacy DRI drivers. Would anyone object if we simply stop building mach64, r128, unichrome, sis, etc? I'd be happy to remove those drivers altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. Sounds good to me. I think we'd only keep the swrast, intel and maybe r300/r600 drivers. Opinions? Um, don't kill nouveau_vieux, please. Does the old nouveau driver support some GPUs that the gallium nv50/nvc0 drivers don't support? Yes. Like Corbin said, 'nouveau_vieux' is for NV04-NV2x, while the gallium driver 'nouveau' supports NV30 and later. http://nouveau.freedesktop.org/wiki/MesaDrivers If we want to keep the older driver someone will need to volunteer to update the code to support the new driver hooks. Sorry, I cannot promise that. Nouveau_vieux seems to have been missing a maintainer for some time now. Any of the older DRI drivers that get dropped could easily be revived later if someone wants to do the work. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().
2011/7/18 Mathias Fröhlich : > > Hi, > > On Monday, July 18, 2011 18:28:26 Marek Olšák wrote: >> We can't do try-map + create + map + dereference internally in a >> driver. Creating a new buffer and replacing a pointer to the old one >> may lead to the following issue. If a buffer pointer is replaced, it >> doesn't necessarily update all the states the buffer is set in in all >> existing contexts. Such states and contexts would still use the old >> buffer and wouldn't see the change until the old buffer is unbound. > Sadly yes. > >> I think the only correct way to implement the DISCARD flags in drivers >> is through a temporary (staging) resource and doing an on-gpu copy to >> the original one (i.e. what we do for texture transfers in rX00g). > Which is a bit heavyweight I think. > At least for the PIPE_DISCARD_WHOLE_RESOURCE case. > > The main use case I think of is buffer object streaming with possibly *huge* > buffer object data. You would do map/unmap pairs with the unsyncronized flag . > Once your buffer has filled up, you need to detach from the old one, just > leaving the old one around until it is no longer used. An extra copy should > not be required for this case. The case you described doesn't need the DISCARD flags at all. You even mention that all you need is the unsychronized flag and grabbing a new buffer when needed. DISCARD is really just for stuff like transfer_inline_write, BufferData, BufferSubData (all those imply DISCARD), and whenever you need to do a non-blocking write-only transfer to an existing buffer. If you *can* grab a new buffer, it's always preferred to do so. There is another fact which should be taken into account. Considering that pipe_resource (or any struct derived from it) is a screen object, which means it can be shared among multiple contexts running on different threads, it either must not be changed during its lifetime or any read/write accesses to it must be guarded by mutexes. Otherwise very bad things may happen. The gpu copy ensures that pipe_resource (or any struct derived from it) is not changed during transfers. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [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: [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-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [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: [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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.
[Mesa-dev] [PATCH 0/8] Fix non-constant array-of-matrix accesses
As can be seen from the giant pile of tests recently sent to the piglit mailing list for review, the lower_variable_index_to_cond_assign pass had some issues. With this patch series, *all* of the variable indexing tests posted to the piglit list pass with (classic) swrast. 102 additional tests pass on the i965 driver. See also: http://people.freedesktop.org/~idr/variable-indexing-results/ src/glsl/lower_variable_index_to_cond_assign.cpp | 176 ++ src/glsl/lower_vec_index_to_cond_assign.cpp | 29 +++- src/mesa/drivers/dri/i965/brw_vs_emit.c | 12 +- src/mesa/program/ir_to_mesa.cpp | 14 ++- 4 files changed, 195 insertions(+), 36 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/8] glsl: Move is_array_or_matrix outside visitor class
From: Ian Romanick
There's no reason for it to be there, and another class that may not
have access to the visitor will need it soon.
---
src/glsl/lower_variable_index_to_cond_assign.cpp | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/glsl/lower_variable_index_to_cond_assign.cpp
b/src/glsl/lower_variable_index_to_cond_assign.cpp
index 8eb1612..45adb26 100644
--- a/src/glsl/lower_variable_index_to_cond_assign.cpp
+++ b/src/glsl/lower_variable_index_to_cond_assign.cpp
@@ -37,6 +37,12 @@
#include "glsl_types.h"
#include "main/macros.h"
+static inline bool
+is_array_or_matrix(const ir_instruction *ir)
+{
+ return (ir->type->is_array() || ir->type->is_matrix());
+}
+
struct assignment_generator
{
ir_instruction* base_ir;
@@ -233,11 +239,6 @@ public:
bool lower_temps;
bool lower_uniforms;
- bool is_array_or_matrix(const ir_instruction *ir) const
- {
- return (ir->type->is_array() || ir->type->is_matrix());
- }
-
bool needs_lowering(ir_dereference_array *deref) const
{
if (deref == NULL || deref->array_index->as_constant()
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/8] glsl: Split out part of variable_index_to_cond_assign_visitor::needs_lowering
From: Ian Romanick
Other code will soon need to know if an array needs lowering based
exclusively on the storage mode.
---
src/glsl/lower_variable_index_to_cond_assign.cpp | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/glsl/lower_variable_index_to_cond_assign.cpp
b/src/glsl/lower_variable_index_to_cond_assign.cpp
index 45adb26..c0b69c8 100644
--- a/src/glsl/lower_variable_index_to_cond_assign.cpp
+++ b/src/glsl/lower_variable_index_to_cond_assign.cpp
@@ -239,12 +239,8 @@ public:
bool lower_temps;
bool lower_uniforms;
- bool needs_lowering(ir_dereference_array *deref) const
+ bool storage_type_needs_lowering(ir_dereference_array *deref) const
{
- if (deref == NULL || deref->array_index->as_constant()
- || !is_array_or_matrix(deref->array))
-return false;
-
if (deref->array->ir_type == ir_type_constant)
return this->lower_temps;
@@ -268,6 +264,15 @@ public:
return false;
}
+ bool needs_lowering(ir_dereference_array *deref) const
+ {
+ if (deref == NULL || deref->array_index->as_constant()
+ || !is_array_or_matrix(deref->array))
+return false;
+
+ return this->storage_type_needs_lowering(deref);
+ }
+
ir_variable *convert_dereference_array(ir_dereference_array *orig_deref,
ir_assignment* orig_assign)
{
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/8] glsl: Rework lowering of non-constant array indexing
From: Ian Romanick
The previous implementation could easily get tricked if the LHS of an
assignment included a non-constant index that was "inside" another
dereference. For example:
mat4 m[2];
m[0][i] = vec4(0.0);
Due to the way it tracked whether the array was being assigned, it
would think that the non-constant index was in an r-value. The new
code fixes that by tracking l-values and r-values differently. The
index is also replaced by cloning the IR and replacing the index
variable instead of the odd way it was done before.
Fixes i965 piglit fs-temp-array-mat[234]-index-wr and
vs-varying-array-mat[234]-index-wr.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34691
---
src/glsl/lower_variable_index_to_cond_assign.cpp | 129 +++--
1 files changed, 116 insertions(+), 13 deletions(-)
diff --git a/src/glsl/lower_variable_index_to_cond_assign.cpp
b/src/glsl/lower_variable_index_to_cond_assign.cpp
index c0b69c8..03621b5 100644
--- a/src/glsl/lower_variable_index_to_cond_assign.cpp
+++ b/src/glsl/lower_variable_index_to_cond_assign.cpp
@@ -29,6 +29,21 @@
*
* Pre-DX10 GPUs often don't have a native way to do this operation,
* and this works around that.
+ *
+ * The lowering process proceeds as follows. Each non-constant index
+ * found in an r-value is converted to a canonical form \c array[i]. Each
+ * element of the array is conditionally assigned to a temporary by comparing
+ * \c i to a constant index. This is done by cloning the canonical form and
+ * replacing all occurances of \c i with a constant. Each remaining occurance
+ * of the canonical form in the IR is replaced with a dereference of the
+ * temporary variable.
+ *
+ * L-values with non-constant indices are handled similarly. In this case,
+ * the RHS of the assignment is assigned to a temporary. The non-constant
+ * index is replace with the canonical form (just like for r-values). The
+ * temporary is conditionally assigned to each element of the canonical form
+ * by comparing \c i with each index. The same clone-and-replace scheme is
+ * used.
*/
#include "ir.h"
@@ -43,10 +58,70 @@ is_array_or_matrix(const ir_instruction *ir)
return (ir->type->is_array() || ir->type->is_matrix());
}
+/**
+ * Replace a dereference of a variable with a specified r-value
+ *
+ * Each time a dereference of the specified value is replaced, the r-value
+ * tree is cloned.
+ */
+class deref_replacer : public ir_rvalue_visitor {
+public:
+ deref_replacer(const ir_variable *variable_to_replace, ir_rvalue *value)
+ : variable_to_replace(variable_to_replace), value(value),
+ progress(false)
+ {
+ assert(this->variable_to_replace != NULL);
+ assert(this->value != NULL);
+ }
+
+ virtual void handle_rvalue(ir_rvalue **rvalue)
+ {
+ ir_dereference_variable *const dv = (*rvalue)->as_dereference_variable();
+
+ if ((dv != NULL) && (dv->var == this->variable_to_replace)) {
+this->progress = true;
+*rvalue = this->value->clone(ralloc_parent(*rvalue), NULL);
+ }
+ }
+
+ const ir_variable *variable_to_replace;
+ ir_rvalue *value;
+ bool progress;
+};
+
+/**
+ * Find a variable index dereference of an array in an rvalue tree
+ */
+class find_variable_index : public ir_hierarchical_visitor {
+public:
+ find_variable_index()
+ : deref(NULL)
+ {
+ /* empty */
+ }
+
+ virtual ir_visitor_status visit_enter(ir_dereference_array *ir)
+ {
+ if (is_array_or_matrix(ir->array)
+ && (ir->array_index->as_constant() == NULL)) {
+this->deref = ir;
+return visit_stop;
+ }
+
+ return visit_continue;
+ }
+
+ /**
+* First array dereference found in the tree that has a non-constant index.
+*/
+ ir_dereference_array *deref;
+};
+
struct assignment_generator
{
ir_instruction* base_ir;
- ir_rvalue* array;
+ ir_rvalue *rvalue;
+ ir_variable *old_index;
bool is_write;
unsigned int write_mask;
ir_variable* var;
@@ -61,14 +136,25 @@ struct assignment_generator
* underlying variable.
*/
void *mem_ctx = ralloc_parent(base_ir);
- ir_dereference *element =
-new(mem_ctx) ir_dereference_array(this->array->clone(mem_ctx, NULL),
- new(mem_ctx) ir_constant(i));
- ir_rvalue *variable = new(mem_ctx) ir_dereference_variable(this->var);
+ /* Clone the old r-value in its entirety. Then replace any occurances of
+ * the old variable index with the new constant index.
+ */
+ ir_rvalue *element = this->rvalue->clone(mem_ctx, NULL);
+ ir_constant *const index = new(mem_ctx) ir_constant(i);
+ deref_replacer r(this->old_index, index);
+ element->accept(&r);
+ assert(r.progress);
+
+ /* Generate a conditional assignment to (or from) the constant indexed
+ * array dereference.
+ */
+ ir_rvalue *variable = new(mem_ctx) ir_dereference_variable(this->var
[Mesa-dev] [PATCH 4/8] glsl: When lowering non-constant array indexing, respect existing conditions
From: Ian Romanick
If the non-constant index was in the LHS of an assignment, any
existing condititon on that assignment would be lost.
Fixes i965 piglit:
fs-temp-array-mat[234]-col-row-wr
fs-temp-array-mat[234]-index-col-row-wr
fs-temp-array-mat[234]-index-col-wr
fs-temp-array-mat[234]-index-row-wr
vs-varying-array-mat[234]-index-col-wr
---
src/glsl/lower_variable_index_to_cond_assign.cpp | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/glsl/lower_variable_index_to_cond_assign.cpp
b/src/glsl/lower_variable_index_to_cond_assign.cpp
index 03621b5..8cb8d98 100644
--- a/src/glsl/lower_variable_index_to_cond_assign.cpp
+++ b/src/glsl/lower_variable_index_to_cond_assign.cpp
@@ -423,9 +423,24 @@ public:
switch_generator sg(ag, index, 4, 4);
- exec_list list;
- sg.generate(0, length, &list);
- base_ir->insert_before(&list);
+ /* If the original assignment has a condition, respect that original
+ * condition! This is acomplished by wrapping the new conditional
+ * assignments in an if-statement that uses the original condition.
+ */
+ if ((orig_assign != NULL) && (orig_assign->condition != NULL)) {
+/* No need to clone the condition because the IR that it hangs on is
+ * going to be removed from the instruction sequence.
+ */
+ir_if *if_stmt = new(mem_ctx) ir_if(orig_assign->condition);
+
+sg.generate(0, length, &if_stmt->then_instructions);
+base_ir->insert_before(if_stmt);
+ } else {
+exec_list list;
+
+sg.generate(0, length, &list);
+base_ir->insert_before(&list);
+ }
return var;
}
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/8] glsl: When lowering non-constant vector indexing, respect existing conditions
From: Ian Romanick
If the non-constant index was in the LHS of an assignment, any
existing condititon on that assignment would be lost.
---
src/glsl/lower_vec_index_to_cond_assign.cpp | 29 ++
1 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/src/glsl/lower_vec_index_to_cond_assign.cpp
b/src/glsl/lower_vec_index_to_cond_assign.cpp
index 3c4d932..15992e2 100644
--- a/src/glsl/lower_vec_index_to_cond_assign.cpp
+++ b/src/glsl/lower_vec_index_to_cond_assign.cpp
@@ -171,21 +171,23 @@
ir_vec_index_to_cond_assign_visitor::visit_leave(ir_assignment *ir)
assert(orig_deref->array_index->type->base_type == GLSL_TYPE_INT);
+ exec_list list;
+
/* Store the index to a temporary to avoid reusing its tree. */
index = new(ir) ir_variable(glsl_type::int_type, "vec_index_tmp_i",
ir_var_temporary);
- ir->insert_before(index);
+ list.push_tail(index);
deref = new(ir) ir_dereference_variable(index);
assign = new(ir) ir_assignment(deref, orig_deref->array_index, NULL);
- ir->insert_before(assign);
+ list.push_tail(assign);
/* Store the RHS to a temporary to avoid reusing its tree. */
var = new(ir) ir_variable(ir->rhs->type, "vec_index_tmp_v",
ir_var_temporary);
- ir->insert_before(var);
+ list.push_tail(var);
deref = new(ir) ir_dereference_variable(var);
assign = new(ir) ir_assignment(deref, ir->rhs, NULL);
- ir->insert_before(assign);
+ list.push_tail(assign);
/* Generate a conditional move of each vector element to the temp. */
for (i = 0; i < orig_deref->array->type->vector_elements; i++) {
@@ -205,8 +207,25 @@
ir_vec_index_to_cond_assign_visitor::visit_leave(ir_assignment *ir)
deref = new(ir) ir_dereference_variable(var);
assign = new(ir) ir_assignment(swizzle, deref, condition);
- ir->insert_before(assign);
+ list.push_tail(assign);
}
+
+ /* If the original assignment has a condition, respect that original
+* condition! This is acomplished by wrapping the new conditional
+* assignments in an if-statement that uses the original condition.
+*/
+ if (ir->condition != NULL) {
+ /* No need to clone the condition because the IR that it hangs on is
+ * going to be removed from the instruction sequence.
+ */
+ ir_if *if_stmt = new(mem_ctx) ir_if(ir->condition);
+
+ list.move_nodes_to(&if_stmt->then_instructions);
+ ir->insert_before(if_stmt);
+ } else {
+ ir->insert_before(&list);
+ }
+
ir->remove();
this->progress = true;
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/8] ir_to_mesa: Add each relative address to the previous
From: Ian Romanick
This fixes many cases of accessing arrays of matrices using
non-constant indices at each level.
Fixes i965 piglit:
vs-temp-array-mat[234]-index-col-rd
vs-temp-array-mat[234]-index-col-row-rd
vs-temp-array-mat[234]-index-col-wr
vs-uniform-array-mat[234]-index-col-rd
Fixes swrast piglit:
fs-temp-array-mat[234]-index-col-rd
fs-temp-array-mat[234]-index-col-row-rd
fs-temp-array-mat[234]-index-col-wr
fs-uniform-array-mat[234]-index-col-rd
fs-uniform-array-mat[234]-index-col-row-rd
fs-varying-array-mat[234]-index-col-rd
fs-varying-array-mat[234]-index-col-row-rd
vs-temp-array-mat[234]-index-col-rd
vs-temp-array-mat[234]-index-col-row-rd
vs-temp-array-mat[234]-index-col-wr
vs-uniform-array-mat[234]-index-col-rd
vs-uniform-array-mat[234]-index-col-row-rd
vs-varying-array-mat[234]-index-col-rd
vs-varying-array-mat[234]-index-col-row-rd
vs-varying-array-mat[234]-index-col-wr
---
src/mesa/program/ir_to_mesa.cpp | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index d8e5a3a..beb481b 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -1496,6 +1496,18 @@ ir_to_mesa_visitor::visit(ir_dereference_array *ir)
this->result, src_reg_for_float(element_size));
}
+ /* If there was already a relative address register involved, add the
+ * new and the old together to get the new offset.
+ */
+ if (src.reladdr != NULL) {
+src_reg accum_reg = get_temp(glsl_type::float_type);
+
+emit(ir, OPCODE_ADD, dst_reg(accum_reg),
+ index_reg, *src.reladdr);
+
+index_reg = accum_reg;
+ }
+
src.reladdr = ralloc(mem_ctx, src_reg);
memcpy(src.reladdr, &index_reg, sizeof(index_reg));
}
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/8] ir_to_mesa: Copy reladdr in src_reg(dst_reg) constructor
From: Ian Romanick Fixes i965 piglit: vs-temp-array-mat[234]-col-row-wr vs-temp-array-mat[234]-index-col-row-wr vs-temp-array-mat[234]-index-row-wr vs-temp-mat[234]-col-row-wr Fixes swrast piglit: fs-temp-array-mat[234]-col-row-wr fs-temp-array-mat[234]-index-col-row-wr fs-temp-array-mat[234]-index-row-wr fs-temp-mat[234]-col-row-wr vs-temp-array-mat[234]-col-row-wr vs-temp-array-mat[234]-index-col-row-wr vs-temp-array-mat[234]-index-row-wr vs-temp-mat[234]-col-row-wr --- src/mesa/program/ir_to_mesa.cpp |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp index beb481b..8b4a535 100644 --- a/src/mesa/program/ir_to_mesa.cpp +++ b/src/mesa/program/ir_to_mesa.cpp @@ -134,7 +134,7 @@ src_reg::src_reg(dst_reg reg) this->index = reg.index; this->swizzle = SWIZZLE_XYZW; this->negate = 0; - this->reladdr = NULL; + this->reladdr = reg.reladdr; } dst_reg::dst_reg(src_reg reg) -- 1.7.4.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 8/8] i965: Only iterate over the actual number of source registers
From: Ian Romanick
Itrating over all 3 possible source registers regardless of the opcode
was causing a variety of problems. The most noticable was an
occasional assertion failure:
brw_vs_emit.c:1381: get_src_reg: Assertion `c->regs[file][index].nr !=
0' failed.
This assertion seemed to be triggered by reading from an uniform
array-of-matrix using multiple non-constant indices.
Fixes i965 piglit:
vs-uniform-array-mat[234]-col-row-rd
vs-uniform-array-mat[234]-index-col-row-rd
vs-uniform-array-mat[234]-index-row-rd
vs-uniform-mat[234]-col-row-rd
---
src/mesa/drivers/dri/i965/brw_vs_emit.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs_emit.c
b/src/mesa/drivers/dri/i965/brw_vs_emit.c
index 9d73334..3949382 100644
--- a/src/mesa/drivers/dri/i965/brw_vs_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_vs_emit.c
@@ -220,8 +220,9 @@ static void brw_vs_alloc_regs( struct brw_vs_compile *c )
i++) {
struct prog_instruction *inst = &c->vp->program.Base.Instructions[i];
int arg;
+ const unsigned num_src = _mesa_num_inst_src_regs(inst->Opcode);
- for (arg = 0; arg < 3 && constant < max_constant; arg++) {
+ for (arg = 0; arg < num_src && constant < max_constant; arg++) {
if (inst->SrcReg[arg].File != PROGRAM_STATE_VAR &&
inst->SrcReg[arg].File != PROGRAM_CONSTANT &&
inst->SrcReg[arg].File != PROGRAM_UNIFORM &&
@@ -1931,11 +1932,12 @@ void brw_vs_emit(struct brw_vs_compile *c )
for (insn = 0; insn < nr_insns; insn++) {
GLuint i;
struct prog_instruction *inst = &c->vp->program.Base.Instructions[insn];
+ const unsigned num_src = _mesa_num_inst_src_regs(inst->Opcode);
/* Message registers can't be read, so copy the output into GRF
* register if they are used in source registers
*/
- for (i = 0; i < 3; i++) {
+ for (i = 0; i < num_src; i++) {
struct prog_src_register *src = &inst->SrcReg[i];
GLuint index = src->Index;
GLuint file = src->File;
@@ -1975,8 +1977,9 @@ void brw_vs_emit(struct brw_vs_compile *c )
/* Get argument regs. SWZ is special and does this itself.
*/
- if (inst->Opcode != OPCODE_SWZ)
- for (i = 0; i < 3; i++) {
+ if (inst->Opcode != OPCODE_SWZ) {
+ const unsigned num_src = _mesa_num_inst_src_regs(inst->Opcode);
+ for (i = 0; i < num_src; i++) {
const struct prog_src_register *src = &inst->SrcReg[i];
index = src->Index;
file = src->File;
@@ -1985,6 +1988,7 @@ void brw_vs_emit(struct brw_vs_compile *c )
else
args[i] = get_arg(c, inst, i);
}
+ }
/* Get dest regs. Note that it is possible for a reg to be both
* dst and arg, given the static allocation of registers. So
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [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: [Mesa-dev] [PATCH 1/4] mesa: Add an ifndef guard around the definition of the INLINE macro
On 18 July 2011 11:58, Brian Paul wrote: > On 07/18/2011 12:37 PM, Paul Berry wrote: >> >> Several headers redundantly define the INLINE macro. Adding this >> guard prevents the compiler from complaining about macro redefinition. > > Other Mesa headers? Or system headers? Or? Other Mesa headers. I found definitions of INLINE in four header files: src/egl/main/eglcompiler.h src/gallium/include/pipe/p_compiler.h src/mapi/mapi/u_compiler.h src/mesa/main/compiler.h Ideally we should put all of our definitions of INLINE in one place, but I was doing enough in other parts of the patch series that I didn't want to shave that particular yak :) I'll update the commit comment to clarify. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39307] vdpau advertises support for MPEG1, but it's unimplemented
https://bugs.freedesktop.org/show_bug.cgi?id=39307 --- Comment #1 from Emeric Grange 2011-07-18 15:09:49 PDT --- Indeed MPEG1 should be supported, but remains mostly untested. That patch should do the trick, I'll try to get it commited later if I manage to test it first. http://cgit.freedesktop.org/~emericg/mesa-vp8/commit/?h=vp8&id=0c1f9a959bc42b51a2064922adca6d422273a79e -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().
- Original Message -
> We can't do try-map + create + map + dereference internally in a
> driver. Creating a new buffer and replacing a pointer to the old one
> may lead to the following issue. If a buffer pointer is replaced, it
> doesn't necessarily update all the states the buffer is set in in all
> existing contexts. Such states and contexts would still use the old
> buffer and wouldn't see the change until the old buffer is unbound.
First, I don't think this is a real issue. OpenGL 3.3. section "Shared Objects
and Multiple Contexts" says:
Rule 3 State Changes to the contents of shared objects are not automatically
prop-
agated between contexts. If the contents of a shared object T are changed in a
con-
text other than the current context, and T is already directly or indirectly
attached
to the current context, any operations on the current context involving T via
those
attachments are not guaranteed to use its new contents.
And even if it was, it's straightforward to implement: other contexts need
validate the storage of bound resources on each draw call. Of course, it
wouldn't be efficient to revalidate all buffers if the pipe buffer bindings
didn't change, which is probably why the spec doesn't require it.
> I think the only correct way to implement the DISCARD flags in
> drivers
> is through a temporary (staging) resource and doing an on-gpu copy to
> the original one (i.e. what we do for texture transfers in rX00g).
Queueing a gpu copy would be an efficient way to implement
MAP_INVALIDATE_RANGE_BIT without stalling, but to implement
GL_MAP_INVALIDATE_BUFFER_BIT an gpu copy is overkill. The whole point of
MAP_INVALIDATE_RANGE_BIT/DISCARD_WHOLE_RESOURCE is changing the underlying
storage, without chaning the resource/buffer-object.
That is:
struct foo_resource {
struct pipe_resource base;
struct kernel_buffer_object_t *bo.
};
if (flags & DISCARD_WHOLE_RESOURCE) {
if (is_kernel_buffer_object_busy(resource->bo) {
bo = kernel_buffer_object_create()
reference(resource->bo, bo);
}
}
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [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: [Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().
On Mon, Jul 18, 2011 at 6:21 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> We can't do try-map + create + map + dereference internally in a
>> driver. Creating a new buffer and replacing a pointer to the old one
>> may lead to the following issue. If a buffer pointer is replaced, it
>> doesn't necessarily update all the states the buffer is set in in all
>> existing contexts. Such states and contexts would still use the old
>> buffer and wouldn't see the change until the old buffer is unbound.
>
> First, I don't think this is a real issue. OpenGL 3.3. section "Shared
> Objects and Multiple Contexts" says:
>
> Rule 3 State Changes to the contents of shared objects are not automatically
> prop-
> agated between contexts. If the contents of a shared object T are changed in
> a con-
> text other than the current context, and T is already directly or indirectly
> attached
> to the current context, any operations on the current context involving T via
> those
> attachments are not guaranteed to use its new contents.
>
> And even if it was, it's straightforward to implement: other contexts need
> validate the storage of bound resources on each draw call. Of course, it
> wouldn't be efficient to revalidate all buffers if the pipe buffer bindings
> didn't change, which is probably why the spec doesn't require it.
>
>> I think the only correct way to implement the DISCARD flags in
>> drivers
>> is through a temporary (staging) resource and doing an on-gpu copy to
>> the original one (i.e. what we do for texture transfers in rX00g).
>
> Queueing a gpu copy would be an efficient way to implement
> MAP_INVALIDATE_RANGE_BIT without stalling, but to implement
> GL_MAP_INVALIDATE_BUFFER_BIT an gpu copy is overkill. The whole point of
> MAP_INVALIDATE_RANGE_BIT/DISCARD_WHOLE_RESOURCE is changing the underlying
> storage, without chaning the resource/buffer-object.
>
> That is:
>
> struct foo_resource {
> struct pipe_resource base;
>
> struct kernel_buffer_object_t *bo.
>
> };
>
> if (flags & DISCARD_WHOLE_RESOURCE) {
> if (is_kernel_buffer_object_busy(resource->bo) {
> bo = kernel_buffer_object_create()
> reference(resource->bo, bo);
> }
> }
>
> Jose
I implemented exactly that in Nouveau pre-TTM, just created a new BO
and updated the pointer. The old BO was then freed after the last
command buffer it was referenced in was executed. That was exactly the
original motivation for adding the DISCARD flag.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [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
Re: [Mesa-dev] [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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().
On Tue, Jul 19, 2011 at 12:21 AM, Jose Fonseca wrote:
>
>
> - Original Message -
>> We can't do try-map + create + map + dereference internally in a
>> driver. Creating a new buffer and replacing a pointer to the old one
>> may lead to the following issue. If a buffer pointer is replaced, it
>> doesn't necessarily update all the states the buffer is set in in all
>> existing contexts. Such states and contexts would still use the old
>> buffer and wouldn't see the change until the old buffer is unbound.
>
> First, I don't think this is a real issue. OpenGL 3.3. section "Shared
> Objects and Multiple Contexts" says:
>
> Rule 3 State Changes to the contents of shared objects are not automatically
> prop-
> agated between contexts. If the contents of a shared object T are changed in
> a con-
> text other than the current context, and T is already directly or indirectly
> attached
> to the current context, any operations on the current context involving T via
> those
> attachments are not guaranteed to use its new contents.
>
> And even if it was, it's straightforward to implement: other contexts need
> validate the storage of bound resources on each draw call. Of course, it
> wouldn't be efficient to revalidate all buffers if the pipe buffer bindings
> didn't change, which is probably why the spec doesn't require it.
>
>> I think the only correct way to implement the DISCARD flags in
>> drivers
>> is through a temporary (staging) resource and doing an on-gpu copy to
>> the original one (i.e. what we do for texture transfers in rX00g).
>
> Queueing a gpu copy would be an efficient way to implement
> MAP_INVALIDATE_RANGE_BIT without stalling, but to implement
> GL_MAP_INVALIDATE_BUFFER_BIT an gpu copy is overkill. The whole point of
> MAP_INVALIDATE_RANGE_BIT/DISCARD_WHOLE_RESOURCE is changing the underlying
> storage, without chaning the resource/buffer-object.
>
> That is:
>
> struct foo_resource {
> struct pipe_resource base;
>
> struct kernel_buffer_object_t *bo.
>
> };
>
> if (flags & DISCARD_WHOLE_RESOURCE) {
> if (is_kernel_buffer_object_busy(resource->bo) {
> bo = kernel_buffer_object_create()
> reference(resource->bo, bo);
> }
> }
I implemented exactly that and it didn't work (= caused regressions).
The current context must still be examined if the bo is bound
somewhere and mark such states as dirty, so that the gpu can see the
change.
I don't like the fact OpenGL makes a lot of obvious object sharing
cases undefined, but whatever. I wonder whether resource sharing works
any different in and between other APIs, like OpenGL vs OpenCL.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().
- Original Message -
> On Tue, Jul 19, 2011 at 12:21 AM, Jose Fonseca
> wrote:
> >
> >
> > - Original Message -
> >> We can't do try-map + create + map + dereference internally in a
> >> driver. Creating a new buffer and replacing a pointer to the old
> >> one
> >> may lead to the following issue. If a buffer pointer is replaced,
> >> it
> >> doesn't necessarily update all the states the buffer is set in in
> >> all
> >> existing contexts. Such states and contexts would still use the
> >> old
> >> buffer and wouldn't see the change until the old buffer is
> >> unbound.
> >
> > First, I don't think this is a real issue. OpenGL 3.3. section
> > "Shared Objects and Multiple Contexts" says:
> >
> > Rule 3 State Changes to the contents of shared objects are not
> > automatically prop-
> > agated between contexts. If the contents of a shared object T are
> > changed in a con-
> > text other than the current context, and T is already directly or
> > indirectly attached
> > to the current context, any operations on the current context
> > involving T via those
> > attachments are not guaranteed to use its new contents.
> >
> > And even if it was, it's straightforward to implement: other
> > contexts need validate the storage of bound resources on each draw
> > call. Of course, it wouldn't be efficient to revalidate all
> > buffers if the pipe buffer bindings didn't change, which is
> > probably why the spec doesn't require it.
> >
> >> I think the only correct way to implement the DISCARD flags in
> >> drivers
> >> is through a temporary (staging) resource and doing an on-gpu copy
> >> to
> >> the original one (i.e. what we do for texture transfers in rX00g).
> >
> > Queueing a gpu copy would be an efficient way to implement
> > MAP_INVALIDATE_RANGE_BIT without stalling, but to implement
> > GL_MAP_INVALIDATE_BUFFER_BIT an gpu copy is overkill. The whole
> > point of MAP_INVALIDATE_RANGE_BIT/DISCARD_WHOLE_RESOURCE is
> > changing the underlying storage, without chaning the
> > resource/buffer-object.
> >
> > That is:
> >
> > struct foo_resource {
> > struct pipe_resource base;
> >
> > struct kernel_buffer_object_t *bo.
> >
> > };
> >
> > if (flags & DISCARD_WHOLE_RESOURCE) {
> > if (is_kernel_buffer_object_busy(resource->bo) {
> > bo = kernel_buffer_object_create()
> > reference(resource->bo, bo);
> > }
> > }
>
> I implemented exactly that and it didn't work (= caused regressions).
> The current context must still be examined if the bo is bound
> somewhere and mark such states as dirty, so that the gpu can see the
> change.
Yes. Ideally, there should be no references to the storage object inside the
context except as relocations in the command buffers. Other places inside the
driver should prefer the pipe_resource as much as possible.
> I don't like the fact OpenGL makes a lot of obvious object sharing
> cases undefined, but whatever. I wonder whether resource sharing
> works
> any different in and between other APIs, like OpenGL vs OpenCL.
Undefined is, for all purposes, same as should not be used. Why loose time and
ink describing what should happen, if the point is that applications writers
should not do this.
I'm not familiar with OpenCL. But the basic principle with OpenGL is to not
allow things that would require expensive/complex multithreading
synchronization schemes to implement.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: GLES2 should return different error enums for invalid fbo queries
ES 2.0.25 page 127 says:
If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then
querying any other pname will generate INVALID_ENUM.
See also:
b9e9df78a03edb35472c2e231aef4747e09db792
NOTE: This is a candidate for the 7.10 and 7.11 branches.
---
src/mesa/main/fbobject.c | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 8496936..1e11513 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2134,10 +2134,13 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
{
const struct gl_renderbuffer_attachment *att;
struct gl_framebuffer *buffer;
+ GLboolean is_gl;
GET_CURRENT_CONTEXT(ctx);
ASSERT_OUTSIDE_BEGIN_END(ctx);
+ is_gl = ctx->API == API_OPENGL;
+
buffer = get_framebuffer_target(ctx, target);
if (!buffer) {
_mesa_error(ctx, GL_INVALID_ENUM,
@@ -2188,7 +2191,12 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
}
else {
assert(att->Type == GL_NONE);
- *params = 0;
+ if (is_gl) {
+*params = 0;
+ } else {
+_mesa_error(ctx, GL_INVALID_ENUM,
+"glGetFramebufferAttachmentParameterivEXT(pname)");
+ }
}
return;
case GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL_EXT:
@@ -2196,7 +2204,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
*params = att->TextureLevel;
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else {
@@ -2214,7 +,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
}
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else {
@@ -2232,7 +2240,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
}
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else {
@@ -2246,7 +2254,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else {
@@ -2267,7 +2275,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
return;
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else {
@@ -2301,7 +2309,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else if (att->Texture) {
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] glsl: Move initialize_context() to glsl_parser_extras.cpp so it can be re-used.
On 07/18/2011 11:37 AM, Paul Berry wrote:
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -926,6 +926,39 @@ do_common_optimization(exec_list *ir, bool linked,
> unsigned max_unroll_iteration
> return progress;
> }
>
> +void initialize_context_to_defaults(struct gl_context *ctx, gl_api api)
> +{
> + memset(ctx, 0, sizeof(*ctx));
> +
> + ctx->API = api;
> +
> + ctx->Extensions.ARB_ES2_compatibility = GL_TRUE;
> + ctx->Extensions.ARB_draw_buffers = GL_TRUE;
> + ctx->Extensions.ARB_draw_instanced = GL_TRUE;
> + ctx->Extensions.ARB_fragment_coord_conventions = GL_TRUE;
> + ctx->Extensions.EXT_texture_array = GL_TRUE;
> + ctx->Extensions.NV_texture_rectangle = GL_TRUE;
> + ctx->Extensions.EXT_texture3D = GL_TRUE;
Would you mind converting these to "true" as long as you're moving them?
Either way,
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] mesa: Add an ifndef guard around the definition of the INLINE macro
On 07/18/2011 11:37 AM, Paul Berry wrote: > Several headers redundantly define the INLINE macro. Adding this > guard prevents the compiler from complaining about macro redefinition. > --- > src/mesa/main/compiler.h | 42 ++ > 1 files changed, 22 insertions(+), 20 deletions(-) Seems strange, I haven't run into this. But it shouldn't hurt anything, and is probably a good idea. Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2] configure.ac: Check for the respective libdrm_* when building gallium drivers
Pushed, thanks. Marek On Fri, Jul 15, 2011 at 12:07 AM, Emil Velikov wrote: > In a rare case of building gallium only, we need to > check if the required packages are available > > libdrm_[intel|nouveau] - gallium[i915 i965|nouveau] > > v2: r300g and r600g do not need libdrm_radeon > > Signed-off-by: Emil Velikov > --- > configure.ac | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/configure.ac b/configure.ac > index c186240..87c8ffc 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1908,6 +1908,7 @@ if test "x$with_gallium_drivers" != x; then > gallium_check_st "svga/drm" "dri-vmwgfx" "xorg-vmwgfx" "xa-vmwgfx" > ;; > xi915) > + PKG_CHECK_MODULES([INTEL], [libdrm_intel >= > $LIBDRM_INTEL_REQUIRED]) > GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS i915 softpipe" > if test "x$MESA_LLVM" = x1; then > GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS llvmpipe" > @@ -1916,6 +1917,7 @@ if test "x$with_gallium_drivers" != x; then > gallium_check_st "i915/drm" "dri-i915" "xorg-i915" > ;; > xi965) > + PKG_CHECK_MODULES([INTEL], [libdrm_intel >= > $LIBDRM_INTEL_REQUIRED]) > GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS i965 softpipe" > if test "x$MESA_LLVM" = x1; then > GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS llvmpipe" > @@ -1932,6 +1934,7 @@ if test "x$with_gallium_drivers" != x; then > gallium_check_st "r600/drm" "dri-r600" "" "" "xvmc-r600" > "vdpau-r600" "va-r600" > ;; > xnouveau) > + PKG_CHECK_MODULES([NOUVEAU], [libdrm_nouveau >= > $LIBDRM_NOUVEAU_REQUIRED]) > GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS nouveau nvfx nv50 > nvc0" > gallium_check_st "nouveau/drm" "dri-nouveau" "xorg-nouveau" "" > "xvmc-nouveau" > ;; > -- > 1.7.6 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().
On Mon, Jul 18, 2011 at 8:32 PM, Marek Olšák wrote:
> On Tue, Jul 19, 2011 at 12:21 AM, Jose Fonseca wrote:
>>
>>
>> - Original Message -
>>> We can't do try-map + create + map + dereference internally in a
>>> driver. Creating a new buffer and replacing a pointer to the old one
>>> may lead to the following issue. If a buffer pointer is replaced, it
>>> doesn't necessarily update all the states the buffer is set in in all
>>> existing contexts. Such states and contexts would still use the old
>>> buffer and wouldn't see the change until the old buffer is unbound.
>>
>> First, I don't think this is a real issue. OpenGL 3.3. section "Shared
>> Objects and Multiple Contexts" says:
>>
>> Rule 3 State Changes to the contents of shared objects are not
>> automatically prop-
>> agated between contexts. If the contents of a shared object T are changed in
>> a con-
>> text other than the current context, and T is already directly or indirectly
>> attached
>> to the current context, any operations on the current context involving T
>> via those
>> attachments are not guaranteed to use its new contents.
>>
>> And even if it was, it's straightforward to implement: other contexts need
>> validate the storage of bound resources on each draw call. Of course, it
>> wouldn't be efficient to revalidate all buffers if the pipe buffer bindings
>> didn't change, which is probably why the spec doesn't require it.
>>
>>> I think the only correct way to implement the DISCARD flags in
>>> drivers
>>> is through a temporary (staging) resource and doing an on-gpu copy to
>>> the original one (i.e. what we do for texture transfers in rX00g).
>>
>> Queueing a gpu copy would be an efficient way to implement
>> MAP_INVALIDATE_RANGE_BIT without stalling, but to implement
>> GL_MAP_INVALIDATE_BUFFER_BIT an gpu copy is overkill. The whole point of
>> MAP_INVALIDATE_RANGE_BIT/DISCARD_WHOLE_RESOURCE is changing the underlying
>> storage, without chaning the resource/buffer-object.
>>
>> That is:
>>
>> struct foo_resource {
>> struct pipe_resource base;
>>
>> struct kernel_buffer_object_t *bo.
>>
>> };
>>
>> if (flags & DISCARD_WHOLE_RESOURCE) {
>> if (is_kernel_buffer_object_busy(resource->bo) {
>> bo = kernel_buffer_object_create()
>> reference(resource->bo, bo);
>> }
>> }
>
> I implemented exactly that and it didn't work (= caused regressions).
> The current context must still be examined if the bo is bound
> somewhere and mark such states as dirty, so that the gpu can see the
> change.
>
> I don't like the fact OpenGL makes a lot of obvious object sharing
> cases undefined, but whatever. I wonder whether resource sharing works
> any different in and between other APIs, like OpenGL vs OpenCL.
>
> Marek
We didn't keep references to the BO anywhere in the context, just the
nouveau subclasses of pipe_buffer and pipe_texture where needed. The
only place we kept BO refs was in a list associated with each command
buffer, and as each command buffer's fence came up we freed up any BOs
in the list that were no longer ref'd elsewhere.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: st_copy_texsubimage: clip source size to rb size
On 07/18/2011 09:29 AM, Vadim Girlin wrote:
On Mon, 2011-07-18 at 08:34 -0600, Brian Paul wrote:
On Mon, Jul 18, 2011 at 8:11 AM, Vadim Girlin wrote:
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39286
---
src/mesa/state_tracker/st_cb_texture.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 6907cfc..63cd142 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1490,6 +1490,14 @@ st_copy_texsubimage(struct gl_context *ctx,
destY = 0;
}
+ if (srcX + width> strb->Base.Width) {
+ width = strb->Base.Width - srcX;
+ }
+
+ if (srcY + height> strb->Base.Height) {
+ height = strb->Base.Height - srcY;
+ }
+
if (width< 0 || height< 0)
return;
Clipping for glCopyTexSubImage() should be done by
_mesa_clip_copytexsubimage() (in image.c, called from teximage.c).
Maybe you could do a bit of debugging to see why that's not doing the
job.
Yes, I have some doubts too, especially now when I've seen the comment
before the st_copy_texsubimage definition, which explicitly states the
region should be clipped already. AFAICS _mesa_clip_copytexsubimage is
called only from copytexsubimage, but st_copy_texsubimage is called from
copyteximage (without sub) too, that's why no clipping occurs. I'm not
sure now where and how is better to fix it then, because my knowledge of
this code is still not very good. On the other hand, st_copy_texsubimage
already contains some clipping code, that's why I've added the checks in
this function. How should I fix this correctly?
Here's a patch to try.
Basically, it reimplements glCopyTexImage() like a sequence of
glTexImage() and glCopyTexSubImage() calls (and does the clipping that
was missing). I was planning on doing this as a follow-on to the
map-texture-image-v4 work.
With this change, we can remove the ctx->Driver.CopyTexImage1D/2D()
hooks and the corresponding code in all the drivers.
-Brian
clip-copyteximage.patch
Description: application/pgp-keys
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r300/compiler: simplify code in peephole_add_presub_add
This looks good, I'll test it when I get a chance.
-Tom
On Mon, Jul 18, 2011 at 07:14:06AM +0200, Tobias Droste wrote:
> Signed-off-by: Tobias Droste
> ---
> .../drivers/dri/r300/compiler/radeon_optimize.c| 35 ++-
> 1 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_optimize.c
> b/src/mesa/drivers/dri/r300/compiler/radeon_optimize.c
> index b242742..39dcb21 100644
> --- a/src/mesa/drivers/dri/r300/compiler/radeon_optimize.c
> +++ b/src/mesa/drivers/dri/r300/compiler/radeon_optimize.c
> @@ -561,28 +561,29 @@ static int peephole_add_presub_add(
> struct rc_instruction * inst_add)
> {
> unsigned dstmask = inst_add->U.I.DstReg.WriteMask;
> - struct rc_src_register * src1 = NULL;
> - unsigned int i;
> -
> - if (!is_presub_candidate(c, inst_add))
> - return 0;
> +unsigned src0_neg = inst_add->U.I.SrcReg[0].Negate & dstmask;
> +unsigned src1_neg = inst_add->U.I.SrcReg[1].Negate & dstmask;
>
> if (inst_add->U.I.SrcReg[0].Swizzle != inst_add->U.I.SrcReg[1].Swizzle)
> return 0;
>
> - /* XXX This isn't fully implemented, is it? */
> - /* src0 and src1 can't have absolute values only one can be negative
> and they must be all negative or all positive. */
> - for (i = 0; i < 2; i++) {
> - if (inst_add->U.I.SrcReg[i].Abs)
> - return 0;
> + /* src0 and src1 can't have absolute values */
> + if (inst_add->U.I.SrcReg[0].Abs || inst_add->U.I.SrcReg[1].Abs)
> + return 0;
>
> - /* XXX This looks weird, but it's basically what was here
> before this commit (see git blame): */
> - if ((inst_add->U.I.SrcReg[i].Negate & dstmask) != dstmask &&
> !src1) {
> - src1 = &inst_add->U.I.SrcReg[i];
> - }
> - }
> + /* presub_replace_add() assumes only one is negative */
> + if (inst_add->U.I.SrcReg[0].Negate && inst_add->U.I.SrcReg[1].Negate)
> + return 0;
> +
> +/* if src0 is negative, at least all bits of dstmask have to be set
> */
> +if (inst_add->U.I.SrcReg[0].Negate && src0_neg != dstmask)
> + return 0;
>
> - if (!src1)
> +/* if src1 is negative, at least all bits of dstmask have to be set
> */
> +if (inst_add->U.I.SrcReg[1].Negate && src1_neg != dstmask)
> + return 0;
> +
> + if (!is_presub_candidate(c, inst_add))
> return 0;
>
> if (presub_helper(c, inst_add, RC_PRESUB_ADD, presub_replace_add)) {
> @@ -615,7 +616,7 @@ static void presub_replace_inv(
> * of the add instruction must have the constatnt 1 swizzle. This function
> * does not check const registers to see if their value is 1.0, so it should
> * be called after the constant_folding optimization.
> - * @return
> + * @return
> * 0 if the ADD instruction is still part of the program.
> * 1 if the ADD instruction is no longer part of the program.
> */
> --
> 1.7.3.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [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 pgpXkLB36er63.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38716] Can't build, error: undefined reference to `_eglFilterConfigArray'
https://bugs.freedesktop.org/show_bug.cgi?id=38716 --- Comment #12 from Jos van Wolput 2011-07-18 21:56:55 PDT --- (In reply to comment #1) > The command for linking wrongly put the local library search path after the > system's. It should be fixed with 24137af. Please test. I am using Debian Sid amd64 but still can't compile the gallium EGL driver.I cloned the latest git and 'make' shows: /usr/bin/ld: error: cannot open ../../../../x86_64-linux-gnu/libEGL.so: No such file or directory --- mklib: Making Linux shared library: egl_gallium.so /usr/bin/ld: error: cannot open ../../../../x86_64-linux-gnu/libEGL.so: No such file or directory egl.c:98: error: undefined reference to '_eglLog' egl.c:150: error: undefined reference to '_eglLog' egl.c:150: error: undefined reference to '_eglLog' egl.c:78: error: undefined reference to '_eglLog' egl_st.c:79: error: undefined reference to '_eglSearchPathForEach' common/egl_g3d.c:469: error: undefined reference to '_eglReleaseDisplayResources' common/egl_g3d.c:472: error: undefined reference to '_eglDestroyArray' common/egl_g3d.c:476: error: undefined reference to '_eglDestroyArray' common/egl_g3d.c:480: error: undefined reference to '_eglCleanupDisplay' common/egl_g3d.c:186: error: undefined reference to '_eglInitScreen' common/egl_g3d.c:203: error: undefined reference to '_eglLinkScreen' common/egl_g3d.c:526: error: undefined reference to '_eglError' common/egl_g3d.c:581: error: undefined reference to '_eglError' common/egl_g3d.c:510: error: undefined reference to '_eglError' common/egl_g3d.c:429: error: undefined reference to '_eglInitConfig' common/egl_g3d.c:307: error: undefined reference to '_eglValidateConfig' common/egl_g3d.c:437: error: undefined reference to '_eglLinkConfig' common/egl_g3d.c:521: error: undefined reference to '_eglError' ../../../../src/egl/main/eglimage.h:127: error: undefined reference to '_eglCheckResource' common/egl_g3d_api.c:639: error: undefined reference to '_eglGetAPIContext' common/egl_g3d_api.c:584: error: undefined reference to '_eglGetCurrentContext' common/egl_g3d_api.c:126: error: undefined reference to '_eglParseConfigAttribList' common/egl_g3d_api.c:140: error: undefined reference to '_eglFilterConfigArray' common/egl_g3d_api.c:254: error: undefined reference to '_eglInitSurface' common/egl_g3d_api.c:353: error: undefined reference to '_eglInitSurface' common/egl_g3d_api.c:706: error: undefined reference to '_eglGetAPIContext' common/egl_g3d_api.c:619: error: undefined reference to '_eglGetCurrentContext' common/egl_g3d_api.c:552: error: undefined reference to '_eglGetCurrentContext' ../../../../src/egl/main/eglcontext.h:95: error: undefined reference to '_eglPutResource' common/egl_g3d_api.c:160: error: undefined reference to '_eglInitContext' ../../../../src/egl/main/eglsurface.h:118: error: undefined reference to '_eglPutResource' common/egl_g3d_api.c:493: error: undefined reference to '_eglBindContext' ../../../../src/egl/main/eglcontext.h:95: error: undefined reference to '_eglPutResource' ../../../../src/egl/main/eglsurface.h:118: error: undefined reference to '_eglPutResource' common/egl_g3d_api.c:531: error: undefined reference to '_eglBindContext' common/egl_g3d_api.c:823: error: undefined reference to '_eglInitDriverFallbacks' common/egl_g3d_api.c:103: error: undefined reference to '_eglCompareConfigs' common/egl_g3d_api.c:117: error: undefined reference to '_eglMatchConfig' cmklib: Making Linux shared library: egl_gallium.so /usr/bin/ld: error: cannot open ../../../../x86_64-linux-gnu/libEGL.so: No such file or directory egl.c:98: error: undefined reference to '_eglLog' egl.c:150: error: undefined reference to '_eglLog' egl.c:150: error: undefined reference to '_eglLog' egl.c:78: error: undefined reference to '_eglLog' egl_st.c:79: error: undefined reference to '_eglSearchPathForEach' common/egl_g3d.c:469: error: undefined reference to '_eglReleaseDisplayResources' common/egl_g3d.c:472: error: undefined reference to '_eglDestroyArray' common/egl_g3d.c:476: error: undefined reference to '_eglDestroyArray' common/egl_g3d.c:480: error: undefined reference to '_eglCleanupDisplay' common/egl_g3d.c:186: error: undefined reference to '_eglInitScreen' common/egl_g3d.c:203: error: undefined reference to '_eglLinkScreen' common/egl_g3d.c:526: error: undefined reference to '_eglError' common/egl_g3d.c:581: error: undefined reference to '_eglError' common/egl_g3d.c:510: error: undefined reference to '_eglError' common/egl_g3d.c:429: error: undefined reference to '_eglInitConfig' common/egl_g3d.c:307: error: undefined reference to '_eglValidateConfig' common/egl_g3d.c:437: error: undefined reference to '_eglLinkConfig' common/egl_g3d.c:521: error: undefined reference to '_eglError' ../../../../src/egl/main/eglimage.h:127: error: undefined reference to '_eglCheckResource' common/egl_g3d_api.c:639: error: undefined reference to '_eglGetAPIContext' common/egl_g3d_api.c:584: error: undefined reference to '_eglGetCurrentConte
