Re: [Mesa-dev] [PATCH v2] android: fix the build
On 07/17/2012 09:54 PM, Sean V Kelley wrote: On Mon, Jul 9, 2012 at 11:50 AM, Chad Versace wrote: Tapani, Is this patch still applicable? It seems that the autoconf work has calmed down, and now is a good time to fix the Android build. -Chad Tapani is out. But this patch has never quite worked for me. The build still breaks on Android over failure to generate enums.c I'm back now, my guess this failure has happened because you had previous build results in the intermediates directory, make clean or manual cleaning is required for this patch to work ok .. but I see there is now a new patch from Daniel which looks good, will try it out. Sean On 06/07/2012 04:11 AM, Tapani Pälli wrote: Some more of the files are now autogenerated, this caused build breakage, patch adds generation of these missing files. Patch also changes existing make so that the files are created to be part of the local source (not intermediate directory, this causes several problems). Signed-off-by: Tapani Pälli --- src/mesa/Android.gen.mk | 45 - 1 file changed, 16 insertions(+), 29 deletions(-) diff --git a/src/mesa/Android.gen.mk b/src/mesa/Android.gen.mk index 2a08184..2ea8cc4 100644 --- a/src/mesa/Android.gen.mk +++ b/src/mesa/Android.gen.mk @@ -28,16 +28,13 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES endif intermediates := $(call local-intermediates-dir) +mydir := $(call my-dir) sources := \ - main/api_exec_es1.c \ main/api_exec_es1_dispatch.h \ main/api_exec_es1_remap_helper.h \ - main/api_exec_es2.c \ main/api_exec_es2_dispatch.h \ - main/api_exec_es2_remap_helper.h \ - program/lex.yy.c \ - program/program_parse.tab.c + main/api_exec_es2_remap_helper.h LOCAL_SRC_FILES := $(filter-out $(sources), $(LOCAL_SRC_FILES)) @@ -53,6 +50,7 @@ endif sources += main/git_sha1.h sources := $(addprefix $(intermediates)/, $(sources)) + LOCAL_GENERATED_SOURCES += $(sources) glapi := $(MESA_TOP)/src/mapi/glapi/gen @@ -73,43 +71,31 @@ define es-gen $(hide) $(PRIVATE_SCRIPT) $(1) $(PRIVATE_XML) > $@ endef -define local-l-to-c - @mkdir -p $(dir $@) - @echo "Mesa Lex: $(PRIVATE_MODULE) <= $<" - $(hide) $(LEX) -o$@ $< -endef - -define local-y-to-c-and-h - @mkdir -p $(dir $@) - @echo "Mesa Yacc: $(PRIVATE_MODULE) <= $<" - $(hide) $(YACC) -o $@ $< +define generate-local + @echo "generate local sources" + $(hide) $(MESA_PYTHON2) $(glapi)/gl_enums.py -f $(glapi)/gl_and_es_API.xml > $(mydir)/main/enums.c + $(hide) $(MESA_PYTHON2) $(glapi)/gl_table.py -m remap_table -f $(glapi)/gl_and_es_API.xml > $(mydir)/main/dispatch.h + $(hide) $(MESA_PYTHON2) $(glapi)/remap_helper.py -f $(glapi)/gl_API.xml > $(mydir)/main/remap_helper.h + $(hide) $(MESA_PYTHON2) $(mydir)/main/es_generator.py -V GLES1.1 -S $(mydir)/main/APIspec.xml > $(mydir)/main/api_exec_es1.c + $(hide) $(MESA_PYTHON2) $(mydir)/main/es_generator.py -V GLES2.0 -S $(mydir)/main/APIspec.xml > $(mydir)/main/api_exec_es2.c + + @echo "Mesa Lex : $(PRIVATE_MODULE)" + $(hide) $(LEX) -o $(mydir)/program/lex.yy.c $(mydir)/program/program_lexer.l + @echo "Mesa Yacc: $(PRIVATE_MODULE)" + $(hide) $(YACC) -d -o $(mydir)/program/program_parse.tab.c $(mydir)/program/program_parse.y endef -$(intermediates)/main/api_exec_%.c: PRIVATE_SCRIPT := $(MESA_PYTHON2) $(LOCAL_PATH)/main/es_generator.py -$(intermediates)/main/api_exec_%.c: PRIVATE_XML := -S $(LOCAL_PATH)/main/APIspec.xml $(intermediates)/main/api_exec_%_dispatch.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) $(glapi)/gl_table.py $(intermediates)/main/api_exec_%_dispatch.h: PRIVATE_XML := -f $(glapi)/gl_and_es_API.xml $(intermediates)/main/api_exec_%_remap_helper.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) $(glapi)/remap_helper.py $(intermediates)/main/api_exec_%_remap_helper.h: PRIVATE_XML := -f $(glapi)/gl_and_es_API.xml -$(intermediates)/main/api_exec_es1.c: $(es_src_deps) - $(call es-gen,-V GLES1.1) - -$(intermediates)/main/api_exec_es2.c: $(es_src_deps) - $(call es-gen,-V GLES2.0) - $(intermediates)/main/api_exec_%_dispatch.h: $(es_hdr_deps) $(call es-gen, -c $* -m remap_table) $(intermediates)/main/api_exec_%_remap_helper.h: $(es_hdr_deps) $(call es-gen, -c $*) -$(intermediates)/program/program_parse.tab.c: $(LOCAL_PATH)/program/program_parse.y - $(local-y-to-c-and-h) - -$(intermediates)/program/lex.yy.c: $(LOCAL_PATH)/program/program_lexer.l - $(local-l-to-c) - $(intermediates)/main/git_sha1.h: @mkdir -p $(dir $@) @echo "GIT-SHA1: $(PRIVATE_MODULE) <= git" @@ -129,3 +115,4 @@ $(intermediates)/x86/matypes.h: $(matypes_deps) @mkdir -p $(dir $@) @echo "MATYPES: $(PRIVATE_MODULE) <= $(notdir $@)" $(hide) $< > $@ + $(call generate-local) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinf
Re: [Mesa-dev] [PATCHv2] automake: Honor GL_LIB for mangled/custom lib names
On 07/16/2012 09:10 AM, Brad King wrote: > Use "@GL_LIB@" in src/mesa/drivers/x11/Makefile.am to configure the > library name. Also use this approach to simplify src/glx/Makefile.am > and drop the HAVE_MANGLED_GL conditional. > > On 07/11/2012 04:05 PM, Dan Nicholson wrote: >> Looks good to me. I wonder if the HAVE_MANGLED_GL conditional can be >> dropped at this point? Anyway, >> >> Reviewed-by: Dan Nicholson > > Additional changes have been made on master which conflict with > the previous patch, so here is another one rebased on 81de0431. > I also dropped the HAVE_MANGLED_GL conditional as it no longer > appears necessary. Please review this patch again when you get a chance. There is no rush, I just don't want it to be forgotten. Thanks, -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52346] libxcb version not specified (correctly) in dependency check
https://bugs.freedesktop.org/show_bug.cgi?id=52346 --- Comment #1 from Tom Stellard 2012-07-23 13:18:19 PDT --- I sent a patch to fix this to the mailing list a few days ago. http://comments.gmane.org/gmane.comp.video.mesa3d.devel/42535 I'm not really sure if this is correct. I was hoping to get some reviews, but I can push it if it fixes the problem for you. -- 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 12/15] intel: Downsample on DRI2 flush
On Sat, Jul 21, 2012 at 6:36 PM, Chad Versace
wrote:
> CC: Eric Anholt
> CC: Paul Berry
> Signed-off-by: Chad Versace
> ---
> src/mesa/drivers/dri/intel/intel_screen.c | 31
> +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> b/src/mesa/drivers/dri/intel/intel_screen.c
> index 4a12b67..958ff9f 100644
> --- a/src/mesa/drivers/dri/intel/intel_screen.c
> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> @@ -177,6 +177,36 @@ static const __DRItexBufferExtension
> intelTexBufferExtension = {
> };
>
> static void
> +intel_downsample_for_dri2_flush(struct intel_context *intel,
> +__DRIdrawable *drawable)
> +{
> + if (intel->gen < 6) {
> + /* MSAA is not supported, so don't waste time checking for
> + * a multisample buffer.
> + */
> + return;
> + }
> +
> + struct gl_framebuffer *fb = drawable->driverPrivate;
> + struct intel_renderbuffer *rb;
Declarations following code will cause a compiler error (depending on
the compiler and flags). You might want to fix that, just in case.
> +
> + /* Usually, only the back buffer will need to be downsampled. However,
> +* the front buffer will also need it if the user has rendered into it.
> +*/
> + static const gl_buffer_index buffers[2] = {
> + BUFFER_BACK_LEFT,
> + BUFFER_FRONT_LEFT,
> + };
> +
> + for (int i = 0; i < 2; ++i) {
> + rb = intel_get_renderbuffer(fb, buffers[i]);
> + if (rb == NULL || rb->mt == NULL)
> + continue;
> + intel_miptree_downsample(intel, rb->mt);
> + }
> +}
> +
> +static void
> intelDRI2Flush(__DRIdrawable *drawable)
> {
> GET_CURRENT_CONTEXT(ctx);
> @@ -187,6 +217,7 @@ intelDRI2Flush(__DRIdrawable *drawable)
> if (intel->gen < 4)
>INTEL_FIREVERTICES(intel);
>
> + intel_downsample_for_dri2_flush(intel, drawable);
> intel->need_throttle = true;
>
> if (intel->batch.used)
> --
> 1.7.11.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 0/4] Makefile.am fixes and clean-up
Some follow-up patches after my automake changes of last week. Jon TURNEY (4): drivers/X11: Link X11 libGL with -no-undefined libtool flag drivers/osmesa: Link OSMesa using -no-undefined libtool flag Update mesa/drivers/x11/Makefile.am for xm_image.h removal Remove redundant osmesa shared library install from Makefile.old configs/current.in |1 - configs/default |1 - configure.ac|2 -- src/mesa/Makefile.am|7 --- src/mesa/Makefile.old | 27 --- src/mesa/drivers/osmesa/Makefile.am |2 +- src/mesa/drivers/x11/Makefile.am|2 +- 7 files changed, 6 insertions(+), 36 deletions(-) delete mode 100644 src/mesa/Makefile.old -- 1.7.9 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] drivers/X11: Link X11 libGL with -no-undefined libtool flag
"Use -no-undefined to assure libtool that the library has no unresolved symbols at link time, so that libtool will build a shared library on platforms require that all symbols are resolved when the library is linked." Signed-off-by: Jon TURNEY --- src/mesa/drivers/x11/Makefile.am |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/x11/Makefile.am b/src/mesa/drivers/x11/Makefile.am index 52febbb..53c5142 100644 --- a/src/mesa/drivers/x11/Makefile.am +++ b/src/mesa/drivers/x11/Makefile.am @@ -60,6 +60,7 @@ libGL_la_LIBADD = \ $(top_builddir)/src/mapi/glapi/libglapi.la libGL_la_LDFLAGS = \ -version-number $(GL_MAJOR):$(GL_MINOR):$(GL_PATCH) \ + -no-undefined \ $(GL_LIB_DEPS) if HAVE_SHARED_GLAPI -- 1.7.9 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] drivers/osmesa: Link OSMesa using -no-undefined libtool flag
"Use -no-undefined to assure libtool that the library has no unresolved symbols at link time, so that libtool will build a shared library on platforms require that all symbols are resolved when the library is linked." Signed-off-by: Jon TURNEY --- src/mesa/drivers/osmesa/Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/osmesa/Makefile.am b/src/mesa/drivers/osmesa/Makefile.am index 7c151bf..59ee62a 100644 --- a/src/mesa/drivers/osmesa/Makefile.am +++ b/src/mesa/drivers/osmesa/Makefile.am @@ -37,7 +37,7 @@ endif lib@OSMESA_LIB@_la_SOURCES = osmesa.c -lib@OSMESA_LIB@_la_LDFLAGS = -module -version-number @OSMESA_VERSION@ -shared +lib@OSMESA_LIB@_la_LDFLAGS = -module -version-number @OSMESA_VERSION@ -shared -no-undefined lib@OSMESA_LIB@_la_LIBADD = \ $(top_builddir)/src/mesa/libmesa.la \ $(top_builddir)/src/mapi/glapi/libglapi.la -- 1.7.9 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] Update mesa/drivers/x11/Makefile.am for xm_image.h removal
Commit 6c6803f28de0d4cb6937fcd95a47aa81da31fd78 removed xm_image.[ch], and removed xm_image.c, but not xm_image.h from the Makefile, this was subsequently carried over into Makefile.am Remove xm_image.h from Makfile.am. This allows 'make dist' to succeed, even if it doesn't do anything useful Signed-off-by: Jon TURNEY --- src/mesa/drivers/x11/Makefile.am |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/x11/Makefile.am b/src/mesa/drivers/x11/Makefile.am index 53c5142..49c531d 100644 --- a/src/mesa/drivers/x11/Makefile.am +++ b/src/mesa/drivers/x11/Makefile.am @@ -41,7 +41,6 @@ libGL_la_SOURCES = \ glxheader.h \ xfonts.h \ xmesaP.h \ - xm_image.h \ fakeglx.c \ glxapi.c \ xfonts.c \ -- 1.7.9 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] Remove redundant osmesa shared library install from Makefile.old
Since osmesa now has been converted to Makefile.am, an appropriate install: rule
is generated to install the shared libary, so we no longer need to do that in
src/mesa/Makefile.old
This leaves nothing in src/mesa/Makefile.old but the tags: rule, so move that to
Makefile.am and remove Makefile.old
Also, nothing now uses OSMESA_LIB_GLOB anymore, so remove it
Signed-off-by: Jon TURNEY
---
configs/current.in|1 -
configs/default |1 -
configure.ac |2 --
src/mesa/Makefile.am |7 ---
src/mesa/Makefile.old | 27 ---
5 files changed, 4 insertions(+), 34 deletions(-)
delete mode 100644 src/mesa/Makefile.old
diff --git a/configs/current.in b/configs/current.in
index dc0dea8..9785a5a 100644
--- a/configs/current.in
+++ b/configs/current.in
@@ -99,7 +99,6 @@ GLAPI_LIB_NAME = @GLAPI_LIB_NAME@
GL_LIB_GLOB = @GL_LIB_GLOB@
GLU_LIB_GLOB = @GLU_LIB_GLOB@
GLW_LIB_GLOB = @GLW_LIB_GLOB@
-OSMESA_LIB_GLOB = @OSMESA_LIB_GLOB@
EGL_LIB_GLOB = @EGL_LIB_GLOB@
GLESv1_CM_LIB_GLOB = @GLESv1_CM_LIB_GLOB@
GLESv2_LIB_GLOB = @GLESv2_LIB_GLOB@
diff --git a/configs/default b/configs/default
index 734b2f6..8a8d8f8 100644
--- a/configs/default
+++ b/configs/default
@@ -76,7 +76,6 @@ GLAPI_LIB_NAME = lib$(GLAPI_LIB).so
GL_LIB_GLOB = $(GL_LIB_NAME)*
GLU_LIB_GLOB = $(GLU_LIB_NAME)*
GLW_LIB_GLOB = $(GLW_LIB_NAME)*
-OSMESA_LIB_GLOB = $(OSMESA_LIB_NAME)*
EGL_LIB_GLOB = $(EGL_LIB_NAME)*
GLESv1_CM_LIB_GLOB = $(GLESv1_CM_LIB_NAME)*
GLESv2_LIB_GLOB = $(GLESv2_LIB_NAME)*
diff --git a/configure.ac b/configure.ac
index 7b88331..5e12c07 100644
--- a/configure.ac
+++ b/configure.ac
@@ -417,7 +417,6 @@ GLAPI_LIB_NAME='lib$(GLAPI_LIB).'${LIB_EXTENSION}
GL_LIB_GLOB=${LIB_PREFIX_GLOB}'$(GL_LIB)'${LIB_VERSION_SEPARATOR}'*'${LIB_EXTENSION}'*'
GLU_LIB_GLOB=${LIB_PREFIX_GLOB}'$(GLU_LIB)'${LIB_VERSION_SEPARATOR}'*'${LIB_EXTENSION}'*'
-OSMESA_LIB_GLOB=${LIB_PREFIX_GLOB}'$(OSMESA_LIB)'${LIB_VERSION_SEPARATOR}'*'${LIB_EXTENSION}'*'
EGL_LIB_GLOB=${LIB_PREFIX_GLOB}'$(EGL_LIB)'${LIB_VERSION_SEPARATOR}'*'${LIB_EXTENSION}'*'
EGL_LIB_GLOB=${LIB_PREFIX_GLOB}'$(EGL_LIB)'${LIB_VERSION_SEPARATOR}'*'${LIB_EXTENSION}'*'
GLESv1_CM_LIB_GLOB=${LIB_PREFIX_GLOB}'$(GLESv1_CM_LIB)'${LIB_VERSION_SEPARATOR}'*'${LIB_EXTENSION}'*'
@@ -436,7 +435,6 @@ AC_SUBST([GLAPI_LIB_NAME])
AC_SUBST([GL_LIB_GLOB])
AC_SUBST([GLU_LIB_GLOB])
-AC_SUBST([OSMESA_LIB_GLOB])
AC_SUBST([EGL_LIB_GLOB])
AC_SUBST([GLESv1_CM_LIB_GLOB])
AC_SUBST([GLESv2_LIB_GLOB])
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index 2b023d7..94fe499 100644
--- a/src/mesa/Makefile.am
+++ b/src/mesa/Makefile.am
@@ -131,9 +131,6 @@ libmesagallium_la_SOURCES = \
libmesagallium_la_LIBADD = $(top_builddir)/src/glsl/libglsl.la
libmesagallium_la_LDFLAGS =
-install-exec-local:
- $(MAKE) -f $(srcdir)/Makefile.old install
-
# Provide compatibility with scripts for the old Mesa build system for
# a while by putting a link to the library in the current directory.
all-local: libmesa.la libmesagallium.la
@@ -149,3 +146,7 @@ pkgconfig_DATA = osmesa.pc
else
pkgconfig_DATA = gl.pc
endif
+
+# Emacs tags
+tags:
+ etags `find . -name \*.[ch]` $(TOP)/include/GL/*.h
diff --git a/src/mesa/Makefile.old b/src/mesa/Makefile.old
deleted file mode 100644
index 3266a5d..000
--- a/src/mesa/Makefile.old
+++ /dev/null
@@ -1,27 +0,0 @@
-# src/mesa/Makefile
-
-TOP = ../..
-include $(TOP)/configs/current
-
-SRCDIR = .
-include sources.mak
-
-default:
-
-##
-# Installation rules
-
-install: default $(DRICORE_INSTALL_TARGET)
- @for driver in $(DRIVER_DIRS) ; do \
- case "$$driver" in \
- osmesa) $(MAKE) -f Makefile.old install-osmesa || exit 1 ;; \
- esac ; \
- done
-
-install-osmesa: default
- $(MINSTALL) $(TOP)/$(LIB_DIR)/$(OSMESA_LIB_GLOB) \
- $(DESTDIR)$(INSTALL_LIB_DIR)
-
-# Emacs tags
-tags:
- etags `find . -name \*.[ch]` $(TOP)/include/GL/*.h
--
1.7.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix format checking when doing a multisample resolve
On 07/21/2012 03:30 PM, Marek Olšák wrote:
v2: make it more bullet-proof
---
src/mesa/main/fbobject.c | 112 +-
1 file changed, 111 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 4370c72..ca43f81 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2633,6 +2633,116 @@ compatible_color_datatypes(gl_format srcFormat,
gl_format dstFormat)
/**
+ * Return the equivalent non-generic internal format.
+ * This is useful for comparing whether two internal formats are semantically
+ * equivalent.
+ */
+static GLenum
+get_nongeneric_internalformat(GLenum format)
+{
+ switch (format) {
+ /* GL 1.1 formats. */
+ case 4:
+ case GL_RGBA:
+ return GL_RGBA8;
+
+ case 3:
+ case GL_RGB:
+ return GL_RGB8;
+
+ case 2:
+ case GL_LUMINANCE_ALPHA:
+ return GL_LUMINANCE8_ALPHA8;
+
+ case 1:
+ case GL_LUMINANCE:
+ return GL_LUMINANCE8;
+
+ case GL_ALPHA:
+ return GL_ALPHA8;
+
+ case GL_INTENSITY:
+ return GL_INTENSITY8;
+
+ /* GL_ARB_texture_rg */
+ case GL_RED:
+ return GL_R8;
+
+ case GL_RG:
+ return GL_RG8;
+
+ /* GL_EXT_texture_sRGB */
+ case GL_SRGB:
+ return GL_SRGB8;
+
+ case GL_SRGB_ALPHA:
+ return GL_SRGB8_ALPHA8;
+
+ case GL_SLUMINANCE:
+ return GL_SLUMINANCE8;
+
+ case GL_SLUMINANCE_ALPHA:
+ return GL_SLUMINANCE8_ALPHA8;
+
+ /* GL_EXT_texture_snorm */
+ case GL_RGBA_SNORM:
+ return GL_RGBA8_SNORM;
+
+ case GL_RGB_SNORM:
+ return GL_RGB8_SNORM;
+
+ case GL_RG_SNORM:
+ return GL_RG8_SNORM;
+
+ case GL_RED_SNORM:
+ return GL_R8_SNORM;
+
+ case GL_LUMINANCE_ALPHA_SNORM:
+ return GL_LUMINANCE8_ALPHA8_SNORM;
+
+ case GL_LUMINANCE_SNORM:
+ return GL_LUMINANCE8_SNORM;
+
+ case GL_ALPHA_SNORM:
+ return GL_ALPHA8_SNORM;
+
+ case GL_INTENSITY_SNORM:
+ return GL_INTENSITY8_SNORM;
+
+ default:
+ return format;
+ }
+}
+
+
+static GLboolean
+compatible_resolve_formats(const struct gl_renderbuffer *colorReadRb,
+ const struct gl_renderbuffer *colorDrawRb)
+{
+ /* The simple case where we know the backing formats are the same.
+*/
+ if (colorReadRb->Format == colorDrawRb->Format) {
+ return GL_TRUE;
+ }
+
+ /* The Mesa formats are different, so we must check whether the internal
+* formats are compatible.
+*
+* Under some circumstances, the user may request e.g. two GL_RGBA8
+* textures and get two entirely different Mesa formats like RGBA and
+* ARGB. Drivers behaving like that should be able to cope with
+* non-matching formats by themselves, because it's not the user's fault.
+*/
+ if (get_nongeneric_internalformat(colorReadRb->InternalFormat) ==
+ get_nongeneric_internalformat(colorDrawRb->InternalFormat)) {
+ return GL_TRUE;
+ }
+
+ return GL_FALSE;
+}
+
+
+/**
* Blit rectangular region, optionally from one framebuffer to another.
*
* Note, if the src buffer is multisampled and the dest is not, this is
@@ -2798,7 +2908,7 @@ _mesa_BlitFramebufferEXT(GLint srcX0, GLint srcY0, GLint
srcX1, GLint srcY1,
/* color formats must match */
if (colorReadRb&&
colorDrawRb&&
- colorReadRb->Format != colorDrawRb->Format) {
+ !compatible_resolve_formats(colorReadRb, colorDrawRb)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
"glBlitFramebufferEXT(bad src/dst multisample pixel
formats)");
return;
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: set the correct window renderbuffer internal format
On 07/21/2012 05:37 PM, Marek Olšák wrote: The multisample-resolve blit relies on this being correct. --- src/mesa/state_tracker/st_cb_fbo.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/mesa/state_tracker/st_cb_fbo.c b/src/mesa/state_tracker/st_cb_fbo.c index e1818ab..7eef5c6 100644 --- a/src/mesa/state_tracker/st_cb_fbo.c +++ b/src/mesa/state_tracker/st_cb_fbo.c @@ -291,13 +291,21 @@ st_new_renderbuffer_fb(enum pipe_format format, int samples, boolean sw) case PIPE_FORMAT_R8G8B8A8_UNORM: case PIPE_FORMAT_B8G8R8A8_UNORM: case PIPE_FORMAT_A8R8G8B8_UNORM: + strb->Base.InternalFormat = GL_RGBA8; + break; case PIPE_FORMAT_R8G8B8X8_UNORM: case PIPE_FORMAT_B8G8R8X8_UNORM: case PIPE_FORMAT_X8R8G8B8_UNORM: + strb->Base.InternalFormat = GL_RGB8; + break; case PIPE_FORMAT_B5G5R5A1_UNORM: + strb->Base.InternalFormat = GL_RGB5_A1; + break; case PIPE_FORMAT_B4G4R4A4_UNORM: + strb->Base.InternalFormat = GL_RGBA4; + break; case PIPE_FORMAT_B5G6R5_UNORM: - strb->Base.InternalFormat = GL_RGBA; + strb->Base.InternalFormat = GL_RGB565; break; case PIPE_FORMAT_Z16_UNORM: strb->Base.InternalFormat = GL_DEPTH_COMPONENT16; Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): st/mesa: remove st_flush_bitmap wrapper
On 07/21/2012 07:39 PM, Marek Olšák wrote:
Module: Mesa
Branch: master
Commit: f96405f254819238ef6bce8e7341fcc7d00eaf85
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f96405f254819238ef6bce8e7341fcc7d00eaf85
Author: Marek Olšák
Date: Sun Jul 22 02:46:30 2012 +0200
st/mesa: remove st_flush_bitmap wrapper
just a cleanup
---
src/mesa/state_tracker/st_cb_bitmap.c | 10 --
src/mesa/state_tracker/st_cb_bitmap.h |6 --
src/mesa/state_tracker/st_cb_flush.c |2 +-
3 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c
b/src/mesa/state_tracker/st_cb_bitmap.c
index 09152c7..f48c9c1 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -684,16 +684,6 @@ st_flush_bitmap_cache(struct st_context *st)
/**
- * Flush bitmap cache.
- */
-void
-st_flush_bitmap( struct st_context *st )
-{
- st_flush_bitmap_cache(st);
-}
-
-
-/**
* Try to accumulate this glBitmap call in the bitmap cache.
* \return GL_TRUE for success, GL_FALSE if bitmap is too large, etc.
*/
diff --git a/src/mesa/state_tracker/st_cb_bitmap.h
b/src/mesa/state_tracker/st_cb_bitmap.h
index ed14158..25410e5 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.h
+++ b/src/mesa/state_tracker/st_cb_bitmap.h
@@ -58,12 +58,6 @@ st_make_bitmap_fragment_program(struct st_context *st,
extern void
st_flush_bitmap_cache(struct st_context *st);
-/* Flush bitmap cache and release vertex buffer. Needed at end of
- * frame to avoid synchronous rendering.
- */
-extern void
-st_flush_bitmap(struct st_context *st);
-
#else
static INLINE void
diff --git a/src/mesa/state_tracker/st_cb_flush.c
b/src/mesa/state_tracker/st_cb_flush.c
index 4e40a93..b4372ae 100644
--- a/src/mesa/state_tracker/st_cb_flush.c
+++ b/src/mesa/state_tracker/st_cb_flush.c
@@ -81,7 +81,7 @@ void st_flush( struct st_context *st,
{
FLUSH_CURRENT(st->ctx, 0);
- st_flush_bitmap(st);
+ st_flush_bitmap_cache(st);
st->pipe->flush( st->pipe, fence );
}
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: flush the glBitmap cache before changing framebuffer state
On 07/21/2012 08:41 PM, Marek Olšák wrote:
This fixes the piglit EXT_framebuffer_multisample/bitmap tests.
Note that we must not rely on ctx->DrawBuffer when flushing the cache, because
that's already updated with a new framebuffer. We want to draw into the old
framebuffer where glBitmap was called.
---
src/mesa/state_tracker/st_atom_framebuffer.c |4 ++
src/mesa/state_tracker/st_cb_bitmap.c| 74 --
src/mesa/state_tracker/st_context.h |2 +
3 files changed, 41 insertions(+), 39 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c
b/src/mesa/state_tracker/st_atom_framebuffer.c
index a8907c1..6f94a47 100644
--- a/src/mesa/state_tracker/st_atom_framebuffer.c
+++ b/src/mesa/state_tracker/st_atom_framebuffer.c
@@ -33,6 +33,7 @@
#include "st_context.h"
#include "st_atom.h"
+#include "st_cb_bitmap.h"
#include "st_cb_fbo.h"
#include "st_texture.h"
#include "pipe/p_context.h"
@@ -103,6 +104,9 @@ update_framebuffer_state( struct st_context *st )
struct st_renderbuffer *strb;
GLuint i;
+ st_flush_bitmap_cache(st);
+
+ st->state.fb_orientation = st_fb_orientation(fb);
framebuffer->width = fb->Width;
framebuffer->height = fb->Height;
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c
b/src/mesa/state_tracker/st_cb_bitmap.c
index f48c9c1..c260588 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -335,9 +335,8 @@ setup_bitmap_vertex_data(struct st_context *st, bool
normalized,
struct pipe_resource **vbuf,
unsigned *vbuf_offset)
{
- const struct gl_framebuffer *fb = st->ctx->DrawBuffer;
- const GLfloat fb_width = (GLfloat)fb->Width;
- const GLfloat fb_height = (GLfloat)fb->Height;
+ const GLfloat fb_width = (GLfloat)st->state.framebuffer.width;
+ const GLfloat fb_height = (GLfloat)st->state.framebuffer.height;
const GLfloat x0 = (GLfloat)x;
const GLfloat x1 = (GLfloat)(x + width);
const GLfloat y0 = (GLfloat)y;
@@ -502,10 +501,9 @@ draw_bitmap_quad(struct gl_context *ctx, GLint x, GLint y,
GLfloat z,
/* viewport state: viewport matching window dims */
{
- const struct gl_framebuffer *fb = st->ctx->DrawBuffer;
- const GLboolean invert = (st_fb_orientation(fb) == Y_0_TOP);
- const GLfloat width = (GLfloat)fb->Width;
- const GLfloat height = (GLfloat)fb->Height;
+ const GLboolean invert = st->state.fb_orientation == Y_0_TOP;
+ const GLfloat width = (GLfloat)st->state.framebuffer.width;
+ const GLfloat height = (GLfloat)st->state.framebuffer.height;
struct pipe_viewport_state vp;
vp.scale[0] = 0.5f * width;
vp.scale[1] = height * (invert ? -0.5f : 0.5f);
@@ -636,43 +634,41 @@ st_flush_bitmap_cache(struct st_context *st)
if (!st->bitmap.cache->empty) {
struct bitmap_cache *cache = st->bitmap.cache;
- if (st->ctx->DrawBuffer) {
- struct pipe_context *pipe = st->pipe;
- struct pipe_sampler_view *sv;
+ struct pipe_context *pipe = st->pipe;
+ struct pipe_sampler_view *sv;
- assert(cache->xmin<= cache->xmax);
-
-/* printf("flush size %d x %d at %d, %d\n",
-cache->xmax - cache->xmin,
-cache->ymax - cache->ymin,
-cache->xpos, cache->ypos);
+ assert(cache->xmin<= cache->xmax);
+
+/*printf("flush size %d x %d at %d, %d\n",
+ cache->xmax - cache->xmin,
+ cache->ymax - cache->ymin,
+ cache->xpos, cache->ypos);
*/
- /* The texture transfer has been mapped until now.
+ /* The texture transfer has been mapped until now.
* So unmap and release the texture transfer before drawing.
*/
- if (cache->trans) {
-if (0)
- print_cache(cache);
-pipe_transfer_unmap(pipe, cache->trans);
-cache->buffer = NULL;
-
-pipe->transfer_destroy(pipe, cache->trans);
-cache->trans = NULL;
- }
-
- sv = st_create_texture_sampler_view(st->pipe, cache->texture);
- if (sv) {
-draw_bitmap_quad(st->ctx,
- cache->xpos,
- cache->ypos,
- cache->zpos,
- BITMAP_CACHE_WIDTH, BITMAP_CACHE_HEIGHT,
- sv,
- cache->color);
-
-pipe_sampler_view_reference(&sv, NULL);
- }
+ if (cache->trans) {
+ if (0)
+print_cache(cache);
+ pipe_transfer_unmap(pipe, cache->trans);
+ cache->buffer = NULL;
+
+ pipe->transfer_destroy(pipe, cache->trans);
+ cache->trans = NULL;
+ }
+
+ sv = st_create_texture_sampler_view(st->pipe, cache->texture);
+ if (sv) {
+ draw_bitmap_quad(st->ctx,
+ cache->xpos
Re: [Mesa-dev] [PATCH 1/2] st/mesa: set the centroid qualifier in fragment shader inputs
On 07/22/2012 05:37 PM, Marek Olšák wrote:
This fixes some centroid tests in the EXT_framebuffer_multisample piglit group.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 10 ++
src/mesa/state_tracker/st_glsl_to_tgsi.h |1 +
src/mesa/state_tracker/st_program.c|4
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 50c450e..45136de 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4481,6 +4481,7 @@ st_translate_program(
const ubyte inputSemanticName[],
const ubyte inputSemanticIndex[],
const GLuint interpMode[],
+ const GLboolean is_centroid[],
GLuint numOutputs,
const GLuint outputMapping[],
const ubyte outputSemanticName[],
@@ -4522,10 +4523,11 @@ st_translate_program(
*/
if (procType == TGSI_PROCESSOR_FRAGMENT) {
for (i = 0; i< numInputs; i++) {
- t->inputs[i] = ureg_DECL_fs_input(ureg,
- inputSemanticName[i],
- inputSemanticIndex[i],
- interpMode[i]);
+ t->inputs[i] = ureg_DECL_fs_input_cyl_centroid(ureg,
+inputSemanticName[i],
+inputSemanticIndex[i],
+interpMode[i], 0,
+is_centroid[i]);
}
if (proginfo->InputsRead& FRAG_BIT_WPOS) {
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.h
b/src/mesa/state_tracker/st_glsl_to_tgsi.h
index 55d59d5..a3fe91f 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.h
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.h
@@ -45,6 +45,7 @@ enum pipe_error st_translate_program(
const ubyte inputSemanticName[],
const ubyte inputSemanticIndex[],
const GLuint interpMode[],
+ const GLboolean is_centroid[],
GLuint numOutputs,
const GLuint outputMapping[],
const ubyte outputSemanticName[],
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index 9f98298..36015f6 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -347,6 +347,7 @@ st_translate_vertex_program(struct st_context *st,
NULL, /* input semantic name */
NULL, /* input semantic index */
NULL, /* interp mode */
+ NULL, /* is centroid */
/* outputs */
stvp->num_outputs,
stvp->result_to_output,
@@ -484,6 +485,7 @@ st_translate_fragment_program(struct st_context *st,
ubyte input_semantic_name[PIPE_MAX_SHADER_INPUTS];
ubyte input_semantic_index[PIPE_MAX_SHADER_INPUTS];
+ GLboolean is_centroid[PIPE_MAX_SHADER_INPUTS];
uint fs_num_inputs = 0;
ubyte fs_output_semantic_name[PIPE_MAX_SHADER_OUTPUTS];
@@ -537,6 +539,7 @@ st_translate_fragment_program(struct st_context *st,
const GLuint slot = fs_num_inputs++;
inputMapping[attr] = slot;
+ is_centroid[slot] = (stfp->Base.IsCentroid& BITFIELD64_BIT(attr)) !=
0;
switch (attr) {
case FRAG_ATTRIB_WPOS:
@@ -716,6 +719,7 @@ st_translate_fragment_program(struct st_context *st,
input_semantic_name,
input_semantic_index,
interpMode,
+ is_centroid,
/* outputs */
fs_num_outputs,
outputMapping,
Reviewed-by: Brian Paul
___
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: fix DDY opcode for FBOs
On 07/22/2012 05:37 PM, Marek Olšák wrote:
This fixes piglit/fbo-deriv.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 45136de..fcd69b1 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -1448,9 +1448,29 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
emit(ir, TGSI_OPCODE_DDX, result_dst, op[0]);
break;
case ir_unop_dFdy:
- op[0].negate = ~op[0].negate;
- emit(ir, TGSI_OPCODE_DDY, result_dst, op[0]);
+ {
+ /* The X component contains 1 or -1 depending on whether the framebuffer
+ * is a FBO or the window system buffer, respectively.
+ * It is then multiplied with the source operand of DDY.
+ */
+ static const gl_state_index transform_y_state[STATE_LENGTH]
+ = { STATE_INTERNAL, STATE_FB_WPOS_Y_TRANSFORM };
+
+ unsigned transform_y_index =
+ _mesa_add_state_reference(this->prog->Parameters,
+ transform_y_state);
+
+ st_src_reg transform_y = st_src_reg(PROGRAM_STATE_VAR,
+ transform_y_index,
+ glsl_type::vec4_type);
+ transform_y.swizzle = SWIZZLE_;
+
+ st_src_reg temp = get_temp(glsl_type::vec4_type);
+
+ emit(ir, TGSI_OPCODE_MUL, st_dst_reg(temp), transform_y, op[0]);
+ emit(ir, TGSI_OPCODE_DDY, result_dst, temp);
break;
+ }
case ir_unop_noise: {
/* At some point, a motivated person could add a better
This was on my list of things to check/test too. Thanks.
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] drivers/X11: Link X11 libGL with -no-undefined libtool flag
On Mon, Jul 23, 2012 at 6:32 AM, Jon TURNEY wrote: > "Use -no-undefined to assure libtool that the library has no > unresolved symbols at link time, so that libtool will build a shared > library on platforms require that all symbols are resolved when the > library is linked." > > Signed-off-by: Jon TURNEY > --- > src/mesa/drivers/x11/Makefile.am |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/src/mesa/drivers/x11/Makefile.am > b/src/mesa/drivers/x11/Makefile.am > index 52febbb..53c5142 100644 > --- a/src/mesa/drivers/x11/Makefile.am > +++ b/src/mesa/drivers/x11/Makefile.am > @@ -60,6 +60,7 @@ libGL_la_LIBADD = \ > $(top_builddir)/src/mapi/glapi/libglapi.la > libGL_la_LDFLAGS = \ > -version-number $(GL_MAJOR):$(GL_MINOR):$(GL_PATCH) \ > + -no-undefined \ > $(GL_LIB_DEPS) > > if HAVE_SHARED_GLAPI > -- > 1.7.9 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev Series is 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 0/4] Makefile.am fixes and clean-up
On 07/23/2012 07:32 AM, Jon TURNEY wrote: Some follow-up patches after my automake changes of last week. Jon TURNEY (4): drivers/X11: Link X11 libGL with -no-undefined libtool flag drivers/osmesa: Link OSMesa using -no-undefined libtool flag Update mesa/drivers/x11/Makefile.am for xm_image.h removal Remove redundant osmesa shared library install from Makefile.old configs/current.in |1 - configs/default |1 - configure.ac|2 -- src/mesa/Makefile.am|7 --- src/mesa/Makefile.old | 27 --- src/mesa/drivers/osmesa/Makefile.am |2 +- src/mesa/drivers/x11/Makefile.am|2 +- 7 files changed, 6 insertions(+), 36 deletions(-) delete mode 100644 src/mesa/Makefile.old The series looks OK to me. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
On Sun, Jul 22, 2012 at 8:58 PM, Marek Olšák wrote: > On Fri, Jul 20, 2012 at 4:54 AM, Jerome Glisse wrote: >> On Thu, Jul 19, 2012 at 10:25 PM, Marek Olšák wrote: >>> On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse wrote: On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák wrote: > I actually care a lot about lockups. Well, you are complaing about > lockups, yet you have quite obvious bugs in your hyperz code, so let's > fix them first. (I wouldn't even try and run the hyperz code in its > current state. Please don't take that personally.) Then, if the > lockups persist, we can start looking into *what* fixes them. You seem > to think that this patch helps a lot, but you don't say why. Aren't > you interested in what sequence of GPU commands helps? If I am > counting correctly, there are 7 changes in behavior in this patch. It > should be pretty easy to nail down the few that help, document them > (like /* these two lines fix a lockup with hyperz */), and discard the > rest. The documenting part is very important, so that the other > developers won't break your code accidentally. > > Marek > You haven't even try hyperz and you say i have an obvious bug, that's kind of funny, but you would not know why. I try pretty much all of >>> >>> Oh come on, I already told you about all the bugs I found in the >>> hyperz patch. You now know them too, and so does everybody else >>> reading mesa-dev. >>> >>> Marek >>> >> >> None of the issue you pointed out showed in piglit, none of them did >> have impact on things like openarena, nexuiz, doomIII, lightmark, ... >> so no issue you pointed does not cripple the hyperz patch, it's >> working quite well for many things. Before you extrapolate, yes issue >> you pointed out have impact in backward use of GL but none the less i >> addressed them and i can tell you it does help a bit with lockup. > > I have no doubt that it helps with your lockups and I also have no > doubt that the piece of code that helps can be bisected. I have > mentioned 7 changes in the patch which are questionable, so the > bisection should ideally take 3 steps. After we find the change which > helps (and document it), we can discard the rest. That should give us > the same stability as this patch does, but without unnecessary code > which does cost GPU cycles (regardless of whether it is measurable on > a particular machine or not). > > By the way, in draw_vbo, the emit functions should be called after > r600_need_cs_space. Otherwise the command stream may overflow. > > Marek Again i haven't found a combination other than the outcome of the full patch that helps more. So be my guest bisect on rv610, rv635, rv670, rv710, rv740, rv770. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Add support for OES_standard_derivatives in GLSL ES
On Mon, Jul 16, 2012 at 8:45 PM, Tomeu Vizoso wrote: > Previously, we advertised the extension but the builtin functions > were enabled only for GLSL and not for ES. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52003 > > Signed-off-by: Tomeu Vizoso > Reviewed-by: Ian Romanick Hello, anybody could push this one? I don't have commit rights. Thanks, Tomeu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45292] Compilation failure on d3d1x state tracker: ‘ID3D10Include’ has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=45292 Andrew Cook changed: What|Removed |Added Attachment #60001|0 |1 is obsolete|| --- Comment #10 from Andrew Cook 2012-07-23 14:42:42 PDT --- Created attachment 64550 --> https://bugs.freedesktop.org/attachment.cgi?id=64550 Another hackish patch against c3bc4101... patch against c3bc41011f9ffe648b7dd4915c6202b776cd1ab4 compiles without error with wine-1.5.8 demo's still fail on display->init (forgot the line number) -- 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] [Bug 45292] Compilation failure on d3d1x state tracker: ‘ID3D10Include’ has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=45292 Andrew Cook changed: What|Removed |Added CC||aris...@gmail.com -- 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, android-build] android-build: fix dricore build for autogenerated files
On 07/20/2012 02:41 PM, Daniel Charles wrote: > Recently more files were removed from control to be auto-generated > in the dricore library. Android build was not able to locate the > new files if they were not created beforehand. > > LOCAL_SRC_FILES includes some of those files and Android.gen.mk > re-defines this variable by filtering out the auto-generated files. > Unfortunately for this variable it is not the same to have the SRCDIR > variable defined as the current directory. > > By removing SRCDIR the Android build system is happy again and the new > files were actually removed from the sources to use the auto generated > versions. > > Also patch d5c1801a018efda8ac2b was partially reverted as the files > can not be compiled to the LOCAL_PATH, instead they should live on the > intermediates folder so that a clean can wipe them out. > > Change-Id: I75e86453d23f6b6f0e2a7dfb1b48272965c9fbf2 > Signed-off-by: Daniel Charles > --- > src/mesa/Android.gen.mk | 68 +-- > src/mesa/Android.mk |1 - > src/mesa/sources.mak| 558 > +++ > 3 files changed, 330 insertions(+), 297 deletions(-) > > diff --git a/src/mesa/Android.gen.mk b/src/mesa/Android.gen.mk > index 2ea8cc4..5443bb9 100644 Daniel, By removing SRCDIR from sources.mak, this patch breaks the autotools build. See where SRCDIR is used in src/mesa/Makefile.am. If you were to redefine SRCDIR in Android*.mk to $(LOCAL_PATH), would that fix the Android build? If not, then we may have to resort to $(addprefix) magic. Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/15] intel: Downsample on DRI2 flush
On 07/23/2012 06:30 AM, Brian Paul wrote:
> On Sat, Jul 21, 2012 at 6:36 PM, Chad Versace
> wrote:
>> CC: Eric Anholt
>> CC: Paul Berry
>> Signed-off-by: Chad Versace
>> ---
>> src/mesa/drivers/dri/intel/intel_screen.c | 31
>> +++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
>> b/src/mesa/drivers/dri/intel/intel_screen.c
>> index 4a12b67..958ff9f 100644
>> --- a/src/mesa/drivers/dri/intel/intel_screen.c
>> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
>> @@ -177,6 +177,36 @@ static const __DRItexBufferExtension
>> intelTexBufferExtension = {
>> };
>>
>> static void
>> +intel_downsample_for_dri2_flush(struct intel_context *intel,
>> +__DRIdrawable *drawable)
>> +{
>> + if (intel->gen < 6) {
>> + /* MSAA is not supported, so don't waste time checking for
>> + * a multisample buffer.
>> + */
>> + return;
>> + }
>> +
>> + struct gl_framebuffer *fb = drawable->driverPrivate;
>> + struct intel_renderbuffer *rb;
>
> Declarations following code will cause a compiler error (depending on
> the compiler and flags). You might want to fix that, just in case.
It's ok here. The Intel driver is compiled with -std=c99 and uses
code-after-declarations in other places too.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] Makefile.am fixes and clean-up
Jon TURNEY writes: > Some follow-up patches after my automake changes of last week. > > Jon TURNEY (4): > drivers/X11: Link X11 libGL with -no-undefined libtool flag > drivers/osmesa: Link OSMesa using -no-undefined libtool flag > Update mesa/drivers/x11/Makefile.am for xm_image.h removal > Remove redundant osmesa shared library install from Makefile.old Reviewed-by: Eric Anholt pgpGRKxOcdEle.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 02/11] glsl: Incorporate all UBO language changes into GLSL 1.40.
Ian Romanick writes:
> On 07/20/2012 03:33 PM, Eric Anholt wrote:
>> ---
>> src/glsl/glsl_parser.yy |4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
>> index b2533c8..0ed424d 100644
>> --- a/src/glsl/glsl_parser.yy
>> +++ b/src/glsl/glsl_parser.yy
>> @@ -291,6 +291,10 @@ version_statement:
>> state->version_string,
>> state->supported_version_string);
>> }
>> +
>> + if (state->language_version >= 140) {
>> + state->ARB_uniform_buffer_object_enable = true;
>> + }
>
> Do we need something to prevent
>
> #extension GL_ARB_uniform_buffer_object: disable
>
> from making dumb things happen?
I had thought about that briefly, and decided that if you really go out
of your way to do that, the behavior you end up with is probably sort of
like what you meant, but seriously what were you thinking?
pgpGAH8YGBnjp.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52405] New: Openarena 0.8.8 performance regression with current master.
https://bugs.freedesktop.org/show_bug.cgi?id=52405 Bug #: 52405 Summary: Openarena 0.8.8 performance regression with current master. Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: low Component: Drivers/Gallium/r600 AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: pontost...@gmail.com uname -a Linux linux-gyo1 3.5.0-rc7 OpenGL renderer string: Gallium 0.4 on AMD JUNIPER OpenGL version string: 2.1 Mesa 8.1-devel OpenGL shading language version string: 1.30 Mesa-git_2012.07.05 1024x768 - 129 fps, 1920x1080 - 85 fps Mesa-git_2012.07.21 1024x768 - 77 fps, 1920x1080 - 42 fps -- 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] [Bug 52405] Openarena 0.8.8 performance regression with current master.
https://bugs.freedesktop.org/show_bug.cgi?id=52405 --- Comment #1 from Alex Deucher 2012-07-23 16:42:40 PDT --- Can you bisect? -- 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 v3 0/8] Improve integer texture support & add i965 texture_rgb10_a2ui support
v3: * 4 reviewed patches from v2 were committed, and thus removed from the series * Updated _mesa_meta_CopyTexSubImage to fix an issue with a texture using MESA_FORMAT_R8 * Note: patches 1-3 & 8 of this series have been previously reviewed v2: * Add glformats.c/glformats.h * Move integer texture clamping fixes from ReadPixels to CopyTexSubImage * updated docs/GL3.txt for i965 & texture_rgb10_a2ui * Fix ugly pseudo-template in .h. I just duplicated the code and dropped pack_int_cases_tmp.h. v1: * Improve integer texture support * Add i965 texture_rgb10_a2ui support Jordan Justen (8): mesa pack: handle uint and int clamping properly mesa GetTexImage: handle signed/unsigned integer clamping mesa texstore: handle signed/unsigned integer clamping mesa unpack: use _mesa_problem rather than assert mesa pack: handle packed integer formats with clamping ReadPixels: handle signed/unsigned integer clamping meta: allow CopyTexSubImage on integer formats i965: add ARB_texture_rgb10_a2ui support docs/GL3.txt |2 +- src/mesa/drivers/common/meta.c | 16 +- src/mesa/drivers/dri/i965/brw_wm_surface_state.c |1 + src/mesa/drivers/dri/intel/intel_extensions.c|1 + src/mesa/main/format_unpack.c|5 + src/mesa/main/pack.c | 651 +- src/mesa/main/pack.h | 12 +- src/mesa/main/readpix.c | 13 +- src/mesa/main/texgetimage.c | 12 +- src/mesa/main/texstore.c | 95 +++- 10 files changed, 766 insertions(+), 42 deletions(-) -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 2/8] mesa GetTexImage: handle signed/unsigned integer clamping
Signed-off-by: Jordan Justen
Reviewed-by: Brian Paul
---
src/mesa/main/texgetimage.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 5d2f4da..06d4464 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -306,6 +306,7 @@ get_tex_rgba_uncompressed(struct gl_context *ctx, GLuint
dimensions,
GLfloat (*rgba)[4];
GLuint (*rgba_uint)[4];
GLboolean is_integer = _mesa_is_format_integer_color(texImage->TexFormat);
+ GLboolean is_unsiged_integer =
_mesa_is_format_unsigned(texImage->TexFormat);
/* Allocate buffer for one row of texels */
rgba = (GLfloat (*)[4]) malloc(4 * width * sizeof(GLfloat));
@@ -361,8 +362,15 @@ get_tex_rgba_uncompressed(struct gl_context *ctx, GLuint
dimensions,
_mesa_unpack_uint_rgba_row(texFormat, width, src, rgba_uint);
if (rebaseFormat)
_mesa_rebase_rgba_uint(width, rgba_uint, rebaseFormat);
- _mesa_pack_rgba_span_from_uints(ctx, width, rgba_uint,
-format, type, dest);
+ if (is_unsiged_integer) {
+ _mesa_pack_rgba_span_from_uints(ctx, width,
+ (GLuint (*)[4]) rgba_uint,
+ format, type, dest);
+ } else {
+ _mesa_pack_rgba_span_from_ints(ctx, width,
+ (GLint (*)[4]) rgba_uint,
+ format, type, dest);
+ }
} else {
_mesa_unpack_rgba_row(texFormat, width, src, rgba);
if (rebaseFormat)
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 1/8] mesa pack: handle uint and int clamping properly
Rename _mesa_pack_rgba_span_int to _mesa_pack_rgba_span_from_uints.
Add _mesa_pack_rgba_span_from_ints.
These separate routines allow the integer clamping to be handled
properly for signed versus unsigned integers.
Signed-off-by: Jordan Justen
Reviewed-by: Brian Paul
---
src/mesa/main/pack.c| 106 ---
src/mesa/main/pack.h| 12 +++--
src/mesa/main/readpix.c |4 +-
src/mesa/main/texgetimage.c |4 +-
4 files changed, 112 insertions(+), 14 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index 83192c1..efbff5d 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
@@ -462,8 +462,7 @@ get_type_min_max(GLenum type, GLfloat *min, GLfloat *max)
}
}
-/* Customization of integer packing. We always treat src as uint, and can
pack dst
- * as any integer type/format combo.
+/* Customization of unsigned integer packing.
*/
#define SRC_TYPE GLuint
@@ -475,6 +474,14 @@ get_type_min_max(GLenum type, GLfloat *min, GLfloat *max)
#undef SRC_CONVERT
#undef FN_NAME
+#define DST_TYPE GLint
+#define SRC_CONVERT(x) MIN2(x, 0x7fff)
+#define FN_NAME pack_int_from_uint_rgba
+#include "pack_tmp.h"
+#undef DST_TYPE
+#undef SRC_CONVERT
+#undef FN_NAME
+
#define DST_TYPE GLushort
#define SRC_CONVERT(x) MIN2(x, 0x)
#define FN_NAME pack_ushort_from_uint_rgba
@@ -507,18 +514,19 @@ get_type_min_max(GLenum type, GLfloat *min, GLfloat *max)
#undef SRC_CONVERT
#undef FN_NAME
+#undef SRC_TYPE
+
void
-_mesa_pack_rgba_span_int(struct gl_context *ctx, GLuint n, GLuint rgba[][4],
- GLenum dstFormat, GLenum dstType,
- GLvoid *dstAddr)
+_mesa_pack_rgba_span_from_uints(struct gl_context *ctx, GLuint n, GLuint
rgba[][4],
+GLenum dstFormat, GLenum dstType,
+GLvoid *dstAddr)
{
switch(dstType) {
case GL_UNSIGNED_INT:
pack_uint_from_uint_rgba(ctx, dstAddr, dstFormat, rgba, n);
break;
case GL_INT:
- /* No conversion necessary. */
- pack_uint_from_uint_rgba(ctx, dstAddr, dstFormat, rgba, n);
+ pack_int_from_uint_rgba(ctx, dstAddr, dstFormat, rgba, n);
break;
case GL_UNSIGNED_SHORT:
pack_ushort_from_uint_rgba(ctx, dstAddr, dstFormat, rgba, n);
@@ -532,6 +540,90 @@ _mesa_pack_rgba_span_int(struct gl_context *ctx, GLuint n,
GLuint rgba[][4],
case GL_BYTE:
pack_byte_from_uint_rgba(ctx, dstAddr, dstFormat, rgba, n);
break;
+
+ default:
+ _mesa_problem(ctx,
+ "Unsupported type (%s) for format (%s)",
+ _mesa_lookup_enum_by_nr(dstType),
+ _mesa_lookup_enum_by_nr(dstFormat));
+ return;
+ }
+}
+
+
+/* Customization of signed integer packing.
+ */
+#define SRC_TYPE GLint
+
+#define DST_TYPE GLuint
+#define SRC_CONVERT(x) MAX2(x, 0)
+#define FN_NAME pack_uint_from_int_rgba
+#include "pack_tmp.h"
+#undef DST_TYPE
+#undef SRC_CONVERT
+#undef FN_NAME
+
+#define DST_TYPE GLushort
+#define SRC_CONVERT(x) MAX2(x, 0)
+#define FN_NAME pack_ushort_from_int_rgba
+#include "pack_tmp.h"
+#undef DST_TYPE
+#undef SRC_CONVERT
+#undef FN_NAME
+
+#define DST_TYPE GLshort
+#define SRC_CONVERT(x) CLAMP(x, -0x8000, 0x7fff)
+#define FN_NAME pack_short_from_int_rgba
+#include "pack_tmp.h"
+#undef DST_TYPE
+#undef SRC_CONVERT
+#undef FN_NAME
+
+#define DST_TYPE GLubyte
+#define SRC_CONVERT(x) MAX2(x, 0)
+#define FN_NAME pack_ubyte_from_int_rgba
+#include "pack_tmp.h"
+#undef DST_TYPE
+#undef SRC_CONVERT
+#undef FN_NAME
+
+#define DST_TYPE GLbyte
+#define SRC_CONVERT(x) CLAMP(x, -0x80, 0x7f)
+#define FN_NAME pack_byte_from_int_rgba
+#include "pack_tmp.h"
+#undef DST_TYPE
+#undef SRC_CONVERT
+#undef FN_NAME
+
+#undef SRC_TYPE
+
+void
+_mesa_pack_rgba_span_from_ints(struct gl_context *ctx, GLuint n, GLint
rgba[][4],
+ GLenum dstFormat, GLenum dstType,
+ GLvoid *dstAddr)
+{
+
+ switch(dstType) {
+ case GL_UNSIGNED_INT:
+ pack_uint_from_int_rgba(ctx, dstAddr, dstFormat, rgba, n);
+ break;
+ case GL_INT:
+ /* No conversion necessary. */
+ pack_uint_from_uint_rgba(ctx, dstAddr, dstFormat, rgba, n);
+ break;
+ case GL_UNSIGNED_SHORT:
+ pack_ushort_from_int_rgba(ctx, dstAddr, dstFormat, rgba, n);
+ break;
+ case GL_SHORT:
+ pack_short_from_int_rgba(ctx, dstAddr, dstFormat, rgba, n);
+ break;
+ case GL_UNSIGNED_BYTE:
+ pack_ubyte_from_int_rgba(ctx, dstAddr, dstFormat, rgba, n);
+ break;
+ case GL_BYTE:
+ pack_byte_from_int_rgba(ctx, dstAddr, dstFormat, rgba, n);
+ break;
+
default:
_mesa_problem(ctx,
"Unsupported type (%s) for format (%s)",
diff --git a/src/mesa/main/pack.h b/src/mesa/main/pack.h
index cd49c74..2fbdf91 100644
--- a/src/mesa/main/pack.h
+++ b/src/mesa/main/pack.h
@@ -145,9 +145,15 @@ _mesa_unpack_image(GLuint dimensions,
void
-_mesa_pack_rgba_span_int(struct gl_co
[Mesa-dev] [PATCH v3 3/8] mesa texstore: handle signed/unsigned integer clamping
Signed-off-by: Jordan Justen
Reviewed-by: Brian Paul
---
src/mesa/main/texstore.c | 95 --
1 file changed, 75 insertions(+), 20 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index ab9fdf2..01d0a10 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -3200,6 +3200,7 @@ _mesa_texstore_rgba_int8(TEXSTORE_PARAMS)
srcPacking);
const GLuint *src = tempImage;
GLint img, row;
+ GLboolean is_unsigned = _mesa_is_type_unsigned(srcType);
if (!tempImage)
return GL_FALSE;
for (img = 0; img < srcDepth; img++) {
@@ -3207,8 +3208,14 @@ _mesa_texstore_rgba_int8(TEXSTORE_PARAMS)
for (row = 0; row < srcHeight; row++) {
GLbyte *dstTexel = (GLbyte *) dstRow;
GLint i;
-for (i = 0; i < srcWidth * components; i++) {
- dstTexel[i] = (GLbyte) src[i];
+if (is_unsigned) {
+ for (i = 0; i < srcWidth * components; i++) {
+ dstTexel[i] = (GLbyte) MIN2(src[i], 0x7f);
+ }
+} else {
+ for (i = 0; i < srcWidth * components; i++) {
+ dstTexel[i] = (GLbyte) CLAMP((GLint) src[i], -0x80, 0x7f);
+ }
}
dstRow += dstRowStride;
src += srcWidth * components;
@@ -3270,6 +3277,7 @@ _mesa_texstore_rgba_int16(TEXSTORE_PARAMS)
srcPacking);
const GLuint *src = tempImage;
GLint img, row;
+ GLboolean is_unsigned = _mesa_is_type_unsigned(srcType);
if (!tempImage)
return GL_FALSE;
for (img = 0; img < srcDepth; img++) {
@@ -3277,8 +3285,14 @@ _mesa_texstore_rgba_int16(TEXSTORE_PARAMS)
for (row = 0; row < srcHeight; row++) {
GLshort *dstTexel = (GLshort *) dstRow;
GLint i;
-for (i = 0; i < srcWidth * components; i++) {
- dstTexel[i] = (GLint) src[i];
+if (is_unsigned) {
+ for (i = 0; i < srcWidth * components; i++) {
+ dstTexel[i] = (GLshort) MIN2(src[i], 0x7fff);
+ }
+} else {
+ for (i = 0; i < srcWidth * components; i++) {
+ dstTexel[i] = (GLshort)CLAMP((GLint) src[i], -0x8000,
0x7fff);
+ }
}
dstRow += dstRowStride;
src += srcWidth * components;
@@ -3340,6 +3354,7 @@ _mesa_texstore_rgba_int32(TEXSTORE_PARAMS)
srcPacking);
const GLuint *src = tempImage;
GLint img, row;
+ GLboolean is_unsigned = _mesa_is_type_unsigned(srcType);
if (!tempImage)
return GL_FALSE;
for (img = 0; img < srcDepth; img++) {
@@ -3347,8 +3362,14 @@ _mesa_texstore_rgba_int32(TEXSTORE_PARAMS)
for (row = 0; row < srcHeight; row++) {
GLint *dstTexel = (GLint *) dstRow;
GLint i;
-for (i = 0; i < srcWidth * components; i++) {
- dstTexel[i] = (GLint) src[i];
+if (is_unsigned) {
+ for (i = 0; i < srcWidth * components; i++) {
+ dstTexel[i] = (GLint) MIN2(src[i], 0x7fff);
+ }
+} else {
+ for (i = 0; i < srcWidth * components; i++) {
+ dstTexel[i] = (GLint) src[i];
+ }
}
dstRow += dstRowStride;
src += srcWidth * components;
@@ -3407,6 +3428,7 @@ _mesa_texstore_rgba_uint8(TEXSTORE_PARAMS)
srcFormat, srcType, srcAddr, srcPacking);
const GLuint *src = tempImage;
GLint img, row;
+ GLboolean is_unsigned = _mesa_is_type_unsigned(srcType);
if (!tempImage)
return GL_FALSE;
for (img = 0; img < srcDepth; img++) {
@@ -3414,8 +3436,14 @@ _mesa_texstore_rgba_uint8(TEXSTORE_PARAMS)
for (row = 0; row < srcHeight; row++) {
GLubyte *dstTexel = (GLubyte *) dstRow;
GLint i;
-for (i = 0; i < srcWidth * components; i++) {
- dstTexel[i] = (GLubyte) CLAMP(src[i], 0, 0xff);
+if (is_unsigned) {
+ for (i = 0; i < srcWidth * components; i++) {
+ dstTexel[i] = (GLubyte) MIN2(src[i], 0xff);
+ }
+} else {
+ for (i = 0; i < srcWidth * components; i++) {
+ dstTexel[i] = (GLubyte) CLAMP((GLint) src[i], 0, 0xff);
+ }
}
dstRow += dstRowStride;
src += srcWidth * components;
@@ -3474,6 +3502,7 @@ _mesa_texstore_rgba_uint16(TEXSTORE_PARAMS)
srcFormat, srcType, srcAddr, srcPacking);
const GLuint *src = tempImage;
GLint img, row;
+ GLboolean is_unsigned = _mesa_is_type_unsigned(srcType);
[Mesa-dev] [PATCH v3 4/8] mesa unpack: use _mesa_problem rather than assert
If the unpack functions is not available, use _mesa_problem
rather than asserting.
Signed-off-by: Jordan Justen
---
src/mesa/main/format_unpack.c |5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 529c416..bd21852 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -1604,6 +1604,11 @@ get_unpack_rgba_function(gl_format format)
initialized = GL_TRUE;
}
+ if (table[format] == NULL) {
+ _mesa_problem(NULL, "unsupported unpack for format %s",
+_mesa_get_format_name(format));
+ }
+
return table[format];
}
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 6/8] ReadPixels: handle signed/unsigned integer clamping
Signed-off-by: Jordan Justen
---
src/mesa/main/readpix.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 784aaad..4fa816f 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -321,6 +321,8 @@ slow_read_rgba_pixels( struct gl_context *ctx,
void *rgba;
GLubyte *dst, *map;
int dstStride, stride, j;
+ GLboolean is_integer = _mesa_is_enum_format_integer(format);
+ GLboolean is_unsiged_integer = _mesa_is_format_unsigned(rbFormat);
dstStride = _mesa_image_row_stride(packing, width, format, type);
dst = (GLubyte *) _mesa_image_address2d(packing, pixels, width, height,
@@ -338,12 +340,17 @@ slow_read_rgba_pixels( struct gl_context *ctx,
goto done;
for (j = 0; j < height; j++) {
- if (_mesa_is_enum_format_integer(format)) {
+ if (is_integer) {
_mesa_unpack_uint_rgba_row(rbFormat, width, map, (GLuint (*)[4]) rgba);
_mesa_rebase_rgba_uint(width, (GLuint (*)[4]) rgba,
rb->_BaseFormat);
- _mesa_pack_rgba_span_from_uints(ctx, width, (GLuint (*)[4]) rgba,
format,
- type, dst);
+ if (is_unsiged_integer) {
+_mesa_pack_rgba_span_from_uints(ctx, width, (GLuint (*)[4]) rgba,
format,
+type, dst);
+ } else {
+_mesa_pack_rgba_span_from_ints(ctx, width, (GLint (*)[4]) rgba,
format,
+ type, dst);
+ }
} else {
_mesa_unpack_rgba_row(rbFormat, width, map, (GLfloat (*)[4]) rgba);
_mesa_rebase_rgba_float(width, (GLfloat (*)[4]) rgba,
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 7/8] meta: allow CopyTexSubImage on integer formats
Signed-off-by: Jordan Justen
---
src/mesa/drivers/common/meta.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index cf2d053..d1fd268 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -72,6 +72,8 @@
#include "program/program.h"
#include "swrast/swrast.h"
#include "drivers/common/meta.h"
+#include "main/enums.h"
+#include "main/glformats.h"
/** Return offset in bytes of the field within a vertex struct */
@@ -3158,8 +3160,12 @@ _mesa_meta_GenerateMipmap(struct gl_context *ctx, GLenum
target,
* ReadPixels() and passed to Tex[Sub]Image().
*/
static GLenum
-get_temp_image_type(struct gl_context *ctx, GLenum baseFormat)
+get_temp_image_type(struct gl_context *ctx, gl_format format)
{
+ GLenum baseFormat, type;
+
+ baseFormat = _mesa_get_format_base_format(format);
+
switch (baseFormat) {
case GL_RGBA:
case GL_RGB:
@@ -3174,7 +3180,7 @@ get_temp_image_type(struct gl_context *ctx, GLenum
baseFormat)
else if (ctx->DrawBuffer->Visual.redBits <= 16)
return GL_UNSIGNED_SHORT;
else
- return GL_FLOAT;
+ return _mesa_get_format_datatype(format);
case GL_DEPTH_COMPONENT:
return GL_UNSIGNED_INT;
case GL_DEPTH_STENCIL:
@@ -3216,12 +3222,10 @@ _mesa_meta_CopyTexSubImage(struct gl_context *ctx,
GLuint dims,
format = GL_RGBA;
}
+ type = get_temp_image_type(ctx, texImage->TexFormat);
if (_mesa_is_format_integer_color(texImage->TexFormat)) {
- _mesa_problem(ctx, "unsupported integer color copyteximage");
- return;
+ format = _mesa_base_format_to_integer_format(format);
}
-
- type = get_temp_image_type(ctx, format);
bpp = _mesa_bytes_per_pixel(format, type);
if (bpp <= 0) {
_mesa_problem(ctx, "Bad bpp in _mesa_meta_CopyTexSubImage()");
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 5/8] mesa pack: handle packed integer formats with clamping
Signed-off-by: Jordan Justen
---
src/mesa/main/pack.c | 549 +-
1 file changed, 547 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index efbff5d..a599f21 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
@@ -521,6 +521,8 @@ _mesa_pack_rgba_span_from_uints(struct gl_context *ctx,
GLuint n, GLuint rgba[][
GLenum dstFormat, GLenum dstType,
GLvoid *dstAddr)
{
+ GLuint i;
+
switch(dstType) {
case GL_UNSIGNED_INT:
pack_uint_from_uint_rgba(ctx, dstAddr, dstFormat, rgba, n);
@@ -540,7 +542,278 @@ _mesa_pack_rgba_span_from_uints(struct gl_context *ctx,
GLuint n, GLuint rgba[][
case GL_BYTE:
pack_byte_from_uint_rgba(ctx, dstAddr, dstFormat, rgba, n);
break;
-
+ case GL_UNSIGNED_BYTE_3_3_2:
+ if ((dstFormat == GL_RGB) || (dstFormat == GL_RGB_INTEGER)) {
+ GLubyte *dst = (GLubyte *) dstAddr;
+ for (i=0;ihttp://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 8/8] i965: add ARB_texture_rgb10_a2ui support
Signed-off-by: Jordan Justen Reviewed-by: Brian Paul --- docs/GL3.txt |2 +- src/mesa/drivers/dri/i965/brw_wm_surface_state.c |1 + src/mesa/drivers/dri/intel/intel_extensions.c|1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 7c68745..0f6521d 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -78,7 +78,7 @@ GL_ARB_explicit_attrib_location DONE (i915, i965, r300, r6 GL_ARB_occlusion_query2 DONE (r300, r600, swrast) GL_ARB_sampler_objectsDONE (i965, r300, r600) GL_ARB_shader_bit_encodingDONE -GL_ARB_texture_rgb10_a2ui DONE (r600) +GL_ARB_texture_rgb10_a2ui DONE (i965, r600) GL_ARB_texture_swizzleDONE (same as EXT version) (i965, r300, r600, swrast) GL_ARB_timer_queryDONE GL_ARB_instanced_arrays DONE (i965, r300, r600) diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c index 82e44f9..57a83d8 100644 --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c @@ -325,6 +325,7 @@ brw_format_for_mesa_format(gl_format mesa_format) [MESA_FORMAT_RG1616] = BRW_SURFACEFORMAT_R16G16_UNORM, [MESA_FORMAT_RG1616_REV] = 0, [MESA_FORMAT_ARGB2101010] = BRW_SURFACEFORMAT_B10G10R10A2_UNORM, + [MESA_FORMAT_ABGR2101010_UINT] = BRW_SURFACEFORMAT_R10G10B10A2_UINT, [MESA_FORMAT_Z24_S8] = 0, [MESA_FORMAT_S8_Z24] = 0, [MESA_FORMAT_Z16] = 0, diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c b/src/mesa/drivers/dri/intel/intel_extensions.c index c2bc072..2bdb8e8 100755 --- a/src/mesa/drivers/dri/intel/intel_extensions.c +++ b/src/mesa/drivers/dri/intel/intel_extensions.c @@ -92,6 +92,7 @@ intelInitExtensions(struct gl_context *ctx) #endif ctx->Extensions.OES_draw_texture = true; ctx->Extensions.OES_compressed_ETC1_RGB8_texture = true; + ctx->Extensions.ARB_texture_rgb10_a2ui = true; if (intel->gen >= 6) ctx->Const.GLSLVersion = 130; -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 2/8] mesa GetTexImage: handle signed/unsigned integer clamping
On 07/23/2012 10:59 AM, Jordan Justen wrote:
Signed-off-by: Jordan Justen
Reviewed-by: Brian Paul
---
src/mesa/main/texgetimage.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 5d2f4da..06d4464 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -306,6 +306,7 @@ get_tex_rgba_uncompressed(struct gl_context *ctx, GLuint
dimensions,
GLfloat (*rgba)[4];
GLuint (*rgba_uint)[4];
GLboolean is_integer = _mesa_is_format_integer_color(texImage->TexFormat);
+ GLboolean is_unsiged_integer =
_mesa_is_format_unsigned(texImage->TexFormat);
"unsigned"
I'll try to review the rest soon.
/* Allocate buffer for one row of texels */
rgba = (GLfloat (*)[4]) malloc(4 * width * sizeof(GLfloat));
@@ -361,8 +362,15 @@ get_tex_rgba_uncompressed(struct gl_context *ctx, GLuint
dimensions,
_mesa_unpack_uint_rgba_row(texFormat, width, src, rgba_uint);
if (rebaseFormat)
_mesa_rebase_rgba_uint(width, rgba_uint, rebaseFormat);
- _mesa_pack_rgba_span_from_uints(ctx, width, rgba_uint,
-format, type, dest);
+ if (is_unsiged_integer) {
+ _mesa_pack_rgba_span_from_uints(ctx, width,
+ (GLuint (*)[4]) rgba_uint,
+ format, type, dest);
+ } else {
+ _mesa_pack_rgba_span_from_ints(ctx, width,
+ (GLint (*)[4]) rgba_uint,
+ format, type, dest);
+ }
} else {
_mesa_unpack_rgba_row(texFormat, width, src, rgba);
if (rebaseFormat)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH, android-build] android-build: fix dricore build for autogenerated files
On Mon, Jul 23, 2012 at 7:58 AM, Chad Versace wrote: > On 07/20/2012 02:41 PM, Daniel Charles wrote: >> Recently more files were removed from control to be auto-generated >> in the dricore library. Android build was not able to locate the >> new files if they were not created beforehand. >> >> LOCAL_SRC_FILES includes some of those files and Android.gen.mk >> re-defines this variable by filtering out the auto-generated files. >> Unfortunately for this variable it is not the same to have the SRCDIR >> variable defined as the current directory. >> >> By removing SRCDIR the Android build system is happy again and the new >> files were actually removed from the sources to use the auto generated >> versions. >> >> Also patch d5c1801a018efda8ac2b was partially reverted as the files >> can not be compiled to the LOCAL_PATH, instead they should live on the >> intermediates folder so that a clean can wipe them out. >> >> Change-Id: I75e86453d23f6b6f0e2a7dfb1b48272965c9fbf2 >> Signed-off-by: Daniel Charles >> --- >> src/mesa/Android.gen.mk | 68 +-- >> src/mesa/Android.mk |1 - >> src/mesa/sources.mak| 558 >> +++ >> 3 files changed, 330 insertions(+), 297 deletions(-) >> >> diff --git a/src/mesa/Android.gen.mk b/src/mesa/Android.gen.mk >> index 2ea8cc4..5443bb9 100644 > > > Daniel, > > By removing SRCDIR from sources.mak, this patch breaks the autotools build. > See > where SRCDIR is used in src/mesa/Makefile.am. I was thinking that sources.mak was used by Android build engine only. Would it be good to have a sources.android.mak file? > > If you were to redefine SRCDIR in Android*.mk to $(LOCAL_PATH), would that fix > the Android build? If not, then we may have to resort to $(addprefix) magic. > The problem is that whatever prefix we add to LOCAL_SRC_FILES forces it to be also used when declaring the build target like this LOCAL_SRC_FILES:= $(SRCDIR)/some_file $(intermediates)/$(SRCDIR)/some_file: some_deps do_something. IMO, adding the logic for the addprefix needed for auto-tools might be easier, than adding a for cycle to remove the $(SRCDIR) for Android needs. The relative directory is used only by autotools. Thanks. -- Daniel. > > Chad Versace > chad.vers...@linux.intel.com > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH, android-build] android-build: fix dricore build for autogenerated files
On Mon, Jul 23, 2012 at 9:59 AM, Charles, Daniel wrote: > On Mon, Jul 23, 2012 at 7:58 AM, Chad Versace > wrote: >> On 07/20/2012 02:41 PM, Daniel Charles wrote: >>> Recently more files were removed from control to be auto-generated >>> in the dricore library. Android build was not able to locate the >>> new files if they were not created beforehand. >>> >>> LOCAL_SRC_FILES includes some of those files and Android.gen.mk >>> re-defines this variable by filtering out the auto-generated files. >>> Unfortunately for this variable it is not the same to have the SRCDIR >>> variable defined as the current directory. >>> >>> By removing SRCDIR the Android build system is happy again and the new >>> files were actually removed from the sources to use the auto generated >>> versions. >>> >>> Also patch d5c1801a018efda8ac2b was partially reverted as the files >>> can not be compiled to the LOCAL_PATH, instead they should live on the >>> intermediates folder so that a clean can wipe them out. >>> >>> Change-Id: I75e86453d23f6b6f0e2a7dfb1b48272965c9fbf2 >>> Signed-off-by: Daniel Charles >>> --- >>> src/mesa/Android.gen.mk | 68 +-- >>> src/mesa/Android.mk |1 - >>> src/mesa/sources.mak| 558 >>> +++ >>> 3 files changed, 330 insertions(+), 297 deletions(-) >>> >>> diff --git a/src/mesa/Android.gen.mk b/src/mesa/Android.gen.mk >>> index 2ea8cc4..5443bb9 100644 >> >> >> Daniel, >> >> By removing SRCDIR from sources.mak, this patch breaks the autotools build. >> See >> where SRCDIR is used in src/mesa/Makefile.am. > > I was thinking that sources.mak was used by Android build engine only. > Would it be good to have a sources.android.mak file? > >> >> If you were to redefine SRCDIR in Android*.mk to $(LOCAL_PATH), would that >> fix >> the Android build? If not, then we may have to resort to $(addprefix) magic. >> > > The problem is that whatever prefix we add to LOCAL_SRC_FILES forces > it to be also used when declaring the build target like this > > LOCAL_SRC_FILES:= $(SRCDIR)/some_file > > $(intermediates)/$(SRCDIR)/some_file: some_deps > do_something. > > IMO, adding the logic for the addprefix needed for auto-tools might be > easier, than adding a for cycle to remove the $(SRCDIR) for Android > needs. The relative directory is used only by autotools. > Or, I can just re-define SRCDIR on Makefile.am so that Android build can avoid using it. I will submit a new version of the patch. > > Thanks. > -- > Daniel. > >> >> Chad Versace >> chad.vers...@linux.intel.com >> >> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] intel: Remove dead code in intelAllocateBuffer
Chris Wilson writes:
> On Sat, 21 Jul 2012 17:36:40 -0700, Chad Versace
> wrote:
>> After commit "intel: Convert to using private depth/stencil buffers", we
>> request from DRI2GetBuffersWithFormat only the front left and back left
>> buffers. We no longer request depth and stencil buffers.
>>
>> Assert that in intelAllocateBuffer and remove the related dead code.
>
>> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
>> b/src/mesa/drivers/dri/intel/intel_screen.c
>> index 81953ce..2d46d67 100644
>> --- a/src/mesa/drivers/dri/intel/intel_screen.c
>> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
>> @@ -972,54 +972,6 @@ struct intel_buffer {
>> struct intel_region *region;
>
>> - ok = intel_get_dri_buffer_tiling(intelScreen, attachment, &tiling);
>
>> + /* The front and back buffers are color buffers, which are X tiled. */
>> intelBuffer->region = intel_region_alloc(intelScreen,
>> -tiling,
>> -region_cpp,
>> -region_width,
>> -region_height,
>> +I915_TILING_X,
>> +format / 8,
>> +width,
>> +height,
>> true);
>
> I see no reason to bake in the assumption that the buffers are X-tiled.
> Presumably Y-tiling will still be advantageous in many circumstances,
> basically any surface which is not a candidate for pageflipping?
If there was some reason, it probably won't be based on just the
attachment type, so this seems like a good change.
pgpRiYR2s8Sky.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Remove unused param conversion code.
Ever since ctx->NativeIntegers was set, the conversion flag has been
PARAM_NO_CONVERT.
---
src/mesa/drivers/dri/i965/brw_context.h | 41 --
src/mesa/drivers/dri/i965/brw_curbe.c|3 +-
src/mesa/drivers/dri/i965/brw_fs.cpp | 27 --
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |5 ---
src/mesa/drivers/dri/i965/brw_wm_pass0.c |1 -
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |3 +-
src/mesa/drivers/dri/i965/gen6_wm_state.c|3 +-
7 files changed, 3 insertions(+), 80 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 87f7a12..125ed12 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -283,14 +283,6 @@ struct brw_shader_program {
struct gl_shader_program base;
};
-enum param_conversion {
- PARAM_NO_CONVERT,
- PARAM_CONVERT_F2I,
- PARAM_CONVERT_F2U,
- PARAM_CONVERT_F2B,
- PARAM_CONVERT_ZERO,
-};
-
/* Data about a particular attempt to compile a program. Note that
* there can be many of these, each in a different GL state
* corresponding to a different brw_wm_prog_key struct, with different
@@ -323,9 +315,7 @@ struct brw_wm_prog_data {
* _mesa_load_state_parameters has been called at runtime).
*/
const float *param[MAX_UNIFORMS * 4]; /* should be: BRW_MAX_CURBE */
- enum param_conversion param_convert[MAX_UNIFORMS * 4];
const float *pull_param[MAX_UNIFORMS * 4];
- enum param_conversion pull_param_convert[MAX_UNIFORMS * 4];
};
/**
@@ -1231,37 +1221,6 @@ brw_fragment_program_const(const struct
gl_fragment_program *p)
return (const struct brw_fragment_program *) p;
}
-static inline
-float convert_param(enum param_conversion conversion, const float *param)
-{
- union {
- float f;
- uint32_t u;
- int32_t i;
- } fi;
-
- switch (conversion) {
- case PARAM_NO_CONVERT:
- return *param;
- case PARAM_CONVERT_F2I:
- fi.i = *param;
- return fi.f;
- case PARAM_CONVERT_F2U:
- fi.u = *param;
- return fi.f;
- case PARAM_CONVERT_F2B:
- if (*param != 0.0)
-fi.i = 1;
- else
-fi.i = 0;
- return fi.f;
- case PARAM_CONVERT_ZERO:
- return 0.0;
- default:
- return *param;
- }
-}
-
/**
* Pre-gen6, the register file of the EUs was shared between threads,
* and each thread used some subset allocated on a 16-register block
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c
b/src/mesa/drivers/dri/i965/brw_curbe.c
index 93ee709..35980bb 100644
--- a/src/mesa/drivers/dri/i965/brw_curbe.c
+++ b/src/mesa/drivers/dri/i965/brw_curbe.c
@@ -205,8 +205,7 @@ brw_upload_constant_buffer(struct brw_context *brw)
/* copy float constants */
for (i = 0; i < brw->wm.prog_data->nr_params; i++) {
-buf[offset + i] = convert_param(brw->wm.prog_data->param_convert[i],
-brw->wm.prog_data->param[i]);
+buf[offset + i] = *brw->wm.prog_data->param[i];
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 3a4cb03..90dddce 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -530,28 +530,6 @@ fs_visitor::setup_uniform_values(int loc, const glsl_type
*type)
assert(param < ARRAY_SIZE(c->prog_data.param));
-if (ctx->Const.NativeIntegers) {
- c->prog_data.param_convert[param] = PARAM_NO_CONVERT;
-} else {
- switch (type->base_type) {
- case GLSL_TYPE_FLOAT:
- c->prog_data.param_convert[param] = PARAM_NO_CONVERT;
- break;
- case GLSL_TYPE_UINT:
- c->prog_data.param_convert[param] = PARAM_CONVERT_F2U;
- break;
- case GLSL_TYPE_INT:
- c->prog_data.param_convert[param] = PARAM_CONVERT_F2I;
- break;
- case GLSL_TYPE_BOOL:
- c->prog_data.param_convert[param] = PARAM_CONVERT_F2B;
- break;
- default:
- assert(!"not reached");
- c->prog_data.param_convert[param] = PARAM_NO_CONVERT;
- break;
- }
-}
this->param_index[param] = loc;
this->param_offset[param] = i;
}
@@ -609,8 +587,6 @@ fs_visitor::setup_builtin_uniform_values(ir_variable *ir)
break;
last_swiz = swiz;
-c->prog_data.param_convert[c->prog_data.nr_params] =
- PARAM_NO_CONVERT;
this->param_index[c->prog_data.nr_params] = index;
this->param_offset[c->prog_data.nr_params] = swiz;
c->prog_data.nr_params++;
@@ -1170,7 +1146,6 @@ fs_visitor::remove_dead_constants()
* about param_index and param_offset.
*/
c->prog_data.param[remapped] = c->prog_data.param[i];
-c->prog_data.param_convert[remapp
[Mesa-dev] [Bug 52405] Openarena 0.8.8 performance regression with current master.
https://bugs.freedesktop.org/show_bug.cgi?id=52405 --- Comment #2 from Iaroslav 2012-07-23 18:47:45 PDT --- (In reply to comment #1) > Can you bisect? I made 7 builds of mesa with various git reset commits from 07.05 to 07.21, and nothing changes. Looks like the problem in other place. Now Kernel – 3.5-rc7 libdrm – 2.4.37_git2012.07.21 xorg-server – 1.13.0-rc2 xf86-video-ati – 6.99.99_2012.07.13 Previously Kernel – 3.5-rc4 libdrm – 2.4.37_git2012.07.05 xorg-server – 1.12.2 xf86-video-ati – 6.14.999_2012.07.03 Nexuiz and lightsmark show the same or better results with current master, problem only with Openarena, and only with r600 driver. i965 do not have this problem. -- 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] [Bug 52405] Openarena 0.8.8 performance regression with current master.
https://bugs.freedesktop.org/show_bug.cgi?id=52405 --- Comment #3 from Alex Deucher 2012-07-23 18:58:32 PDT --- Can you narrow down what component (mesa, kernel, ddx) is causing the problem? -- 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 v2, android-build] android-build: fix dricore build for autogenerated files
Recently more files were removed from control to be auto-generated in the dricore library. Android build was not able to locate the new files if they were not created beforehand. LOCAL_SRC_FILES includes some of those files and Android.gen.mk re-defines this variable by filtering out the auto-generated files. Unfortunately for this variable it is not the same to have the SRCDIR variable defined as the current directory. By re-defining SRCDIR for the autotools build the Android build system is happy again and the new files were actually removed from the sources to use the auto generated versions. Also patch d5c1801a018efda8ac2b was partially reverted as the files can not be compiled to the LOCAL_PATH, instead they should live on the intermediates folder so that a clean can wipe them out. Change-Id: I75e86453d23f6b6f0e2a7dfb1b48272965c9fbf2 Signed-off-by: Daniel Charles --- src/mesa/Android.gen.mk | 68 +-- src/mesa/Android.mk |1 - src/mesa/Makefile.am|4 +- src/mesa/sources.mak| 561 --- 4 files changed, 337 insertions(+), 297 deletions(-) diff --git a/src/mesa/Android.gen.mk b/src/mesa/Android.gen.mk index 2ea8cc4..5443bb9 100644 --- a/src/mesa/Android.gen.mk +++ b/src/mesa/Android.gen.mk @@ -28,12 +28,19 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES endif intermediates := $(call local-intermediates-dir) -mydir := $(call my-dir) +# This is the list of auto-generated files: sources and headers sources := \ + main/enums.c \ + main/api_exec_es1.c \ main/api_exec_es1_dispatch.h \ main/api_exec_es1_remap_helper.h \ + main/api_exec_es2.c \ main/api_exec_es2_dispatch.h \ + program/program_parse.tab.c \ + program/lex.yy.c \ + main/dispatch.h \ + main/remap_helper.h \ main/api_exec_es2_remap_helper.h LOCAL_SRC_FILES := $(filter-out $(sources), $(LOCAL_SRC_FILES)) @@ -65,37 +72,49 @@ es_hdr_deps := \ $(wildcard $(glapi)/*.py) \ $(wildcard $(glapi)/*.xml) +define local-l-to-c + @mkdir -p $(dir $@) + @echo "Mesa Lex: $(PRIVATE_MODULE) <= $<" + $(hide) $(LEX) -o$@ $< +endef + +define local-y-to-c-and-h + @mkdir -p $(dir $@) + @echo "Mesa Yacc: $(PRIVATE_MODULE) <= $<" + $(hide) $(YACC) -o $@ $< +endef + define es-gen @mkdir -p $(dir $@) @echo "Gen ES: $(PRIVATE_MODULE) <= $(notdir $(@))" $(hide) $(PRIVATE_SCRIPT) $(1) $(PRIVATE_XML) > $@ endef -define generate-local - @echo "generate local sources" - $(hide) $(MESA_PYTHON2) $(glapi)/gl_enums.py -f $(glapi)/gl_and_es_API.xml > $(mydir)/main/enums.c - $(hide) $(MESA_PYTHON2) $(glapi)/gl_table.py -m remap_table -f $(glapi)/gl_and_es_API.xml > $(mydir)/main/dispatch.h - $(hide) $(MESA_PYTHON2) $(glapi)/remap_helper.py -f $(glapi)/gl_API.xml > $(mydir)/main/remap_helper.h - $(hide) $(MESA_PYTHON2) $(mydir)/main/es_generator.py -V GLES1.1 -S $(mydir)/main/APIspec.xml > $(mydir)/main/api_exec_es1.c - $(hide) $(MESA_PYTHON2) $(mydir)/main/es_generator.py -V GLES2.0 -S $(mydir)/main/APIspec.xml > $(mydir)/main/api_exec_es2.c - - @echo "Mesa Lex : $(PRIVATE_MODULE)" - $(hide) $(LEX) -o $(mydir)/program/lex.yy.c $(mydir)/program/program_lexer.l - @echo "Mesa Yacc: $(PRIVATE_MODULE)" - $(hide) $(YACC) -d -o $(mydir)/program/program_parse.tab.c $(mydir)/program/program_parse.y -endef - +$(intermediates)/main/api_exec_%.c: PRIVATE_SCRIPT := $(MESA_PYTHON2) $(LOCAL_PATH)/main/es_generator.py +$(intermediates)/main/api_exec_%.c: PRIVATE_XML := -S $(LOCAL_PATH)/main/APIspec.xml $(intermediates)/main/api_exec_%_dispatch.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) $(glapi)/gl_table.py $(intermediates)/main/api_exec_%_dispatch.h: PRIVATE_XML := -f $(glapi)/gl_and_es_API.xml $(intermediates)/main/api_exec_%_remap_helper.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) $(glapi)/remap_helper.py $(intermediates)/main/api_exec_%_remap_helper.h: PRIVATE_XML := -f $(glapi)/gl_and_es_API.xml +$(intermediates)/main/api_exec_es1.c: $(es_src_deps) + $(call es-gen, -V GLES1.1) + +$(intermediates)/main/api_exec_es2.c: $(es_src_deps) + $(call es-gen, -V GLES2.0) + $(intermediates)/main/api_exec_%_dispatch.h: $(es_hdr_deps) $(call es-gen, -c $* -m remap_table) $(intermediates)/main/api_exec_%_remap_helper.h: $(es_hdr_deps) $(call es-gen, -c $*) +$(intermediates)/program/program_parse.tab.c: $(LOCAL_PATH)/program/program_parse.y + $(local-y-to-c-and-h) + +$(intermediates)/program/lex.yy.c: $(LOCAL_PATH)/program/program_lexer.l + $(local-l-to-c) + $(intermediates)/main/git_sha1.h: @mkdir -p $(dir $@) @echo "GIT-SHA1: $(PRIVATE_MODULE) <= git" @@ -115,4 +134,21 @@ $(intermediates)/x86/matypes.h: $(matypes_deps) @mkdir -p $(dir $@) @echo "MATYPES: $(PRIVATE_MODULE) <= $(notdir $@)" $(hide) $< > $@ - $(call generate-loca
[Mesa-dev] Can --enable-shared-glapi die?
Perhaps someone can refresh my memory as to what exactly this option does? Can we make this the default and remove the option from configure? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] d3d11 binary shader blob hashing
hello, i needed to create my own d3d11 binary shaders (without using microsoft compiler) so i reverse engineered the hashing they use. while i was looking in the internet for info i found some mentions that related the mesa project with d3d1x binary shaders (i dont remember how exactly). so i thought someone here may be interested in the shader hashing method too. thus i decided to post it here, hoping it will be helpful to someone :) dx11-shader-hash.c Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 14/15] intel: Refactor intel_screen_make_configs
On 07/21/2012 05:36 PM, Chad Versace wrote:
Transform the code from clever, obfuscated, and imperative to
straight-forward and table-driven.
Does the output of glxinfo change? It's somewhat advantageous for the
IDs associated with a specific set of values to remain the same. We
have a lot of bug reports, for example, that list specific IDs. It
makes it a lot easier to reproduce the bugs that way.
CC: Ian Romanick
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_screen.c | 167 +-
1 file changed, 97 insertions(+), 70 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 9bb42dd..61daea7 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -851,85 +851,112 @@ intel_detect_swizzling(struct intel_screen *screen)
static __DRIconfig**
intel_screen_make_configs(__DRIscreen *dri_screen)
{
- static const GLenum back_buffer_modes[] = {
- GLX_NONE, GLX_SWAP_UNDEFINED_OML, GLX_SWAP_COPY_OML
+ struct config_params {
+ GLenum color_format;
+ GLenum color_type;
+ const uint8_t depth_sizes[4];
+ const uint8_t stencil_sizes[4];
Do you really mean const here?
+ unsigned num_depth_stencil_sizes;
+ unsigned num_back_buffer_modes;
+ unsigned num_msaa_modes;
+ bool enable_accum;
};
- GLenum fb_format[3];
- GLenum fb_type[3];
- uint8_t depth_bits[4], stencil_bits[4], msaa_samples_array[1];
- int color;
- __DRIconfig **configs = NULL;
-
- msaa_samples_array[0] = 0;
-
- fb_format[0] = GL_RGB;
- fb_type[0] = GL_UNSIGNED_SHORT_5_6_5;
-
- fb_format[1] = GL_BGR;
- fb_type[1] = GL_UNSIGNED_INT_8_8_8_8_REV;
-
- fb_format[2] = GL_BGRA;
- fb_type[2] = GL_UNSIGNED_INT_8_8_8_8_REV;
+ static const GLenum back_buffer_modes[] = {
+ GLX_SWAP_UNDEFINED_OML, GLX_NONE, GLX_SWAP_COPY_OML,
+ };
- depth_bits[0] = 0;
- stencil_bits[0] = 0;
+ static const uint8_t msaa_samples[] = {0};
- /* Generate a rich set of useful configs that do not include an
-* accumulation buffer.
+ /* Starting with DRI2 protocol version 1.1 we can request a depth/stencil
+* buffer that has a different number of bits per pixel than the color
+* buffer. This isn't yet supported here.
*/
- for (color = 0; color < ARRAY_SIZE(fb_format); color++) {
- __DRIconfig **new_configs;
- int depth_factor;
-
- /* Starting with DRI2 protocol version 1.1 we can request a depth/stencil
- * buffer that has a different number of bits per pixel than the color
- * buffer. This isn't yet supported here.
+ struct config_params params[] = {
It seems like this should be const instead of the pair of fields in the
structure.
+ /* Configs without accumulation buffer. */
+ {
+ .color_format = GL_RGB,
+ .color_type = GL_UNSIGNED_SHORT_5_6_5,
+ .depth_sizes = {0, 16},
+ .stencil_sizes = {0, 0},
+ .num_depth_stencil_sizes = 2,
+ .num_back_buffer_modes = 3,
+ .num_msaa_modes = 1,
+ .enable_accum = false,
+ },
+ {
+ .color_format = GL_BGR,
+ .color_type = GL_UNSIGNED_INT_8_8_8_8_REV,
+ .depth_sizes = {0, 24},
+ .stencil_sizes = {0, 8},
+ .num_depth_stencil_sizes = 2,
+ .num_back_buffer_modes = 3,
+ .num_msaa_modes = 1,
+ .enable_accum = false,
+ },
+ {
+ .color_format = GL_BGRA,
+ .color_type = GL_UNSIGNED_INT_8_8_8_8_REV,
+ .depth_sizes = {0, 24},
+ .stencil_sizes = {0, 8},
+ .num_depth_stencil_sizes = 2,
+ .num_back_buffer_modes = 3,
+ .num_msaa_modes = 1,
+ .enable_accum = false,
+ },
+
+ /* Configs with accumulation buffer.
+ *
+ * We generate the minimum possible set of configs that include an
+ * accumulation buffer.
*/
- if (fb_type[color] == GL_UNSIGNED_SHORT_5_6_5) {
- depth_bits[1] = 16;
- stencil_bits[1] = 0;
- } else {
- depth_bits[1] = 24;
- stencil_bits[1] = 8;
- }
-
- depth_factor = 2;
-
- new_configs = driCreateConfigs(fb_format[color], fb_type[color],
- depth_bits,
- stencil_bits,
- depth_factor,
- back_buffer_modes,
- ARRAY_SIZE(back_buffer_modes),
- msaa_samples_array,
- ARRAY_SIZE(msaa_samples_array),
- false);
- if (configs == NULL)
- configs = new_configs;
- else
- configs = driConcatConfigs(configs, new_configs);
- }
+ {
+ .color_format = GL_RGB,
+ .color_type = GL_UNSIGNED_SHORT_5_6_5,
+
Re: [Mesa-dev] [PATCH 15/15] intel: Advertise multisample DRI2 configs on gen >= 6
On 07/21/2012 05:36 PM, Chad Versace wrote:
This turns on window system multisampling.
No Piglit regressions on Ivybridge.
Tested with `glxgears -samples 1`.
Passes 53/70 of oglconform's winsys multisample tests. The failing tests
mostly consist of those that call glDrawPixels on the depth and stencil
buffer (which fail due to a swrast fallback) or do fancy things with the
msaa alpha enums.
CC: Eric Anholt
CC: Ian Romanick
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_screen.c | 44 +--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 61daea7..420901e 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -866,14 +866,54 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
GLX_SWAP_UNDEFINED_OML, GLX_NONE, GLX_SWAP_COPY_OML,
};
- static const uint8_t msaa_samples[] = {0};
+ static const uint8_t msaa_samples[] = {0, 4};
+
+ struct intel_screen *screen = dri_screen->driverPrivate;
+
+ int num_msaa_modes;
+ if (screen->gen >= 6)
+ num_msaa_modes = 2;
+ else
+ num_msaa_modes = 1;
/* Starting with DRI2 protocol version 1.1 we can request a depth/stencil
* buffer that has a different number of bits per pixel than the color
* buffer. This isn't yet supported here.
*/
struct config_params params[] = {
- /* Configs without accumulation buffer. */
+ /* Multisample configs. */
The new configs should go at the end. This is to maintain the numbering
that I mentioned in the previous patch.
+ {
+ .color_format = GL_RGB,
+ .color_type = GL_UNSIGNED_SHORT_5_6_5,
+ .depth_sizes = {0, 16},
+ .stencil_sizes = {0, 0},
+ .num_depth_stencil_sizes = 2,
+ .num_back_buffer_modes = 1,
+ .num_msaa_modes = num_msaa_modes,
+ .enable_accum = false,
+ },
+ {
+ .color_format = GL_BGR,
+ .color_type = GL_UNSIGNED_INT_8_8_8_8_REV,
+ .depth_sizes = {0, 24},
+ .stencil_sizes = {0, 8},
It occurs to me that there is some advantage in advertising 24/0 formats
on GPUs that require the use of separate stencil. On these GPUs we
allocate a giant (32-bits per pixel!) stencil buffer that the
application is never going to use.
Of course, adding these in a sensible way will ruin the config
numbering. Alas.
+ .num_depth_stencil_sizes = 2,
+ .num_back_buffer_modes = 1,
+ .num_msaa_modes = num_msaa_modes,
+ .enable_accum = false,
+ },
+ {
+ .color_format = GL_BGRA,
+ .color_type = GL_UNSIGNED_INT_8_8_8_8_REV,
+ .depth_sizes = {0, 24},
+ .stencil_sizes = {0, 8},
+ .num_depth_stencil_sizes = 2,
+ .num_back_buffer_modes = 1,
+ .num_msaa_modes = num_msaa_modes,
+ .enable_accum = false,
+ },
+
+ /* Single sample configs. */
{
.color_format = GL_RGB,
.color_type = GL_UNSIGNED_SHORT_5_6_5,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Remove unused param conversion code.
On 07/23/2012 10:55 AM, Eric Anholt wrote:
Ever since ctx->NativeIntegers was set, the conversion flag has been
PARAM_NO_CONVERT.
Reviewed-by: Ian Romanick
---
src/mesa/drivers/dri/i965/brw_context.h | 41 --
src/mesa/drivers/dri/i965/brw_curbe.c|3 +-
src/mesa/drivers/dri/i965/brw_fs.cpp | 27 --
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |5 ---
src/mesa/drivers/dri/i965/brw_wm_pass0.c |1 -
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |3 +-
src/mesa/drivers/dri/i965/gen6_wm_state.c|3 +-
7 files changed, 3 insertions(+), 80 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 87f7a12..125ed12 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -283,14 +283,6 @@ struct brw_shader_program {
struct gl_shader_program base;
};
-enum param_conversion {
- PARAM_NO_CONVERT,
- PARAM_CONVERT_F2I,
- PARAM_CONVERT_F2U,
- PARAM_CONVERT_F2B,
- PARAM_CONVERT_ZERO,
-};
-
/* Data about a particular attempt to compile a program. Note that
* there can be many of these, each in a different GL state
* corresponding to a different brw_wm_prog_key struct, with different
@@ -323,9 +315,7 @@ struct brw_wm_prog_data {
* _mesa_load_state_parameters has been called at runtime).
*/
const float *param[MAX_UNIFORMS * 4]; /* should be: BRW_MAX_CURBE */
- enum param_conversion param_convert[MAX_UNIFORMS * 4];
const float *pull_param[MAX_UNIFORMS * 4];
- enum param_conversion pull_param_convert[MAX_UNIFORMS * 4];
};
/**
@@ -1231,37 +1221,6 @@ brw_fragment_program_const(const struct
gl_fragment_program *p)
return (const struct brw_fragment_program *) p;
}
-static inline
-float convert_param(enum param_conversion conversion, const float *param)
-{
- union {
- float f;
- uint32_t u;
- int32_t i;
- } fi;
-
- switch (conversion) {
- case PARAM_NO_CONVERT:
- return *param;
- case PARAM_CONVERT_F2I:
- fi.i = *param;
- return fi.f;
- case PARAM_CONVERT_F2U:
- fi.u = *param;
- return fi.f;
- case PARAM_CONVERT_F2B:
- if (*param != 0.0)
-fi.i = 1;
- else
-fi.i = 0;
- return fi.f;
- case PARAM_CONVERT_ZERO:
- return 0.0;
- default:
- return *param;
- }
-}
-
/**
* Pre-gen6, the register file of the EUs was shared between threads,
* and each thread used some subset allocated on a 16-register block
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c
b/src/mesa/drivers/dri/i965/brw_curbe.c
index 93ee709..35980bb 100644
--- a/src/mesa/drivers/dri/i965/brw_curbe.c
+++ b/src/mesa/drivers/dri/i965/brw_curbe.c
@@ -205,8 +205,7 @@ brw_upload_constant_buffer(struct brw_context *brw)
/* copy float constants */
for (i = 0; i < brw->wm.prog_data->nr_params; i++) {
-buf[offset + i] = convert_param(brw->wm.prog_data->param_convert[i],
-brw->wm.prog_data->param[i]);
+buf[offset + i] = *brw->wm.prog_data->param[i];
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 3a4cb03..90dddce 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -530,28 +530,6 @@ fs_visitor::setup_uniform_values(int loc, const glsl_type
*type)
assert(param < ARRAY_SIZE(c->prog_data.param));
-if (ctx->Const.NativeIntegers) {
- c->prog_data.param_convert[param] = PARAM_NO_CONVERT;
-} else {
- switch (type->base_type) {
- case GLSL_TYPE_FLOAT:
- c->prog_data.param_convert[param] = PARAM_NO_CONVERT;
- break;
- case GLSL_TYPE_UINT:
- c->prog_data.param_convert[param] = PARAM_CONVERT_F2U;
- break;
- case GLSL_TYPE_INT:
- c->prog_data.param_convert[param] = PARAM_CONVERT_F2I;
- break;
- case GLSL_TYPE_BOOL:
- c->prog_data.param_convert[param] = PARAM_CONVERT_F2B;
- break;
- default:
- assert(!"not reached");
- c->prog_data.param_convert[param] = PARAM_NO_CONVERT;
- break;
- }
-}
this->param_index[param] = loc;
this->param_offset[param] = i;
}
@@ -609,8 +587,6 @@ fs_visitor::setup_builtin_uniform_values(ir_variable *ir)
break;
last_swiz = swiz;
-c->prog_data.param_convert[c->prog_data.nr_params] =
- PARAM_NO_CONVERT;
this->param_index[c->prog_data.nr_params] = index;
this->param_offset[c->prog_data.nr_params] = swiz;
c->prog_data.nr_params++;
@@ -1170,7 +1146,6 @@ fs_visitor::remove_dead_constants()
* about param_index and param_offset.
*/
Re: [Mesa-dev] [PATCH v3 6/8] ReadPixels: handle signed/unsigned integer clamping
On 07/23/2012 09:59 AM, Jordan Justen wrote:
Signed-off-by: Jordan Justen
---
src/mesa/main/readpix.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 784aaad..4fa816f 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -321,6 +321,8 @@ slow_read_rgba_pixels( struct gl_context *ctx,
void *rgba;
GLubyte *dst, *map;
int dstStride, stride, j;
+ GLboolean is_integer = _mesa_is_enum_format_integer(format);
+ GLboolean is_unsiged_integer = _mesa_is_format_unsigned(rbFormat);
Same typo as patch 2/8.
dstStride = _mesa_image_row_stride(packing, width, format, type);
dst = (GLubyte *) _mesa_image_address2d(packing, pixels, width, height,
@@ -338,12 +340,17 @@ slow_read_rgba_pixels( struct gl_context *ctx,
goto done;
for (j = 0; j < height; j++) {
- if (_mesa_is_enum_format_integer(format)) {
+ if (is_integer) {
_mesa_unpack_uint_rgba_row(rbFormat, width, map, (GLuint (*)[4]) rgba);
_mesa_rebase_rgba_uint(width, (GLuint (*)[4]) rgba,
rb->_BaseFormat);
- _mesa_pack_rgba_span_from_uints(ctx, width, (GLuint (*)[4]) rgba,
format,
- type, dst);
+ if (is_unsiged_integer) {
+_mesa_pack_rgba_span_from_uints(ctx, width, (GLuint (*)[4]) rgba,
format,
+type, dst);
+ } else {
+_mesa_pack_rgba_span_from_ints(ctx, width, (GLint (*)[4]) rgba,
format,
+ type, dst);
+ }
} else {
_mesa_unpack_rgba_row(rbFormat, width, map, (GLfloat (*)[4]) rgba);
_mesa_rebase_rgba_float(width, (GLfloat (*)[4]) rgba,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 8/8] i965: add ARB_texture_rgb10_a2ui support
On 07/23/2012 09:59 AM, Jordan Justen wrote: Signed-off-by: Jordan Justen Reviewed-by: Brian Paul --- docs/GL3.txt |2 +- src/mesa/drivers/dri/i965/brw_wm_surface_state.c |1 + src/mesa/drivers/dri/intel/intel_extensions.c|1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 7c68745..0f6521d 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -78,7 +78,7 @@ GL_ARB_explicit_attrib_location DONE (i915, i965, r300, r6 GL_ARB_occlusion_query2 DONE (r300, r600, swrast) GL_ARB_sampler_objectsDONE (i965, r300, r600) GL_ARB_shader_bit_encodingDONE -GL_ARB_texture_rgb10_a2ui DONE (r600) +GL_ARB_texture_rgb10_a2ui DONE (i965, r600) GL_ARB_texture_swizzleDONE (same as EXT version) (i965, r300, r600, swrast) GL_ARB_timer_queryDONE GL_ARB_instanced_arrays DONE (i965, r300, r600) diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c index 82e44f9..57a83d8 100644 --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c @@ -325,6 +325,7 @@ brw_format_for_mesa_format(gl_format mesa_format) [MESA_FORMAT_RG1616] = BRW_SURFACEFORMAT_R16G16_UNORM, [MESA_FORMAT_RG1616_REV] = 0, [MESA_FORMAT_ARGB2101010] = BRW_SURFACEFORMAT_B10G10R10A2_UNORM, + [MESA_FORMAT_ABGR2101010_UINT] = BRW_SURFACEFORMAT_R10G10B10A2_UINT, [MESA_FORMAT_Z24_S8] = 0, [MESA_FORMAT_S8_Z24] = 0, [MESA_FORMAT_Z16] = 0, diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c b/src/mesa/drivers/dri/intel/intel_extensions.c index c2bc072..2bdb8e8 100755 --- a/src/mesa/drivers/dri/intel/intel_extensions.c +++ b/src/mesa/drivers/dri/intel/intel_extensions.c @@ -92,6 +92,7 @@ intelInitExtensions(struct gl_context *ctx) #endif ctx->Extensions.OES_draw_texture = true; ctx->Extensions.OES_compressed_ETC1_RGB8_texture = true; + ctx->Extensions.ARB_texture_rgb10_a2ui = true; Alphabetize. if (intel->gen >= 6) ctx->Const.GLSLVersion = 130; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
On Mon, Jul 23, 2012 at 4:25 PM, Jerome Glisse wrote: > On Sun, Jul 22, 2012 at 8:58 PM, Marek Olšák wrote: >> On Fri, Jul 20, 2012 at 4:54 AM, Jerome Glisse wrote: >>> On Thu, Jul 19, 2012 at 10:25 PM, Marek Olšák wrote: On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse wrote: > On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák wrote: >> I actually care a lot about lockups. Well, you are complaing about >> lockups, yet you have quite obvious bugs in your hyperz code, so let's >> fix them first. (I wouldn't even try and run the hyperz code in its >> current state. Please don't take that personally.) Then, if the >> lockups persist, we can start looking into *what* fixes them. You seem >> to think that this patch helps a lot, but you don't say why. Aren't >> you interested in what sequence of GPU commands helps? If I am >> counting correctly, there are 7 changes in behavior in this patch. It >> should be pretty easy to nail down the few that help, document them >> (like /* these two lines fix a lockup with hyperz */), and discard the >> rest. The documenting part is very important, so that the other >> developers won't break your code accidentally. >> >> Marek >> > > You haven't even try hyperz and you say i have an obvious bug, that's > kind of funny, but you would not know why. I try pretty much all of Oh come on, I already told you about all the bugs I found in the hyperz patch. You now know them too, and so does everybody else reading mesa-dev. Marek >>> >>> None of the issue you pointed out showed in piglit, none of them did >>> have impact on things like openarena, nexuiz, doomIII, lightmark, ... >>> so no issue you pointed does not cripple the hyperz patch, it's >>> working quite well for many things. Before you extrapolate, yes issue >>> you pointed out have impact in backward use of GL but none the less i >>> addressed them and i can tell you it does help a bit with lockup. >> >> I have no doubt that it helps with your lockups and I also have no >> doubt that the piece of code that helps can be bisected. I have >> mentioned 7 changes in the patch which are questionable, so the >> bisection should ideally take 3 steps. After we find the change which >> helps (and document it), we can discard the rest. That should give us >> the same stability as this patch does, but without unnecessary code >> which does cost GPU cycles (regardless of whether it is measurable on >> a particular machine or not). >> >> By the way, in draw_vbo, the emit functions should be called after >> r600_need_cs_space. Otherwise the command stream may overflow. >> >> Marek > > Again i haven't found a combination other than the outcome of the full > patch that helps more. So be my guest bisect on rv610, rv635, rv670, > rv710, rv740, rv770. So your patch doesn't fix any issue with evergreen? That's great. Thanks for keeping that to yourself. It's always a pleasure working with you. :) Now that we know the truth, the questionable changes to the evergreen code can be discarded freely. Concerning older chipsets, I can do the bisection only on rs880, rv670 and rv730. That will have to suffice. One way or another, every single change must be done for a *reason* and that reason should be documented if it's not obvious. Please give me all the necessary information, so that I can start bisecting. That is what lockups your patch fixes and where (name apps or tests, a specific place in a game, etc.) on what chipsets and whether hyperz is enabled. It is very likely that all the changes I questioned in my first email do not make any difference with regard to lockups, because there are also other changes in your patch which may help too and which I fully agree with. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
On Mon, Jul 23, 2012 at 5:28 PM, Marek Olšák wrote: > On Mon, Jul 23, 2012 at 4:25 PM, Jerome Glisse wrote: >> On Sun, Jul 22, 2012 at 8:58 PM, Marek Olšák wrote: >>> On Fri, Jul 20, 2012 at 4:54 AM, Jerome Glisse wrote: On Thu, Jul 19, 2012 at 10:25 PM, Marek Olšák wrote: > On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse wrote: >> On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák wrote: >>> I actually care a lot about lockups. Well, you are complaing about >>> lockups, yet you have quite obvious bugs in your hyperz code, so let's >>> fix them first. (I wouldn't even try and run the hyperz code in its >>> current state. Please don't take that personally.) Then, if the >>> lockups persist, we can start looking into *what* fixes them. You seem >>> to think that this patch helps a lot, but you don't say why. Aren't >>> you interested in what sequence of GPU commands helps? If I am >>> counting correctly, there are 7 changes in behavior in this patch. It >>> should be pretty easy to nail down the few that help, document them >>> (like /* these two lines fix a lockup with hyperz */), and discard the >>> rest. The documenting part is very important, so that the other >>> developers won't break your code accidentally. >>> >>> Marek >>> >> >> You haven't even try hyperz and you say i have an obvious bug, that's >> kind of funny, but you would not know why. I try pretty much all of > > Oh come on, I already told you about all the bugs I found in the > hyperz patch. You now know them too, and so does everybody else > reading mesa-dev. > > Marek > None of the issue you pointed out showed in piglit, none of them did have impact on things like openarena, nexuiz, doomIII, lightmark, ... so no issue you pointed does not cripple the hyperz patch, it's working quite well for many things. Before you extrapolate, yes issue you pointed out have impact in backward use of GL but none the less i addressed them and i can tell you it does help a bit with lockup. >>> >>> I have no doubt that it helps with your lockups and I also have no >>> doubt that the piece of code that helps can be bisected. I have >>> mentioned 7 changes in the patch which are questionable, so the >>> bisection should ideally take 3 steps. After we find the change which >>> helps (and document it), we can discard the rest. That should give us >>> the same stability as this patch does, but without unnecessary code >>> which does cost GPU cycles (regardless of whether it is measurable on >>> a particular machine or not). >>> >>> By the way, in draw_vbo, the emit functions should be called after >>> r600_need_cs_space. Otherwise the command stream may overflow. >>> >>> Marek >> >> Again i haven't found a combination other than the outcome of the full >> patch that helps more. So be my guest bisect on rv610, rv635, rv670, >> rv710, rv740, rv770. > > So your patch doesn't fix any issue with evergreen? That's great. > Thanks for keeping that to yourself. It's always a pleasure working > with you. :) Now that we know the truth, the questionable changes to > the evergreen code can be discarded freely. No, it helps on evergreen too, redwood,juniper,turks and bart are the only one i tested with. Evergreen is in a slightly better position but when it comes to lockup there is no good metrics. > Concerning older chipsets, I can do the bisection only on rs880, rv670 > and rv730. That will have to suffice. One way or another, every single > change must be done for a *reason* and that reason should be > documented if it's not obvious. Please give me all the necessary > information, so that I can start bisecting. That is what lockups your > patch fixes and where (name apps or tests, a specific place in a game, > etc.) on what chipsets and whether hyperz is enabled. Sorry no such things. It just helps, pick something test with and without and you will see that with it lockup less often. I did not did any of the change in isolation to fix a single case, it's just that with all the change it helps. But of course you assume that i dumb and i did spend no time testing, and just put together some random thing. > It is very likely that all the changes I questioned in my first email > do not make any difference with regard to lockups, because there are > also other changes in your patch which may help too and which I fully > agree with. > > Marek As i said it's a package deal, i did not find a solution but i did find something that improved the overall. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
On Mon, Jul 23, 2012 at 5:28 PM, Marek Olšák wrote: > On Mon, Jul 23, 2012 at 4:25 PM, Jerome Glisse wrote: >> On Sun, Jul 22, 2012 at 8:58 PM, Marek Olšák wrote: >>> On Fri, Jul 20, 2012 at 4:54 AM, Jerome Glisse wrote: On Thu, Jul 19, 2012 at 10:25 PM, Marek Olšák wrote: > On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse wrote: >> On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák wrote: >>> I actually care a lot about lockups. Well, you are complaing about >>> lockups, yet you have quite obvious bugs in your hyperz code, so let's >>> fix them first. (I wouldn't even try and run the hyperz code in its >>> current state. Please don't take that personally.) Then, if the >>> lockups persist, we can start looking into *what* fixes them. You seem >>> to think that this patch helps a lot, but you don't say why. Aren't >>> you interested in what sequence of GPU commands helps? If I am >>> counting correctly, there are 7 changes in behavior in this patch. It >>> should be pretty easy to nail down the few that help, document them >>> (like /* these two lines fix a lockup with hyperz */), and discard the >>> rest. The documenting part is very important, so that the other >>> developers won't break your code accidentally. >>> >>> Marek >>> >> >> You haven't even try hyperz and you say i have an obvious bug, that's >> kind of funny, but you would not know why. I try pretty much all of > > Oh come on, I already told you about all the bugs I found in the > hyperz patch. You now know them too, and so does everybody else > reading mesa-dev. > > Marek > None of the issue you pointed out showed in piglit, none of them did have impact on things like openarena, nexuiz, doomIII, lightmark, ... so no issue you pointed does not cripple the hyperz patch, it's working quite well for many things. Before you extrapolate, yes issue you pointed out have impact in backward use of GL but none the less i addressed them and i can tell you it does help a bit with lockup. >>> >>> I have no doubt that it helps with your lockups and I also have no >>> doubt that the piece of code that helps can be bisected. I have >>> mentioned 7 changes in the patch which are questionable, so the >>> bisection should ideally take 3 steps. After we find the change which >>> helps (and document it), we can discard the rest. That should give us >>> the same stability as this patch does, but without unnecessary code >>> which does cost GPU cycles (regardless of whether it is measurable on >>> a particular machine or not). >>> >>> By the way, in draw_vbo, the emit functions should be called after >>> r600_need_cs_space. Otherwise the command stream may overflow. >>> >>> Marek >> >> Again i haven't found a combination other than the outcome of the full >> patch that helps more. So be my guest bisect on rv610, rv635, rv670, >> rv710, rv740, rv770. > > So your patch doesn't fix any issue with evergreen? That's great. > Thanks for keeping that to yourself. It's always a pleasure working > with you. :) Now that we know the truth, the questionable changes to > the evergreen code can be discarded freely. As usual you make the worst assumption about me. Cheers, Jerome > Concerning older chipsets, I can do the bisection only on rs880, rv670 > and rv730. That will have to suffice. One way or another, every single > change must be done for a *reason* and that reason should be > documented if it's not obvious. Please give me all the necessary > information, so that I can start bisecting. That is what lockups your > patch fixes and where (name apps or tests, a specific place in a game, > etc.) on what chipsets and whether hyperz is enabled. > > It is very likely that all the changes I questioned in my first email > do not make any difference with regard to lockups, because there are > also other changes in your patch which may help too and which I fully > agree with. > > Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] msaa: Compute visual samples/sampleBuffers from all buffers.
On 07/18/2012 08:15 AM, Paul Berry wrote: > This patch ensures that Visual.samples and Visual.sampleBuffers are > set correctly even in the case where there is no color buffer. > Previously, these values would retain their default value of 0 in this > circumstance, even if the depth or stencil buffer was multisampled. > --- > src/mesa/main/framebuffer.c |9 +++-- > 1 files changed, 7 insertions(+), 2 deletions(-) Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On 07/23/2012 12:59 PM, Ian Romanick wrote: > Perhaps someone can refresh my memory as to what exactly this option > does? Can we make this the default and remove the option from configure? The --enable-shared-glapi option allows programs to use both libGL.so and libGLESv2.so without zillions of conflicting linker symbols. IIRC it basically extracts the API dispatch stuff into libglapi.so and makes both libraries depend on a single copy. I'm failing at email archaeology, but I know we've talked about this before. I believe Chia-I said he thought it would be a good idea to make it the default, but essentially left the option as a chicken bit, in case it didn't work in all situations. It looks like Matt Turner, Jon Turney, and Homer Hsing also approved of the change. Somebody had a patch but I can't find it now. The only trouble I know about is that if your libglapi gets out of sync with your libGL/libGLES, all hell breaks loose: glCompileShader gets routed to glLinkProgram and so on. Apps fail in spectacular ways. But as long as you keep them in sync (and it's not hard), then it works fine. I'm all for making shared-glapi mandatory. People who care about GLES will want it (and thus distros would want it), there's no real downside, and reducing the number of configurations would be great. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/15] intel: Allocate miptree for multisample DRI2 buffers
On 21 July 2012 17:36, Chad Versace wrote:
> Immediately after obtaining, with DRI2GetBuffersWithFormat, the DRM buffer
> handle for a DRI2 buffer, we wrap that DRM buffer handle with a region and
> a miptre. This patch additionally allocates an accompanying multisample
>
"miptree"
> miptree if the DRI2 buffer is multisampled.
>
> Since we do not yet advertise multisample GL configs, the code for
> allocating the multisample miptree is currently inactive.
>
> CC: Eric Anholt
> CC: Paul Berry
> Signed-off-by: Chad Versace
> ---
> src/mesa/drivers/dri/intel/intel_context.c | 26 +
> src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 52
> ++
> src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 6 +++
> 3 files changed, 76 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_context.c
> b/src/mesa/drivers/dri/intel/intel_context.c
> index 378859c..9a85d83 100644
> --- a/src/mesa/drivers/dri/intel/intel_context.c
> +++ b/src/mesa/drivers/dri/intel/intel_context.c
> @@ -893,14 +893,24 @@ intel_process_dri2_buffer(struct intel_context
> *intel,
> if (!rb)
>return;
>
> + unsigned num_samples = rb->Base.Base.NumSamples;
> +
> /* We try to avoid closing and reopening the same BO name, because the
> first
> * use of a mapping of the buffer involves a bunch of page faulting
> which is
> * moderately expensive.
> */
> - if (rb->mt &&
> - rb->mt->region &&
> - rb->mt->region->name == buffer->name)
> - return;
> + if (num_samples == 0) {
> + if (rb->mt &&
> + rb->mt->region &&
> + rb->mt->region->name == buffer->name)
> + return;
> + } else {
> + if (rb->mt &&
> + rb->mt->singlesample_mt &&
> + rb->mt->singlesample_mt->region &&
> + rb->mt->singlesample_mt->region->name == buffer->name)
> + return;
> + }
>
> if (unlikely(INTEL_DEBUG & DEBUG_DRI)) {
>fprintf(stderr,
> @@ -920,9 +930,9 @@ intel_process_dri2_buffer(struct intel_context *intel,
> if (!region)
>return;
>
> - rb->mt = intel_miptree_create_for_region(intel,
> -GL_TEXTURE_2D,
> -intel_rb_format(rb),
> -region);
> + rb->mt = intel_miptree_create_for_dri2_buffer(intel,
> + intel_rb_format(rb),
> + num_samples,
> + region);
> intel_region_release(®ion);
> }
> diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> index b402099..c4496ea 100644
> --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> @@ -324,6 +324,58 @@ compute_msaa_layout(struct intel_context *intel,
> gl_format format)
> }
> }
>
> +/**
> + * If the DRI2 buffer is multisampled, then its content is undefined
> + * after calling this. This behavior violates the GLX spec for the
> + * benefit of avoiding a performance penalty.
> + */
> +struct intel_mipmap_tree*
> +intel_miptree_create_for_dri2_buffer(struct intel_context *intel,
> + gl_format format,
> + uint32_t num_samples,
> + struct intel_region *region)
> +{
> + struct intel_mipmap_tree *singlesample_mt = NULL;
> + struct intel_mipmap_tree *multisample_mt = NULL;
> + GLenum base_format = _mesa_get_format_base_format(format);
> +
> + /* Only the front and back buffers, which are color buffers, are shared
> +* through DRI2.
> +*/
> + assert(base_format == GL_RGB || base_format == GL_RGBA);
> +
> + singlesample_mt = intel_miptree_create_for_region(intel, GL_TEXTURE_2D,
> + format, region);
> + if (!singlesample_mt)
> + return NULL;
> +
> + if (num_samples == 0) {
> + return singlesample_mt;
> + } else {
> + multisample_mt = intel_miptree_create_for_renderbuffer(intel,
> + format,
> +
> region->width,
> +
> region->height,
> + num_samples);
> + if (!multisample_mt) {
> + intel_miptree_release(&singlesample_mt);
> + return NULL;
> + }
> +
> + multisample_mt->singlesample_mt = singlesample_mt;
> + multisample_mt->need_downsample = false;
> +
> + /* If we wanted to preserve the contents of the DRI2 buffer, here we
> + * would need to do an upsample from singlesample_mt to
> multisample_mt.
> + * However, it is unlikely that any app desires that behavior. So we
> + * invalidate its content for the benefit of avoiding the upsample
> + * performance
Re: [Mesa-dev] [PATCH 2/2] r600g: simplify and fix flushing and synchronization v2
On Mon, Jul 23, 2012 at 11:42 PM, Jerome Glisse wrote: > No, it helps on evergreen too, redwood,juniper,turks and bart are the > only one i tested with. Evergreen is in a slightly better position but > when it comes to lockup there is no good metrics. > >> Concerning older chipsets, I can do the bisection only on rs880, rv670 >> and rv730. That will have to suffice. One way or another, every single >> change must be done for a *reason* and that reason should be >> documented if it's not obvious. Please give me all the necessary >> information, so that I can start bisecting. That is what lockups your >> patch fixes and where (name apps or tests, a specific place in a game, >> etc.) on what chipsets and whether hyperz is enabled. > > Sorry no such things. It just helps, pick something test with and > without and you will see that with it lockup less often. I did not did > any of the change in isolation to fix a single case, it's just that > with all the change it helps. Fair enough, but please add clearly-understandable comments describing why each questionable piece of code is required to all the places in the code that I mentioned in the sections (1) and (3) of my first email. To give you just one example: /* XXX We flush the texture cache every drawing operation on chipsets without a vertex cache, which may decrease performance, but it helps with hyperz lockups. */ ... before "if (!rctx->has_vertex_cache)" in *_flush_emit. Only this will assure the other developers won't touch your code until the hyperz issue is resolved completely. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] intel: Remove dead code in intelAllocateBuffer
On 23 July 2012 09:15, Eric Anholt wrote:
> Chris Wilson writes:
>
> > On Sat, 21 Jul 2012 17:36:40 -0700, Chad Versace <
> chad.vers...@linux.intel.com> wrote:
> >> After commit "intel: Convert to using private depth/stencil buffers", we
> >> request from DRI2GetBuffersWithFormat only the front left and back left
> >> buffers. We no longer request depth and stencil buffers.
> >>
> >> Assert that in intelAllocateBuffer and remove the related dead code.
> >
> >> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> b/src/mesa/drivers/dri/intel/intel_screen.c
> >> index 81953ce..2d46d67 100644
> >> --- a/src/mesa/drivers/dri/intel/intel_screen.c
> >> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> >> @@ -972,54 +972,6 @@ struct intel_buffer {
> >> struct intel_region *region;
> >
> >> - ok = intel_get_dri_buffer_tiling(intelScreen, attachment, &tiling);
> >
> >> + /* The front and back buffers are color buffers, which are X tiled.
> */
> >> intelBuffer->region = intel_region_alloc(intelScreen,
> >> -tiling,
> >> -region_cpp,
> >> -region_width,
> >> -region_height,
> >> +I915_TILING_X,
> >> +format / 8,
> >> +width,
> >> +height,
> >> true);
> >
> > I see no reason to bake in the assumption that the buffers are X-tiled.
> > Presumably Y-tiling will still be advantageous in many circumstances,
> > basically any surface which is not a candidate for pageflipping?
>
> If there was some reason, it probably won't be based on just the
> attachment type, so this seems like a good change.
>
Agreed. Besides, the old code had a baked-in assumption of X-tiling for
front buffers too, so there is no change. This patch is:
Reviewed-by: Paul Berry
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/15] i965: Add function intel_miptree_downsample
On 21 July 2012 17:36, Chad Versace wrote:
> This function does a downsample from mt to mt->singlesample_mt.
>
> Conceptually, this function belongs in intel_mipmap_tree.c. However, it
> needs to interact with blorp, which is C++. So I created a new file,
> brw_blorp_orphands.cpp, for this and other functions that fall into the
>
No "d" in "orphans". Other than that, this patch is:
Reviewed-by: Paul Berry
> same category.
>
> CC: Eric Anholt
> CC: Paul Berry
> Signed-off-by: Chad Versace
> ---
> src/mesa/drivers/dri/i965/Makefile.sources | 1 +
> src/mesa/drivers/dri/i965/brw_blorp_orphans.cpp | 66
> +
> src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 10
> 3 files changed, 77 insertions(+)
> create mode 100644 src/mesa/drivers/dri/i965/brw_blorp_orphans.cpp
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 334bfd9..4bbd905 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -113,6 +113,7 @@ i965_C_FILES = \
> i965_CXX_FILES = \
> brw_blorp.cpp \
> brw_blorp_blit.cpp \
> + brw_blorp_orphans.cpp \
> brw_cubemap_normalize.cpp \
> brw_fs.cpp \
> brw_fs_cfg.cpp \
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_orphans.cpp
> b/src/mesa/drivers/dri/i965/brw_blorp_orphans.cpp
> new file mode 100644
> index 000..0b16438
> --- /dev/null
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_orphans.cpp
> @@ -0,0 +1,66 @@
> +/*
> + * Copyright © 2012 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
> + *
> + * This file contains functions which whose definitions conceptually
> belong
> + * in other C files but need to interact closely with blorp.
> + */
> +
> +#include "intel_mipmap_tree.h"
> +
> +#include "brw_blorp.h"
> +
> +extern "C" {
> +
> +/**
> + * \brief Downsample from mt to mt->singlesample_mt.
> + *
> + * If the miptree needs no downsample, then skip.
> + */
> +void
> +intel_miptree_downsample(struct intel_context *intel,
> + struct intel_mipmap_tree *mt)
> +{
> + if (!mt->need_downsample)
> + return;
> +
> + int src_x0 = 0;
> + int src_y0 = 0;
> + int dst_x0 = 0;
> + int dst_y0 = 0;
> +
> + brw_blorp_blit_params params(brw_context(&intel->ctx),
> +mt, mt->singlesample_mt,
> +src_x0, src_y0,
> +dst_x0, dst_y0,
> +mt->singlesample_mt->width0,
> +mt->singlesample_mt->height0,
> +false, false);
> + brw_blorp_exec(intel, ¶ms);
> +
> + mt->need_downsample = false;
> +}
> +
> +} /* end extern "C" */
> diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
> b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
> index bb3fa50..0b76fad 100644
> --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
> +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
> @@ -540,6 +540,9 @@ intel_miptree_unmap(struct intel_context *intel,
> unsigned int slice);
>
> #ifdef I915
> +
> +void intel_miptree_downsample();
> +
> static inline void
> intel_hiz_exec(struct intel_context *intel, struct intel_mipmap_tree *mt,
>unsigned int level, unsigned int layer, enum gen6_hiz_op op)
> @@ -548,7 +551,14 @@ intel_hiz_exec(struct intel_context *intel, struct
> intel_mipmap_tree *mt,
> * there.
> */
> }
> +
> #else
> +
> +void
> +intel_miptree_downsample(struct intel_context *intel,
> + struct intel_mipmap_tree *mt);
> +
> +
> void
> intel_hiz_exec(struct intel_context *intel, struct intel_mipmap_tree *mt,
>unsigned int level, unsigned
Re: [Mesa-dev] [PATCH 02/10] i965/msaa: Control multisampling behaviour via the visual.
On 07/18/2012 08:15 AM, Paul Berry wrote: > Previously, we used the number of samples in draw buffer 0 to > determine whether to set up the 3D pipeline for multisampling. Using > the visual is cleaner, and has the benefit of working properly when > there is no color buffer. > > Fixes all piglit tests "EXT_framebuffer_multisample/no-color" on Gen7. > On Gen6, the "depth-computed" variants of these tests still fail; this > will be addresed in a later patch. Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] shared-glapi: Install libglapi.so.0.0.0 and .0 links in lib/.
We already provided these files on 'make install', but only created a 'libglapi.so' in the top-level lib/ convenience folder. We used to create all three, but at some point in the build system churn, it broke. Various applications (like the ES2 conformance suite) seem to link against libglapi.so.0, so without these links, setting LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH can lead to using /usr/lib/libglapi.so.0 with /home/whatever/libGL.so, which leads to API calls getting routed incorrectly (i.e. glCompileShader -> _mesa_LinkProgramARB), which leads to rage problems. Preserve developer sanity...install links. Signed-off-by: Kenneth Graunke --- src/mapi/shared-glapi/Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/mapi/shared-glapi/Makefile.am b/src/mapi/shared-glapi/Makefile.am index 9485683..8db7688 100644 --- a/src/mapi/shared-glapi/Makefile.am +++ b/src/mapi/shared-glapi/Makefile.am @@ -25,4 +25,6 @@ AM_CPPFLAGS = \ all-local: libglapi.la $(MKDIR_P) $(top_builddir)/$(LIB_DIR) - ln -f .libs/libglapi.so.0.0.0 $(top_builddir)/$(LIB_DIR)/libglapi.so + ln -f .libs/libglapi.so.0.0.0 $(top_builddir)/$(LIB_DIR)/libglapi.so.0.0.0 + ln -sf libglapi.so.0.0.0 $(top_builddir)/$(LIB_DIR)/libglapi.so.0 + ln -sf libglapi.so.0 $(top_builddir)/$(LIB_DIR)/libglapi.so -- 1.7.11.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 13/15] intel: Refactor creation of DRI2 configs
On 21 July 2012 17:36, Chad Versace wrote:
> DRI2 configs were constructed in intelInitScreen2. That function already
> does too much, so move verbatim the code for creating configs to a new
> function, intel_screen_make_configs.
>
> CC: Eric Anholt
> CC: Paul Berry
> Signed-off-by: Chad Versace
> ---
> src/mesa/drivers/dri/intel/intel_screen.c | 189
> --
> 1 file changed, 98 insertions(+), 91 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> b/src/mesa/drivers/dri/intel/intel_screen.c
> index 958ff9f..9bb42dd 100644
> --- a/src/mesa/drivers/dri/intel/intel_screen.c
> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> @@ -848,6 +848,103 @@ intel_detect_swizzling(struct intel_screen *screen)
>return true;
> }
>
> +static __DRIconfig**
> +intel_screen_make_configs(__DRIscreen *dri_screen)
> +{
> + static const GLenum back_buffer_modes[] = {
> + GLX_NONE, GLX_SWAP_UNDEFINED_OML, GLX_SWAP_COPY_OML
> + };
> +
> + GLenum fb_format[3];
> + GLenum fb_type[3];
> + uint8_t depth_bits[4], stencil_bits[4], msaa_samples_array[1];
> + int color;
> + __DRIconfig **configs = NULL;
> +
> + msaa_samples_array[0] = 0;
> +
> + fb_format[0] = GL_RGB;
> + fb_type[0] = GL_UNSIGNED_SHORT_5_6_5;
> +
> + fb_format[1] = GL_BGR;
> + fb_type[1] = GL_UNSIGNED_INT_8_8_8_8_REV;
> +
> + fb_format[2] = GL_BGRA;
> + fb_type[2] = GL_UNSIGNED_INT_8_8_8_8_REV;
> +
> + depth_bits[0] = 0;
> + stencil_bits[0] = 0;
> +
> + /* Generate a rich set of useful configs that do not include an
> +* accumulation buffer.
> +*/
> + for (color = 0; color < ARRAY_SIZE(fb_format); color++) {
> + __DRIconfig **new_configs;
> + int depth_factor;
> +
> + /* Starting with DRI2 protocol version 1.1 we can request a
> depth/stencil
> + * buffer that has a different number of bits per pixel than the
> color
> + * buffer. This isn't yet supported here.
> + */
> + if (fb_type[color] == GL_UNSIGNED_SHORT_5_6_5) {
> + depth_bits[1] = 16;
> + stencil_bits[1] = 0;
> + } else {
> + depth_bits[1] = 24;
> + stencil_bits[1] = 8;
> + }
> +
> + depth_factor = 2;
> +
> + new_configs = driCreateConfigs(fb_format[color], fb_type[color],
> + depth_bits,
> + stencil_bits,
> + depth_factor,
> + back_buffer_modes,
> + ARRAY_SIZE(back_buffer_modes),
> + msaa_samples_array,
> + ARRAY_SIZE(msaa_samples_array),
> + false);
> + if (configs == NULL)
> + configs = new_configs;
> + else
> + configs = driConcatConfigs(configs, new_configs);
> + }
> +
> + /* Generate the minimum possible set of configs that include an
> +* accumulation buffer.
> +*/
> + for (color = 0; color < ARRAY_SIZE(fb_format); color++) {
> + __DRIconfig **new_configs;
> +
> + if (fb_type[color] == GL_UNSIGNED_SHORT_5_6_5) {
> + depth_bits[0] = 16;
> + stencil_bits[0] = 0;
> + } else {
> + depth_bits[0] = 24;
> + stencil_bits[0] = 8;
> + }
> +
> + new_configs = driCreateConfigs(fb_format[color], fb_type[color],
> + depth_bits, stencil_bits, 1,
> + back_buffer_modes + 1, 1,
> + msaa_samples_array, 1,
> + true);
> + if (configs == NULL)
> + configs = new_configs;
> + else
> + configs = driConcatConfigs(configs, new_configs);
> + }
> +
> + if (configs == NULL) {
> + fprintf(stderr, "[%s:%u] Error creating FBConfig!\n", __func__,
> + __LINE__);
> + return NULL;
> + }
> +
> + return configs;
> +}
> +
> /**
> * This is the driver specific part of the createNewScreen entry point.
> * Called when using DRI2.
> @@ -858,17 +955,8 @@ static const
> __DRIconfig **intelInitScreen2(__DRIscreen *psp)
> {
> struct intel_screen *intelScreen;
> - GLenum fb_format[3];
> - GLenum fb_type[3];
> unsigned int api_mask;
>
> - static const GLenum back_buffer_modes[] = {
> - GLX_NONE, GLX_SWAP_UNDEFINED_OML, GLX_SWAP_COPY_OML
> - };
> - uint8_t depth_bits[4], stencil_bits[4], msaa_samples_array[1];
> - int color;
> - __DRIconfig **configs = NULL;
> -
> if (psp->dri2.loader->base.version <= 2 ||
> psp->dri2.loader->getBuffersWithFormat == NULL) {
>fprintf(stderr,
> @@ -941,88 +1029,7 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
>
> psp->extensions = intelScreenExtensions;
>
> - msaa_samples_array[0] = 0;
> -
> - fb_format[0] = GL_RGB;
> - fb_type[0] = GL_UNSIGNED_SHORT_5_6_5;
> -
> - fb_format[1] = G
Re: [Mesa-dev] [PATCH 10/15] i965: Mark winsys MSAA color buffer as needing resolve postdraw
On 21 July 2012 17:36, Chad Versace wrote:
> Do this immediately after drawing is complete and at the same time that we
> mark the depth buffer as needing a depth resolve.
>
> CC: Eric Anholt
> CC: Paul Berry
> Signed-off-by: Chad Versace
> ---
> src/mesa/drivers/dri/i965/brw_draw.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 1069a63..ca44ff8 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -326,18 +326,29 @@ brw_predraw_resolve_buffers(struct brw_context *brw)
> * If the depth buffer was written to and if it has an accompanying HiZ
> * buffer, then mark that it needs a depth resolve.
> *
> - * (In the future, this will also mark needed MSAA resolves).
> + * If the color buffer is a multisampled window system buffer, then
> + * mark that it needs a downsample resolve.
> */
> static void brw_postdraw_set_buffers_need_resolve(struct brw_context *brw)
> {
> struct gl_context *ctx = &brw->intel.ctx;
> struct gl_framebuffer *fb = ctx->DrawBuffer;
> - struct intel_renderbuffer *depth_irb =
> -intel_get_renderbuffer(fb, BUFFER_DEPTH);
> +
> + gl_buffer_index color_buffer = brw->intel.is_front_buffer_rendering
> +? BUFFER_FRONT_LEFT
> +: BUFFER_BACK_LEFT;
>
If we're rendering to GL_FRONT_AND_BACK, we need to set need_downsample on
both front and back buffers. This code looks like it will only set
need_downsample on the front buffer in that case.
> +
> + struct intel_renderbuffer *depth_irb = intel_get_renderbuffer(fb,
> BUFFER_DEPTH);
> + struct intel_renderbuffer *color_irb = intel_get_renderbuffer(fb,
> color_buffer);
>
> if (depth_irb && ctx->Depth.Mask) {
>intel_renderbuffer_set_needs_depth_resolve(depth_irb);
> }
> +
> + if (color_irb && color_irb->mt->singlesample_mt) {
> + assert(fb->Name == 0);
>
This would be clearer as "assert(_mesa_is_winsys_fbo(fb));". (Note: I'm
working on a patch to clean a bunch of these up, but I want to wait until
some of my other patches land before doing so).
> + color_irb->mt->need_downsample = true;
> + }
> }
>
> static int
> --
> 1.7.11.2
>
>
A similar change also needs to be made to try_blorp_blit() (in
brw_blorp_blit.cpp), so that we'll set need_downsample if the client blits
to a multisampled window. Or perhaps it would be better to do some
refactoring so that we don't have to repeat ourselves :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/15] intel: Downsample during glReadPixels
On 21 July 2012 17:36, Chad Versace wrote:
> Actually, this patch forces an automatic downsample during
> intel_miptree_map. And this should occur only due to glReadPixels.
>
> CC: Eric Anholt
> CC: Paul Berry
> Signed-off-by: Chad Versace
> ---
> src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> index c4496ea..26002c2 100644
> --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> @@ -1339,6 +1339,15 @@ intel_miptree_map(struct intel_context *intel,
> {
> struct intel_miptree_map *map;
>
> + if (mt->num_samples > 0 && (mode & GL_MAP_WRITE_BIT)) {
> + /* We choose not support swrast on multisample buffers because
> + * it would require an upsample on unmap. As of 2012-07-20, this
> + * warning occurs only on glDrawPixels(GL_STENCIL_INDEX).
> + */
> + _mesa_warning(&intel->ctx, "unsupported fallback to software "
> +"rasterization on a multisample buffer");
> + }
> +
> map = calloc(1, sizeof(struct intel_miptree_map));
> if (!map){
>*out_ptr = NULL;
> @@ -1354,6 +1363,7 @@ intel_miptree_map(struct intel_context *intel,
> map->w = w;
> map->h = h;
>
> + intel_miptree_downsample(intel, mt);
> intel_miptree_slice_resolve_depth(intel, mt, level, slice);
> if (map->mode & GL_MAP_WRITE_BIT) {
>intel_miptree_slice_set_needs_hiz_resolve(mt, level, slice);
> --
> 1.7.11.2
>
>
It seems to me that we also need to write some code to ensure that
glReadPixels() reads from mt->singlesample_mt rather than mt. (Otherwise,
on Gen6, glReadPixels() will see something awful, and on Gen7,
glReadPixels() will read from the first slice of the UMS/CMS buffer, which
will look ok like no multisampled occurred). Or am I missing something?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On Mon, Jul 23, 2012 at 3:15 PM, Kenneth Graunke wrote: > On 07/23/2012 12:59 PM, Ian Romanick wrote: >> Perhaps someone can refresh my memory as to what exactly this option >> does? Can we make this the default and remove the option from configure? > > The --enable-shared-glapi option allows programs to use both libGL.so > and libGLESv2.so without zillions of conflicting linker symbols. IIRC > it basically extracts the API dispatch stuff into libglapi.so and makes > both libraries depend on a single copy. > > I'm failing at email archaeology, but I know we've talked about this > before. I believe Chia-I said he thought it would be a good idea to > make it the default, but essentially left the option as a chicken bit, > in case it didn't work in all situations. > > It looks like Matt Turner, Jon Turney, and Homer Hsing also approved of > the change. Somebody had a patch but I can't find it now. > > The only trouble I know about is that if your libglapi gets out of sync > with your libGL/libGLES, all hell breaks loose: glCompileShader gets > routed to glLinkProgram and so on. Apps fail in spectacular ways. But > as long as you keep them in sync (and it's not hard), then it works fine. > > I'm all for making shared-glapi mandatory. People who care about GLES > will want it (and thus distros would want it), there's no real downside, > and reducing the number of configurations would be great. Yeah, I think I had a patch to make this mandatory. I'm also not remembering why it wasn't committed. It seems like there was some configuration (xlib-glx, osmesa, etc) that didn't work with shared-glapi. I'll take a look and try to get this sorted out. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On Mon, Jul 23, 2012 at 9:08 PM, Matt Turner wrote: > On Mon, Jul 23, 2012 at 3:15 PM, Kenneth Graunke > wrote: >> On 07/23/2012 12:59 PM, Ian Romanick wrote: >>> Perhaps someone can refresh my memory as to what exactly this option >>> does? Can we make this the default and remove the option from configure? >> >> The --enable-shared-glapi option allows programs to use both libGL.so >> and libGLESv2.so without zillions of conflicting linker symbols. IIRC >> it basically extracts the API dispatch stuff into libglapi.so and makes >> both libraries depend on a single copy. >> >> I'm failing at email archaeology, but I know we've talked about this >> before. I believe Chia-I said he thought it would be a good idea to >> make it the default, but essentially left the option as a chicken bit, >> in case it didn't work in all situations. >> >> It looks like Matt Turner, Jon Turney, and Homer Hsing also approved of >> the change. Somebody had a patch but I can't find it now. >> >> The only trouble I know about is that if your libglapi gets out of sync >> with your libGL/libGLES, all hell breaks loose: glCompileShader gets >> routed to glLinkProgram and so on. Apps fail in spectacular ways. But >> as long as you keep them in sync (and it's not hard), then it works fine. >> >> I'm all for making shared-glapi mandatory. People who care about GLES >> will want it (and thus distros would want it), there's no real downside, >> and reducing the number of configurations would be great. > > Yeah, I think I had a patch to make this mandatory. I'm also not > remembering why it wasn't committed. It seems like there was some > configuration (xlib-glx, osmesa, etc) that didn't work with > shared-glapi. Yeah, I'd like to see it happen too, but I think osmesa doesn't work with shared-glapi: https://bugs.freedesktop.org/show_bug.cgi?id=47824 Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Check the compilation problems in mesa-user
Hello. Would you please check the compilation problem posted at mesa-user? Several days passed and no software renderer. I rather would like to test the llvmpipe than fix the compiler... What is the status with OSMesa and llvmpipe? How to compile Mesa so that gtkglext can be used with llvmpipe? What other choises than gtkglext? Is gtkglext up-to-date? I used it previously with Mesa 5.0 or the like. Juhana ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Remove unused param conversion code.
On 07/23/2012 10:55 AM, Eric Anholt wrote: > Ever since ctx->NativeIntegers was set, the conversion flag has been > PARAM_NO_CONVERT. And good riddance! :) Odd that I missed that, thanks. 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] automake: Honor GL_LIB for mangled/custom lib names
On Mon, Jul 23, 2012 at 08:29:55AM -0400, Brad King wrote: > On 07/16/2012 09:10 AM, Brad King wrote: > > Use "@GL_LIB@" in src/mesa/drivers/x11/Makefile.am to configure the > > library name. Also use this approach to simplify src/glx/Makefile.am > > and drop the HAVE_MANGLED_GL conditional. > > > > On 07/11/2012 04:05 PM, Dan Nicholson wrote: > >> Looks good to me. I wonder if the HAVE_MANGLED_GL conditional can be > >> dropped at this point? Anyway, > >> > >> Reviewed-by: Dan Nicholson > > > > Additional changes have been made on master which conflict with > > the previous patch, so here is another one rebased on 81de0431. > > I also dropped the HAVE_MANGLED_GL conditional as it no longer > > appears necessary. > > Please review this patch again when you get a chance. > There is no rush, I just don't want it to be forgotten. Applied as 27382c0f. I had been hoping Eric would pick it up since I'm not really keeping up with master these days, but the change looked good enough to me. Thanks! -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
