Re: [Mesa-dev] Patches to make Gallium drivers respect the force_s3tc_enable environment variable

2011-08-04 Thread Michel Dänzer
On Mit, 2011-07-20 at 17:53 -0500, Bryan Cain wrote: 
 The purpose of the following two patches is to make st/mesa expose the S3TC
 extensions when the force_s3tc_enable environment variable is used.  This is
 to match the behavior of the DRI drivers, in which force_s3tc_enable is an
 option in driconf.  Although st/mesa can't use the driconf functions, it can
 at least respect the environment variable for this option.

This may be adeuqate for now, but in the long term it would be better to
properly hook up driconf, so e.g. this could be set on a per-app basis
in ~/.drirc or /etc/drirc.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 39588] [bisected] mesa demo xeglgears draw nothing if surface type is a pixmap

2011-08-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=39588

--- Comment #5 from Benjamin Franzke benjaminfran...@googlemail.com 
2011-08-04 02:42:36 PDT ---
(In reply to comment #4)
 I've bisected this to:
 
 commit 87dde5b1cd596c4008695ff2db9469f88c09f925
 Author: Benjamin Franzke benjaminfran...@googlemail.com
 Date:   Wed Feb 9 15:30:20 2011 +0100
 
 egl_dri2: Use double buffering for window surfaces
 
 We really should have piglit tests for drawing to pixmaps and pbuffers.  
 Simple
 tests that just draw a single triangle should be sufficient.

Ok, Thanks for bisecting.

At the time of writing this patch I owned only radeon hardware, where it works
(r600g).
So a piglit test wouldnt have helped directly (sure, you'd have found it
earlier).

The commit was about using dri double buffer configs for window surfaces
(made the wayland backend code nicer).
This results in contexts being created with double buffer configs,
which are somewhat mixed with single buffer configs, when using pixmap
surfaces.

Why does this work with r600g?
st/mesa sets the context's DrawBuffer[0] depending on its visual render_buffer,
which is set by st/dri depending on the drawables gl_config's doubleBufferMode.

I'll attach a patch that does this for intel in make_current.

-- 
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 39588] [bisected] mesa demo xeglgears draw nothing if surface type is a pixmap

2011-08-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=39588

--- Comment #6 from Benjamin Franzke benjaminfran...@googlemail.com 
2011-08-04 02:43:33 PDT ---
Created an attachment (id=49902)
 View: https://bugs.freedesktop.org/attachment.cgi?id=49902
 Review: https://bugs.freedesktop.org/review?bug=39588attachment=49902

intel: Set ctx's drawbuffer according to drawables visual

-- 
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 00/15] i965, mesa, glapi: Build libi965_dri on Android

2011-08-04 Thread Chad Versace
This is the first step in porting i965 to Android, initially to Gingerbread.
Android is ubiquituous now, and the platform's importance can't be denied. The
Intel drivers really should support it.

The series first builds libglapi, then libmesa, and then libi965_dri.
lib965_dri doens't work yet; it doesn't even link to libdrm. This is just the
initial work to get it to build.

I'm aware that this may be controversial, so I've attempted to integrate the
Android makefiles as non-disruptively as possible.
  - The Android makefiles attempt to duplicate as little as possible from the
existing makefiles. In one case, this dictated that some Makefile code be
extracted into a shared makefile.
  - I've avoided modifying the existsing makefiles except when absolutely
necessary. When a modification or cleanup was necessary, I have attempted
to keep the changes minimal and do them incrementally.
  - The locations of the Android makefiles mirror those of the existing
makefiles.

The series does not break the Linux i965 build. I doubt it breaks other
drivers' builds, but I haven't tested it. If you want me to check that it
doesn't break your build, just let me know the autoconf options.

The series lives on my android-gingerbread-i965 branch. If you'd like to try
the Android build yourself, you should pull from my personal Android manifest
[1], which closely mirrors android-x86, and set `BOARD_USES_I965 := true` in
buildspeck.mk.

[1] repo init -u 
git://anongit.freedesktop.git/~chadversary/android.manifeset.git -b 
gingerbread-i965

Chad Versace (15):
  mesa: Add toplevel Android.mk
  glapi: Build libmesa_glapi on Android
  mesa/sources.mak: Convert all variables to be simply-expanded
  mesa/sources.mak: Cleanup include paths for Android
  mesa/sources.mak: Change handling of lex and yacc files for Android
  main: Remove problematic #include on Android
  main: Add -o option to es_generator.py
  mesa: Build libmesa_main for Android
  dri/Makefile.defines: Remove non-existent dir from include paths
  dri/Makefile.defines: Convert all variables to be simply-expanded
  dri/Makefile.defines: Only add -Iserver to includes if the dir exists
  dri/Makefile.defines: Cleanup filepaths for Android
  i965: New file sources.mk
  i965: Include sources.mk in Makefile
  i965: Build libi965_dri on Android

 Android.mk|   68 +++
 android/mesa_local_vars.mk|   32 +
 src/Android.mk|1 +
 src/mapi/Android.mk   |1 +
 src/mapi/shared-glapi/Android.mk  |   95 ++
 src/mesa/Android.mk   |   63 +
 src/mesa/drivers/Android.mk   |1 +
 src/mesa/drivers/dri/Android.mk   |   33 +
 src/mesa/drivers/dri/Makefile.defines |   61 ++---
 src/mesa/drivers/dri/Makefile.targets |5 ++
 src/mesa/drivers/dri/i965/Android.mk  |   61 +
 src/mesa/drivers/dri/i965/Makefile|  119 +
 src/mesa/drivers/dri/i965/sources.mk  |  115 +++
 src/mesa/main/compiler.h  |2 +-
 src/mesa/main/es_generator.py |   10 +++-
 src/mesa/sources.mak  |   87 ++--
 16 files changed, 576 insertions(+), 178 deletions(-)
 create mode 100644 Android.mk
 create mode 100644 android/mesa_local_vars.mk
 create mode 100644 src/Android.mk
 create mode 100644 src/mapi/Android.mk
 create mode 100644 src/mapi/shared-glapi/Android.mk
 create mode 100644 src/mesa/Android.mk
 create mode 100644 src/mesa/drivers/Android.mk
 create mode 100644 src/mesa/drivers/dri/Android.mk
 create mode 100644 src/mesa/drivers/dri/i965/Android.mk
 create mode 100644 src/mesa/drivers/dri/i965/sources.mk

-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk

2011-08-04 Thread Chad Versace
This is the first step in porting libGLES* and libEGL to Android.

The makefile doesn't build anything yet; it just defines common variables.

The values for MESA_COMMON_C_FLAGS and MESA_COMMON_CPP_FLAGS, I obtained
by invoking autogen.sh with the options below and then inspecting
MESA_TOP/configs/autoconf. My immediate goal is to port i965 to Android,
so I used the typical flags for building i965.
--disable-gallium
--disable-glu
--disable-glw
--disable-glut
--enable-32-bit
--enable-egl
--enable-gles2
--enable-gles1
--enable-texture-float
--with-dri-drivers=i965
--with-gallium-drivers=

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 Android.mk |   66 
 android/mesa_local_vars.mk |   32 +
 2 files changed, 98 insertions(+), 0 deletions(-)
 create mode 100644 Android.mk
 create mode 100644 android/mesa_local_vars.mk

diff --git a/Android.mk b/Android.mk
new file mode 100644
index 000..4158194
--- /dev/null
+++ b/Android.mk
@@ -0,0 +1,66 @@
+#
+# Copyright © 2011 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+#
+
+ifneq ($(TARGET_SIMULATOR),true)
+
+LOCAL_PATH := $(call my-dir)
+
+# Top directory of Mesa project.
+MESA_TOP := $(LOCAL_PATH)
+
+MESA_PLATFORM := android
+
+# Each Android.mk must include MESA_LOCAL_VARS before building any targets.
+MESA_LOCAL_VARS := $(LOCAL_PATH)/android/mesa_local_vars.mk
+
+MESA_COMMON_C_INCLUDES := \
+   $(MESA_TOP)/include \
+   $(MESA_TOP)/src
+
+MESA_COMMON_CFLAGS :=  \
+   -std=c99   \
+  \
+   -Wall  \
+   -Wmissing-prototypes   \
+   -Wno-sign-compare  \
+   -Wno-sign-compare  \
+  \
+   -ffast-math\
+   -fvisibility=hidden\
+  \
+   -DFEATURE_ES1  \
+   -DFEATURE_ES2  \
+   -D_GNU_SOURCE  \
+   -DHAVE_POSIX_MEMALIGN  \
+   -DPTHREADS \
+   -DTEXTURE_FLOAT_ENABLED\
+   -DUSE_X86_ASM
+
+MESA_COMMON_CPPFLAGS := \
+   -Wno-error=non-virtual-dtor \
+   -Wno-non-virtual-dtor
+
+MESA_PYTHON2 := python2
+MESA_PYTHON_FLAGS := -OO -tt
+
+endif # !TARGET_SIMULATOR
diff --git a/android/mesa_local_vars.mk b/android/mesa_local_vars.mk
new file mode 100644
index 000..2f8abde
--- /dev/null
+++ b/android/mesa_local_vars.mk
@@ -0,0 +1,32 @@
+#
+# Copyright © 2011 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR 

[Mesa-dev] [PATCH 02/15] glapi: Build libmesa_glapi on Android

2011-08-04 Thread Chad Versace
The libmesa_glapi.so on Android is analogous to the libglapi.so on Linux.
libmesa_glapi uses the shared glapi.

