[Mesa-dev] [PATCH] i965: Delete stale "pre-gen4" comment in texture validation code.
In commit 16060c5adcd4d809f97e874fcde763260c17ac18, Eric changed the code to not relayout just for baselevel changes - only if the range of miplevels actually increases. So this comment is now wrong. Notably, the i915 version of the code actually does what the comment says. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/intel_tex_validate.c | 5 - 1 file changed, 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c b/src/mesa/drivers/dri/i965/intel_tex_validate.c index d8497a6..e4587fc 100644 --- a/src/mesa/drivers/dri/i965/intel_tex_validate.c +++ b/src/mesa/drivers/dri/i965/intel_tex_validate.c @@ -102,11 +102,6 @@ intel_finalize_mipmap_tree(struct brw_context *brw, GLuint unit) /* Check tree can hold all active levels. Check tree matches * target, imageFormat, etc. -* -* For pre-gen4, we have to match first_level == tObj->BaseLevel, -* because we don't have the control that gen4 does to make min/mag -* determination happen at a nonzero (hardware) baselevel. Because -* of that, we just always relayout on baselevel change. */ if (intelObj->mt && (!intel_miptree_match_image(intelObj->mt, &firstImage->base.Base) || -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] loader: Allow a non-udev linux fallback
On Fri, 31 Jan 2014 10:58:48 -0800 Kenneth Graunke wrote: > On 01/31/2014 03:14 AM, Lauri Kasanen wrote: > > It's important not to break existing uses. There is no need to require > > udev for 3d. This is an alternative to Stéphane Marchesin's patch > > "loader: Make drmGetVersion logic conditional on non-pci devices". > > > > Signed-off-by: Lauri Kasanen > > I'm still fairly astounded that a Linux user who cares about 3D graphics > would not have udev. Virtually every distribution has shipped it for > years. X input hotplugging has used udev for ages (at least on Linux). > Steam also uses udev. It's a really common system dependency. > > As far as I can tell, the "udev is part of systemd, so I won't touch it" > rationale is just FUD. Yes, the udev sources were put in the systemd > git repository a while back, but that in no way means you need systemd. > udev can still be built and used independently, and from what I've > heard, that will continue into the foreseeable future. Gentoo ships > udev 208 without systemd, so it definitely can be done. > > Other than that, the only other reason I've heard is "I don't want to > install a library", which IMO is pretty weak... The argument is "this setup worked, and was supported, for 10 years now". You don't break supported setups without good reason. - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: Enable large file support for the 32-bit platforms
On Fri, 31 Jan 2014 13:28:48 -0800 Carl Worth wrote: > Lauri Kasanen writes: > >> 32-bit use is on the increase due to Steam; avoid any surprises > >> and make Mesa LFS-aware. > ... > >> AC_PROG_MKDIR_P > >> +AC_SYS_LARGEFILE > > Hi Lauri, > > Can you describe a bit more what failure modes you encounter without > AC_SYS_LARGEFILE in place? I just haven't dealt with this macro, (nor > the resulting compiler options), before and am wanting to understand > things a bit better. It uses the experience gathered in autoconf to enable large file support on all platforms. For 32-bit Linux, it adds -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64. For other platforms, other magic is used. On 64-bit linux, it is a no-op. This means that all IO calls automatically and transparently handle files above 2gb. Without this, you get a cap at 2gb for both read and write, which can be quite unexpected. I hit this in some submitted memory traces from 32-bit platforms. They were capped at exactly UINT_MAX bytes. This code is not in mesa, but it's not hard to imagine other dumps, or perhaps reading a big binary shader exceeding 2gb. > > Ping. Having this done in autoconf is much better than the current > > hardcoding done in vmware svga build files. > > Does that suggest that the patch should also be removing some of these > hard-coded options? Yes. I didn't do it, because I've no way to test the SVGA driver. - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] dri: Require libudev-dev for building DRI on Linux.
On Fri, 31 Jan 2014 23:54:43 -0800 Keith Packard wrote: > Lauri Kasanen writes: > > > Forgot to mention, this would appear to make 3d impossible without udev > > (ie, static devices, mdev, or other solutions). > > No, DRI2 continues to fall back to using the driver provided by the X > server if it can't find one locally. The patch makes libudev required for DRI to build. The non-udev path was broken for both radeon and intel due to another commit, because it uses the kernel driver name if it can't find a pci id. - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Delete stale "pre-gen4" comment in texture validation code.
I wonder if we could lose mt->first_level entirely? It looks like it's always going to be zero in i965 now. On Sat, Feb 1, 2014 at 10:10 PM, Kenneth Graunke wrote: > In commit 16060c5adcd4d809f97e874fcde763260c17ac18, Eric changed the > code to not relayout just for baselevel changes - only if the range of > miplevels actually increases. So this comment is now wrong. > > Notably, the i915 version of the code actually does what the comment > says. > > Signed-off-by: Kenneth Graunke > --- > src/mesa/drivers/dri/i965/intel_tex_validate.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c > b/src/mesa/drivers/dri/i965/intel_tex_validate.c > index d8497a6..e4587fc 100644 > --- a/src/mesa/drivers/dri/i965/intel_tex_validate.c > +++ b/src/mesa/drivers/dri/i965/intel_tex_validate.c > @@ -102,11 +102,6 @@ intel_finalize_mipmap_tree(struct brw_context *brw, > GLuint unit) > > /* Check tree can hold all active levels. Check tree matches > * target, imageFormat, etc. > -* > -* For pre-gen4, we have to match first_level == tObj->BaseLevel, > -* because we don't have the control that gen4 does to make min/mag > -* determination happen at a nonzero (hardware) baselevel. Because > -* of that, we just always relayout on baselevel change. > */ > if (intelObj->mt && > (!intel_miptree_match_image(intelObj->mt, &firstImage->base.Base) || > -- > 1.8.5.2 > > ___ > 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] configure: Enable large file support for the 32-bit platforms
On Sat, 1 Feb 2014 11:36:07 +0200 Lauri Kasanen wrote: > On Fri, 31 Jan 2014 13:28:48 -0800 > Carl Worth wrote: > > > Lauri Kasanen writes: > > >> 32-bit use is on the increase due to Steam; avoid any surprises > > >> and make Mesa LFS-aware. > > ... > > >> AC_PROG_MKDIR_P > > >> +AC_SYS_LARGEFILE > > > > Hi Lauri, > > > > Can you describe a bit more what failure modes you encounter without > > AC_SYS_LARGEFILE in place? I just haven't dealt with this macro, (nor > > the resulting compiler options), before and am wanting to understand > > things a bit better. > > It uses the experience gathered in autoconf to enable large file > support on all platforms. For 32-bit Linux, it adds -D_LARGEFILE_SOURCE > and -D_FILE_OFFSET_BITS=64. For other platforms, other magic is used. > On 64-bit linux, it is a no-op. > > This means that all IO calls automatically and transparently handle > files above 2gb. Without this, you get a cap at 2gb for both read and > write, which can be quite unexpected. > > I hit this in some submitted memory traces from 32-bit platforms. They > were capped at exactly UINT_MAX bytes. This code is not in mesa, but > it's not hard to imagine other dumps, or perhaps reading a big binary > shader exceeding 2gb. > > > > Ping. Having this done in autoconf is much better than the current > > > hardcoding done in vmware svga build files. > > > > Does that suggest that the patch should also be removing some of these > > hard-coded options? > > Yes. I didn't do it, because I've no way to test the SVGA driver. Typo, s/UINT/INT/. - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74312] New: ilo_dri.so is not installed like other drivers
https://bugs.freedesktop.org/show_bug.cgi?id=74312 Priority: medium Bug ID: 74312 CC: olva...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: ilo_dri.so is not installed like other drivers Severity: normal Classification: Unclassified OS: All Reporter: fabio@libero.it Hardware: All Status: NEW Version: git Component: Mesa core Product: Mesa ilo_dri.so builds fine but it is not installed like all other drivers. -- 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 09/13] r300g, r600g, radeonsi: add support for ARB_buffer_storage
Am 31.01.2014 21:36, schrieb Alex Deucher: On Fri, Jan 31, 2014 at 7:05 AM, Marek Olšák wrote: I think we always flush the HDP cache after (before?) command submission. The kernel flushes the HDP cache in the fence command sequence. But we do this at the top of the pipe instead of the bottom and then silently assume that between the top and the bottom the CPU isn't accessing this VRAM buffer. At least theoretically this can lead to a problem if the CPU wants to read a buffer value that's in the same cache line as a value the GPU writes. For example if a stupid application tries something like "while(!value_written_by_GPU_in_VRAM);" this won't work correctly. Christian. Alex This patch adds nothing new to the drivers - we have always had persistent buffer mappings for all buffers and it has always worked. The only thing this does is that persistent mappings are now also supported by Gallium and OpenGL. If there is a missing cache flush somewhere, the new ARB_buffer_storage piglit test will show it. Marek On Fri, Jan 31, 2014 at 2:04 AM, Michel Dänzer wrote: On Don, 2014-01-30 at 23:46 +0100, Fredrik Höglund wrote: On Thursday 30 January 2014, Marek Olšák wrote: From: Marek Olšák All GTT memory mappings are coherent and therefore can be persistent. As we discussed on IRC, I think there should be a comment somewhere explaining that VRAM mappings are uncached, so the memory_barrier implementations don't need to do anything for those. VRAM is mapped uncacheable by the CPU, but there is an HDP cache which must be flushed to ensure coherency between the CPU and GPU. So I suspect memory_barrier actually needs to flush the HDP cache for VRAM. I'm wondering about GTT mappings on AGP as well. I think we're using CPU write-combining for those, so we probably need to flush the write-combining buffers? -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ 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
Re: [Mesa-dev] [PATCH] mesa: don't signal _NEW_TEXTURE in TexSubImage() functions
Reviewed-by: Marek Olšák Marek On Sat, Feb 1, 2014 at 1:38 AM, Brian Paul wrote: > glTexSubImage(), glCopyTexSubImage() and glCompressedTexSubImage() > only change the texel data, not other state like texture size or format. > If a driver really needs do something special it can hook into the > corresponding driver functions or Map/UnmapTextureImage(). > > This should avoid some needless state validation effort. > --- > src/mesa/main/teximage.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c > index 6f84b38..4d635fe 100644 > --- a/src/mesa/main/teximage.c > +++ b/src/mesa/main/teximage.c > @@ -3442,7 +3442,9 @@ texsubimage(struct gl_context *ctx, GLuint dims, GLenum > target, GLint level, > > check_gen_mipmap(ctx, target, texObj, level); > > - ctx->NewState |= _NEW_TEXTURE; > + /* NOTE: Don't signal _NEW_TEXTURE since we've only changed > + * the texel data, not the texture format, size, etc. > + */ >} > } > _mesa_unlock_texture(ctx, texObj); > @@ -3729,7 +3731,9 @@ copytexsubimage(struct gl_context *ctx, GLuint dims, > GLenum target, GLint level, > > check_gen_mipmap(ctx, target, texObj, level); > > - ctx->NewState |= _NEW_TEXTURE; > + /* NOTE: Don't signal _NEW_TEXTURE since we've only changed > + * the texel data, not the texture format, size, etc. > + */ >} > } > _mesa_unlock_texture(ctx, texObj); > @@ -3954,7 +3958,9 @@ compressed_tex_sub_image(GLuint dims, GLenum target, > GLint level, > > check_gen_mipmap(ctx, target, texObj, level); > > - ctx->NewState |= _NEW_TEXTURE; > + /* NOTE: Don't signal _NEW_TEXTURE since we've only changed > + * the texel data, not the texture format, size, etc. > + */ >} > } > _mesa_unlock_texture(ctx, texObj); > -- > 1.7.10.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
[Mesa-dev] [Bug 74312] ilo_dri.so is not installed like other drivers
https://bugs.freedesktop.org/show_bug.cgi?id=74312 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Ian Romanick --- Use i965_dri.so. -- 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 1/4] r600g, radeonsi: force VRAM placement for DRI2 buffers
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index f80a6a2..434a651 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -668,7 +668,7 @@ r600_texture_create_object(struct pipe_screen *screen,
} else {
resource->buf = buf;
resource->cs_buf = rscreen->ws->buffer_get_cs_handle(buf);
- resource->domains = RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM;
+ resource->domains = RADEON_DOMAIN_VRAM;
}
if (rtex->cmask.size) {
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] r600g, radeonsi: treat DYNAMIC and STREAM usage as STAGING
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 73526d8..b8a96fe 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -112,19 +112,15 @@ bool r600_init_resource(struct r600_common_screen
*rscreen,
switch(usage) {
case PIPE_USAGE_STAGING:
- /* Staging resources participate in transfers, i.e. are used
+ case PIPE_USAGE_DYNAMIC:
+ case PIPE_USAGE_STREAM:
+ /* These resources participate in transfers, i.e. are used
* for uploads and downloads from regular resources.
* We generate them internally for some transfers.
*/
initial_domain = RADEON_DOMAIN_GTT;
domains = RADEON_DOMAIN_GTT;
break;
- case PIPE_USAGE_DYNAMIC:
- case PIPE_USAGE_STREAM:
- /* Default to GTT, but allow the memory manager to move it to
VRAM. */
- initial_domain = RADEON_DOMAIN_GTT;
- domains = RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM;
- break;
case PIPE_USAGE_DEFAULT:
case PIPE_USAGE_STATIC:
case PIPE_USAGE_IMMUTABLE:
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] r600g, radeonsi: skip busy-checking for DISCARD_RANGE if it has been done already
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index b8a96fe..b7921fa 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -250,8 +250,12 @@ static void *r600_buffer_transfer_map(struct pipe_context
*ctx,
data += box->x % R600_MAP_BUFFER_ALIGNMENT;
return r600_buffer_get_transfer(ctx, resource,
level, usage, box,
ptransfer,
data, staging, offset);
+ } else {
+ return NULL; /* error, shouldn't occur though */
}
}
+ /* At this point, the buffer is always idle (we checked it
above). */
+ usage |= PIPE_TRANSFER_UNSYNCHRONIZED;
}
data = r600_buffer_map_sync_with_rings(rctx, rbuffer, usage);
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] r600g, radeonsi: skip unnecessary buffer_is_busy call, add a comment
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index b7921fa..c973e39 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -49,6 +49,7 @@ void *r600_buffer_map_sync_with_rings(struct
r600_common_context *ctx,
unsigned usage)
{
enum radeon_bo_usage rusage = RADEON_USAGE_READWRITE;
+ bool busy = false;
if (usage & PIPE_TRANSFER_UNSYNCHRONIZED) {
return ctx->ws->buffer_map(resource->cs_buf, NULL, usage);
@@ -67,6 +68,7 @@ void *r600_buffer_map_sync_with_rings(struct
r600_common_context *ctx,
return NULL;
} else {
ctx->rings.gfx.flush(ctx, 0);
+ busy = true;
}
}
if (ctx->rings.dma.cs &&
@@ -78,10 +80,11 @@ void *r600_buffer_map_sync_with_rings(struct
r600_common_context *ctx,
return NULL;
} else {
ctx->rings.dma.flush(ctx, 0);
+ busy = true;
}
}
- if (ctx->ws->buffer_is_busy(resource->buf, rusage)) {
+ if (busy || ctx->ws->buffer_is_busy(resource->buf, rusage)) {
if (usage & PIPE_TRANSFER_DONTBLOCK) {
return NULL;
} else {
@@ -93,6 +96,7 @@ void *r600_buffer_map_sync_with_rings(struct
r600_common_context *ctx,
}
}
+ /* Setting the CS to NULL will prevent doing checks we have done
already. */
return ctx->ws->buffer_map(resource->cs_buf, NULL, usage);
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] mesa: move glBlitFramebuffer code into new blit.c file
Just for better organization.
---
src/mesa/Makefile.sources |1 +
src/mesa/SConscript |1 +
src/mesa/main/blit.c | 513 +
src/mesa/main/blit.h | 39
src/mesa/main/fbobject.c | 473 -
src/mesa/main/fbobject.h |5 -
6 files changed, 554 insertions(+), 478 deletions(-)
create mode 100644 src/mesa/main/blit.c
create mode 100644 src/mesa/main/blit.h
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index d14823d..6a8a045 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -18,6 +18,7 @@ MAIN_FILES = \
$(SRCDIR)main/attrib.c \
$(SRCDIR)main/arrayobj.c \
$(SRCDIR)main/blend.c \
+ $(SRCDIR)main/blit.c \
$(SRCDIR)main/bufferobj.c \
$(SRCDIR)main/buffers.c \
$(SRCDIR)main/clear.c \
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 77e2aaa..4bc4de4 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -46,6 +46,7 @@ main_sources = [
'main/attrib.c',
'main/arrayobj.c',
'main/blend.c',
+'main/blit.c',
'main/bufferobj.c',
'main/buffers.c',
'main/clear.c',
diff --git a/src/mesa/main/blit.c b/src/mesa/main/blit.c
new file mode 100644
index 000..0b70a3d
--- /dev/null
+++ b/src/mesa/main/blit.c
@@ -0,0 +1,513 @@
+/*
+ * Mesa 3-D graphics library
+ *
+ * Copyright (C) 1999-2008 Brian Paul All Rights Reserved.
+ * Copyright (C) 1999-2013 VMware, Inc. All Rights Reserved.
+ *
+ * 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 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.
+ */
+
+/*
+ * glBlitFramebuffer functions.
+ */
+
+#include
+
+#include "context.h"
+#include "enums.h"
+#include "blit.h"
+#include "fbobject.h"
+#include "glformats.h"
+#include "mtypes.h"
+#include "state.h"
+
+
+/** Set this to 1 to debug/log glBlitFramebuffer() calls */
+#define DEBUG_BLIT 0
+
+
+
+static const struct gl_renderbuffer_attachment *
+find_attachment(const struct gl_framebuffer *fb,
+const struct gl_renderbuffer *rb)
+{
+ GLuint i;
+ for (i = 0; i < Elements(fb->Attachment); i++) {
+ if (fb->Attachment[i].Renderbuffer == rb)
+ return &fb->Attachment[i];
+ }
+ return NULL;
+}
+
+
+/**
+ * Helper function for checking if the datatypes of color buffers are
+ * compatible for glBlitFramebuffer. From the 3.1 spec, page 198:
+ *
+ * "GL_INVALID_OPERATION is generated if mask contains GL_COLOR_BUFFER_BIT
+ * and any of the following conditions hold:
+ * - The read buffer contains fixed-point or floating-point values and any
+ * draw buffer contains neither fixed-point nor floating-point values.
+ * - The read buffer contains unsigned integer values and any draw buffer
+ * does not contain unsigned integer values.
+ * - The read buffer contains signed integer values and any draw buffer
+ * does not contain signed integer values."
+ */
+static GLboolean
+compatible_color_datatypes(mesa_format srcFormat, mesa_format dstFormat)
+{
+ GLenum srcType = _mesa_get_format_datatype(srcFormat);
+ GLenum dstType = _mesa_get_format_datatype(dstFormat);
+
+ if (srcType != GL_INT && srcType != GL_UNSIGNED_INT) {
+ assert(srcType == GL_UNSIGNED_NORMALIZED ||
+ srcType == GL_SIGNED_NORMALIZED ||
+ srcType == GL_FLOAT);
+ /* Boil any of those types down to GL_FLOAT */
+ srcType = GL_FLOAT;
+ }
+
+ if (dstType != GL_INT && dstType != GL_UNSIGNED_INT) {
+ assert(dstType == GL_UNSIGNED_NORMALIZED ||
+ dstType == GL_SIGNED_NORMALIZED ||
+ dstType == GL_FLOAT);
+ /* Boil any of those types down to GL_FLOAT */
+ dstType = GL_FLOAT;
+ }
+
+ return srcType == dstType;
+}
+
+
+static GLboolean
+compatible_resolve_formats(const struct gl_renderbuffer *readRb,
+ const struct gl_renderbuffer *drawRb)
+{
+ GLenum readFormat, drawFormat;
+
+ /* The simpl
[Mesa-dev] [PATCH 2/3] mesa: move glGenerateMipmap() code into new genmipmap.c file
Mipmap generation has nothing to do with FBOs.
---
src/mesa/Makefile.sources |1 +
src/mesa/SConscript |1 +
src/mesa/main/fbobject.c | 92 ---
src/mesa/main/fbobject.h |4 --
src/mesa/main/genmipmap.c | 131 +
src/mesa/main/genmipmap.h | 36 +
6 files changed, 169 insertions(+), 96 deletions(-)
create mode 100644 src/mesa/main/genmipmap.c
create mode 100644 src/mesa/main/genmipmap.h
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 6a8a045..3cdcae2 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -49,6 +49,7 @@ MAIN_FILES = \
$(SRCDIR)main/format_unpack.c \
$(SRCDIR)main/framebuffer.c \
$(SRCDIR)main/get.c \
+ $(SRCDIR)main/genmipmap.c \
$(SRCDIR)main/getstring.c \
$(SRCDIR)main/glformats.c \
$(SRCDIR)main/hash.c \
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 4bc4de4..5b3358d 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -78,6 +78,7 @@ main_sources = [
'main/format_pack.c',
'main/format_unpack.c',
'main/framebuffer.c',
+'main/genmipmap.c',
'main/getstring.c',
'main/glformats.c',
'main/hash.c',
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 7a1761f..ccfa984 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2973,98 +2973,6 @@ invalid_pname_enum:
}
-/**
- * Generate all the mipmap levels below the base level.
- * Note: this GL function would be more useful if one could specify a
- * cube face, a set of array slices, etc.
- */
-void GLAPIENTRY
-_mesa_GenerateMipmap(GLenum target)
-{
- struct gl_texture_image *srcImage;
- struct gl_texture_object *texObj;
- GLboolean error;
-
- GET_CURRENT_CONTEXT(ctx);
-
- FLUSH_VERTICES(ctx, 0);
-
- switch (target) {
- case GL_TEXTURE_1D:
- error = _mesa_is_gles(ctx);
- break;
- case GL_TEXTURE_2D:
- error = GL_FALSE;
- break;
- case GL_TEXTURE_3D:
- error = ctx->API == API_OPENGLES;
- break;
- case GL_TEXTURE_CUBE_MAP:
- error = !ctx->Extensions.ARB_texture_cube_map;
- break;
- case GL_TEXTURE_1D_ARRAY:
- error = _mesa_is_gles(ctx) || !ctx->Extensions.EXT_texture_array;
- break;
- case GL_TEXTURE_2D_ARRAY:
- error = (_mesa_is_gles(ctx) && ctx->Version < 30)
- || !ctx->Extensions.EXT_texture_array;
- break;
- default:
- error = GL_TRUE;
- }
-
- if (error) {
- _mesa_error(ctx, GL_INVALID_ENUM, "glGenerateMipmapEXT(target=%s)",
- _mesa_lookup_enum_by_nr(target));
- return;
- }
-
- texObj = _mesa_get_current_tex_object(ctx, target);
-
- if (texObj->BaseLevel >= texObj->MaxLevel) {
- /* nothing to do */
- return;
- }
-
- if (texObj->Target == GL_TEXTURE_CUBE_MAP &&
- !_mesa_cube_complete(texObj)) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
- "glGenerateMipmap(incomplete cube map)");
- return;
- }
-
- _mesa_lock_texture(ctx, texObj);
-
- srcImage = _mesa_select_tex_image(ctx, texObj, target, texObj->BaseLevel);
- if (!srcImage) {
- _mesa_unlock_texture(ctx, texObj);
- _mesa_error(ctx, GL_INVALID_OPERATION,
- "glGenerateMipmap(zero size base image)");
- return;
- }
-
- if (_mesa_is_enum_format_integer(srcImage->InternalFormat) ||
- _mesa_is_depthstencil_format(srcImage->InternalFormat) ||
- _mesa_is_stencil_format(srcImage->InternalFormat)) {
- _mesa_unlock_texture(ctx, texObj);
- _mesa_error(ctx, GL_INVALID_OPERATION,
- "glGenerateMipmap(invalid internal format)");
- return;
- }
-
- if (target == GL_TEXTURE_CUBE_MAP) {
- GLuint face;
- for (face = 0; face < 6; face++)
-ctx->Driver.GenerateMipmap(ctx,
- GL_TEXTURE_CUBE_MAP_POSITIVE_X_ARB + face,
- texObj);
- }
- else {
- ctx->Driver.GenerateMipmap(ctx, target, texObj);
- }
- _mesa_unlock_texture(ctx, texObj);
-}
-
static void
invalidate_framebuffer_storage(GLenum target, GLsizei numAttachments,
const GLenum *attachments, GLint x, GLint y,
diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
index 1f5aa34..cf4bf39 100644
--- a/src/mesa/main/fbobject.h
+++ b/src/mesa/main/fbobject.h
@@ -203,10 +203,6 @@ _mesa_GetFramebufferAttachmentParameteriv(GLenum target,
GLenum attachment,
GLenum pname, GLint *params);
extern void GLAPIENTRY
-_mesa_GenerateMipmap(GLenum target);
-
-
-extern void GLAPIENTRY
_mesa_InvalidateSubFramebuffer(GLenum target, GLsizei numAttachments,
const GLenum *attachments, GLint x, GLint y,
GLsizei width, GLsizei height);
diff --git a/src/mesa/main/genmipmap.c b/src
[Mesa-dev] [PATCH 3/3] mesa: make several FBO functions static
The four functions in question weren't called from any other file.
---
src/mesa/main/fbobject.c | 70 +++---
src/mesa/main/fbobject.h | 20 -
2 files changed, 35 insertions(+), 55 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index ccfa984..e459e0c 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -181,9 +181,9 @@ get_framebuffer_target(struct gl_context *ctx, GLenum
target)
* If \p attachment is GL_DEPTH_STENCIL_ATTACHMENT, return a pointer to
* the depth buffer attachment point.
*/
-struct gl_renderbuffer_attachment *
-_mesa_get_attachment(struct gl_context *ctx, struct gl_framebuffer *fb,
- GLenum attachment)
+static struct gl_renderbuffer_attachment *
+get_attachment(struct gl_context *ctx, struct gl_framebuffer *fb,
+ GLenum attachment)
{
GLuint i;
@@ -313,9 +313,9 @@ _mesa_get_fb0_attachment(struct gl_context *ctx, struct
gl_framebuffer *fb,
* Remove any texture or renderbuffer attached to the given attachment
* point. Update reference counts, etc.
*/
-void
-_mesa_remove_attachment(struct gl_context *ctx,
-struct gl_renderbuffer_attachment *att)
+static void
+remove_attachment(struct gl_context *ctx,
+ struct gl_renderbuffer_attachment *att)
{
struct gl_renderbuffer *rb = att->Renderbuffer;
@@ -418,13 +418,13 @@ _mesa_update_texture_renderbuffer(struct gl_context *ctx,
* Bind a texture object to an attachment point.
* The previous binding, if any, will be removed first.
*/
-void
-_mesa_set_texture_attachment(struct gl_context *ctx,
- struct gl_framebuffer *fb,
- struct gl_renderbuffer_attachment *att,
- struct gl_texture_object *texObj,
- GLenum texTarget, GLuint level, GLuint zoffset,
- GLboolean layered)
+static void
+set_texture_attachment(struct gl_context *ctx,
+ struct gl_framebuffer *fb,
+ struct gl_renderbuffer_attachment *att,
+ struct gl_texture_object *texObj,
+ GLenum texTarget, GLuint level, GLuint zoffset,
+ GLboolean layered)
{
struct gl_renderbuffer *rb = att->Renderbuffer;
@@ -437,7 +437,7 @@ _mesa_set_texture_attachment(struct gl_context *ctx,
}
else {
/* new attachment */
- _mesa_remove_attachment(ctx, att);
+ remove_attachment(ctx, att);
att->Type = GL_TEXTURE;
assert(!att->Texture);
_mesa_reference_texobj(&att->Texture, texObj);
@@ -459,13 +459,13 @@ _mesa_set_texture_attachment(struct gl_context *ctx,
* Bind a renderbuffer to an attachment point.
* The previous binding, if any, will be removed first.
*/
-void
-_mesa_set_renderbuffer_attachment(struct gl_context *ctx,
- struct gl_renderbuffer_attachment *att,
- struct gl_renderbuffer *rb)
+static void
+set_renderbuffer_attachment(struct gl_context *ctx,
+struct gl_renderbuffer_attachment *att,
+struct gl_renderbuffer *rb)
{
/* XXX check if re-doing same attachment, exit early */
- _mesa_remove_attachment(ctx, att);
+ remove_attachment(ctx, att);
att->Type = GL_RENDERBUFFER_EXT;
att->Texture = NULL; /* just to be safe */
att->Complete = GL_FALSE;
@@ -486,20 +486,20 @@ _mesa_framebuffer_renderbuffer(struct gl_context *ctx,
_glthread_LOCK_MUTEX(fb->Mutex);
- att = _mesa_get_attachment(ctx, fb, attachment);
+ att = get_attachment(ctx, fb, attachment);
ASSERT(att);
if (rb) {
- _mesa_set_renderbuffer_attachment(ctx, att, rb);
+ set_renderbuffer_attachment(ctx, att, rb);
if (attachment == GL_DEPTH_STENCIL_ATTACHMENT) {
/* do stencil attachment here (depth already done above) */
- att = _mesa_get_attachment(ctx, fb, GL_STENCIL_ATTACHMENT_EXT);
+ att = get_attachment(ctx, fb, GL_STENCIL_ATTACHMENT_EXT);
assert(att);
- _mesa_set_renderbuffer_attachment(ctx, att, rb);
+ set_renderbuffer_attachment(ctx, att, rb);
}
rb->AttachedAnytime = GL_TRUE;
}
else {
- _mesa_remove_attachment(ctx, att);
+ remove_attachment(ctx, att);
}
invalidate_framebuffer(fb);
@@ -1085,7 +1085,7 @@ _mesa_test_framebuffer_completeness(struct gl_context
*ctx,
for (j = 0; j < ctx->Const.MaxDrawBuffers; j++) {
if (fb->ColorDrawBuffer[j] != GL_NONE) {
const struct gl_renderbuffer_attachment *att
- = _mesa_get_attachment(ctx, fb, fb->ColorDrawBuffer[j]);
+ = get_attachment(ctx, fb, fb->ColorDrawBuffer[j]);
assert(att);
if (att->Type == GL_NONE) {
fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_DRAW_B
Re: [Mesa-dev] [PATCH] i965: Delete stale "pre-gen4" comment in texture validation code.
On 02/01/2014 01:42 AM, Chris Forbes wrote: > I wonder if we could lose mt->first_level entirely? It looks like it's > always going to be zero in i965 now. Oh wow, I hadn't noticed that. It looks like you're right, except maybe in one case...intel_renderbuffer_move_to_temp sets it to intel_image->base.Base.Level. But I'm guessing that may not actually be important... --Ken 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] [Bug 74127] [bisected] GL programs fail with "loader.c:112: asserted_dlsym: Assertion `result' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=74127 --- Comment #10 from Kertesz Laszlo --- I saw this bug when i installed mesa from git on Debian Wheezy (now the stable version). Debian Whezy doesnt have libudev1, only libudev0 (at version 175). After a few hours of recompiling and hair pulling i found a very simple workaround: symlinking "libudev.so.0" to "libudev.so.1". -- 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 1/3] mesa: move glBlitFramebuffer code into new blit.c file
On 02/01/2014 07:59 AM, Brian Paul wrote: > Just for better organization. > --- > src/mesa/Makefile.sources |1 + > src/mesa/SConscript |1 + > src/mesa/main/blit.c | 513 > + > src/mesa/main/blit.h | 39 > src/mesa/main/fbobject.c | 473 - > src/mesa/main/fbobject.h |5 - > 6 files changed, 554 insertions(+), 478 deletions(-) > create mode 100644 src/mesa/main/blit.c > create mode 100644 src/mesa/main/blit.h Patches 1-2 are: Acked-by: Kenneth Graunke (I like the idea, but didn't review the changes thoroughly.) Patch 3 is: Reviewed-by: Kenneth Graunke 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] mesa: remove target param from ctx->Driver.TexParameter()
On 01/31/2014 04:28 PM, Brian Paul wrote: > Not really used anywhere. > --- > src/mesa/drivers/dri/nouveau/nouveau_state.c |2 +- > src/mesa/drivers/dri/r200/r200_tex.c |5 ++--- > src/mesa/drivers/dri/radeon/radeon_tex.c |2 +- > src/mesa/main/dd.h |2 +- > src/mesa/main/texobj.c | 10 +- > src/mesa/main/texparam.c |8 > 6 files changed, 14 insertions(+), 15 deletions(-) Reviewed-by: Kenneth Graunke 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] mesa: make _mesa_get_proxy_target() static
On 01/31/2014 04:12 PM, Brian Paul wrote: > Wasn't used in any other file. > --- > src/mesa/main/teximage.c | 10 +- > src/mesa/main/teximage.h |3 --- > 2 files changed, 5 insertions(+), 8 deletions(-) Reviewed-by: Kenneth Graunke 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 1/6] r200: use _mesa_get_current_tex_object() in r200SetTexBuffer2()
On 01/31/2014 04:11 PM, Brian Paul wrote:
> ---
> src/mesa/drivers/dri/r200/r200_texstate.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/r200/r200_texstate.c
> b/src/mesa/drivers/dri/r200/r200_texstate.c
> index 5160c2c..c3c92cb 100644
> --- a/src/mesa/drivers/dri/r200/r200_texstate.c
> +++ b/src/mesa/drivers/dri/r200/r200_texstate.c
> @@ -712,7 +712,6 @@ static GLboolean r200UpdateTextureEnv( struct gl_context
> *ctx, int unit, int slo
> void r200SetTexBuffer2(__DRIcontext *pDRICtx, GLint target, GLint
> texture_format,
> __DRIdrawable *dPriv)
> {
> - struct gl_texture_unit *texUnit;
> struct gl_texture_object *texObj;
> struct gl_texture_image *texImage;
> struct radeon_renderbuffer *rb;
> @@ -726,9 +725,8 @@ void r200SetTexBuffer2(__DRIcontext *pDRICtx, GLint
> target, GLint texture_format
> radeon = pDRICtx->driverPrivate;
>
> rfb = dPriv->driverPrivate;
> -texUnit =
> &radeon->glCtx.Texture.Unit[radeon->glCtx.Texture.CurrentUnit];
> - texObj = _mesa_select_tex_object(&radeon->glCtx, texUnit, target);
> -texImage = _mesa_get_tex_image(&radeon->glCtx, texObj, target, 0);
> + texObj = _mesa_get_current_tex_object(&radeon->glCtx, target);
> + texImage = _mesa_get_tex_image(&radeon->glCtx, texObj, target, 0);
>
> rImage = get_radeon_texture_image(texImage);
> t = radeon_tex_obj(texObj);
>
This series is:
Reviewed-by: Kenneth Graunke
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] glsl: Fix continue statements in do-while loops.
On 01/31/2014 01:12 PM, Paul Berry wrote:
> From the GLSL 4.40 spec, section 6.4 (Jumps):
>
> The continue jump is used only in loops. It skips the remainder of
> the body of the inner most loop of which it is inside. For while
> and do-while loops, this jump is to the next evaluation of the
> loop condition-expression from which the loop continues as
> previously defined.
>
> Previously, we incorrectly treated a "continue" statement as jumping
> to the top of a do-while loop.
>
> This patch fixes the problem by replicating the loop condition when
> converting the "continue" statement to IR. (We already do a similar
> thing in "for" loops, to ensure that "continue" causes the loop
> expression to be executed).
>
> Fixes piglit tests:
> - glsl-fs-continue-inside-do-while.shader_test
> - glsl-vs-continue-inside-do-while.shader_test
> - glsl-fs-continue-in-switch-in-do-while.shader_test
> - glsl-vs-continue-in-switch-in-do-while.shader_test
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/glsl/ast_to_hir.cpp | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 950f513..8d096ad 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -4029,17 +4029,22 @@ ast_jump_statement::hir(exec_list *instructions,
>_mesa_glsl_error(& loc, state,
> "break may only appear in a loop or a switch");
>} else {
> - /* For a loop, inline the for loop expression again,
> - * since we don't know where near the end of
> - * the loop body the normal copy of it
> - * is going to be placed.
> + /* For a loop, inline the for loop expression again, since we don't
> + * know where near the end of the loop body the normal copy of it is
> + * going to be placed. Same goes for the condition for a do-while
> + * loop.
> */
>if (state->loop_nesting_ast != NULL &&
> - mode == ast_continue &&
> - state->loop_nesting_ast->rest_expression) {
> - state->loop_nesting_ast->rest_expression->hir(instructions,
> - state);
> - }
> + mode == ast_continue) {
> +if (state->loop_nesting_ast->rest_expression) {
> + state->loop_nesting_ast->rest_expression->hir(instructions,
> + state);
> +}
> +if (state->loop_nesting_ast->mode ==
> +ast_iteration_statement::ast_do_while) {
> + state->loop_nesting_ast->condition_to_hir(instructions,
> state);
> +}
> + }
>
>if (state->switch_state.is_switch_innermost &&
>mode == ast_break) {
>
Hmm. This seems different than any of the approaches we talked about on
#dri-devel, but I think it should work out fine. The expression could
have function with side effects, which will get executed again...but
that's precisely what you want in this case.
Longer term we really ought to clean up all this loop code, but...that's
been apparent for a while.
Thanks for the fix, Paul!
Reviewed-by: Kenneth Graunke
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] i965: Delete stale "pre-gen4" comment in texture validation code.
Kenneth Graunke writes: > On 02/01/2014 01:42 AM, Chris Forbes wrote: >> I wonder if we could lose mt->first_level entirely? It looks like it's >> always going to be zero in i965 now. > > Oh wow, I hadn't noticed that. It looks like you're right, except maybe > in one case...intel_renderbuffer_move_to_temp sets it to > intel_image->base.Base.Level. But I'm guessing that may not actually be > important... That's the reason it's still around. If we could figure out how to make my i965-rb-miplevels (ad2ef18ce1ea9db1d20746ed3ef1f61a96184d83) not regress, we'd be able to drop it. pgpdoS5SJyluf.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74127] [bisected] GL programs fail with "loader.c:112: asserted_dlsym: Assertion `result' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=74127 Eric Anholt changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Eric Anholt --- commit 63546b8e3d217d81a67f6f291fab48b3f381a9ca Author: Eric Anholt Date: Thu Jan 30 10:30:57 2014 -0800 dri: Also support the loader with libudev.so.0. -- 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] [Bug 73902] build: move ARCH_LIBS definition over the first usage
https://bugs.freedesktop.org/show_bug.cgi?id=73902 Matt Turner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|pl.seid...@gmail.com|matts...@gmail.com QA Contact||mesa-dev@lists.freedesktop. ||org --- Comment #6 from Matt Turner --- Thanks! Committed and marked for stable. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73900] mesa: Fix build to properly check for supported compiler flags
https://bugs.freedesktop.org/show_bug.cgi?id=73900 --- Comment #2 from Matt Turner --- I've added a request for this to be picked for 10.0.3. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stable 10.0 branch updated for imminent release
Another couple 10.0.3 requests - fcefdc9a595c5 (see https://bugs.freedesktop.org/show_bug.cgi?id=73900) - 1cdeeef6c400 (see https://bugs.freedesktop.org/show_bug.cgi?id=73902) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glsl: Fix continue statements in do-while loops.
Thanks Paul. Both are Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Expand non-expr & non-swizzle scalar rvalues in vectorizing.
On Fri, Jan 31, 2014 at 1:22 PM, Carl Worth wrote: > Matt Turner writes: >> --- >> src/glsl/opt_vectorize.cpp | 14 -- >> 1 file changed, 8 insertions(+), 6 deletions(-) > > Hi Matt, > > I'm missing the rest of your commit message besides the one-line > summary. > > I think the discipline of always typing _something_ there is valuable. I > like to call the one-line summary the "what" of the commit message, and > the following paragraph the "why". > > And it's the "why" that's particularly important during review. > > In this particular case, I'm not very familiar with the code being > modified, (I'm trying to do more active review of mesa patches as a way > of getting more familiar with the code). A bit more of the why would > help me in my review here. What's the value of the change here? > Correctness or optimization? Do you have example code sequences that > would not be operated-on by the previous code, but that will be by the > new code? > > You don't need to answer all of those questions in the commit > message. But I bet if you wrote a sentence or two, I'd have pretty good > guidance for at least some of those answers. > > Thanks for helping out a Mesa newbie here, Hi Carl, Thanks for the comments. The context of this patch is Aras' email titled "glsl: vectorize pass probably needs to change types of scalar constants as well?" Essentially, my vectorization pass needs to expand scalar operands that are reused in multiple operations into vectors. E.g., when combining a.x = pow(b.x, 2.5); a.y = pow(b.y, 2.5); into a.xy = pow(b.xy, vec2(2.5)); we need to expand 2.5 into vec2(2.5), which we do with a swizzle. My original code only expanded scalar variable dereferences, but Aras pointed out that other rvalues should get the same treatment. That's what this patch does. I should have explained that in the commit message. I've already pushed the patch after Aras said it looked good to him, but I wasn't able to coax a Reviewed-by out of him. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 22/30] mesa/cs: Implement MAX_COMPUTE_WORK_GROUP_INVOCATIONS constant.
On Thu, Jan 9, 2014 at 6:19 PM, Paul Berry wrote:
> ---
> src/glsl/main.cpp | 1 +
> src/glsl/standalone_scaffolding.cpp | 1 +
> src/mesa/main/context.c | 1 +
> src/mesa/main/get.c | 1 +
> src/mesa/main/get_hash_params.py| 3 +++
> src/mesa/main/mtypes.h | 1 +
> 6 files changed, 8 insertions(+)
>
> diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp
> index bb2054f..94bc1cc 100644
> --- a/src/glsl/main.cpp
> +++ b/src/glsl/main.cpp
> @@ -53,6 +53,7 @@ initialize_context(struct gl_context *ctx, gl_api api)
> ctx->Const.MaxComputeWorkGroupSize[0] = 1024;
> ctx->Const.MaxComputeWorkGroupSize[1] = 1024;
> ctx->Const.MaxComputeWorkGroupSize[2] = 64;
> + ctx->Const.MaxComputeWorkGroupInvocations = 1024;
> ctx->Const.Program[MESA_SHADER_COMPUTE].MaxTextureImageUnits = 16;
> ctx->Const.Program[MESA_SHADER_COMPUTE].MaxUniformComponents = 1024;
> ctx->Const.Program[MESA_SHADER_COMPUTE].MaxInputComponents = 0; /* not
> used */
> diff --git a/src/glsl/standalone_scaffolding.cpp
> b/src/glsl/standalone_scaffolding.cpp
> index e8eb529..0c83ea3 100644
> --- a/src/glsl/standalone_scaffolding.cpp
> +++ b/src/glsl/standalone_scaffolding.cpp
> @@ -143,6 +143,7 @@ void initialize_context_to_defaults(struct gl_context
> *ctx, gl_api api)
> ctx->Const.MaxComputeWorkGroupSize[0] = 1024;
> ctx->Const.MaxComputeWorkGroupSize[1] = 1024;
> ctx->Const.MaxComputeWorkGroupSize[2] = 64;
> + ctx->Const.MaxComputeWorkGroupInvocations = 1024;
> ctx->Const.Program[MESA_SHADER_COMPUTE].MaxTextureImageUnits = 16;
> ctx->Const.Program[MESA_SHADER_COMPUTE].MaxUniformComponents = 1024;
> ctx->Const.Program[MESA_SHADER_COMPUTE].MaxInputComponents = 0; /* not
> used */
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index ebe27b4..942f247 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -695,6 +695,7 @@ _mesa_init_constants(struct gl_context *ctx)
> ctx->Const.MaxComputeWorkGroupSize[0] = 1024;
> ctx->Const.MaxComputeWorkGroupSize[1] = 1024;
> ctx->Const.MaxComputeWorkGroupSize[2] = 64;
> + ctx->Const.MaxComputeWorkGroupInvocations = 1024;
> }
>
>
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index 6b914f4..bcbb5d5 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -382,6 +382,7 @@ EXTRA_EXT(ARB_texture_multisample);
> EXTRA_EXT(ARB_texture_gather);
> EXTRA_EXT(ARB_shader_atomic_counters);
> EXTRA_EXT(ARB_draw_indirect);
> +EXTRA_EXT(ARB_compute_shader);
>
> static const int
> extra_ARB_color_buffer_float_or_glcore[] = {
> diff --git a/src/mesa/main/get_hash_params.py
> b/src/mesa/main/get_hash_params.py
> index 7f025a9..c18e848 100644
> --- a/src/mesa/main/get_hash_params.py
> +++ b/src/mesa/main/get_hash_params.py
> @@ -742,6 +742,9 @@ descriptor=[
> # GL_ARB_vertex_attrib_binding
>[ "MAX_VERTEX_ATTRIB_RELATIVE_OFFSET",
> "CONTEXT_ENUM(Const.MaxVertexAttribRelativeOffset), NO_EXTRA" ],
>[ "MAX_VERTEX_ATTRIB_BINDINGS",
> "CONTEXT_ENUM(Const.MaxVertexAttribBindings), NO_EXTRA" ],
> +
> +# GL_ARB_compute_shader
> + [ "MAX_COMPUTE_WORK_GROUP_INVOCATIONS",
> "CONTEXT_ENUM(Const.MaxComputeWorkGroupInvocations),
> extra_ARB_compute_shader" ],
CONTEXT_ENUM and CONTEXT_INT seem to follow the same code paths, but
would CONTEXT_INT be a better fit here?
Also, how do we decide between adding to gl_constants and just using
CONST(1024)? My thought would be to use CONST unless we are pretty
sure drivers will want to vary the value.
21-23 Reviewed-by: Jordan Justen
> ]},
>
> # Enums restricted to OpenGL Core profile
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index d3f3a30..6481dc1 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3323,6 +3323,7 @@ struct gl_constants
>
> /** GL_ARB_compute_shader */
> GLuint MaxComputeWorkGroupSize[3];
> + GLuint MaxComputeWorkGroupInvocations;
> };
>
>
> --
> 1.8.5.2
>
> ___
> 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] [PATCH 2/9] mesa: Rename "arrayObj" local variables to "vao".
Now that the field is named "VAO" instead of "ArrayObj", it makes sense
to call the local variables "vao" instead of "arrayObj".
Completely generated by:
$ find . -type f -print0 | xargs 0 sed -i 's/arrayObj/vao/g'
Signed-off-by: Kenneth Graunke
---
src/mesa/main/api_arrayelt.c | 48 ++---
src/mesa/main/arrayobj.c | 44 +--
src/mesa/main/arrayobj.h | 20 -
src/mesa/main/bufferobj.c | 8 ++--
src/mesa/main/enable.c| 26 ++--
src/mesa/main/varray.c| 98 +--
src/mesa/vbo/vbo_exec_array.c | 16 +++
7 files changed, 130 insertions(+), 130 deletions(-)
diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 09f314b..8beda62 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1472,11 +1472,11 @@ check_vbo(AEcontext *actx, struct gl_buffer_object *vbo)
static inline void
update_derived_client_arrays(struct gl_context *ctx)
{
- struct gl_array_object *arrayObj = ctx->Array.VAO;
+ struct gl_array_object *vao = ctx->Array.VAO;
- if (arrayObj->NewArrays) {
- _mesa_update_array_object_client_arrays(ctx, arrayObj);
- arrayObj->NewArrays = 0;
+ if (vao->NewArrays) {
+ _mesa_update_array_object_client_arrays(ctx, vao);
+ vao->NewArrays = 0;
}
}
@@ -1494,50 +1494,50 @@ _ae_update_state(struct gl_context *ctx)
AEarray *aa = actx->arrays; /* non-indexed arrays (ex: glNormal) */
AEattrib *at = actx->attribs; /* indexed arrays (ex: glMultiTexCoord) */
GLuint i;
- struct gl_array_object *arrayObj = ctx->Array.VAO;
+ struct gl_array_object *vao = ctx->Array.VAO;
actx->nr_vbos = 0;
/* conventional vertex arrays */
- if (arrayObj->_VertexAttrib[VERT_ATTRIB_COLOR_INDEX].Enabled) {
- aa->array = &arrayObj->_VertexAttrib[VERT_ATTRIB_COLOR_INDEX];
+ if (vao->_VertexAttrib[VERT_ATTRIB_COLOR_INDEX].Enabled) {
+ aa->array = &vao->_VertexAttrib[VERT_ATTRIB_COLOR_INDEX];
aa->offset = IndexFuncs[TYPE_IDX(aa->array->Type)];
check_vbo(actx, aa->array->BufferObj);
aa++;
}
- if (arrayObj->_VertexAttrib[VERT_ATTRIB_EDGEFLAG].Enabled) {
- aa->array = &arrayObj->_VertexAttrib[VERT_ATTRIB_EDGEFLAG];
+ if (vao->_VertexAttrib[VERT_ATTRIB_EDGEFLAG].Enabled) {
+ aa->array = &vao->_VertexAttrib[VERT_ATTRIB_EDGEFLAG];
aa->offset = _gloffset_EdgeFlagv;
check_vbo(actx, aa->array->BufferObj);
aa++;
}
- if (arrayObj->_VertexAttrib[VERT_ATTRIB_NORMAL].Enabled) {
- aa->array = &arrayObj->_VertexAttrib[VERT_ATTRIB_NORMAL];
+ if (vao->_VertexAttrib[VERT_ATTRIB_NORMAL].Enabled) {
+ aa->array = &vao->_VertexAttrib[VERT_ATTRIB_NORMAL];
aa->offset = NormalFuncs[TYPE_IDX(aa->array->Type)];
check_vbo(actx, aa->array->BufferObj);
aa++;
}
- if (arrayObj->_VertexAttrib[VERT_ATTRIB_COLOR0].Enabled) {
- aa->array = &arrayObj->_VertexAttrib[VERT_ATTRIB_COLOR0];
+ if (vao->_VertexAttrib[VERT_ATTRIB_COLOR0].Enabled) {
+ aa->array = &vao->_VertexAttrib[VERT_ATTRIB_COLOR0];
aa->offset = ColorFuncs[aa->array->Size-3][TYPE_IDX(aa->array->Type)];
check_vbo(actx, aa->array->BufferObj);
aa++;
}
- if (arrayObj->_VertexAttrib[VERT_ATTRIB_COLOR1].Enabled) {
- aa->array = &arrayObj->_VertexAttrib[VERT_ATTRIB_COLOR1];
+ if (vao->_VertexAttrib[VERT_ATTRIB_COLOR1].Enabled) {
+ aa->array = &vao->_VertexAttrib[VERT_ATTRIB_COLOR1];
aa->offset = SecondaryColorFuncs[TYPE_IDX(aa->array->Type)];
check_vbo(actx, aa->array->BufferObj);
aa++;
}
- if (arrayObj->_VertexAttrib[VERT_ATTRIB_FOG].Enabled) {
- aa->array = &arrayObj->_VertexAttrib[VERT_ATTRIB_FOG];
+ if (vao->_VertexAttrib[VERT_ATTRIB_FOG].Enabled) {
+ aa->array = &vao->_VertexAttrib[VERT_ATTRIB_FOG];
aa->offset = FogCoordFuncs[TYPE_IDX(aa->array->Type)];
check_vbo(actx, aa->array->BufferObj);
aa++;
}
for (i = 0; i < ctx->Const.MaxTextureCoordUnits; i++) {
struct gl_client_array *attribArray =
- &arrayObj->_VertexAttrib[VERT_ATTRIB_TEX(i)];
+ &vao->_VertexAttrib[VERT_ATTRIB_TEX(i)];
if (attribArray->Enabled) {
/* NOTE: we use generic glVertexAttribNV functions here.
* If we ever remove GL_NV_vertex_program this will have to change.
@@ -1556,7 +1556,7 @@ _ae_update_state(struct gl_context *ctx)
/* generic vertex attribute arrays */
for (i = 1; i < VERT_ATTRIB_GENERIC_MAX; i++) { /* skip zero! */
struct gl_client_array *attribArray =
- &arrayObj->_VertexAttrib[VERT_ATTRIB_GENERIC(i)];
+ &vao->_VertexAttrib[VERT_ATTRIB_GENERIC(i)];
if (attribArray->Enabled) {
GLint intOrNorm;
at->array = attribArray;
@@ -1583,24 +1583,24 @@ _ae_update_state(struct gl_context *ctx)
}
/* finally, vertex position */
- if (arrayObj->_VertexAttrib[VERT_ATTRIB_GENERI
[Mesa-dev] [PATCH 5/9] mesa: Rename _mesa_lookup_arrayobj to _mesa_lookup_vao.
For consistency with the previous renames.
Completely generated by:
$ find . -type f -print0 | xargs -0 sed -i \
's/_mesa_lookup_arrayobj/_mesa_lookup_vao/g'
Signed-off-by: Kenneth Graunke
---
src/mesa/main/arrayobj.c| 8
src/mesa/main/arrayobj.h| 2 +-
src/mesa/main/objectlabel.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index dde9cf9..0caae43 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -61,7 +61,7 @@
*/
struct gl_vertex_array_object *
-_mesa_lookup_arrayobj(struct gl_context *ctx, GLuint id)
+_mesa_lookup_vao(struct gl_context *ctx, GLuint id)
{
if (id == 0)
return NULL;
@@ -395,7 +395,7 @@ bind_vertex_array(struct gl_context *ctx, GLuint id,
GLboolean genRequired)
}
else {
/* non-default array object */
- newObj = _mesa_lookup_arrayobj(ctx, id);
+ newObj = _mesa_lookup_vao(ctx, id);
if (!newObj) {
if (genRequired) {
_mesa_error(ctx, GL_INVALID_OPERATION,
@@ -482,7 +482,7 @@ _mesa_DeleteVertexArrays(GLsizei n, const GLuint *ids)
}
for (i = 0; i < n; i++) {
- struct gl_vertex_array_object *obj = _mesa_lookup_arrayobj(ctx, ids[i]);
+ struct gl_vertex_array_object *obj = _mesa_lookup_vao(ctx, ids[i]);
if ( obj != NULL ) {
ASSERT( obj->Name == ids[i] );
@@ -588,7 +588,7 @@ _mesa_IsVertexArray( GLuint id )
if (id == 0)
return GL_FALSE;
- obj = _mesa_lookup_arrayobj(ctx, id);
+ obj = _mesa_lookup_vao(ctx, id);
if (obj == NULL)
return GL_FALSE;
diff --git a/src/mesa/main/arrayobj.h b/src/mesa/main/arrayobj.h
index 6511e08..d72761d 100644
--- a/src/mesa/main/arrayobj.h
+++ b/src/mesa/main/arrayobj.h
@@ -46,7 +46,7 @@ struct gl_context;
*/
extern struct gl_vertex_array_object *
-_mesa_lookup_arrayobj(struct gl_context *ctx, GLuint id);
+_mesa_lookup_vao(struct gl_context *ctx, GLuint id);
extern struct gl_vertex_array_object *
_mesa_new_vao(struct gl_context *ctx, GLuint name);
diff --git a/src/mesa/main/objectlabel.c b/src/mesa/main/objectlabel.c
index c87fcfd..8efc33e 100644
--- a/src/mesa/main/objectlabel.c
+++ b/src/mesa/main/objectlabel.c
@@ -158,7 +158,7 @@ get_label_pointer(struct gl_context *ctx, GLenum
identifier, GLuint name,
break;
case GL_VERTEX_ARRAY:
{
- struct gl_vertex_array_object *obj = _mesa_lookup_arrayobj(ctx, name);
+ struct gl_vertex_array_object *obj = _mesa_lookup_vao(ctx, name);
if (obj)
labelPtr = &obj->Label;
}
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 9/9] mesa: Drop unnecessary (void) ctx from VAO code.
ctx is always used, even on release builds.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/arrayobj.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index acb1bf7..b33ba80 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -117,7 +117,6 @@ _mesa_new_vao(struct gl_context *ctx, GLuint name)
void
_mesa_delete_vao(struct gl_context *ctx, struct gl_vertex_array_object *obj)
{
- (void) ctx;
unbind_array_object_vbos(ctx, obj);
_mesa_reference_buffer_object(ctx, &obj->IndexBufferObj, NULL);
_glthread_DESTROY_MUTEX(obj->Mutex);
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/9] mesa: Update some comments relating to VAOs.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/arrayobj.c | 5 -
src/mesa/main/mtypes.h | 15 +++
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 46ccbdc..0b9592f 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -27,7 +27,10 @@
/**
* \file arrayobj.c
- * Functions for the GL_APPLE_vertex_array_object extension.
+ *
+ * Implementation of Vertex Array Objects (VAOs), from OpenGL 3.1+,
+ * the GL_ARB_vertex_array_object extension, or the older
+ * GL_APPLE_vertex_array_object extension.
*
* \todo
* The code in this file borrows a lot from bufferobj.c. There's a certain
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 609c63f..5fc15af 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1551,12 +1551,13 @@ struct gl_vertex_buffer_binding
/**
- * Collection of vertex arrays. Defined by the GL_APPLE_vertex_array_object
- * extension, but a nice encapsulation in any case.
+ * A representation of "Vertex Array Objects" (VAOs) from OpenGL 3.1+,
+ * GL_ARB_vertex_array_object, or the original GL_APPLE_vertex_array_object
+ * extension.
*/
struct gl_vertex_array_object
{
- /** Name of the array object as received from glGenVertexArrayAPPLE. */
+ /** Name of the VAO as received from glGenVertexArray. */
GLuint Name;
GLchar *Label; /**< GL_KHR_debug */
@@ -1584,7 +1585,12 @@ struct gl_vertex_array_object
*/
GLboolean EverBound;
- /** Derived vertex attribute arrays */
+ /**
+* Derived vertex attribute arrays
+*
+* This is a legacy data structure created from gl_vertex_attrib_array and
+* gl_vertex_buffer_binding, for compatibility with existing driver code.
+*/
struct gl_client_array _VertexAttrib[VERT_ATTRIB_MAX];
/** Vertex attribute arrays */
@@ -1605,6 +1611,7 @@ struct gl_vertex_array_object
*/
GLuint _MaxElement;
+ /** The index buffer (also known as the element array buffer in OpenGL). */
struct gl_buffer_object *IndexBufferObj;
};
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/9] mesa: Rename ElementArrayBufferObj to IndexBufferObj.
DirectX and most hardware documentation use the term "Index Buffer" to
refer to a buffer containing indexes into arrays of vertex data, which
allows random access to vertex data, rather than sequential access.
OpenGL uses a different term for this concept: "Element Array Buffer".
However, "Index Buffer" has become much more widespread. A quick
Google search shows 29,300 hits for "Element Array Buffer" vs.
82,300 hits for "Index Buffer."
Arguably, "Index Buffer" is clearer: an "element of an array" (or list)
usually refers to an actual item stored in the array, not the index used
to refer to it.
The terminology is also already used in Mesa: some VBO module code for
dealing with ElementArrayBufferObj names local variables "ib".
Completely generated by:
$ find . -type f -print0 | xargs -0 sed -i \
's/ElementArrayBufferObj/IndexBufferObj/g'
Signed-off-by: Kenneth Graunke
---
src/mesa/main/api_arrayelt.c | 2 +-
src/mesa/main/api_validate.c | 20 ++--
src/mesa/main/arrayobj.c | 4 ++--
src/mesa/main/attrib.c| 12 ++--
src/mesa/main/bufferobj.c | 6 +++---
src/mesa/main/get.c | 2 +-
src/mesa/main/mtypes.h| 2 +-
src/mesa/vbo/vbo_exec_array.c | 38 +++---
src/mesa/vbo/vbo_save_api.c | 4 ++--
9 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index fdda1dc..29a57c8 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1600,7 +1600,7 @@ _ae_update_state(struct gl_context *ctx)
aa++;
}
- check_vbo(actx, vao->ElementArrayBufferObj);
+ check_vbo(actx, vao->IndexBufferObj);
ASSERT(at - actx->attribs <= VERT_ATTRIB_MAX);
ASSERT(aa - actx->arrays < 32);
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 41dfc38..af469e0 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -180,7 +180,7 @@ check_index_bounds(struct gl_context *ctx, GLsizei count,
GLenum type,
memset(&ib, 0, sizeof(ib));
ib.type = type;
ib.ptr = indices;
- ib.obj = ctx->Array.VAO->ElementArrayBufferObj;
+ ib.obj = ctx->Array.VAO->IndexBufferObj;
vbo_get_minmax_indices(ctx, &prim, &ib, &min, &max, 1);
@@ -435,10 +435,10 @@ _mesa_validate_DrawElements(struct gl_context *ctx,
return GL_FALSE;
/* Vertex buffer object tests */
- if (_mesa_is_bufferobj(ctx->Array.VAO->ElementArrayBufferObj)) {
+ if (_mesa_is_bufferobj(ctx->Array.VAO->IndexBufferObj)) {
/* use indices in the buffer object */
/* make sure count doesn't go outside buffer bounds */
- if (index_bytes(type, count) >
ctx->Array.VAO->ElementArrayBufferObj->Size) {
+ if (index_bytes(type, count) > ctx->Array.VAO->IndexBufferObj->Size) {
_mesa_warning(ctx, "glDrawElements index out of buffer bounds");
return GL_FALSE;
}
@@ -493,12 +493,12 @@ _mesa_validate_MultiDrawElements(struct gl_context *ctx,
return GL_FALSE;
/* Vertex buffer object tests */
- if (_mesa_is_bufferobj(ctx->Array.VAO->ElementArrayBufferObj)) {
+ if (_mesa_is_bufferobj(ctx->Array.VAO->IndexBufferObj)) {
/* use indices in the buffer object */
/* make sure count doesn't go outside buffer bounds */
for (i = 0; i < primcount; i++) {
if (index_bytes(type, count[i]) >
- ctx->Array.VAO->ElementArrayBufferObj->Size) {
+ ctx->Array.VAO->IndexBufferObj->Size) {
_mesa_warning(ctx,
"glMultiDrawElements index out of buffer bounds");
return GL_FALSE;
@@ -570,10 +570,10 @@ _mesa_validate_DrawRangeElements(struct gl_context *ctx,
GLenum mode,
return GL_FALSE;
/* Vertex buffer object tests */
- if (_mesa_is_bufferobj(ctx->Array.VAO->ElementArrayBufferObj)) {
+ if (_mesa_is_bufferobj(ctx->Array.VAO->IndexBufferObj)) {
/* use indices in the buffer object */
/* make sure count doesn't go outside buffer bounds */
- if (index_bytes(type, count) >
ctx->Array.VAO->ElementArrayBufferObj->Size) {
+ if (index_bytes(type, count) > ctx->Array.VAO->IndexBufferObj->Size) {
_mesa_warning(ctx, "glDrawRangeElements index out of buffer bounds");
return GL_FALSE;
}
@@ -769,10 +769,10 @@ _mesa_validate_DrawElementsInstanced(struct gl_context
*ctx,
return GL_FALSE;
/* Vertex buffer object tests */
- if (_mesa_is_bufferobj(ctx->Array.VAO->ElementArrayBufferObj)) {
+ if (_mesa_is_bufferobj(ctx->Array.VAO->IndexBufferObj)) {
/* use indices in the buffer object */
/* make sure count doesn't go outside buffer bounds */
- if (index_bytes(type, count) >
ctx->Array.VAO->ElementArrayBufferObj->Size) {
+ if (index_bytes(type, count) > ctx->Array.VAO->IndexBufferObj->Size) {
_mesa_warning(ctx,
"glDrawElementsInstanced index out of buffe
[Mesa-dev] [PATCH 8/9] mesa: Remove "APPLE" from some VAO error messages.
Chances are, people will be using the core names these days.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/arrayobj.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 0b9592f..acb1bf7 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -480,7 +480,7 @@ _mesa_DeleteVertexArrays(GLsizei n, const GLuint *ids)
GLsizei i;
if (n < 0) {
- _mesa_error(ctx, GL_INVALID_VALUE, "glDeleteVertexArrayAPPLE(n)");
+ _mesa_error(ctx, GL_INVALID_VALUE, "glDeleteVertexArray(n)");
return;
}
@@ -524,7 +524,7 @@ gen_vertex_arrays(struct gl_context *ctx, GLsizei n, GLuint
*arrays)
GLint i;
if (n < 0) {
- _mesa_error(ctx, GL_INVALID_VALUE, "glGenVertexArraysAPPLE");
+ _mesa_error(ctx, GL_INVALID_VALUE, "glGenVertexArrays");
return;
}
@@ -541,7 +541,7 @@ gen_vertex_arrays(struct gl_context *ctx, GLsizei n, GLuint
*arrays)
obj = (*ctx->Driver.NewArrayObject)( ctx, name );
if (!obj) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "glGenVertexArraysAPPLE");
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glGenVertexArrays");
return;
}
save_array_object(ctx, obj);
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/9] mesa: Rename _mesa_..._array_obj functions to _mesa_..._vao.
_mesa_update_vao_client_arrays() is less of a mouthful than
_mesa_update_array_object_client_arrays(), and generally clearer.
Generated by:
$ find . -type f -print0 | xargs -0 sed -i \
's/_mesa_\([^_]*\)_array_object/_mesa_\1_vao/g'
with manual whitespace and indentation fixes applied.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/common/driverfuncs.c| 4 ++--
src/mesa/drivers/common/meta.c | 4 ++--
src/mesa/main/api_arrayelt.c | 2 +-
src/mesa/main/arrayobj.c | 32 ++--
src/mesa/main/arrayobj.h | 30 +-
src/mesa/main/attrib.c | 4 ++--
src/mesa/main/context.c | 4 ++--
src/mesa/main/state.c| 4 ++--
src/mesa/main/varray.c | 7 +++---
src/mesa/state_tracker/st_cb_bufferobjects.c | 4 ++--
10 files changed, 47 insertions(+), 48 deletions(-)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index 6d56838..6ece5d8 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -180,8 +180,8 @@ _mesa_init_driver_functions(struct dd_function_table
*driver)
_mesa_init_texture_barrier_functions(driver);
/* APPLE_vertex_array_object */
- driver->NewArrayObject = _mesa_new_array_object;
- driver->DeleteArrayObject = _mesa_delete_array_object;
+ driver->NewArrayObject = _mesa_new_vao;
+ driver->DeleteArrayObject = _mesa_delete_vao;
driver->BindArrayObject = NULL;
_mesa_init_shader_object_functions(driver);
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index dd9b4a7..f27c686 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -726,7 +726,7 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
if (state & MESA_META_VERTEX) {
/* save vertex array object state */
- _mesa_reference_array_object(ctx, &save->VAO,
+ _mesa_reference_vao(ctx, &save->VAO,
ctx->Array.VAO);
_mesa_reference_buffer_object(ctx, &save->ArrayBufferObj,
ctx->Array.ArrayBufferObj);
@@ -1093,7 +1093,7 @@ _mesa_meta_end(struct gl_context *ctx)
/* restore vertex array object */
_mesa_BindVertexArray(save->VAO->Name);
- _mesa_reference_array_object(ctx, &save->VAO, NULL);
+ _mesa_reference_vao(ctx, &save->VAO, NULL);
}
if (state & MESA_META_VIEWPORT) {
diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 981231c..fdda1dc 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1475,7 +1475,7 @@ update_derived_client_arrays(struct gl_context *ctx)
struct gl_vertex_array_object *vao = ctx->Array.VAO;
if (vao->NewArrays) {
- _mesa_update_array_object_client_arrays(ctx, vao);
+ _mesa_update_vao_client_arrays(ctx, vao);
vao->NewArrays = 0;
}
}
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index ca85bc3..dde9cf9 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -96,11 +96,11 @@ unbind_array_object_vbos(struct gl_context *ctx, struct
gl_vertex_array_object *
* \c dd_function_table::NewArrayObject.
*/
struct gl_vertex_array_object *
-_mesa_new_array_object( struct gl_context *ctx, GLuint name )
+_mesa_new_vao(struct gl_context *ctx, GLuint name)
{
struct gl_vertex_array_object *obj = CALLOC_STRUCT(gl_vertex_array_object);
if (obj)
- _mesa_initialize_array_object(ctx, obj, name);
+ _mesa_initialize_vao(ctx, obj, name);
return obj;
}
@@ -112,7 +112,7 @@ _mesa_new_array_object( struct gl_context *ctx, GLuint name
)
* \c dd_function_table::DeleteArrayObject.
*/
void
-_mesa_delete_array_object( struct gl_context *ctx, struct
gl_vertex_array_object *obj )
+_mesa_delete_vao(struct gl_context *ctx, struct gl_vertex_array_object *obj)
{
(void) ctx;
unbind_array_object_vbos(ctx, obj);
@@ -125,13 +125,13 @@ _mesa_delete_array_object( struct gl_context *ctx, struct
gl_vertex_array_object
/**
* Set ptr to vao w/ reference counting.
- * Note: this should only be called from the _mesa_reference_array_object()
+ * Note: this should only be called from the _mesa_reference_vao()
* inline function.
*/
void
-_mesa_reference_array_object_(struct gl_context *ctx,
- struct gl_vertex_array_object **ptr,
- struct gl_vertex_array_object *vao)
+_mesa_reference_vao_(struct gl_context *ctx,
+ struct gl_vertex_array_object **ptr,
+ struct gl_vertex_array_object *vao)
{
assert(*ptr != vao);
@@ -216,9 +216,9 @@ init_array(struct gl_context *ctx,
* Initialize a gl_vertex_array_object's arrays.
*/
void
-_mesa_initialize_array_object( struct gl_context *ctx,
-
[Mesa-dev] [PATCH 3/9] mesa: Rename "struct gl_array_object" to gl_vertex_array_object.
I considered replacing it with "gl_vao", but spelling it out seemed to
fit better with Mesa's traditional style. Mesa doesn't shy away from
long type names - consider gl_transform_feedback_object,
gl_fragment_program_state, gl_uniform_buffer_binding, and so on.
Completely generated by:
$ find . -type f -print0 | xargs -0 sed -i \
's/gl_array_object/gl_vertex_array_object/g'
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/common/meta.c | 2 +-
src/mesa/main/api_arrayelt.c | 4 ++--
src/mesa/main/arrayobj.c | 46
src/mesa/main/arrayobj.h | 24 ++---
src/mesa/main/attrib.c | 10 -
src/mesa/main/bufferobj.c| 2 +-
src/mesa/main/dd.h | 6 +++---
src/mesa/main/enable.c | 2 +-
src/mesa/main/get.c | 2 +-
src/mesa/main/get_hash_params.py | 14 ++--
src/mesa/main/mtypes.h | 6 +++---
src/mesa/main/objectlabel.c | 2 +-
src/mesa/main/varray.c | 18
src/mesa/vbo/vbo_exec_array.c| 4 ++--
14 files changed, 71 insertions(+), 71 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index f0178f7..dd9b4a7 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -164,7 +164,7 @@ struct save_state
GLuint EnvMode; /* unit[0] only */
/** MESA_META_VERTEX */
- struct gl_array_object *VAO;
+ struct gl_vertex_array_object *VAO;
struct gl_buffer_object *ArrayBufferObj;
/** MESA_META_VIEWPORT */
diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 8beda62..981231c 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1472,7 +1472,7 @@ check_vbo(AEcontext *actx, struct gl_buffer_object *vbo)
static inline void
update_derived_client_arrays(struct gl_context *ctx)
{
- struct gl_array_object *vao = ctx->Array.VAO;
+ struct gl_vertex_array_object *vao = ctx->Array.VAO;
if (vao->NewArrays) {
_mesa_update_array_object_client_arrays(ctx, vao);
@@ -1494,7 +1494,7 @@ _ae_update_state(struct gl_context *ctx)
AEarray *aa = actx->arrays; /* non-indexed arrays (ex: glNormal) */
AEattrib *at = actx->attribs; /* indexed arrays (ex: glMultiTexCoord) */
GLuint i;
- struct gl_array_object *vao = ctx->Array.VAO;
+ struct gl_vertex_array_object *vao = ctx->Array.VAO;
actx->nr_vbos = 0;
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 0bfaf97..ca85bc3 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -60,13 +60,13 @@
* non-existent.
*/
-struct gl_array_object *
+struct gl_vertex_array_object *
_mesa_lookup_arrayobj(struct gl_context *ctx, GLuint id)
{
if (id == 0)
return NULL;
else
- return (struct gl_array_object *)
+ return (struct gl_vertex_array_object *)
_mesa_HashLookup(ctx->Array.Objects, id);
}
@@ -77,7 +77,7 @@ _mesa_lookup_arrayobj(struct gl_context *ctx, GLuint id)
* This is done just prior to array object destruction.
*/
static void
-unbind_array_object_vbos(struct gl_context *ctx, struct gl_array_object *obj)
+unbind_array_object_vbos(struct gl_context *ctx, struct gl_vertex_array_object
*obj)
{
GLuint i;
@@ -95,10 +95,10 @@ unbind_array_object_vbos(struct gl_context *ctx, struct
gl_array_object *obj)
* This function is intended to be called via
* \c dd_function_table::NewArrayObject.
*/
-struct gl_array_object *
+struct gl_vertex_array_object *
_mesa_new_array_object( struct gl_context *ctx, GLuint name )
{
- struct gl_array_object *obj = CALLOC_STRUCT(gl_array_object);
+ struct gl_vertex_array_object *obj = CALLOC_STRUCT(gl_vertex_array_object);
if (obj)
_mesa_initialize_array_object(ctx, obj, name);
return obj;
@@ -112,7 +112,7 @@ _mesa_new_array_object( struct gl_context *ctx, GLuint name
)
* \c dd_function_table::DeleteArrayObject.
*/
void
-_mesa_delete_array_object( struct gl_context *ctx, struct gl_array_object *obj
)
+_mesa_delete_array_object( struct gl_context *ctx, struct
gl_vertex_array_object *obj )
{
(void) ctx;
unbind_array_object_vbos(ctx, obj);
@@ -130,15 +130,15 @@ _mesa_delete_array_object( struct gl_context *ctx, struct
gl_array_object *obj )
*/
void
_mesa_reference_array_object_(struct gl_context *ctx,
- struct gl_array_object **ptr,
- struct gl_array_object *vao)
+ struct gl_vertex_array_object **ptr,
+ struct gl_vertex_array_object *vao)
{
assert(*ptr != vao);
if (*ptr) {
/* Unreference the old array object */
GLboolean deleteFlag = GL_FALSE;
- struct gl_array_object *oldObj = *ptr;
+ struct gl_vertex_array_object *oldObj = *ptr;
_glthread_LOCK_MUTEX(oldObj->Mutex);
ASSERT(oldObj->RefCount > 0);
@@ -184,7
Re: [Mesa-dev] [PATCH 26/30] main/cs: Implement query for COMPUTE_WORK_GROUP_SIZE.
On Thu, Jan 9, 2014 at 6:19 PM, Paul Berry wrote:
> ---
> src/mesa/main/shaderapi.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index 053f27b..680d449 100644
> --- a/src/mesa/main/shaderapi.c
> +++ b/src/mesa/main/shaderapi.c
> @@ -663,6 +663,24 @@ get_programiv(struct gl_context *ctx, GLuint program,
> GLenum pname, GLint *param
>
>*params = shProg->NumAtomicBuffers;
>return;
> + case GL_COMPUTE_WORK_GROUP_SIZE: {
> + int i;
> + if (!_mesa_is_desktop_gl(ctx) || !ctx->Extensions.ARB_compute_shader)
> + break;
> + if (!shProg->LinkStatus) {
> + _mesa_error(ctx, GL_INVALID_OPERATION, "glGetProgramiv(program not "
> + "linked successfully)");
Nit, but dropping " successfully" sounds better to me. It seems more
likely that they tried to get the value before linking than that they
ignored a link error.
24-26 Reviewed-by: Jordan Justen
> + return;
> + }
> + if (shProg->_LinkedShaders[MESA_SHADER_COMPUTE] == NULL) {
> + _mesa_error(ctx, GL_INVALID_OPERATION, "glGetProgramiv(no compute "
> + "shaders)");
> + return;
> + }
> + for (i = 0; i < 3; i++)
> + params[i] = shProg->Comp.LocalSize[i];
> + return;
> + }
> default:
>break;
> }
> --
> 1.8.5.2
>
> ___
> 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 28/30] glsl/cs: Prohibit mixing of compute and non-compute shaders.
27-28 Reviewed-by: Jordan Justen
On Thu, Jan 9, 2014 at 6:19 PM, Paul Berry wrote:
> Fixes piglit test:
> spec/ARB_compute_shader/linker/mix_compute_and_non_compute
> ---
> src/glsl/linker.cpp | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index 11e0651..f1344ea 100644
> --- a/src/glsl/linker.cpp
> +++ b/src/glsl/linker.cpp
> @@ -2107,6 +2107,13 @@ link_shaders(struct gl_context *ctx, struct
> gl_shader_program *prog)
>goto done;
> }
>
> + /* Compute shaders have additional restrictions. */
> + if (num_shaders[MESA_SHADER_COMPUTE] > 0 &&
> + num_shaders[MESA_SHADER_COMPUTE] != prog->NumShaders) {
> + linker_error(prog, "Compute shaders may not be linked with any other "
> + "type of shader\n");
> + }
> +
> for (unsigned int i = 0; i < MESA_SHADER_STAGES; i++) {
>if (prog->_LinkedShaders[i] != NULL)
> ctx->Driver.DeleteShader(ctx, prog->_LinkedShaders[i]);
> --
> 1.8.5.2
>
> ___
> 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 29/30] i965/cs: Create the brw_compute_program struct, and the code to initialize it.
On Thu, Jan 9, 2014 at 6:19 PM, Paul Berry wrote:
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 8
> src/mesa/drivers/dri/i965/brw_program.c | 11 +++
> 2 files changed, 19 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index df32ccb..abc1783 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -316,6 +316,14 @@ struct brw_fragment_program {
> GLuint id; /**< serial no. to identify frag progs, never re-used */
> };
>
> +
> +/** Subclass of Mesa compute program */
> +struct brw_compute_program {
> + struct gl_compute_program program;
> + unsigned id; /**< serial no. to identify frag progs, never re-used */
"frag" in comment
Reviewed-by: Jordan Justen
> +};
> +
> +
> struct brw_shader {
> struct gl_shader base;
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c
> b/src/mesa/drivers/dri/i965/brw_program.c
> index 90844e5..2d92acb 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -113,6 +113,17 @@ static struct gl_program *brwNewProgram( struct
> gl_context *ctx,
>}
> }
>
> + case GL_COMPUTE_PROGRAM_NV: {
> + struct brw_compute_program *prog = CALLOC_STRUCT(brw_compute_program);
> + if (prog) {
> + prog->id = get_new_program_id(brw->intelScreen);
> +
> + return _mesa_init_compute_program(ctx, &prog->program, target, id);
> + } else {
> + return NULL;
> + }
> + }
> +
> default:
>assert(!"Unsupported target in brwNewProgram()");
>return NULL;
> --
> 1.8.5.2
>
> ___
> 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 30/30] i965/cs: Allow ARB_compute_shader to be enabled via env var.
On Thu, Jan 9, 2014 at 6:19 PM, Paul Berry wrote:
> This will allow testing of compute shader functionality before it is
> completed.
>
> To enable ARB_compute_shader functionality in the i965 driver, set
> INTEL_COMPUTE_SHADER=1.
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 11 ++-
> src/mesa/drivers/dri/i965/intel_extensions.c | 2 ++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 1b42751..76dd9be 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -298,10 +298,17 @@ brw_initialize_context_constants(struct brw_context
> *brw)
>ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits =
> BRW_MAX_TEX_UNIT;
> else
>ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits = 0;
> + if (getenv("INTEL_COMPUTE_SHADER")) {
What about trying to make use of MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader?
We could add
extensions.c:bool _mesa_is_extension_override_enabled(char *)
And then
if (_mesa_is_extension_override_enabled("GL_ARB_compute_shader"))
Or, similarly, get overrides shoved into ctx->Extensions to allow
checking for overrides at this early stage.
-Jordan
> + ctx->Const.Program[MESA_SHADER_COMPUTE].MaxTextureImageUnits =
> BRW_MAX_TEX_UNIT;
> + ctx->Const.MaxUniformBufferBindings += 12;
> + } else {
> + ctx->Const.Program[MESA_SHADER_COMPUTE].MaxTextureImageUnits = 0;
> + }
> ctx->Const.MaxCombinedTextureImageUnits =
>ctx->Const.Program[MESA_SHADER_VERTEX].MaxTextureImageUnits +
>ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits +
> - ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits;
> + ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits +
> + ctx->Const.Program[MESA_SHADER_COMPUTE].MaxTextureImageUnits;
>
> ctx->Const.MaxTextureLevels = 14; /* 8192 */
> if (ctx->Const.MaxTextureLevels > MAX_TEXTURE_LEVELS)
> @@ -425,9 +432,11 @@ brw_initialize_context_constants(struct brw_context *brw)
>ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxAtomicCounters =
> MAX_ATOMIC_COUNTERS;
>ctx->Const.Program[MESA_SHADER_VERTEX].MaxAtomicCounters =
> MAX_ATOMIC_COUNTERS;
>ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxAtomicCounters =
> MAX_ATOMIC_COUNTERS;
> + ctx->Const.Program[MESA_SHADER_COMPUTE].MaxAtomicCounters =
> MAX_ATOMIC_COUNTERS;
>ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxAtomicBuffers =
> BRW_MAX_ABO;
>ctx->Const.Program[MESA_SHADER_VERTEX].MaxAtomicBuffers = BRW_MAX_ABO;
>ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxAtomicBuffers =
> BRW_MAX_ABO;
> + ctx->Const.Program[MESA_SHADER_COMPUTE].MaxAtomicBuffers = BRW_MAX_ABO;
>ctx->Const.MaxCombinedAtomicBuffers = 3 * BRW_MAX_ABO;
> }
>
> diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
> b/src/mesa/drivers/dri/i965/intel_extensions.c
> index de07b7f..27bc97b 100644
> --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> @@ -294,6 +294,8 @@ intelInitExtensions(struct gl_context *ctx)
> ctx->Extensions.ARB_transform_feedback_instanced = true;
> ctx->Extensions.ARB_draw_indirect = true;
>}
> + if (getenv("INTEL_COMPUTE_SHADER"))
> + ctx->Extensions.ARB_compute_shader = true;
> }
>
> if (brw->gen == 5 || can_write_oacontrol(brw))
> --
> 1.8.5.2
>
> ___
> 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