The libname is libmesa_glapi, rather than libglapi, due to conventions of
the Android build system. Names of intermediate libraries should be
prefixes by the project name so to prevent naming collisions in the build
tree. (For an example, grep for `libc_` in bionic's Makefiles).

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 Android.mk   |2 +
 src/Android.mk   |1 +
 src/mapi/Android.mk  |1 +
 src/mapi/shared-glapi/Android.mk |   95 ++
 4 files changed, 99 insertions(+), 0 deletions(-)
 create mode 100644 src/Android.mk
 create mode 100644 src/mapi/Android.mk
 create mode 100644 src/mapi/shared-glapi/Android.mk

diff --git a/Android.mk b/Android.mk
index 4158194..139491f 100644
--- a/Android.mk
+++ b/Android.mk
@@ -63,4 +63,6 @@ MESA_COMMON_CPPFLAGS := \
 MESA_PYTHON2 := python2
 MESA_PYTHON_FLAGS := -OO -tt
 
+include $(call all-subdir-makefiles)
+
 endif # !TARGET_SIMULATOR
diff --git a/src/Android.mk b/src/Android.mk
new file mode 100644
index 000..5053e7d
--- /dev/null
+++ b/src/Android.mk
@@ -0,0 +1 @@
+include $(call all-subdir-makefiles)
diff --git a/src/mapi/Android.mk b/src/mapi/Android.mk
new file mode 100644
index 000..5053e7d
--- /dev/null
+++ b/src/mapi/Android.mk
@@ -0,0 +1 @@
+include $(call all-subdir-makefiles)
diff --git a/src/mapi/shared-glapi/Android.mk b/src/mapi/shared-glapi/Android.mk
new file mode 100644
index 000..e77f346
--- /dev/null
+++ b/src/mapi/shared-glapi/Android.mk
@@ -0,0 +1,95 @@
+#
+# Copyright © 2011 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+#
+# Authors:
+# Chad Versace c...@chad-versace.us
+#
+
+LOCAL_PATH := $(call my-dir)
+
+# 
+#  Build libmesa_glapi
+# 
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libmesa_glapi
+LOCAL_MODULE_CLASS := SHARED_LIBRARIES
+LOCAL_MODULE_TAGS := optional
+
+intermediates := $(call local-intermediates-dir)
+
+# --
+# Define MAPI_GLAPI_SOURCES
+# --
+
+include $(MESA_TOP)/src/mapi/mapi/sources.mak
+MAPI_GLAPI_SOURCES := $(addprefix $(MESA_TOP)/src/mapi/mapi/, 
$(MAPI_GLAPI_SOURCES))
+
+
+# --
+# Generate MESA_SHARED_GLAPI_H
+# --
+
+MESA_SHARED_GLAPI_H := $(intermediates)/glapi_mapi_tmp.h
+
+MESA_SHARED_GLAPI_H: PRIVATE_APIXML := 
$(MESA_TOP)/src/mapi/glapi/gen/gl_and_es_API.xml
+MESA_SHARED_GLAPI_H: PRIVATE_XML_SOURCES := $(find 
$(MESA_TOP)/src/mapi/glapi/gen -name \*.xml\)
+MESA_SHARED_GLAPI_H: PRIVATE_GEN_SCRIPT := 
$(MESA_TOP)/src/mapi/mapi/mapi_abi.py
+MESA_SHARED_GLAPI_H: PRIVATE_PY_SCRIPTS :=  $(find 
$(MESA_TOP)/src/mapi/glapi/gen -name \*.py\)
+
+MESA_SHARED_GLAPI_H: PRIVATE_DEPS := \
+   $(PRIVATE_XML_SOURCES) \
+   $(PRIVATE_PY_SCRIPTS)
+
+MESA_SHARED_GLAPI_H: PRIVATE_TOOL := \
+   $(MESA_PYTHON2) $(MESA_PYTHON2_FLAGS) $(PRIVATE_GEN_SCRIPT) \
+   --printer shared-glapi \
+   --mode lib \
+   -o $(MESA_SHARED_GLAPI_H) \
+   $(PRIVATE_APIXML)
+
+MESA_SHARED_GLAPI_H: $(PRIVATE_DEPS)
+   @echo XXX01
+   $(call transform-generated-sources)
+
+
+# --
+
+LOCAL_C_FLAGS :=
+
+LOCAL_CPPFLAGS := \
+   -DMAPI_MODE_GLAPI \
+   -DMAPI_ABI_HEADER=\shared-glapi/glapi_mapi_tmp.h\
+
+LOCAL_C_INCLUDES := \
+   $(intermediates) \
+   $(MESA_TOP)/src/mapi
+
+LOCAL_C_SOURCES := \
+   $(MAPI_GLAPI_SOURCES)
+

[Mesa-dev] [PATCH 03/15] mesa/sources.mak: Convert all variables to be simply-expanded

2011-08-04 Thread Chad Versace
This commit converts all variables in Makefile.defines to be of the
simply-expanded flavor.

This commit is a cleanup for Android.

Rationale
-
From the GNU Make manual, Section 6.2 The Two Flavors of Variables:
There are two ways that a variable in GNU make can have a value; we
call them the two flavors of variables. The two flavors are
distinguished in how they are defined and in what they do when
expanded. [...] The first flavor of variable is a recursively expanded
variable. [...] To avoid all the problems and inconveniences of
recursively expanded variables, there is another flavor: simply
expanded variables.

There are two prominent properties of the Android build system that render
the problems and inconveniences of recursively expanded variables
fatally poisonous.
1. All components of the Android platform reside in a single source
   tree.
2. Android is built with a single, non-recursive invocation of `make`.

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/sources.mak |   54 +-
 1 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index 4b2ec08..e45c99f 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -1,11 +1,11 @@
 ### Lists of source files, included by Makefiles
 
 # this is part of MAIN_SOURCES
-MAIN_ES_SOURCES = \
+MAIN_ES_SOURCES := \
main/api_exec_es1.c \
main/api_exec_es2.c
 
-MAIN_SOURCES = \
+MAIN_SOURCES := \
main/api_arrayelt.c \
main/api_exec.c \
main/api_loopback.c \
@@ -103,10 +103,10 @@ MAIN_SOURCES = \
main/vtxfmt.c \
$(MAIN_ES_SOURCES)
 
-MAIN_CXX_SOURCES = \
+MAIN_CXX_SOURCES := \
main/ff_fragment_shader.cpp
 
-MATH_SOURCES = \
+MATH_SOURCES := \
math/m_debug_clip.c \
math/m_debug_norm.c \
math/m_debug_xform.c \
@@ -115,10 +115,10 @@ MATH_SOURCES = \
math/m_translate.c \
math/m_vector.c
 
-MATH_XFORM_SOURCES = \
+MATH_XFORM_SOURCES := \
math/m_xform.c
 
-SWRAST_SOURCES = \
+SWRAST_SOURCES := \
swrast/s_aaline.c \
swrast/s_aatriangle.c \
swrast/s_accum.c \
@@ -148,11 +148,11 @@ SWRAST_SOURCES = \
swrast/s_triangle.c \
swrast/s_zoom.c
 
-SWRAST_SETUP_SOURCES = \
+SWRAST_SETUP_SOURCES := \
swrast_setup/ss_context.c \
swrast_setup/ss_triangle.c 
 
-TNL_SOURCES = \
+TNL_SOURCES := \
tnl/t_context.c \
tnl/t_pipeline.c \
tnl/t_draw.c \
@@ -171,7 +171,7 @@ TNL_SOURCES = \
tnl/t_vertex_sse.c \
tnl/t_vertex_generic.c 
 
-VBO_SOURCES = \
+VBO_SOURCES := \
vbo/vbo_context.c \
vbo/vbo_exec.c \
vbo/vbo_exec_api.c \
@@ -187,7 +187,7 @@ VBO_SOURCES = \
vbo/vbo_save_draw.c \
vbo/vbo_save_loopback.c 
 
-STATETRACKER_SOURCES = \
+STATETRACKER_SOURCES := \
state_tracker/st_atom.c \
state_tracker/st_atom_blend.c \
state_tracker/st_atom_clip.c \
@@ -237,7 +237,7 @@ STATETRACKER_SOURCES = \
state_tracker/st_program.c \
state_tracker/st_texture.c
 
-PROGRAM_SOURCES = \
+PROGRAM_SOURCES := \
program/arbprogparse.c \
program/hash_table.c \
program/lex.yy.c \
@@ -261,11 +261,11 @@ PROGRAM_SOURCES = \
program/symbol_table.c
 
 
-SHADER_CXX_SOURCES = \
+SHADER_CXX_SOURCES := \
program/ir_to_mesa.cpp \
program/sampler.cpp
 
-ASM_C_SOURCES =\
+ASM_C_SOURCES :=   \
x86/common_x86.c \
x86/x86_xform.c \
x86/3dnow.c \
@@ -275,7 +275,7 @@ ASM_C_SOURCES = \
ppc/common_ppc.c \
x86-64/x86-64.c
 
-X86_SOURCES =  \
+X86_SOURCES := \
x86/common_x86_asm.S\
x86/x86_xform2.S\
x86/x86_xform3.S\
@@ -294,21 +294,21 @@ X86_SOURCES = \
x86/sse_normal.S\
x86/read_rgba_span_x86.S
 
-X86-64_SOURCES =   \
+X86-64_SOURCES :=  \
x86-64/xform4.S
 
-SPARC_SOURCES =\
+SPARC_SOURCES :=   \
sparc/clip.S\
sparc/norm.S\
sparc/xform.S
 
-COMMON_DRIVER_SOURCES =\
+COMMON_DRIVER_SOURCES :=   \
drivers/common/driverfuncs.c\
drivers/common/meta.c
 
 
 # Sources for building non-Gallium drivers
-MESA_SOURCES = \
+MESA_SOURCES := \
$(MAIN_SOURCES) \
$(MATH_SOURCES) \
$(MATH_XFORM_SOURCES)   \
@@ -320,12 +320,12 @@ MESA_SOURCES = \
$(COMMON_DRIVER_SOURCES)\
$(ASM_C_SOURCES)
 
-MESA_CXX_SOURCES = \
+MESA_CXX_SOURCES := \
$(MAIN_CXX_SOURCES) \
$(SHADER_CXX_SOURCES)
 
 # Sources for 

[Mesa-dev] [PATCH 04/15] mesa/sources.mak: Cleanup include paths for Android

2011-08-04 Thread Chad Versace
Include paths for Android cannot be prefixed with -I.  So define
INCLUDE_DIRS without the -I's, and add them only if doing a non-Android
build.

Also, define TOP for Android builds.

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/sources.mak |   20 ++--
 1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index e45c99f..6800c47 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -1,5 +1,9 @@
 ### Lists of source files, included by Makefiles
 
+ifeq ($(MESA_PLATFORM), android)
+   TOP := $(MESA_TOP)
+endif
+
 # this is part of MAIN_SOURCES
 MAIN_ES_SOURCES := \
main/api_exec_es1.c \
@@ -371,9 +375,13 @@ GLSL_LIBS := \
 ### Include directories
 
 INCLUDE_DIRS := \
-   -I$(TOP)/include \
-   -I$(TOP)/src/glsl \
-   -I$(TOP)/src/mesa \
-   -I$(TOP)/src/mapi \
-   -I$(TOP)/src/gallium/include \
-   -I$(TOP)/src/gallium/auxiliary
+   $(TOP)/include \
+   $(TOP)/src/glsl \
+   $(TOP)/src/mesa \
+   $(TOP)/src/mapi \
+   $(TOP)/src/gallium/include \
+   $(TOP)/src/gallium/auxiliary
+
+ifneq ($(MESA_PLATFORM), android)
+   INCLUDE_DIRS := $(addprefix -I, $(INCLUDE_DIRS))
+endif
-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 05/15] mesa/sources.mak: Change handling of lex and yacc files for Android

2011-08-04 Thread Chad Versace
The proper way to handle lex and yacc files in Android is to include them
in the list of C and CPP files and let the build system automagically do
the right thing.

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/sources.mak |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index 6800c47..9923133 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -244,11 +244,9 @@ STATETRACKER_SOURCES := \
 PROGRAM_SOURCES := \
program/arbprogparse.c \
program/hash_table.c \
-   program/lex.yy.c \
program/nvfragparse.c \
program/nvvertparse.c \
program/program.c \
-   program/program_parse.tab.c \
program/program_parse_extra.c \
program/prog_cache.c \
program/prog_execute.c \
@@ -264,6 +262,15 @@ PROGRAM_SOURCES := \
program/register_allocate.c \
program/symbol_table.c
 
+ifeq ($(ANDROID),)
+   PROGRAM_SOURCES += \
+   program/program_parse.tab.c \
+   program/lex.yy.c
+else
+   PROGRAM_SOURCES += \
+   program/program_parse.y \
+   program/program_lexer.l
+endif # ANDROID
 
 SHADER_CXX_SOURCES := \
program/ir_to_mesa.cpp \
-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 07/15] main: Add -o option to es_generator.py

2011-08-04 Thread Chad Versace
The -o option specifies the output file.

This is to pacify the Android build system, whose built-in rules for
generated files become grumpy when shell redirection is used.

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/main/es_generator.py |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/src/mesa/main/es_generator.py b/src/mesa/main/es_generator.py
index c0b0a44..21f59b4 100644
--- a/src/mesa/main/es_generator.py
+++ b/src/mesa/main/es_generator.py
@@ -125,10 +125,11 @@ program = os.path.basename(sys.argv[0])
 verbose = 0
 functionList = APIspec.xml
 version = GLES1.1
+outputFile = None
 
 # Allow for command-line switches
 import getopt, time
-options = hvV:S:
+options = hvV:S:o:
 try:
 optlist, args = getopt.getopt(sys.argv[1:], options)
 except getopt.GetoptError, message:
@@ -145,6 +146,7 @@ for option, optarg in optlist:
 for key in VersionSpecificValues.keys():
 sys.stderr.write(%s - %s\n % (key, 
VersionSpecificValues[key]['description']))
 sys.stderr.write(-S specifies API specification file to use [%s]\n % 
functionList)
+sys.stderr.write(-o specifies output file [%s]\n)
 sys.exit(1)
 elif option == -v:
 verbose += 1
@@ -152,6 +154,8 @@ for option, optarg in optlist:
 version = optarg
 elif option == -S:
 functionList = optarg
+elif option == -o:
+outputFile = optarg
 
 # Beyond switches, we support no further command-line arguments
 if len(args)   0:
@@ -168,6 +172,10 @@ versionHeader = VersionSpecificValues[version]['header']
 versionExtHeader = VersionSpecificValues[version]['extheader']
 shortname = VersionSpecificValues[version]['shortname']
 
+# Redirect output if option -o was given.
+if outputFile is not None:
+sys.stdout = open(outputFile, 'w')
+
 # If we get to here, we're good to go.  The version parameter
 # directs GetDispatchedFunctions to only allow functions from
 # that category (version in our parlance).  This allows 
-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 08/15] mesa: Build libmesa_main for Android

2011-08-04 Thread Chad Versace
The libmesa_main.a built on Android is analagous to the libmesa.a built on
Linux.

The libname is libmesa_main, rather than libmesa, due to conventions of
the Android build system. Names of intermediate libraries should be
prefixes by the project name so to prevent naming collisions in the build
tree. (For an example, grep for `libc_` in bionic's Makefiles).

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/Android.mk |   56 +++
 1 files changed, 56 insertions(+), 0 deletions(-)
 create mode 100644 src/mesa/Android.mk

diff --git a/src/mesa/Android.mk b/src/mesa/Android.mk
new file mode 100644
index 000..11259e3
--- /dev/null
+++ b/src/mesa/Android.mk
@@ -0,0 +1,56 @@
+#
+# Copyright © 2011 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+#
+# Authors:
+# Chad Versace c...@chad-versace.us
+#
+
+# 
+#  Build libmesa_main
+# 
+
+LOCAL_PATH := $(call my-dir)
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libmesa_main
+LOCAL_MODULE_CLASS := STATIC_LIBRARIES
+
+intermediates := $(call local-intermediates-dir)
+
+# Import the following variables:
+# INCLUDE_DIRS
+# MESA_SOURCES
+# MESA_CXX_SOURCES
+# MESA_ASM_SOURCES
+include $(LOCAL_PATH)/sources.mak
+
+LOCAL_C_INCLUDES := \
+   $(INCLUDE_DIRS) \
+   $(intermediates) # For lex and yacc headers
+
+LOCAL_C_SRCS := \
+   $(addprefix $(LOCAL_PATH)/, $(MESA_SOURCES)) \
+   $(addprefix $(LOCAL_PATH)/, $(MESA_CXX_SOURCES)) \
+   $(addprefix $(LOCAL_PATH)/, $(MESA_ASM_SOURCES))
+
+include $(MESA_LOCAL_VARS)
+include $(BUILD_STATIC_LIBRARY)
-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 09/15] dri/Makefile.defines: Remove non-existent dir from include paths

2011-08-04 Thread Chad Versace
Remove src/egl/drivers/dri from SHARED_INCLUDES. That directory no longer
exists.

Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/drivers/dri/Makefile.defines |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/Makefile.defines 
b/src/mesa/drivers/dri/Makefile.defines
index 19b6de8..47a3c1b 100644
--- a/src/mesa/drivers/dri/Makefile.defines
+++ b/src/mesa/drivers/dri/Makefile.defines
@@ -27,7 +27,6 @@ SHARED_INCLUDES = \
-I$(TOP)/src/mapi \
-I$(TOP)/src/mesa \
-I$(TOP)/src/egl/main \
-   -I$(TOP)/src/egl/drivers/dri \
$(LIBDRM_CFLAGS)
 
 INCLUDES += $(API_DEFINES)
-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 10/15] dri/Makefile.defines: Convert all variables to be simply-expanded

2011-08-04 Thread Chad Versace
Convert all variables in Makefile.defines to be of the simply-expanded
flavor.

As a side-effect, OBJECTS must be moved from Makefile.defines to
Makefile.targets.

This commit is a cleanup for Android.

Rationale
-
From the GNU Make manual, Section 6.2 The Two Flavors of Variables:
There are two ways that a variable in GNU make can have a value; we
call them the two flavors of variables. The two flavors are
distinguished in how they are defined and in what they do when
expanded. [...] The first flavor of variable is a recursively expanded
variable. [...] To avoid all the problems and inconveniences of
recursively expanded variables, there is another flavor: simply
expanded variables.

There are two prominent properties of the Android build system that render
the problems and inconveniences of recursively expanded variables
fatally poisonous.
1. All components of the Android platform reside in a single source
   tree.
2. Android is built with a single, non-recursive invocation of `make`.

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/drivers/dri/Makefile.defines |   15 +--
 src/mesa/drivers/dri/Makefile.targets |5 +
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/Makefile.defines 
b/src/mesa/drivers/dri/Makefile.defines
index 47a3c1b..1ee6ce2 100644
--- a/src/mesa/drivers/dri/Makefile.defines
+++ b/src/mesa/drivers/dri/Makefile.defines
@@ -1,25 +1,18 @@
 # -*-makefile-*-
 
-COMMON_GALLIUM_SOURCES = \
+COMMON_GALLIUM_SOURCES := \
 ../common/utils.c \
 ../common/vblank.c \
 ../common/dri_util.c \
 ../common/xmlconfig.c
 
-COMMON_SOURCES = $(COMMON_GALLIUM_SOURCES) \
+COMMON_SOURCES := $(COMMON_GALLIUM_SOURCES) \
 ../../common/driverfuncs.c \
 ../common/texmem.c \
 ../common/drirenderbuffer.c
 
-INCLUDES = $(SHARED_INCLUDES) $(EXPAT_INCLUDES)
-
-OBJECTS = $(C_SOURCES:.c=.o) \
- $(CXX_SOURCES:.cpp=.o) \
- $(ASM_SOURCES:.S=.o) 
-
-
 ### Include directories
-SHARED_INCLUDES = \
+SHARED_INCLUDES := \
-I. \
-I$(TOP)/src/mesa/drivers/dri/common \
-Iserver \
@@ -29,5 +22,7 @@ SHARED_INCLUDES = \
-I$(TOP)/src/egl/main \
$(LIBDRM_CFLAGS)
 
+INCLUDES := $(SHARED_INCLUDES) $(EXPAT_INCLUDES)
 INCLUDES += $(API_DEFINES)
+
 CXXFLAGS += $(API_DEFINES)
diff --git a/src/mesa/drivers/dri/Makefile.targets 
b/src/mesa/drivers/dri/Makefile.targets
index 436b2a3..c269bfc 100644
--- a/src/mesa/drivers/dri/Makefile.targets
+++ b/src/mesa/drivers/dri/Makefile.targets
@@ -1,5 +1,10 @@
 # -*-makefile-*-
 
+OBJECTS := $(C_SOURCES:.c=.o) \
+ $(CXX_SOURCES:.cpp=.o) \
+ $(ASM_SOURCES:.S=.o)
+
+
 # RULES #
 
 .c.o:
-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 11/15] dri/Makefile.defines: Only add -Iserver to includes if the dir exists

2011-08-04 Thread Chad Versace
Without this change, the next commit breaks the i915 and i965 builds.

CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/drivers/dri/Makefile.defines |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/Makefile.defines 
b/src/mesa/drivers/dri/Makefile.defines
index 1ee6ce2..3235bdc 100644
--- a/src/mesa/drivers/dri/Makefile.defines
+++ b/src/mesa/drivers/dri/Makefile.defines
@@ -15,13 +15,16 @@ COMMON_SOURCES := $(COMMON_GALLIUM_SOURCES) \
 SHARED_INCLUDES := \
-I. \
-I$(TOP)/src/mesa/drivers/dri/common \
-   -Iserver \
-I$(TOP)/include \
-I$(TOP)/src/mapi \
-I$(TOP)/src/mesa \
-I$(TOP)/src/egl/main \
$(LIBDRM_CFLAGS)
 
+ifeq (0, $(shell test -d server; echo $?))
+   SHARED_INCLUDES += -Iserver
+endif
+
 INCLUDES := $(SHARED_INCLUDES) $(EXPAT_INCLUDES)
 INCLUDES += $(API_DEFINES)
 
-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 12/15] dri/Makefile.defines: Cleanup filepaths for Android

2011-08-04 Thread Chad Versace
Cleanup 1: Android builds out-of-source, so all paths must be absolute.

Cleanup 2: Include paths for Android cannot be prefixed with -I. (Goodbye
pkgconfig). So define SHARED_INCLUDES without the -I's, and conditionally
add them if doing a non-Android build.

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/drivers/dri/Makefile.defines |   50 +---
 1 files changed, 33 insertions(+), 17 deletions(-)

diff --git a/src/mesa/drivers/dri/Makefile.defines 
b/src/mesa/drivers/dri/Makefile.defines
index 3235bdc..71b7c7e 100644
--- a/src/mesa/drivers/dri/Makefile.defines
+++ b/src/mesa/drivers/dri/Makefile.defines
@@ -1,30 +1,46 @@
 # -*-makefile-*-
 
+ifneq ($(MESA_PLATFORM), android)
+   MESA_TOP = ../../../../..
+   LOCAL_PATH = .
+endif
+
 COMMON_GALLIUM_SOURCES := \
-../common/utils.c \
-../common/vblank.c \
-../common/dri_util.c \
-../common/xmlconfig.c
+$(MESA_TOP)/src/mesa/drivers/dri/common/utils.c \
+$(MESA_TOP)/src/mesa/drivers/dri/common/vblank.c \
+$(MESA_TOP)/src/mesa/drivers/dri/common/dri_util.c \
+$(MESA_TOP)/src/mesa/drivers/dri/common/xmlconfig.c
 
 COMMON_SOURCES := $(COMMON_GALLIUM_SOURCES) \
-../../common/driverfuncs.c \
-../common/texmem.c \
-../common/drirenderbuffer.c
+$(MESA_TOP)/src/mesa/drivers/common/driverfuncs.c \
+$(MESA_TOP)/src/mesa/drivers/dri/common/texmem.c \
+$(MESA_TOP)/src/mesa/drivers/dri/common/drirenderbuffer.c
 
 ### Include directories
 SHARED_INCLUDES := \
-   -I. \
-   -I$(TOP)/src/mesa/drivers/dri/common \
-   -I$(TOP)/include \
-   -I$(TOP)/src/mapi \
-   -I$(TOP)/src/mesa \
-   -I$(TOP)/src/egl/main \
-   $(LIBDRM_CFLAGS)
-
-ifeq (0, $(shell test -d server; echo $?))
-   SHARED_INCLUDES += -Iserver
+   $(LOCAL_PATH) \
+   $(MESA_TOP)/src/mesa/drivers/dri/common \
+   $(MESA_TOP)/include \
+   $(MESA_TOP)/src/mapi \
+   $(MESA_TOP)/src/mesa \
+   $(MESA_TOP)/src/egl/main
+
+ifeq (0, $(shell test -d $(LOCAL_PATH)/server; echo $?))
+   SHARED_INCLUDES += $(LOCAL_PATH)/server
 endif
 
+ifeq ($(MESA_PLATFORM), android)
+   SHARED_INCLUDES += \
+   $(call include-path-for drm) \
+   $(call include-path-for expat)
+else
+   SHARED_INCLUDES := $(addprefix -I,$(SHARED_INCLUDES))
+   SHARED_INCLUDES += \
+   $(LIBDRM_CFLAGS) \
+   $(EXPAT_INCLUDES)
+endif # android
+
+
 INCLUDES := $(SHARED_INCLUDES) $(EXPAT_INCLUDES)
 INCLUDES += $(API_DEFINES)
 
-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 13/15] i965: New file sources.mk

2011-08-04 Thread Chad Versace
Copy the lists of sources from the actual Makefile into sources.mk. This is
so the Makefile and (future) Android.mk can share the same lists.

In the next commit, the Makefile will include sources.mk.

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/drivers/dri/i965/sources.mk |  115 ++
 1 files changed, 115 insertions(+), 0 deletions(-)
 create mode 100644 src/mesa/drivers/dri/i965/sources.mk

diff --git a/src/mesa/drivers/dri/i965/sources.mk 
b/src/mesa/drivers/dri/i965/sources.mk
new file mode 100644
index 000..470b7f1
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/sources.mk
@@ -0,0 +1,115 @@
+I965_C_SOURCES := \
+   intel_batchbuffer.c \
+   intel_blit.c \
+   intel_buffer_objects.c \
+   intel_buffers.c \
+   intel_clear.c \
+   intel_context.c \
+   intel_decode.c \
+   intel_extensions.c \
+   intel_extensions_es2.c \
+   intel_fbo.c \
+   intel_mipmap_tree.c \
+   intel_regions.c \
+   intel_screen.c \
+   intel_span.c \
+   intel_pixel.c \
+   intel_pixel_bitmap.c \
+   intel_pixel_copy.c \
+   intel_pixel_draw.c \
+   intel_pixel_read.c \
+   intel_state.c \
+   intel_syncobj.c \
+   intel_tex.c \
+   intel_tex_copy.c \
+   intel_tex_format.c \
+   intel_tex_image.c \
+   intel_tex_layout.c \
+   intel_tex_subimage.c \
+   intel_tex_validate.c \
+   brw_cc.c \
+   brw_clip.c \
+   brw_clip_line.c \
+   brw_clip_point.c \
+   brw_clip_state.c \
+   brw_clip_tri.c \
+   brw_clip_unfilled.c \
+   brw_clip_util.c \
+   brw_context.c \
+   brw_curbe.c \
+   brw_disasm.c \
+   brw_draw.c \
+   brw_draw_upload.c \
+   brw_eu.c \
+   brw_eu_debug.c \
+   brw_eu_emit.c \
+   brw_eu_util.c \
+   brw_fallback.c \
+   brw_gs.c \
+   brw_gs_emit.c \
+   brw_gs_state.c \
+   brw_misc_state.c \
+   brw_optimize.c \
+   brw_program.c \
+   brw_queryobj.c \
+   brw_sf.c \
+   brw_sf_emit.c \
+   brw_sf_state.c \
+   brw_state_batch.c \
+   brw_state_cache.c \
+   brw_state_dump.c \
+   brw_state_upload.c \
+   brw_tex.c \
+   brw_tex_layout.c \
+   brw_urb.c \
+   brw_util.c \
+   brw_vs.c \
+   brw_vs_constval.c \
+   brw_vs_emit.c \
+   brw_vs_state.c \
+   brw_vs_surface_state.c \
+   brw_vtbl.c \
+   brw_wm.c \
+   brw_wm_debug.c \
+   brw_wm_emit.c \
+   brw_wm_fp.c \
+   brw_wm_iz.c \
+   brw_wm_pass0.c \
+   brw_wm_pass1.c \
+   brw_wm_pass2.c \
+   brw_wm_sampler_state.c \
+   brw_wm_state.c \
+   brw_wm_surface_state.c \
+   gen6_cc.c \
+   gen6_clip_state.c \
+   gen6_depthstencil.c \
+   gen6_gs_state.c \
+   gen6_sampler_state.c \
+   gen6_scissor_state.c \
+   gen6_sf_state.c \
+   gen6_urb.c \
+   gen6_viewport_state.c \
+   gen6_vs_state.c \
+   gen6_wm_state.c \
+   gen7_cc_state.c \
+   gen7_clip_state.c \
+   gen7_disable.c \
+   gen7_misc_state.c \
+   gen7_sampler_state.c \
+   gen7_sf_state.c \
+   gen7_urb.c \
+   gen7_viewport_state.c \
+   gen7_vs_state.c \
+   gen7_wm_state.c \
+   gen7_wm_surface_state.c \
+
+I965_CXX_SOURCES := \
+   brw_cubemap_normalize.cpp \
+   brw_fs.cpp \
+   brw_fs_emit.cpp \
+   brw_fs_visitor.cpp \
+   brw_fs_channel_expressions.cpp \
+   brw_fs_reg_allocate.cpp \
+   brw_fs_schedule_instructions.cpp \
+   brw_fs_vector_splitting.cpp \
+   brw_shader.cpp
-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 15/15] i965: Build libi965_dri on Android

2011-08-04 Thread Chad Versace
The driver doesn't work yet, it just builds. Currently, it's not being
linked to libdrm.

Note: This is in preparation for porting i965 to Android.
CC: Chia-I Wu o...@lunarg.com,
CC: Chih-Wei Huang cwhu...@android-x86.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
 src/mesa/Android.mk  |7 
 src/mesa/drivers/Android.mk  |1 +
 src/mesa/drivers/dri/Android.mk  |   10 +
 src/mesa/drivers/dri/i965/Android.mk |   61 ++
 4 files changed, 79 insertions(+), 0 deletions(-)
 create mode 100644 src/mesa/drivers/Android.mk
 create mode 100644 src/mesa/drivers/dri/Android.mk
 create mode 100644 src/mesa/drivers/dri/i965/Android.mk

diff --git a/src/mesa/Android.mk b/src/mesa/Android.mk
index 11259e3..76f7930 100644
--- a/src/mesa/Android.mk
+++ b/src/mesa/Android.mk
@@ -54,3 +54,10 @@ LOCAL_C_SRCS := \
 
 include $(MESA_LOCAL_VARS)
 include $(BUILD_STATIC_LIBRARY)
+
+
+# 
+#  Build drivers
+# 
+
+include $(LOCAL_PATH)/drivers/Android.mk
diff --git a/src/mesa/drivers/Android.mk b/src/mesa/drivers/Android.mk
new file mode 100644
index 000..5053e7d
--- /dev/null
+++ b/src/mesa/drivers/Android.mk
@@ -0,0 +1 @@
+include $(call all-subdir-makefiles)
diff --git a/src/mesa/drivers/dri/Android.mk b/src/mesa/drivers/dri/Android.mk
new file mode 100644
index 000..0d016f3
--- /dev/null
+++ b/src/mesa/drivers/dri/Android.mk
@@ -0,0 +1,10 @@
+#
+# Include the driver that the board requires.
+#
+# TODO: i915
+# TODO: gallium drivers
+#
+
+ifeq ($(BOARD_USES_I965), true)
+   include $(MESA_TOP)/src/mesa/drivers/dri/i965/Android.mk
+endif
diff --git a/src/mesa/drivers/dri/i965/Android.mk 
b/src/mesa/drivers/dri/i965/Android.mk
new file mode 100644
index 000..eecf28e
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/Android.mk
@@ -0,0 +1,61 @@
+#
+# Copyright © 2011 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the Software),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+#
+
+LOCAL_PATH := $(call my-dir)
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libi965_dri
+LOCAL_MODULE_CLASS := SHARED_LIBRARIES
+LOCAL_MODULE_TAGS := optional
+LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/dri
+
+# Import the following variables:
+# COMMON_SOURCES
+# SHARED_INCLUDES
+include $(MESA_TOP)/src/mesa/drivers/dri/Makefile.defines
+
+# Import the following variables:
+# I965_C_SOURCES
+# I965_CXX_SOURCES
+include $(LOCAL_PATH)/sources.mk
+I965_C_SOURCES := $(addprefix $(LOCAL_PATH)/, $(I965_C_SOURCES))
+I965_CXX_SOURCES := $(addprefix $(LOCAL_PATH)/, $(I965_CXX_SOURCES))
+
+LOCAL_C_SOURCES := \
+   $(COMMON_SOURCES) \
+   $(I965_C_SOURCES) \
+   $(I965_CXX_SOURCES)
+
+LOCAL_C_INCLUDES := \
+   $(MESA_TOP)/src/mesa/drivers/dri/intel \
+   $(SHARED_INCLUDES)
+
+# TODO: Link to libdrm once it is building on Android.
+#LOCAL_SHARED_LIBRARIES := \
+#  libdrm
+
+LOCAL_REQUIRED_MODULES := \
+   libmesa_main
+
+include $(MESA_LOCAL_VARS)
+include $(BUILD_SHARED_LIBRARY)
-- 
1.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue

2011-08-04 Thread Rudolf Polzer
On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 08/03/2011 12:11 PM, Bryan Cain wrote:
  On 08/03/2011 01:58 PM, Ian Romanick wrote:
  I think this solves the issue for the compressor and for the software
  decompressor.  I don't think this solves the problem for the
  decompressor for hardware drivers, so that may still pose a problem for
  Linux distros.
  
  Pardon my ignorance, but why do hardware drivers need a decompressor?
 
 To quote the EXT_texture_compression_s3tc spec:
 
 WARNING:  Vendors able to support S3TC texture compression in Direct3D
 drivers do not necessarily have the right to use the same
 functionality in
 OpenGL.
 
 This is the same issue that Linux distros have with ARB_texture_float
 being enabled in hardware drivers.  The hardware may implement the
 functionality, and the hardware vendor may have some license for the
 patent, but that license may not cover making the functionality
 available in Mesa.  That S3 has sued Apple is some indication that these
 licenses may have very narrow scope.

Why should exactly Mesa be the one to have IP rights then? Mesa doesn't feed
S3TC data anywhere, when using S2TC or another alternative.

Feeding self-compressed S2TC data is no issue, as it doesn't use any of the
S3TC IP. How the GPU actually decodes it, is none of Mesa's business.

Feeding precompressed data, however, is also none of Mesa's business - and
also, Mesa ALREADY does this, so if it's illegal, that's a risk Mesa already is
taking. However, Mesa doesn't know if it's feeding S3TC or S2TC data - it feeds
a data block as is. So, if anyone needs IP rights then, it's the author of the
game that comes with precompressed S3TC textures - and not the graphics driver!

Or does this cause a ridculous interpretation where Mesa COULD legally use this
interface ONLY if it verifies the bitstream of the texture to see that no S3TC
IP is used by it, or fixes it by turning S3TC into S2TC by a proper mapping
of pixel values?

At least that's my opinion (IANAL too).

Best regards,

Rudolf Polzer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] intel: Set ctx's drawbuffer according to drawables visual

2011-08-04 Thread Benjamin Franzke
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588

egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and
WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to
GL_BACK.
If a pixmap surface is created egl_dri2 will use a single buffer config,
so MakeCurrent has to adjust DrawBuffer[0] to the current drawable.
---
 src/mesa/drivers/dri/intel/intel_context.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_context.c 
b/src/mesa/drivers/dri/intel/intel_context.c
index fe8be08..0eeffc0 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
 readFb = driReadPriv-driverPrivate;
 driContextPriv-dri2.draw_stamp = driDrawPriv-dri2.stamp - 1;
 driContextPriv-dri2.read_stamp = driReadPriv-dri2.stamp - 1;
+
+ if (fb-Visual.doubleBufferMode) {
+intel-ctx.Color.DrawBuffer[0] = GL_BACK;
+ } else {
+intel-ctx.Color.DrawBuffer[0] = GL_FRONT;
+ }
   }
 
   intel_prepare_render(intel);
-- 
1.7.3.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 39813] Account request for Mesa git push access

2011-08-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=39813

Brian Paul bri...@vmware.com changed:

   What|Removed |Added

Product|Mesa|freedesktop.org
Version|git |unspecified
  Component|Other   |New Accounts
 AssignedTo|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes
   |org |ktop.org

--- Comment #2 from Brian Paul bri...@vmware.com 2011-08-04 06:22:19 PDT ---
Reassigning to admins.

-- 
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] vbo: do not call _mesa_max_buffer_index in debug builds

2011-08-04 Thread Brian Paul

On 08/03/2011 11:44 PM, Marek Olšák wrote:

That code drops performance in Unigine Heaven and Tropics
by a factor of 10. That's too crazy even for a debug build.

NOTE: This is a candidate for the 7.11 branch.
---
  src/mesa/vbo/vbo_exec_array.c |4 +---
  1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index b908d5a..32ce0e4 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -909,11 +909,10 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
if (0)
   _mesa_print_arrays(ctx);

-#ifdef DEBUG
/* 'end' was out of bounds, but now let's check the actual array
 * indexes to see if any of them are out of bounds.
 */
-  {
+  if (0) {
   GLuint max = _mesa_max_buffer_index(ctx, count, type, indices,
   
ctx-Array.ElementArrayBufferObj);
   if (max= ctx-Array.ArrayObj-_MaxElement) {
@@ -934,7 +933,6 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
* upper bound wrong.
*/
}
-#endif

/* Set 'end' to the max possible legal value */
assert(ctx-Array.ArrayObj-_MaxElement= 1);


Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] intel: Set ctx's drawbuffer according to drawables visual

2011-08-04 Thread Benjamin Franzke
2011/8/4 Brian Paul bri...@vmware.com:
 On 08/04/2011 06:31 AM, Benjamin Franzke wrote:

 Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588

 egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and
 WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to
 GL_BACK.
 If a pixmap surface is created egl_dri2 will use a single buffer config,
 so MakeCurrent has to adjust DrawBuffer[0] to the current drawable.
 ---
  src/mesa/drivers/dri/intel/intel_context.c |    6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

 diff --git a/src/mesa/drivers/dri/intel/intel_context.c
 b/src/mesa/drivers/dri/intel/intel_context.c
 index fe8be08..0eeffc0 100644
 --- a/src/mesa/drivers/dri/intel/intel_context.c
 +++ b/src/mesa/drivers/dri/intel/intel_context.c
 @@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
         readFb = driReadPriv-driverPrivate;
         driContextPriv-dri2.draw_stamp = driDrawPriv-dri2.stamp - 1;
         driContextPriv-dri2.read_stamp = driReadPriv-dri2.stamp - 1;
 +
 +         if (fb-Visual.doubleBufferMode) {
 +            intel-ctx.Color.DrawBuffer[0] = GL_BACK;
 +         } else {
 +            intel-ctx.Color.DrawBuffer[0] = GL_FRONT;
 +         }
        }

        intel_prepare_render(intel);

 This doesn't seem right to me.  We shouldn't be changing context state like
 that during a make-current() call.

 During context initialization we call _mesa_init_color() where we set
 ctx-Color.DrawBuffer[0] to either GL_BACK or GL_FRONT depending on the
 visual's double-buffer flag.  You might investigate why that's not doing the
 job.

Yea, I saw that, but the problem is it sets GL_BACK/GL_FRONT depending
on the contexts config,
which may be different from the config used for the drawable (as
described in the commit message).

So mixing configs could be defined as invalid, but its also allowed in
src/mesa/main/context.c:1324

Furthermore st/mesa also modifes the state in make_current, see
st_manager.c:781.

Any ideas where to put it instead?


 -Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600

2011-08-04 Thread Christian König
Am Donnerstag, den 04.08.2011, 13:41 +0800 schrieb fykc...@gmail.com:
 I guess that may be related with driver or DRM stack, after playback,
 my desktop corrupts
 http://dev.lemote.com/files/upload/software/temp/newmobcal1920-desktop-corrupt.png
 (Similar with -vc ffmpeg12vdpau -vo vdpau).

I've seen something very similar at the very beginning of pipe-video
development, back then it was related to some invalid offset
calculations inside the kernel module, but that was fixed long ago.

What we see here is definitely some corruption of vram wich isn't
related to video playback all together, maybe a piglit run could help
narrowing down the problem a bit.

  I don't know how close to rv670 rs780 is, but I have artifact issues with my
  rv670 that don't show with my rv790.
Not very, if I remember correctly rs780 is an igp chipset with r7xx
instruction set directly wired to the motherboard, while rv670 is an
normal PCIe card with r6xx instruction set. I was able to narrow down
your problems with the rv670 to somewhere in the instruction set
compiler, so I don't think that these two bugs are related to each
other.

  If you can get it to display I would interested what -
 
  http://www.andyqos.ukfsn.org/Pendulum.mpg
 No, this renders a corrupted playback
 http://dev.lemote.com/files/upload/software/temp/Pendulum-playback.png,
 but doesn't cause my desktop corruption.
I would bet that it has something todo with the resolution/ maximum
texture size. Try the tex3d-maxsize and fbo-maxsize tests in piglit, and
see what the outcome of this is.

Christian.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks

2011-08-04 Thread Lucas Stach
Am Mittwoch, den 03.08.2011, 22:55 -0700 schrieb Eric Anholt:
 On Wed, 27 Jul 2011 20:52:00 -0600, Brian Paul brian.e.p...@gmail.com wrote:
  On Wed, Jul 27, 2011 at 7:29 PM, Eric Anholt e...@anholt.net wrote:
   On Sat, 23 Jul 2011 11:58:22 -0600, Brian Paul brian.e.p...@gmail.com 
   wrote:
   On Sat, Jul 23, 2011 at 9:14 AM, Eric Anholt e...@anholt.net wrote:
On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul bri...@vmware.com 
wrote:
On 07/22/2011 01:32 PM, Eric Anholt wrote:
 On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paulbri...@vmware.com  
 wrote:

 I'd like to overhaul the part of Mesa related to texture memory
 reading/writing.

 OK, I'm taking a look at map-texture-image-v4.  I like what I'm 
 seeing
 overall, I just want to be sure that this isn't something that gets
 squash-merged.  There's going to be breakage, and I want to be able 
 to
 bisect into it.

 In the metaops code, please use glBufferData instead of
 glBufferSubData.  If you BufferSubData, I have to block on the GPU 
 if it
 was using that buffer already.
   
It looks like we'd have to change that in several other places too.
Can we do that change later?
   
   
 In the comments for void (*MapTextureImage), please note what the 
 units
 of rowStride are.  I see that's present in swrast later, but I 
 think the
 mtypes.h and dd.h files are used for reference a lot (I do, 
 certainly).
   
Will do.  The parameter comments in s_texture.c are out of date too.
   
   
 c029312ad62039904818a8b1765c6bcdf50044df is huge, and it doesn't 
 even
 build.  Ouch.  I think there's some room for splitting some of this 
 up
 so that we can get a nice series.
   
Where's the build breakage?  I don't remember that.
   
This was originally a long series of sometimes ugly WIP patches.  At
one point I had a git mishap and trashed some of the intermediate
patches.  I agree that splitting up this commit would be good, but it
would be a lot of work that I don't really have time for.
   
It would be great if you could do a full piglit run with the branch
and check for i965/i915 regressions.  I'm not aware of any with swrast
or gallium.  I'd help diagnose any regressions.
   
The piglit run was in bad shape and then hung the GPU, something that
piglit hasn't done for me in a long time.
   
I think I'm going to need to split up the commits to make progress.
  
   OK, I'll try to find some time to do a piglit run on my i945 and see
   what's up (I don't have a i965 handy).  I may not get to it for a few
   days though.
  
   I'm cutting up your patches into a reasonable series so that we can
   actually review and bisect the code.  So far I've run my mti-tested
   branch on snb, and mti is your code I'm rebasing onto it as I cut chunks
   out.
  
  Thanks for doing that.
  
  I found that the map-texture-image-v4 branch is missing some stuff
  that I lost during my git accident.  I think I'm nearly done restoring
  it.  I'll push it to the branch asap, maybe tonight.
 
 New mti-tested branch is up.  Splitting up commits has paid off for at
 least 3 regressions due to driver bugs so far that would have been awful
 to work out otherwise.  I'd like to land these bits before we try
 tackling the rest of this mess (particularly the move of fields to
 swrast didn't look like it was going to work for hardware driver
 fallbacks, the way it was done).  I'd also love to see some serious
 review of this code.
 
 mti-tested is not regressing on intel.
 
 radeon is down to 1 regression on the very tip commit now that I got
 some hardware -- gen-compressed-teximage fails because the GetTexImage()
 of the meta-decompressed texture returns garbage.
 
 softpipe is thoroughly regressed, probably because I missed a required
 change there.  Just noticed it tonight, will look into it next.
 
 I expect nouveau is rather broken for compressed textures, because I
 didn't catch it up to things I noticed while working on other drivers.
 I'm hoping I have some hardware that works (is gf 7600/7800 the right
 kind for this driver?), but I might not get to it before siggraph.

No, gf7xxx is nvfx generation and has only a gallium driver. To test the
vieux driver the newest card generation you could use is a geforce 4.

 
 My DRI1 system is so slow and buggy that I'm having a hard time testing
 it.  This branch shouldn't break anything there as far as I can see, but
 I'll try again on testing.  Also, we could delete a bunch of dri1 driver
 code by implementing mapteximage in them instead.
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600

2011-08-04 Thread Alex Deucher
On Thu, Aug 4, 2011 at 10:26 AM, Christian König
deathsim...@vodafone.de wrote:
 Am Donnerstag, den 04.08.2011, 13:41 +0800 schrieb fykc...@gmail.com:
 I guess that may be related with driver or DRM stack, after playback,
 my desktop corrupts
 http://dev.lemote.com/files/upload/software/temp/newmobcal1920-desktop-corrupt.png
 (Similar with -vc ffmpeg12vdpau -vo vdpau).

 I've seen something very similar at the very beginning of pipe-video
 development, back then it was related to some invalid offset
 calculations inside the kernel module, but that was fixed long ago.


Might try a newer kernel.

 What we see here is definitely some corruption of vram wich isn't
 related to video playback all together, maybe a piglit run could help
 narrowing down the problem a bit.

  I don't know how close to rv670 rs780 is, but I have artifact issues with 
  my
  rv670 that don't show with my rv790.
 Not very, if I remember correctly rs780 is an igp chipset with r7xx
 instruction set directly wired to the motherboard, while rv670 is an
 normal PCIe card with r6xx instruction set. I was able to narrow down
 your problems with the rv670 to somewhere in the instruction set
 compiler, so I don't think that these two bugs are related to each
 other.


RS780 actually has an r6xx-based (rv610) 3d core.  RS880 is also r6xx
(rv620) based.

  If you can get it to display I would interested what -
 
  http://www.andyqos.ukfsn.org/Pendulum.mpg
 No, this renders a corrupted playback
 http://dev.lemote.com/files/upload/software/temp/Pendulum-playback.png,
 but doesn't cause my desktop corruption.
 I would bet that it has something todo with the resolution/ maximum
 texture size. Try the tex3d-maxsize and fbo-maxsize tests in piglit, and
 see what the outcome of this is.

 Christian.

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] intel: Set ctx's drawbuffer according to drawables visual

2011-08-04 Thread Benjamin Franzke
2011/8/4 Brian Paul bri...@vmware.com:
 On 08/04/2011 07:39 AM, Benjamin Franzke wrote:

 2011/8/4 Brian Paulbri...@vmware.com:

 On 08/04/2011 06:31 AM, Benjamin Franzke wrote:

 Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588

 egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and
 WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to
 GL_BACK.
 If a pixmap surface is created egl_dri2 will use a single buffer config,
 so MakeCurrent has to adjust DrawBuffer[0] to the current drawable.
 ---
  src/mesa/drivers/dri/intel/intel_context.c |    6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

 diff --git a/src/mesa/drivers/dri/intel/intel_context.c
 b/src/mesa/drivers/dri/intel/intel_context.c
 index fe8be08..0eeffc0 100644
 --- a/src/mesa/drivers/dri/intel/intel_context.c
 +++ b/src/mesa/drivers/dri/intel/intel_context.c
 @@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
         readFb = driReadPriv-driverPrivate;
         driContextPriv-dri2.draw_stamp = driDrawPriv-dri2.stamp - 1;
         driContextPriv-dri2.read_stamp = driReadPriv-dri2.stamp - 1;
 +
 +         if (fb-Visual.doubleBufferMode) {
 +            intel-ctx.Color.DrawBuffer[0] = GL_BACK;
 +         } else {
 +            intel-ctx.Color.DrawBuffer[0] = GL_FRONT;
 +         }
        }

        intel_prepare_render(intel);

 This doesn't seem right to me.  We shouldn't be changing context state
 like
 that during a make-current() call.

 During context initialization we call _mesa_init_color() where we set
 ctx-Color.DrawBuffer[0] to either GL_BACK or GL_FRONT depending on the
 visual's double-buffer flag.  You might investigate why that's not doing
 the
 job.

 Yea, I saw that, but the problem is it sets GL_BACK/GL_FRONT depending
 on the contexts config,
 which may be different from the config used for the drawable (as
 described in the commit message).

 So mixing configs could be defined as invalid, but its also allowed in
 src/mesa/main/context.c:1324

 Furthermore st/mesa also modifes the state in make_current, see
 st_manager.c:781.

 Any ideas where to put it instead?

 OK, I see.  How about doing something like this instead:

 ctx-Color.DrawBuffer[0] = ctx-DrawBuffer-ColorDrawBuffer[0];

 The gl_framebuffer also carries the current drawbuffer state (since
 GL_EXT_framebuffer_object came along).  The framebuffer's state gets set
 upon creation and when glDrawBuffer() is called.

 I think this is the behaviour that I'd expect if I were alternately
 rendering to single and double-buffered windows with one context.

 What do you think?

That looks like the better solution.

I now think its not really the drivers task, to update the contexts
Draw/ReadBuffer,
so I'd put it directly into _mesa_make_current. New patch attached.

Of course this implies that the framebuffer's
ColorDrawBuffer/ColorReadBuffer is setup
properly by all drivers.
So do you think its safe to always copy those over in _mesa_make_current?

Thanks so far.

 BTW, we'd probably want to copy/update all elements of the ColorDrawBuffer[]
 array plus the ColorReadBuffer state.

 -Brian



0001-mesa-Apply-drawables-draw-readbuffers-to-context-in-.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] glsl: When linking, emit functions at the tail of the final linked program.

2011-08-04 Thread Eric Anholt
On Wed,  3 Aug 2011 17:07:42 -0700, Paul Berry stereotype...@gmail.com wrote:
 When link_functions.cpp adds a new function to the final linked
 program, it needs to add it after any global variable declarations
 that the function refers to, otherwise the IR will be invalid (because
 variable declarations must occur before variable accesses).  The
 easiest way to do that is to have the linker emit functions to the
 tail of the final linked program.
 
 The linker used to emit functions to the head of the final linked
 program, in an effort to keep callees sorted before their callers.
 However, this was not reliable: it didn't work for functions declared
 or defined in the same compilation unit as main, for diamond-shaped
 patterns in the call graph, or for some obscure cases involving
 overloaded functions.  And no code currently relies on this sort
 order.

Usually we'd swap the order of these around, so that if we have a
testcase that would hit this, you don't get extra failures when a bisect
lands on patch 1/2.


pgp1UnG58uFg3.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 06/15] main: Remove problematic #include on Android

2011-08-04 Thread Eric Anholt
On Thu,  4 Aug 2011 02:47:15 -0700, Chad Versace c...@chad-versace.us wrote:
 Remove ``#include fpu_control.h`` from compiler.h.
 
 Note: This is in preparation for porting i965 to Android.
 CC: Chia-I Wu o...@lunarg.com,
 CC: Chih-Wei Huang cwhu...@android-x86.org
 Signed-off-by: Chad Versace c...@chad-versace.us
 ---
  src/mesa/main/compiler.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
 index d736fdf..3981644 100644
 --- a/src/mesa/main/compiler.h
 +++ b/src/mesa/main/compiler.h
 @@ -45,7 +45,7 @@
  #include stdlib.h
  #include stdio.h
  #include string.h
 -#if defined(__linux__)  defined(__i386__)
 +#if defined(__linux__)  defined(__i386__)  !defined(ANDROID)
  #include fpu_control.h
  #endif
  #include float.h
 -- 
 1.7.6

I've noticed that this include is missing on my debian cross-build
environment too.  Can we tell if it's even required on linux 386 any
more?  I doesn't appear to be to me.


pgplPSV9dWTmX.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 11/15] dri/Makefile.defines: Only add -Iserver to includes if the dir exists

2011-08-04 Thread Eric Anholt
On Thu,  4 Aug 2011 02:47:20 -0700, Chad Versace c...@chad-versace.us wrote:
 Without this change, the next commit breaks the i915 and i965 builds.
 
 CC: Chia-I Wu o...@lunarg.com,
 CC: Chih-Wei Huang cwhu...@android-x86.org
 Signed-off-by: Chad Versace c...@chad-versace.us
 ---
  src/mesa/drivers/dri/Makefile.defines |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)
 
 diff --git a/src/mesa/drivers/dri/Makefile.defines 
 b/src/mesa/drivers/dri/Makefile.defines
 index 1ee6ce2..3235bdc 100644
 --- a/src/mesa/drivers/dri/Makefile.defines
 +++ b/src/mesa/drivers/dri/Makefile.defines
 @@ -15,13 +15,16 @@ COMMON_SOURCES := $(COMMON_GALLIUM_SOURCES) \
  SHARED_INCLUDES := \
   -I. \
   -I$(TOP)/src/mesa/drivers/dri/common \
 - -Iserver \
   -I$(TOP)/include \
   -I$(TOP)/src/mapi \
   -I$(TOP)/src/mesa \
   -I$(TOP)/src/egl/main \
   $(LIBDRM_CFLAGS)
  
 +ifeq (0, $(shell test -d server; echo $?))
 + SHARED_INCLUDES += -Iserver
 +endif
 +
  INCLUDES := $(SHARED_INCLUDES) $(EXPAT_INCLUDES)
  INCLUDES += $(API_DEFINES)

Or we could just shove the -Iserver down into the DRI1 drivers.


pgp1jJMnij6Qc.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] intel: Set ctx's drawbuffer according to drawables visual

2011-08-04 Thread Eric Anholt
On Thu,  4 Aug 2011 14:31:01 +0200, Benjamin Franzke 
benjaminfran...@googlemail.com wrote:
 Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588
 
 egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and
 WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to
 GL_BACK.
 If a pixmap surface is created egl_dri2 will use a single buffer config,
 so MakeCurrent has to adjust DrawBuffer[0] to the current drawable.
 ---
  src/mesa/drivers/dri/intel/intel_context.c |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)
 
 diff --git a/src/mesa/drivers/dri/intel/intel_context.c 
 b/src/mesa/drivers/dri/intel/intel_context.c
 index fe8be08..0eeffc0 100644
 --- a/src/mesa/drivers/dri/intel/intel_context.c
 +++ b/src/mesa/drivers/dri/intel/intel_context.c
 @@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
readFb = driReadPriv-driverPrivate;
driContextPriv-dri2.draw_stamp = driDrawPriv-dri2.stamp - 1;
driContextPriv-dri2.read_stamp = driReadPriv-dri2.stamp - 1;
 +
 + if (fb-Visual.doubleBufferMode) {
 +intel-ctx.Color.DrawBuffer[0] = GL_BACK;
 + } else {
 +intel-ctx.Color.DrawBuffer[0] = GL_FRONT;
 + }
}

Something touching this seems like it should live in _mesa_make_current,
not as a driver workaround.


pgpzYuxltFRgk.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] Implement HW accelerated GL_SELECT

2011-08-04 Thread Micael Dias
---
 src/mesa/SConscript  |1 +
 src/mesa/main/fbobject.c |   16 +-
 src/mesa/main/fbobject.h |6 +
 src/mesa/sources.mak |1 +
 src/mesa/state_tracker/st_cb_feedback.c  |   21 +-
 src/mesa/state_tracker/st_context.h  |   10 +
 src/mesa/state_tracker/st_draw.h |   17 +
 src/mesa/state_tracker/st_draw_select_emul.c |  468 ++
 8 files changed, 527 insertions(+), 13 deletions(-)
 create mode 100644 src/mesa/state_tracker/st_draw_select_emul.c

diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 24e2155..288b162 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -262,6 +262,7 @@ statetracker_sources = [
 'state_tracker/st_debug.c',
 'state_tracker/st_draw.c',
 'state_tracker/st_draw_feedback.c',
+'state_tracker/st_draw_select_emul.c',
 'state_tracker/st_extensions.c',
 'state_tracker/st_format.c',
 'state_tracker/st_gen_mipmap.c',
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 82eb7fb..1aea62b 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1560,8 +1560,8 @@ _mesa_IsFramebufferEXT(GLuint framebuffer)
  * (render to texture).  Call ctx-Driver.RenderTexture() for such
  * attachments.
  */
-static void
-check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb)
+void
+_mesa_check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer 
*fb)
 {
GLuint i;
ASSERT(ctx-Driver.RenderTexture);
@@ -1583,8 +1583,8 @@ check_begin_texture_render(struct gl_context *ctx, struct 
gl_framebuffer *fb)
  * If so, call ctx-Driver.FinishRenderTexture() for each texture to
  * notify the device driver that the texture image may have changed.
  */
-static void
-check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb)
+void
+_mesa_check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer 
*fb)
 {
if (is_winsys_fbo(fb))
   return; /* can't render to texture with winsys framebuffers */
@@ -1713,7 +1713,7 @@ _mesa_BindFramebufferEXT(GLenum target, GLuint 
framebuffer)
   FLUSH_VERTICES(ctx, _NEW_BUFFERS);
 
   /* check if old readbuffer was render-to-texture */
-  check_end_texture_render(ctx, oldReadFb);
+  _mesa_check_end_texture_render(ctx, oldReadFb);
 
   _mesa_reference_framebuffer(ctx-ReadBuffer, newReadFb);
}
@@ -1723,13 +1723,13 @@ _mesa_BindFramebufferEXT(GLenum target, GLuint 
framebuffer)
 
   /* check if old read/draw buffers were render-to-texture */
   if (!bindReadBuf)
- check_end_texture_render(ctx, oldReadFb);
+ _mesa_check_end_texture_render(ctx, oldReadFb);
 
   if (oldDrawFb != oldReadFb)
- check_end_texture_render(ctx, oldDrawFb);
+ _mesa_check_end_texture_render(ctx, oldDrawFb);
 
   /* check if newly bound framebuffer has any texture attachments */
-  check_begin_texture_render(ctx, newDrawFb);
+  _mesa_check_begin_texture_render(ctx, newDrawFb);
 
   _mesa_reference_framebuffer(ctx-DrawBuffer, newDrawFb);
}
diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
index 7eb2005..ca6251c 100644
--- a/src/mesa/main/fbobject.h
+++ b/src/mesa/main/fbobject.h
@@ -101,6 +101,12 @@ _mesa_is_legal_color_format(const struct gl_context *ctx, 
GLenum baseFormat);
 extern GLenum
 _mesa_base_fbo_format(struct gl_context *ctx, GLenum internalFormat);
 
+extern void
+_mesa_check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer 
*fb);
+
+extern void
+_mesa_check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer 
*fb);
+
 extern GLboolean GLAPIENTRY
 _mesa_IsRenderbufferEXT(GLuint renderbuffer);
 
diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index 4b2ec08..9af4079 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -229,6 +229,7 @@ STATETRACKER_SOURCES = \
state_tracker/st_debug.c \
state_tracker/st_draw.c \
state_tracker/st_draw_feedback.c \
+   state_tracker/st_draw_select_emul.c \
state_tracker/st_extensions.c \
state_tracker/st_format.c \
state_tracker/st_gen_mipmap.c \
diff --git a/src/mesa/state_tracker/st_cb_feedback.c 
b/src/mesa/state_tracker/st_cb_feedback.c
index 9b85a39..c96c97c 100644
--- a/src/mesa/state_tracker/st_cb_feedback.c
+++ b/src/mesa/state_tracker/st_cb_feedback.c
@@ -276,17 +276,28 @@ st_RenderMode(struct gl_context *ctx, GLenum newMode )
 {
struct st_context *st = st_context(ctx);
struct draw_context *draw = st-draw;
+   bool hw_acc_path = _mesa_getenv(MESA_HW_SELECT)  
!st-select_emul.hw_unsupported;
 
if (newMode == GL_RENDER) {
   /* restore normal VBO draw function */
   vbo_set_draw_func(ctx, st_draw_vbo);
}
else if (newMode == GL_SELECT) {
-  if (!st-selection_stage)
- st-selection_stage = draw_glselect_stage(ctx, draw);
-  

[Mesa-dev] [PATCH] Implement HW accelerated GL_SELECT

2011-08-04 Thread Micael Dias
---
 src/mesa/SConscript  |1 +
 src/mesa/main/fbobject.c |   16 +-
 src/mesa/main/fbobject.h |6 +
 src/mesa/sources.mak |1 +
 src/mesa/state_tracker/st_cb_feedback.c  |   21 +-
 src/mesa/state_tracker/st_context.h  |   10 +
 src/mesa/state_tracker/st_draw.h |   17 +
 src/mesa/state_tracker/st_draw_select_emul.c |  490 ++
 8 files changed, 549 insertions(+), 13 deletions(-)
 create mode 100644 src/mesa/state_tracker/st_draw_select_emul.c

diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 24e2155..288b162 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -262,6 +262,7 @@ statetracker_sources = [
 'state_tracker/st_debug.c',
 'state_tracker/st_draw.c',
 'state_tracker/st_draw_feedback.c',
+'state_tracker/st_draw_select_emul.c',
 'state_tracker/st_extensions.c',
 'state_tracker/st_format.c',
 'state_tracker/st_gen_mipmap.c',
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 82eb7fb..1aea62b 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1560,8 +1560,8 @@ _mesa_IsFramebufferEXT(GLuint framebuffer)
  * (render to texture).  Call ctx-Driver.RenderTexture() for such
  * attachments.
  */
-static void
-check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb)
+void
+_mesa_check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer 
*fb)
 {
GLuint i;
ASSERT(ctx-Driver.RenderTexture);
@@ -1583,8 +1583,8 @@ check_begin_texture_render(struct gl_context *ctx, struct 
gl_framebuffer *fb)
  * If so, call ctx-Driver.FinishRenderTexture() for each texture to
  * notify the device driver that the texture image may have changed.
  */
-static void
-check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb)
+void
+_mesa_check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer 
*fb)
 {
if (is_winsys_fbo(fb))
   return; /* can't render to texture with winsys framebuffers */
@@ -1713,7 +1713,7 @@ _mesa_BindFramebufferEXT(GLenum target, GLuint 
framebuffer)
   FLUSH_VERTICES(ctx, _NEW_BUFFERS);
 
   /* check if old readbuffer was render-to-texture */
-  check_end_texture_render(ctx, oldReadFb);
+  _mesa_check_end_texture_render(ctx, oldReadFb);
 
   _mesa_reference_framebuffer(ctx-ReadBuffer, newReadFb);
}
@@ -1723,13 +1723,13 @@ _mesa_BindFramebufferEXT(GLenum target, GLuint 
framebuffer)
 
   /* check if old read/draw buffers were render-to-texture */
   if (!bindReadBuf)
- check_end_texture_render(ctx, oldReadFb);
+ _mesa_check_end_texture_render(ctx, oldReadFb);
 
   if (oldDrawFb != oldReadFb)
- check_end_texture_render(ctx, oldDrawFb);
+ _mesa_check_end_texture_render(ctx, oldDrawFb);
 
   /* check if newly bound framebuffer has any texture attachments */
-  check_begin_texture_render(ctx, newDrawFb);
+  _mesa_check_begin_texture_render(ctx, newDrawFb);
 
   _mesa_reference_framebuffer(ctx-DrawBuffer, newDrawFb);
}
diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
index 7eb2005..ca6251c 100644
--- a/src/mesa/main/fbobject.h
+++ b/src/mesa/main/fbobject.h
@@ -101,6 +101,12 @@ _mesa_is_legal_color_format(const struct gl_context *ctx, 
GLenum baseFormat);
 extern GLenum
 _mesa_base_fbo_format(struct gl_context *ctx, GLenum internalFormat);
 
+extern void
+_mesa_check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer 
*fb);
+
+extern void
+_mesa_check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer 
*fb);
+
 extern GLboolean GLAPIENTRY
 _mesa_IsRenderbufferEXT(GLuint renderbuffer);
 
diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index 4b2ec08..9af4079 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -229,6 +229,7 @@ STATETRACKER_SOURCES = \
state_tracker/st_debug.c \
state_tracker/st_draw.c \
state_tracker/st_draw_feedback.c \
+   state_tracker/st_draw_select_emul.c \
state_tracker/st_extensions.c \
state_tracker/st_format.c \
state_tracker/st_gen_mipmap.c \
diff --git a/src/mesa/state_tracker/st_cb_feedback.c 
b/src/mesa/state_tracker/st_cb_feedback.c
index 9b85a39..c96c97c 100644
--- a/src/mesa/state_tracker/st_cb_feedback.c
+++ b/src/mesa/state_tracker/st_cb_feedback.c
@@ -276,17 +276,28 @@ st_RenderMode(struct gl_context *ctx, GLenum newMode )
 {
struct st_context *st = st_context(ctx);
struct draw_context *draw = st-draw;
+   bool hw_acc_path = _mesa_getenv(MESA_HW_SELECT)  
!st-select_emul.hw_unsupported;
 
if (newMode == GL_RENDER) {
   /* restore normal VBO draw function */
   vbo_set_draw_func(ctx, st_draw_vbo);
}
else if (newMode == GL_SELECT) {
-  if (!st-selection_stage)
- st-selection_stage = draw_glselect_stage(ctx, draw);
-  

Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600

2011-08-04 Thread Andy Furniss

fykc...@gmail.com wrote:


Does it work now then?

No, it renders a corrupted playback
http://dev.lemote.com/files/upload/software/temp/newmobcal1920-playback.png

I guess that may be related with driver or DRM stack, after playback,
my desktop corrupts
http://dev.lemote.com/files/upload/software/temp/newmobcal1920-desktop-corrupt.png
(Similar with -vc ffmpeg12vdpau -vo vdpau).



I don't know how close to rv670 rs780 is, but I have artifact issues with my
rv670 that don't show with my rv790.

If you can get it to display I would interested what -

http://www.andyqos.ukfsn.org/Pendulum.mpg

No, this renders a corrupted playback
http://dev.lemote.com/files/upload/software/temp/Pendulum-playback.png,
but doesn't cause my desktop corruption.


These look far worse than I see, and I get no desktop corruption, so as 
Christian says it's probably not the same issue.



mplayer -lavdopts threads=4 will use all of your cores.



That still doesn't use all CPU power(even with thread=8) according to top.


I guess a single core is maxed - press 1 (one) while top is running to 
see separate lines for each core.


By chance it seems that your big buck bunny does not work with multithread.
I don't see any difference either - probably because it's too simple, 
mediainfo shows it as using  Main@L3.1 with no CABAC


If I test with something that uses High@L5.1 and CABAC eg.

http://www.andyqos.ukfsn.org/Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv

Then I see a 3x increase between 1 and 4 threads.




With:
1. Option  SwapbuffersWait off
2. xvattr -a XV_VSYNC -v 0
3. Use metacity instead of compiz
4. mplayer -nosound -benchmark -lavdopts threads=N  -vo xv
video-test/big_buck_bunny_720p_h264.mov

threads=1 vs threads=4, the result showed little difference:
* 1 thread: 1519.509s
* 4 threads: 1486.825s
The details http://dev.lemote.com/files/upload/software/temp/thread_1.log
vs http://dev.lemote.com/files/upload/software/temp/thread_4.log


Hmm, that's really slow. I guess I am spoiled by mplayer/ffmpeg using 
asm and mmx.


Even if I force my CPUs to 800MHz I can play that stream at almost 2X speed.

Maybe it would be worth researching whether there are compile tweaks you 
can use for your arch with ffmpeg and mplayer.






___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Status of the GLSL-TGSI translator, part 2

2011-08-04 Thread Bryan Cain
On 08/04/2011 08:24 AM, Brian Paul wrote:
 On Tue, Aug 2, 2011 at 3:50 PM, Bryan Cain bryanca...@gmail.com wrote:
 On 08/02/2011 11:27 AM, Brian Paul wrote:
 On 08/01/2011 12:38 PM, Bryan Cain wrote:
 Since Mesa 7.11 is released now, I figure it's time to discuss merging
 the glsl-to-tgsi branch to master again.  The translator is more mature
 than last time.  There are no regressions that I know of on any driver.
 The code generation has improved so that it's the same as or better than
 ir_to_mesa in almost every case.

 It also will still emit TGSI integer opcodes if you change
 ctx-GLSLVersion from 120 to 130 in st_extensions.c.  Driver developers
 can use this to implement these opcodes in their drivers, since they
 will be needed for GLSL 1.30 eventually.

 Are there any objections to merging it to master now?  If there aren't,
 I'll revise some of the commit messages for correctness and wrap long
 lines since cgit doesn't do that automatically, then merge it after
 getting approval.
 Sounds OK to me.

 I was just skimming over the new stuff - it looks like
 create_color_map_texture() is duplicated in two files and could be
 shared.

 -Brian
 Yes, where should the function go and what header should it be declared
 in?  It appears to me that none of the functions in st_atom_*.c are
 declared directly in header files.
 How about st_texture.[ch]?  That's where st_texture_create() lives.

Okay, done.  Is there anything else that should be done, or is it ready
to merge to master?

Bryan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Status of the GLSL-TGSI translator, part 2

2011-08-04 Thread Brian Paul

On 08/04/2011 10:53 AM, Bryan Cain wrote:

On 08/04/2011 08:24 AM, Brian Paul wrote:

On Tue, Aug 2, 2011 at 3:50 PM, Bryan Cainbryanca...@gmail.com  wrote:

On 08/02/2011 11:27 AM, Brian Paul wrote:

On 08/01/2011 12:38 PM, Bryan Cain wrote:

Since Mesa 7.11 is released now, I figure it's time to discuss merging
the glsl-to-tgsi branch to master again.  The translator is more mature
than last time.  There are no regressions that I know of on any driver.
The code generation has improved so that it's the same as or better than
ir_to_mesa in almost every case.

It also will still emit TGSI integer opcodes if you change
ctx-GLSLVersion from 120 to 130 in st_extensions.c.  Driver developers
can use this to implement these opcodes in their drivers, since they
will be needed for GLSL 1.30 eventually.

Are there any objections to merging it to master now?  If there aren't,
I'll revise some of the commit messages for correctness and wrap long
lines since cgit doesn't do that automatically, then merge it after
getting approval.

Sounds OK to me.

I was just skimming over the new stuff - it looks like
create_color_map_texture() is duplicated in two files and could be
shared.

-Brian

Yes, where should the function go and what header should it be declared
in?  It appears to me that none of the functions in st_atom_*.c are
declared directly in header files.

How about st_texture.[ch]?  That's where st_texture_create() lives.


Okay, done.  Is there anything else that should be done, or is it ready
to merge to master?


I have no objections.

-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 00/15] i965, mesa, glapi: Build libi965_dri on Android

2011-08-04 Thread Chia-I Wu
Hi Chad,

On Thu, Aug 4, 2011 at 6:47 PM, Chad Versace c...@chad-versace.us wrote:
 This is the first step in porting i965 to Android, initially to Gingerbread.
 Android is ubiquituous now, and the platform's importance can't be denied. The
 Intel drivers really should support it.

 The series first builds libglapi, then libmesa, and then libi965_dri.
 lib965_dri doens't work yet; it doesn't even link to libdrm. This is just the
 initial work to get it to build.

 I'm aware that this may be controversial, so I've attempted to integrate the
 Android makefiles as non-disruptively as possible.
  - The Android makefiles attempt to duplicate as little as possible from the
    existing makefiles. In one case, this dictated that some Makefile code be
    extracted into a shared makefile.
  - I've avoided modifying the existsing makefiles except when absolutely
    necessary. When a modification or cleanup was necessary, I have attempted
    to keep the changes minimal and do them incrementally.
  - The locations of the Android makefiles mirror those of the existing
    makefiles.

 The series does not break the Linux i965 build. I doubt it breaks other
 drivers' builds, but I haven't tested it. If you want me to check that it
 doesn't break your build, just let me know the autoconf options.

 The series lives on my android-gingerbread-i965 branch. If you'd like to try
 the Android build yourself, you should pull from my personal Android manifest
 [1], which closely mirrors android-x86, and set `BOARD_USES_I965 := true` in
 buildspeck.mk.

 [1] repo init -u 
 git://anongit.freedesktop.git/~chadversary/android.manifeset.git -b 
 gingerbread-i965
Thanks for bringing this up and working on it.  Before commenting on
the changes to Mesa, I'd like to talk a little bit about the external
dependencies.

To have a working build of Mesa for the Android Gingerbread source
tree, these external changes are needed

 1) modify Android's init (pid 1) to create DRI device nodes under /dev
 2) make off_t 64-bit so that mmap() a GEM object works
 3) figure out how to authenticate a DRM fd
 4) add libdrm to Android source tree
 5) add drm_gralloc (the DDX driver, sort of) to Android source tree

There may be more that I cannot recall now.

Of these changes, only 3), 4), and 5) affect how Mesa is built.
It is safe to assume 4) and 5) are already there, as we have
good relationship with those projects.  But how to solve 3) is still
an open question.

We can either spend several months discussing 3) with the Android team
before landing Android support to Mesa.  Or we can assume it is
solved, land the Android support for Mesa probably over the next few
weeks, and initiate the discussion with the Android team with
something concrete.  Now that we are at this, my preference is the
latter.

Back to your changes.  I am fine with landing your version and is
willing to help review them, proivided your work won't stop after
i915/i965 is supported.  Otherwise, I prefer to prepare my version[1]
for upstreaming, which can build all actively maintained drivers
including Gallium ones.  It would also be really great you can help,
and suppose the list is fine with yet another build system for Mesa.

[1] http://cgit.freedesktop.org/~olv/mesa/log/?h=android-gingerbread-7.11

 Chad Versace (15):
  mesa: Add toplevel Android.mk
  glapi: Build libmesa_glapi on Android
  mesa/sources.mak: Convert all variables to be simply-expanded
  mesa/sources.mak: Cleanup include paths for Android
  mesa/sources.mak: Change handling of lex and yacc files for Android
  main: Remove problematic #include on Android
  main: Add -o option to es_generator.py
  mesa: Build libmesa_main for Android
  dri/Makefile.defines: Remove non-existent dir from include paths
  dri/Makefile.defines: Convert all variables to be simply-expanded
  dri/Makefile.defines: Only add -Iserver to includes if the dir exists
  dri/Makefile.defines: Cleanup filepaths for Android
  i965: New file sources.mk
  i965: Include sources.mk in Makefile
  i965: Build libi965_dri on Android

  Android.mk                            |   68 +++
  android/mesa_local_vars.mk            |   32 +
  src/Android.mk                        |    1 +
  src/mapi/Android.mk                   |    1 +
  src/mapi/shared-glapi/Android.mk      |   95 ++
  src/mesa/Android.mk                   |   63 +
  src/mesa/drivers/Android.mk           |    1 +
  src/mesa/drivers/dri/Android.mk       |   33 +
  src/mesa/drivers/dri/Makefile.defines |   61 ++---
  src/mesa/drivers/dri/Makefile.targets |    5 ++
  src/mesa/drivers/dri/i965/Android.mk  |   61 +
  src/mesa/drivers/dri/i965/Makefile    |  119 
 +
  src/mesa/drivers/dri/i965/sources.mk  |  115 +++
  src/mesa/main/compiler.h              |    2 +-
  src/mesa/main/es_generator.py         |   10 +++-
  src/mesa/sources.mak     

[Mesa-dev] [Bug 39841] New: Buffer access out-of-bounds in texcompress_rgtc_tmp.h

2011-08-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=39841

   Summary: Buffer access out-of-bounds in texcompress_rgtc_tmp.h
   Product: Mesa
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: timo.wi...@gmail.com


Cppcheck found out-of-bounds buffer access in
\mesa\main\texcompress_rgtc_tmp.h:185: acutValues.  Array size is 7, but the
loop is over 8 elements.  Found in Mesa 7.11 release.

-- 
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] glsl: empty declarations should be valid

2011-08-04 Thread Eric Anholt
On Thu,  4 Aug 2011 12:59:35 +0900, Chia-I Wu olva...@gmail.com wrote:
 From: Chia-I Wu o...@lunarg.com
 
 Unlike C++, empty declarations such as
 
   float;
 
 should be valid.  The spec is not explicit about this actually.
 
 Some apps that generate their shader sources may rely on this.  This was
 noted when porting one of them to Linux from Windows.

Ew.  Looking the GLSL 1.20 spec, I see:

statement:
declaration_statement

declaration_statement:
declaration

declaration:
init_declarator_list SEMICOLON

init_declarator_list:
single_declaration

single_declaration:
fully_specified_type
fully_specified_type IDENTIFIER

so it looks like that is actually valid code.  That's awful.


pgpfJuk23mAKh.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 39841] Buffer access out-of-bounds in texcompress_rgtc_tmp.h

2011-08-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=39841

Brian Paul bri...@vmware.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Brian Paul bri...@vmware.com 2011-08-04 14:34:59 PDT ---
Fixed with commit 1c8d079e205919b24e04efdc2421c18d03f078ff

-- 
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] Removing GLw from the main Mesa repository

2011-08-04 Thread Kenneth Graunke
Hey,

I'd like to remove libGLw from the main Mesa repository.  It never
changes, and almost noone uses it...because GL and Motif is awesome, right?

Since Debian still packages it, I pulled it into its own git repository,
preserving history, and then autotooled it.

You can get it here:
git://people.freedesktop.org/~kwg/glw

--Kenneth
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk

2011-08-04 Thread Dan Nicholson
On Thu, Aug 4, 2011 at 2:47 AM, Chad Versace c...@chad-versace.us wrote:
 This is the first step in porting libGLES* and libEGL to Android.

 The makefile doesn't build anything yet; it just defines common variables.

 The values for MESA_COMMON_C_FLAGS and MESA_COMMON_CPP_FLAGS, I obtained
 by invoking autogen.sh with the options below and then inspecting
 MESA_TOP/configs/autoconf. My immediate goal is to port i965 to Android,
 so I used the typical flags for building i965.
    --disable-gallium
    --disable-glu
    --disable-glw
    --disable-glut
    --enable-32-bit
    --enable-egl
    --enable-gles2
    --enable-gles1
    --enable-texture-float
    --with-dri-drivers=i965
    --with-gallium-drivers=

 Note: This is in preparation for porting i965 to Android.
 CC: Chia-I Wu o...@lunarg.com,
 CC: Chih-Wei Huang cwhu...@android-x86.org
 Signed-off-by: Chad Versace c...@chad-versace.us
 ---
  Android.mk                 |   66 
 
  android/mesa_local_vars.mk |   32 +
  2 files changed, 98 insertions(+), 0 deletions(-)
  create mode 100644 Android.mk
  create mode 100644 android/mesa_local_vars.mk

There's quite a bit of new build infrastructure here. What would it
take to fit this into either the existing autoconf support or add a
targeted configs/android? Duplicating a pile of make targets and
adding another way to configure/build mesa seems like it might not be
the best way to go. What are the current constraints that make
building mesa on android difficult?

--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk

2011-08-04 Thread Jose Fonseca
- Original Message -
 On Thu, Aug 4, 2011 at 2:47 AM, Chad Versace c...@chad-versace.us
 wrote:
  This is the first step in porting libGLES* and libEGL to Android.
 
  The makefile doesn't build anything yet; it just defines common
  variables.
 
  The values for MESA_COMMON_C_FLAGS and MESA_COMMON_CPP_FLAGS, I
  obtained
  by invoking autogen.sh with the options below and then inspecting
  MESA_TOP/configs/autoconf. My immediate goal is to port i965 to
  Android,
  so I used the typical flags for building i965.
     --disable-gallium
     --disable-glu
     --disable-glw
     --disable-glut
     --enable-32-bit
     --enable-egl
     --enable-gles2
     --enable-gles1
     --enable-texture-float
     --with-dri-drivers=i965
     --with-gallium-drivers=
 
  Note: This is in preparation for porting i965 to Android.
  CC: Chia-I Wu o...@lunarg.com,
  CC: Chih-Wei Huang cwhu...@android-x86.org
  Signed-off-by: Chad Versace c...@chad-versace.us
  ---
   Android.mk                 |   66
   
   android/mesa_local_vars.mk |   32 +
   2 files changed, 98 insertions(+), 0 deletions(-)
   create mode 100644 Android.mk
   create mode 100644 android/mesa_local_vars.mk
 
 There's quite a bit of new build infrastructure here. What would it
 take to fit this into either the existing autoconf support or add a
 targeted configs/android? Duplicating a pile of make targets and
 adding another way to configure/build mesa seems like it might not be
 the best way to go. What are the current constraints that make
 building mesa on android difficult?

I agree. I'd prefer not have yet another build infrastructure in the mix, 
unless there's a very good reason.

Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glsl: empty declarations should be valid

2011-08-04 Thread Chad Versace
On 08/04/2011 01:29 PM, Eric Anholt wrote:
 On Thu,  4 Aug 2011 12:59:35 +0900, Chia-I Wu olva...@gmail.com wrote:
 From: Chia-I Wu o...@lunarg.com

 Unlike C++, empty declarations such as

   float;

 should be valid.  The spec is not explicit about this actually.

 Some apps that generate their shader sources may rely on this.  This was
 noted when porting one of them to Linux from Windows.
 
 Ew.  Looking the GLSL 1.20 spec, I see:
 
 statement:
 declaration_statement
 
 declaration_statement:
 declaration
 
 declaration:
 init_declarator_list SEMICOLON
 
 init_declarator_list:
 single_declaration
 
 single_declaration:
 fully_specified_type
 fully_specified_type IDENTIFIER
 
 so it looks like that is actually valid code.  That's awful.

I first suspected that this was a spec grammar bug. But it is still present in
the GLSL 4.10 spec, so it's unlikely to be a bug.

Surprisingly, C also allows empty declarations. Compiling this
float;
int main() { return 0; }
with `gcc --std=c99` succeeds and emits this warning:
 warning: useless type name in empty declaration [enabled by default]

I hate to say this, but I believe the spec grammar intentionally allows empty
declarations. C allows it, and GLSL tries to mimic C.

Even though I don't like empty declarations, this patch is
Reviewed-by: Chad Versace c...@chad-versace.us

-- 
Chad Versace
c...@chad-versace.us



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/3] glsl: Make is_lvalue() and variable_referenced() const.

2011-08-04 Thread Chad Versace
On 08/02/2011 05:38 PM, Paul Berry wrote:
 These functions don't modify the target instruction, so it makes sense
 to make them const.  This allows these functions to be called from ir
 validation code (which uses const to ensure that it doesn't
 accidentally modify the IR being validated).
 ---
  src/glsl/ir.cpp |4 ++--
  src/glsl/ir.h   |   18 +-
  2 files changed, 11 insertions(+), 11 deletions(-)
 
 diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
 index 827fe8e..6f8676e 100644
 --- a/src/glsl/ir.cpp
 +++ b/src/glsl/ir.cpp
 @@ -1096,7 +1096,7 @@ 
 ir_dereference_record::ir_dereference_record(ir_variable *var,
  }
  
  bool
 -ir_dereference::is_lvalue()
 +ir_dereference::is_lvalue() const
  {
 ir_variable *var = this-variable_referenced();
  
 @@ -1310,7 +1310,7 @@ ir_swizzle::create(ir_rvalue *val, const char *str, 
 unsigned vector_length)
  #undef I
  
  ir_variable *
 -ir_swizzle::variable_referenced()
 +ir_swizzle::variable_referenced() const
  {
 return this-val-variable_referenced();
  }
 diff --git a/src/glsl/ir.h b/src/glsl/ir.h
 index 50a9d6e..04fa97b 100644
 --- a/src/glsl/ir.h
 +++ b/src/glsl/ir.h
 @@ -144,7 +144,7 @@ public:
  
 ir_rvalue *as_rvalue_to_saturate();
  
 -   virtual bool is_lvalue()
 +   virtual bool is_lvalue() const
 {
return false;
 }
 @@ -152,7 +152,7 @@ public:
 /**
  * Get the variable that is ultimately referenced by an r-value
  */
 -   virtual ir_variable *variable_referenced()
 +   virtual ir_variable *variable_referenced() const
 {
return NULL;
 }
 @@ -1355,7 +1355,7 @@ public:
  
 virtual ir_visitor_status accept(ir_hierarchical_visitor *);
  
 -   bool is_lvalue()
 +   bool is_lvalue() const
 {
return val-is_lvalue()  !mask.has_duplicates;
 }
 @@ -1363,7 +1363,7 @@ public:
 /**
  * Get the variable that is ultimately referenced by an r-value
  */
 -   virtual ir_variable *variable_referenced();
 +   virtual ir_variable *variable_referenced() const;
  
 ir_rvalue *val;
 ir_swizzle_mask mask;
 @@ -1387,12 +1387,12 @@ public:
return this;
 }
  
 -   bool is_lvalue();
 +   bool is_lvalue() const;
  
 /**
  * Get the variable that is ultimately referenced by an r-value
  */
 -   virtual ir_variable *variable_referenced() = 0;
 +   virtual ir_variable *variable_referenced() const = 0;
  };
  
  
 @@ -1413,7 +1413,7 @@ public:
 /**
  * Get the variable that is ultimately referenced by an r-value
  */
 -   virtual ir_variable *variable_referenced()
 +   virtual ir_variable *variable_referenced() const
 {
return this-var;
 }
 @@ -1462,7 +1462,7 @@ public:
 /**
  * Get the variable that is ultimately referenced by an r-value
  */
 -   virtual ir_variable *variable_referenced()
 +   virtual ir_variable *variable_referenced() const
 {
return this-array-variable_referenced();
 }
 @@ -1496,7 +1496,7 @@ public:
 /**
  * Get the variable that is ultimately referenced by an r-value
  */
 -   virtual ir_variable *variable_referenced()
 +   virtual ir_variable *variable_referenced() const
 {
return this-record-variable_referenced();
 }

This patch is sensible and straightforward.
Reviwed-by: Chad Versace c...@chad-versace.us

-- 
Chad Versace
c...@chad-versace.us



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/3] glsl: Perform implicit type conversions on function call out parameters.

2011-08-04 Thread Chad Versace
On 08/02/2011 05:38 PM, Paul Berry wrote:
 When an out parameter undergoes an implicit type conversion, we need
 to store it in a temporary, and then after the call completes, convert
 the resulting value.  In other words, we convert code like the
 following:
 
 void f(out int x);
 float value;
 f(value);
 
 Into IR that's equivalent to this:
 
 void f(out int x);
 float value;
 int x_converted;
 f(x_converted);
 value = float(x_converted);
 
 This transformation needs to happen during ast-to-IR convertion (as
 opposed to, say, a lowering pass), because it is invalid IR for formal
 and actual parameters to have types that don't match.

It is odd that we generate the post_call_conversions IR during ast-to-hir. It is
even more odd that we generate it in a function named match_function_by_name();
after all, it now does much more than a match.

After exploring the code, though, I discovered that match_function_by_name() is
really a misnomer. It is already doing conversion for 'in' parameters, so it
also seems the proper place to do conversion of 'out' parameters.

 
 Fixes piglit tests spec/glsl-1.20/compiler/qualifiers/out-03.vert and
 spec/glsl-1.20/execution/qualifiers/vs-out-{01,02,03}.shader_test, and
 bug 39651.

The Piglit names will need updating after you rename them. Please rename and
commit the Piglit tests before committing this patch.

 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39651
 ---
  src/glsl/ast_function.cpp |   64 +---
  1 files changed, 59 insertions(+), 5 deletions(-)
 
 diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
 index 8bcf48d..f945a94 100644
 --- a/src/glsl/ast_function.cpp
 +++ b/src/glsl/ast_function.cpp
 @@ -134,6 +134,8 @@ match_function_by_name(exec_list *instructions, const 
 char *name,
}
 }
  
 +   exec_list post_call_conversions;
 +
 if (sig != NULL) {
/* Verify that 'out' and 'inout' actual parameters are lvalues.  This
 * isn't done in ir_function::matching_signature because that function
 @@ -141,6 +143,13 @@ match_function_by_name(exec_list *instructions, const 
 char *name,
 *
 * Also, validate that 'const_in' formal parameters (an extension of 
 our
 * IR) correspond to ir_constant actual parameters.
 +   *
 +   * Also, perform implicit conversion of arguments.  Note: to
 +   * implicitly convert out parameters, we need to place them in a
 +   * temporary variable, and do the conversion after the call
 +   * takes place.  Since we haven't emitted the call yet, we'll
 +   * place the post-call conversions in a temporary exec_list, and
 +   * emit them later.
 */
exec_list_iterator actual_iter = actual_parameters-iterator();
exec_list_iterator formal_iter = sig-parameters.iterator();
 @@ -185,8 +194,50 @@ match_function_by_name(exec_list *instructions, const 
 char *name,
}
  
if (formal-type-is_numeric() || formal-type-is_boolean()) {
 - ir_rvalue *converted = convert_component(actual, formal-type);
 - actual-replace_with(converted);
 +switch (formal-mode) {
 +case ir_var_in:
 +   {
 +  ir_rvalue *converted
 + = convert_component(actual, formal-type);
 +  actual-replace_with(converted);
 +   }
 +   break;
 +case ir_var_out:
 +   if (actual-type != formal-type)
 +   {
 +  /* Create a temporary variable to hold the out
 +   * parameter.  Don't pass a hashtable to clone()
 +   * because we don't want this temporary variable to
 +   * be in scope.

This comment would be more instructive if it contained this snippet from the
commit message:

As as example, this code
void f(out int x);
float value;
f(value);
is translated into IR equivalent to
void f(out int x);
float value;
int x_converted;
f(x_converted);
value = float(x_converted);

This example goes a long way to helping someone understand how you are juggling
the IR.

 +   */
 +  ir_variable *tmp = formal-clone(ctx, NULL);
 +  tmp-mode = ir_var_auto;
 +  instructions-push_tail(tmp);
 +  ir_dereference_variable *deref_tmp_1
 + = new(ctx) ir_dereference_variable(tmp);
 +  ir_dereference_variable *deref_tmp_2
 + = new(ctx) ir_dereference_variable(tmp);
 +  ir_rvalue *converted_tmp
 + = convert_component(deref_tmp_1, actual-type);
 +  ir_assignment *assignment
 + = new(ctx) ir_assignment(actual, converted_tmp);
 +  post_call_conversions.push_tail(assignment);
 +  actual-replace_with(deref_tmp_2);

Re: [Mesa-dev] [PATCH 06/15] main: Remove problematic #include on Android

2011-08-04 Thread Chad Versace
On 08/04/2011 08:43 AM, Eric Anholt wrote:
 On Thu,  4 Aug 2011 02:47:15 -0700, Chad Versace c...@chad-versace.us wrote:
 Remove ``#include fpu_control.h`` from compiler.h.

 Note: This is in preparation for porting i965 to Android.
 CC: Chia-I Wu o...@lunarg.com,
 CC: Chih-Wei Huang cwhu...@android-x86.org
 Signed-off-by: Chad Versace c...@chad-versace.us
 ---
  src/mesa/main/compiler.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
 index d736fdf..3981644 100644
 --- a/src/mesa/main/compiler.h
 +++ b/src/mesa/main/compiler.h
 @@ -45,7 +45,7 @@
  #include stdlib.h
  #include stdio.h
  #include string.h
 -#if defined(__linux__)  defined(__i386__)
 +#if defined(__linux__)  defined(__i386__)  !defined(ANDROID)
  #include fpu_control.h
  #endif
  #include float.h
 -- 
 1.7.6
 
 I've noticed that this include is missing on my debian cross-build
 environment too.  Can we tell if it's even required on linux 386 any
 more?  I doesn't appear to be to me.

You're right. compiler.h uses no symbols from fpu_control.h.

-- 
Chad Versace
c...@chad-versace.us



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 11/15] dri/Makefile.defines: Only add -Iserver to includes if the dir exists

2011-08-04 Thread Chad Versace
On 08/04/2011 08:45 AM, Eric Anholt wrote:
 On Thu,  4 Aug 2011 02:47:20 -0700, Chad Versace c...@chad-versace.us wrote:
 Without this change, the next commit breaks the i915 and i965 builds.

 CC: Chia-I Wu o...@lunarg.com,
 CC: Chih-Wei Huang cwhu...@android-x86.org
 Signed-off-by: Chad Versace c...@chad-versace.us
 ---
  src/mesa/drivers/dri/Makefile.defines |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)

 diff --git a/src/mesa/drivers/dri/Makefile.defines 
 b/src/mesa/drivers/dri/Makefile.defines
 index 1ee6ce2..3235bdc 100644
 --- a/src/mesa/drivers/dri/Makefile.defines
 +++ b/src/mesa/drivers/dri/Makefile.defines
 @@ -15,13 +15,16 @@ COMMON_SOURCES := $(COMMON_GALLIUM_SOURCES) \
  SHARED_INCLUDES := \
  -I. \
  -I$(TOP)/src/mesa/drivers/dri/common \
 --Iserver \
  -I$(TOP)/include \
  -I$(TOP)/src/mapi \
  -I$(TOP)/src/mesa \
  -I$(TOP)/src/egl/main \
  $(LIBDRM_CFLAGS)
  
 +ifeq (0, $(shell test -d server; echo $?))
 +SHARED_INCLUDES += -Iserver
 +endif
 +
  INCLUDES := $(SHARED_INCLUDES) $(EXPAT_INCLUDES)
  INCLUDES += $(API_DEFINES)
 
 Or we could just shove the -Iserver down into the DRI1 drivers.

Agreed. I like that solution much more than my ugly make/shell hack.

-- 
Chad Versace
c...@chad-versace.us



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk

2011-08-04 Thread Chad Versace
On 08/04/2011 04:17 PM, Jose Fonseca wrote:
 - Original Message -
 On Thu, Aug 4, 2011 at 2:47 AM, Chad Versace c...@chad-versace.us
 wrote:
 This is the first step in porting libGLES* and libEGL to Android.

 The makefile doesn't build anything yet; it just defines common
 variables.

 The values for MESA_COMMON_C_FLAGS and MESA_COMMON_CPP_FLAGS, I
 obtained
 by invoking autogen.sh with the options below and then inspecting
 MESA_TOP/configs/autoconf. My immediate goal is to port i965 to
 Android,
 so I used the typical flags for building i965.
--disable-gallium
--disable-glu
--disable-glw
--disable-glut
--enable-32-bit
--enable-egl
--enable-gles2
--enable-gles1
--enable-texture-float
--with-dri-drivers=i965
--with-gallium-drivers=

 Note: This is in preparation for porting i965 to Android.
 CC: Chia-I Wu o...@lunarg.com,
 CC: Chih-Wei Huang cwhu...@android-x86.org
 Signed-off-by: Chad Versace c...@chad-versace.us
 ---
  Android.mk |   66
  
  android/mesa_local_vars.mk |   32 +
  2 files changed, 98 insertions(+), 0 deletions(-)
  create mode 100644 Android.mk
  create mode 100644 android/mesa_local_vars.mk

 There's quite a bit of new build infrastructure here. What would it
 take to fit this into either the existing autoconf support or add a
 targeted configs/android? Duplicating a pile of make targets and
 adding another way to configure/build mesa seems like it might not be
 the best way to go. What are the current constraints that make
 building mesa on android difficult?
 
 I agree. I'd prefer not have yet another build infrastructure in the mix, 
 unless there's a very good reason.
 
 Jose

I also agree. I would prefer to not add another build system to Mesa. We have
too many as it is.

To address Dan's questions, the Android build cannot be fitted into autoconf or
configs/android. I explored this option, and discovered that it was impossible.
The Android build system is... well... interesting. Allow me to explain.

The entirety of the Android project --- libc, webkit, the window manager,
*everything* --- exists in a single source tree [1]. And that source tree is
built with a single, non-recursive invocation of make. Every time I say that, I
find it hard to believe myself, so I'll say it again: The entirety of the
Android OS, all core libraries and apps, are built with a single, non-recursive
invocation of make. (The kernel is the special exception to this
all-encompassing build). The final build artifact is a bootable iso image.

[1] http://android.git.kernel.org/

Given this unified design of the Android source tree and build process, it
requires system components, such as Mesa, to be integrated into its build
system. If Mesa is going to support Android, the Android.mk's are necessary.

To address another concern of Dan's, this will not add another way to configure
the Mesa build. Android handles the system's build configuration in a single
location which is outside of Mesa.

I'm aware that the extra set of makefiles is unwelcome, but their presence will
be innocuous. The only people that will need to touch them are those maintaining
the Android build.

-- 
Chad Versace
c...@chad-versace.us



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 00/15] i965, mesa, glapi: Build libi965_dri on Android

2011-08-04 Thread Chad Versace
On 08/04/2011 11:25 AM, Chia-I Wu wrote:
 Hi Chad,
 
 On Thu, Aug 4, 2011 at 6:47 PM, Chad Versace c...@chad-versace.us wrote:
 This is the first step in porting i965 to Android, initially to Gingerbread.
 Android is ubiquituous now, and the platform's importance can't be denied. 
 The
 Intel drivers really should support it.

 The series first builds libglapi, then libmesa, and then libi965_dri.
 lib965_dri doens't work yet; it doesn't even link to libdrm. This is just the
 initial work to get it to build.

 I'm aware that this may be controversial, so I've attempted to integrate the
 Android makefiles as non-disruptively as possible.
  - The Android makefiles attempt to duplicate as little as possible from the
existing makefiles. In one case, this dictated that some Makefile code be
extracted into a shared makefile.
  - I've avoided modifying the existsing makefiles except when absolutely
necessary. When a modification or cleanup was necessary, I have attempted
to keep the changes minimal and do them incrementally.
  - The locations of the Android makefiles mirror those of the existing
makefiles.

 The series does not break the Linux i965 build. I doubt it breaks other
 drivers' builds, but I haven't tested it. If you want me to check that it
 doesn't break your build, just let me know the autoconf options.

 The series lives on my android-gingerbread-i965 branch. If you'd like to try
 the Android build yourself, you should pull from my personal Android manifest
 [1], which closely mirrors android-x86, and set `BOARD_USES_I965 := true` in
 buildspeck.mk.

 [1] repo init -u 
 git://anongit.freedesktop.git/~chadversary/android.manifeset.git -b 
 gingerbread-i965
 Thanks for bringing this up and working on it.  Before commenting on
 the changes to Mesa, I'd like to talk a little bit about the external
 dependencies.
 
 To have a working build of Mesa for the Android Gingerbread source
 tree, these external changes are needed
 
  1) modify Android's init (pid 1) to create DRI device nodes under /dev
  2) make off_t 64-bit so that mmap() a GEM object works
  3) figure out how to authenticate a DRM fd
  4) add libdrm to Android source tree
  5) add drm_gralloc (the DDX driver, sort of) to Android source tree
 
 There may be more that I cannot recall now.
 
 Of these changes, only 3), 4), and 5) affect how Mesa is built.
 It is safe to assume 4) and 5) are already there, as we have
 good relationship with those projects.  But how to solve 3) is still
 an open question.

Luckily, some key people who can help us with 3 belong to my team: the author of
Wayland, and the authors of Intel's DRM module, i915.ko. I will probe them when
we reach that bridge.

 We can either spend several months discussing 3) with the Android team
 before landing Android support to Mesa. 

I have been given a timeframe to complete this, and though I cannot discuss the
details, several months is unacceptable. The Mesa port needs to be completed
before yesterday.

 Or we can assume it is
 solved, land the Android support for Mesa probably over the next few
 weeks, and initiate the discussion with the Android team with
 something concrete.  Now that we are at this, my preference is the
 latter.

Yes. We should take the latter approach.

 Back to your changes.  I am fine with landing your version and is
 willing to help review them, proivided your work won't stop after
 i915/i965 is supported.  Otherwise, I prefer to prepare my version[1]
 for upstreaming, which can build all actively maintained drivers
 including Gallium ones.  It would also be really great you can help,
 and suppose the list is fine with yet another build system for Mesa.
 
 [1] http://cgit.freedesktop.org/~olv/mesa/log/?h=android-gingerbread-7.11

You have done a lot of work on the Mesa port, and I want to acknowledge your
expertise there. Please don't interpret my submission of this series as a
dismissal of that work. My intent in submitting my own patches was just to start
the process of getting Android support upstream, incrementally, in a public,
code-reviewed forum.

Other drivers, of course, should also be supported. I do not want to place any
obstacle in way of that goal. At each step of the review process, we should
check with each other that the approach taken is compatible with both Gallium
and non-Gallium drivers.

My work won't stop once i965 support is completed. I will continue to maintain
Android i965 for the forseeable future. I expect that we will be collaborating
on this for a long time.

-- 
Chad Versace
c...@chad-versace.us



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glsl: empty declarations should be valid

2011-08-04 Thread Chad Versace
On 08/04/2011 06:18 PM, Chad Versace wrote:
 On 08/04/2011 01:29 PM, Eric Anholt wrote:
 On Thu,  4 Aug 2011 12:59:35 +0900, Chia-I Wu olva...@gmail.com wrote:
 From: Chia-I Wu o...@lunarg.com

 Unlike C++, empty declarations such as

   float;

 should be valid.  The spec is not explicit about this actually.

 Some apps that generate their shader sources may rely on this.  This was
 noted when porting one of them to Linux from Windows.

 Ew.  Looking the GLSL 1.20 spec, I see:

 statement:
 declaration_statement

 declaration_statement:
 declaration

 declaration:
 init_declarator_list SEMICOLON

 init_declarator_list:
 single_declaration

 single_declaration:
 fully_specified_type
 fully_specified_type IDENTIFIER

 so it looks like that is actually valid code.  That's awful.
 
 I first suspected that this was a spec grammar bug. But it is still present in
 the GLSL 4.10 spec, so it's unlikely to be a bug.
 
 Surprisingly, C also allows empty declarations. Compiling this
 float;
 int main() { return 0; }
 with `gcc --std=c99` succeeds and emits this warning:
  warning: useless type name in empty declaration [enabled by default]
 
 I hate to say this, but I believe the spec grammar intentionally allows empty
 declarations. C allows it, and GLSL tries to mimic C.
 
 Even though I don't like empty declarations, this patch is
 Reviewed-by: Chad Versace c...@chad-versace.us


Also, please update the commit message to say that `gcc --std=c99` allows empty
declrations and include the appropriate quotation from the GLSL 1.20 spec's
grammar. Without that extra info, someone may stumble onto this commit and say 
WTF.

-- 
Chad Versace
c...@chad-versace.us



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 39846] New: can' t compile mesa ‘__u64’problem .

2011-08-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=39846

   Summary: can't compile mesa ‘__u64’problem.
   Product: Mesa
   Version: 7.10
  Platform: Other
OS/Version: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/X11
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: sol...@ucsd.edu


Hi, I am having trouble compiling mesa due to this problem.
I tried an internet solution of removing std=c99, but still does not work.
(http://lists.freedesktop.org/archives/mesa-users/2011-February/000197.html)

[root@localhost Mesa-7.10.3]# gmake
gmake[1]: Entering directory `/home/sol013/Mesa-7.10.3/src'
Making sources for autoconf
gmake[2]: Entering directory `/home/sol013/Mesa-7.10.3/src/mapi/glapi'
gmake[2]: `default'를 위해 할 일이 없습니다
gmake[2]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mapi/glapi'
gmake[2]: Entering directory `/home/sol013/Mesa-7.10.3/src/glsl'
gmake[2]: `default'를 위해 할 일이 없습니다
gmake[2]: Leaving directory `/home/sol013/Mesa-7.10.3/src/glsl'
gmake[2]: Entering directory `/home/sol013/Mesa-7.10.3/src/mesa'
gmake[3]: Entering directory `/home/sol013/Mesa-7.10.3/src/mesa/x86'
gmake[3]: `default'를 위해 할 일이 없습니다
gmake[3]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mesa/x86'
gmake[3]: Entering directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers'
gmake[4]: Entering directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri'
gmake[5]: Entering directory
`/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri/i810'
gmake[6]: Entering directory
`/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri/i810'
gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
-I../../../../../include -I../../../../../src/mapi -I../../../../../src/mesa
-I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
-I/usr/local/include -I/usr/local/include/libdrm-g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM
-DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DFEATURE_GL=1 
../common/utils.c -o ../common/utils.o
In file included from ../../../../../include/GL/internal/dri_interface.h:51,
 from ../common/utils.h:32,
 from ../common/utils.c:37:
/usr/local/include/libdrm/drm.h:612: error: expected specifier-qualifier-list
before ‘__u64’
/usr/local/include/libdrm/drm.h:617: error: expected specifier-qualifier-list
before ‘__u64’
In file included from /usr/local/include/libdrm/drm.h:621,
 from ../../../../../include/GL/internal/dri_interface.h:51,
 from ../common/utils.h:32,
 from ../common/utils.c:37:
/usr/local/include/libdrm/drm_mode.h:97: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:110: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:168: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:194: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:199: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:211: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:219: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:268: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:309: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:344: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:356: error: expected
specifier-qualifier-list before ‘__u64’
/usr/local/include/libdrm/drm_mode.h:369: error: expected
specifier-qualifier-list before ‘__u64’
In file included from ../../../../../include/GL/internal/dri_interface.h:51,
 from ../common/utils.h:32,
 from ../common/utils.c:37:
/usr/local/include/libdrm/drm.h:750: error: expected specifier-qualifier-list
before ‘__u64’
gmake[6]: *** [../common/utils.o] 오류 1
gmake[6]: Leaving directory
`/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri/i810'
gmake[5]: *** [lib] 오류 2
gmake[5]: Leaving directory
`/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri/i810'
gmake[4]: *** [subdirs] 오류 1
gmake[4]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri'
gmake[3]: *** [default] 오류 1
gmake[3]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers'
gmake[2]: *** [driver_subdirs] 오류 2
gmake[2]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mesa'
gmake[1]: *** [subdirs] 오류 1
gmake[1]: Leaving directory `/home/sol013/Mesa-7.10.3/src'
gmake: *** [default] 오류 1

-- 
Configure bugmail: 

[Mesa-dev] [Bug 39846] can' t compile mesa ‘__u64’problem .

2011-08-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=39846

--- Comment #1 from Michel Dänzer mic...@daenzer.net 2011-08-04 22:51:25 PDT 
---
__u64 is supposed to be defined by the userspace headers from the Linux kernel
(/usr/include/linux/, /usr/include/asm*). Where are you getting those from?

-- 
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