[Mesa-dev] [PATCH 0/6] glapi: remove gen-es

2011-08-11 Thread Chia-I Wu
Hi list,

This patch series removes the gen-es subdirectory of glapi.  In
gen-es/, there are two sets of GLAPI XMLs for GLESv1 and GLESv2
respectively, and rules to generate headers for GLES on the fly.

To be able to get rid of the two sets of GLAPI XMLs, a new python file
is added to describe the names of GLESv2 and GLESv2 entry points.
Ultimately, we want to incorporate that info into GLAPI XML.  But it
is not trivial to do.  While this solution is not perfect, it is still
far better than maintaining two more copies of GLAPI XMLs.

And to get rid of the rules for header generation, a new helper file,
glapi_gen.mk is added.  Users of glapi that need to generate the
headers on the fly is supposed to include the helper file to simplify
the task.

The last patch is not sent out due to its size.  All it does is to removes
gen-es subdirectory, which saves us

 13 files changed, 0 insertions(+), 7703 deletions(-)

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


[Mesa-dev] [PATCH 1/6] glapi: add gles_api.py

2011-08-11 Thread Chia-I Wu
From: Chia-I Wu 

Move the list of entry points belong to GLES from mapi_abi.py to a new
file.

Until we figure out how to describe the APIs an entry point belongs to
in the XML file, and how to handle the case where an entry point others
alias is missing in some APIs, this is an easier solution than
maintaining another two sets of XMLs in glapi/gen-es/.
---
 src/mapi/glapi/gen/gl_and_es_API.xml |5 +
 src/mapi/glapi/gen/gles_api.py   |  452 ++
 src/mapi/mapi/mapi_abi.py|  424 +---
 3 files changed, 464 insertions(+), 417 deletions(-)
 create mode 100644 src/mapi/glapi/gen/gles_api.py

diff --git a/src/mapi/glapi/gen/gl_and_es_API.xml 
b/src/mapi/glapi/gen/gl_and_es_API.xml
index ac7d43c..1313da0 100644
--- a/src/mapi/glapi/gen/gl_and_es_API.xml
+++ b/src/mapi/glapi/gen/gl_and_es_API.xml
@@ -3,6 +3,11 @@
 
 
 
+
+
 
 
 http://www.w3.org/2001/XInclude"/>
diff --git a/src/mapi/glapi/gen/gles_api.py b/src/mapi/glapi/gen/gles_api.py
new file mode 100644
index 000..4cde9e5
--- /dev/null
+++ b/src/mapi/glapi/gen/gles_api.py
@@ -0,0 +1,452 @@
+#!/usr/bin/env python
+
+# Mesa 3-D graphics library
+# Version:  7.12
+#
+# Copyright (C) 2011 LunarG Inc.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+#
+# Authors:
+#Chia-I Wu 
+
+# These info should be part of GLAPI XML.  Until that is possible, scripts have
+# to use tables here to filter gl_api.
+
+es1_core = (
+# OpenGL ES 1.1
+'ActiveTexture',
+'AlphaFunc',
+'AlphaFuncx',
+'BindBuffer',
+'BindTexture',
+'BlendFunc',
+'BufferData',
+'BufferSubData',
+'Clear',
+'ClearColor',
+'ClearColorx',
+'ClearDepthf',
+'ClearDepthx',
+'ClearStencil',
+'ClientActiveTexture',
+'ClipPlanef',
+'ClipPlanex',
+'Color4f',
+'Color4ub',
+'Color4x',
+'ColorMask',
+'ColorPointer',
+'CompressedTexImage2D',
+'CompressedTexSubImage2D',
+'CopyTexImage2D',
+'CopyTexSubImage2D',
+'CullFace',
+'DeleteBuffers',
+'DeleteTextures',
+'DepthFunc',
+'DepthMask',
+'DepthRangef',
+'DepthRangex',
+'Disable',
+'DisableClientState',
+'DrawArrays',
+'DrawElements',
+'Enable',
+'EnableClientState',
+'Finish',
+'Flush',
+'Fogf',
+'Fogfv',
+'Fogx',
+'Fogxv',
+'FrontFace',
+'Frustumf',
+'Frustumx',
+'GenBuffers',
+'GenTextures',
+'GetBooleanv',
+'GetBufferParameteriv',
+'GetClipPlanef',
+'GetClipPlanex',
+'GetError',
+'GetFixedv',
+'GetFloatv',
+'GetIntegerv',
+'GetLightfv',
+'GetLightxv',
+'GetMaterialfv',
+'GetMaterialxv',
+'GetPointerv',
+'GetString',
+'GetTexEnvfv',
+'GetTexEnviv',
+'GetTexEnvxv',
+'GetTexParameterfv',
+'GetTexParameteriv',
+'GetTexParameterxv',
+'Hint',
+'IsBuffer',
+'IsEnabled',
+'IsTexture',
+'Lightf',
+'Lightfv',
+'LightModelf',
+'LightModelfv',
+'LightModelx',
+'LightModelxv',
+'Lightx',
+'Lightxv',
+'LineWidth',
+'LineWidthx',
+'LoadIdentity',
+'LoadMatrixf',
+'LoadMatrixx',
+'LogicOp',
+'Materialf',
+'Materialfv',
+'Materialx',
+'Materialxv',
+'MatrixMode',
+'MultiTexCoord4f',
+'MultiTexCoord4x',
+'MultMatrixf',
+'MultMatrixx',
+'Normal3f',
+'Normal3x',
+'NormalPointer',
+'Orthof',
+'Orthox',
+'PixelStorei',
+'PointParameterf',
+'PointParameterfv',
+   

[Mesa-dev] [PATCH 2/6] glapi: add methods to filter functions

2011-08-11 Thread Chia-I Wu
From: Chia-I Wu 

add gl_api::filter_functions and gl_function::filter_entry_points to
filter out unwanted functions and entry points.
---
 src/mapi/glapi/gen/gl_XML.py |   46 +++--
 1 files changed, 39 insertions(+), 7 deletions(-)

diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
index 4d414e8..4dc2e8f 100644
--- a/src/mapi/glapi/gen/gl_XML.py
+++ b/src/mapi/glapi/gen/gl_XML.py
@@ -618,7 +618,7 @@ class gl_function( gl_item ):
# for each entry-point.  Otherwise, they may generate code
# that won't compile.
 
-   self.parameter_strings = {}
+   self.entry_point_parameters = {}
 
self.process_element( element )
 
@@ -703,12 +703,34 @@ class gl_function( gl_item ):
 
if element.children:
self.initialized = 1
-   self.parameter_strings[name] = 
create_parameter_string(parameters, 1)
+   self.entry_point_parameters[name] = parameters
else:
-   self.parameter_strings[name] = None
+   self.entry_point_parameters[name] = []
 
return
 
+   def filter_entry_points(self, entry_point_list):
+   """Filter out entry points not in entry_point_list."""
+   if not self.initialized:
+   raise RuntimeError('%s is not initialized yet' % 
self.name)
+
+   entry_points = []
+   for ent in self.entry_points:
+   if ent not in entry_point_list:
+   if ent in self.static_entry_points:
+   self.static_entry_points.remove(ent)
+   self.entry_point_parameters.pop(ent)
+   else:
+   entry_points.append(ent)
+
+   if not entry_points:
+   raise RuntimeError('%s has no entry point after 
filtering' % self.name)
+
+   self.entry_points = entry_points
+   if self.name not in entry_points:
+   # use the first remaining entry point
+   self.name = entry_points[0]
+   self.parameters = 
self.entry_point_parameters[entry_points[0]]
 
def get_images(self):
"""Return potentially empty list of input images."""
@@ -721,11 +743,11 @@ class gl_function( gl_item ):
 
def get_parameter_string(self, entrypoint = None):
if entrypoint:
-   s = self.parameter_strings[ entrypoint ]
-   if s:
-   return s
+   params = self.entry_point_parameters[ entrypoint ]
+   else:
+   params = self.parameters

-   return create_parameter_string( self.parameters, 1 )
+   return create_parameter_string( params, 1 )
 
def get_called_parameter_string(self):
p_string = ""
@@ -791,6 +813,16 @@ class gl_api:
typeexpr.create_initial_types()
return
 
+   def filter_functions(self, entry_point_list):
+   """Filter out entry points not in entry_point_list."""
+   functions_by_name = {}
+   for func in self.functions_by_name.itervalues():
+   entry_points = [ent for ent in func.entry_points if ent 
in entry_point_list]
+   if entry_points:
+   func.filter_entry_points(entry_points)
+   functions_by_name[func.name] = func
+
+   self.functions_by_name = functions_by_name
 
def process_element(self, doc):
element = doc.children
-- 
1.7.5.4

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


[Mesa-dev] [PATCH 3/6] glapi: use gl_and_es_API.xml to generate GLES headers

2011-08-11 Thread Chia-I Wu
From: Chia-I Wu 

glapi/gen-es/ defines two sets of GLAPI XMLs for OpenGL ES 1.1
(es1_API.xml) and 2.0 (es2_API.xml) respectively.  They are used to
generate dispatch.h and remap_helper.h for GLES.  Together with
gl_and_es_API.xml, we have to maintain three sets of GLAPI XMLs.

This commit makes dispatch.h and remap_helper.h for GLES be generated
from gl_and_es_API.xml.
---
 src/mapi/glapi/gen-es/Makefile |   10 ++
 src/mapi/glapi/gen/Makefile|6 ++
 src/mapi/glapi/gen/gl_table.py |   20 +++-
 src/mapi/glapi/gen/remap_helper.py |   18 --
 src/mesa/SConscript|   16 
 5 files changed, 47 insertions(+), 23 deletions(-)

diff --git a/src/mapi/glapi/gen-es/Makefile b/src/mapi/glapi/gen-es/Makefile
index bf66ec0..3fd539d 100644
--- a/src/mapi/glapi/gen-es/Makefile
+++ b/src/mapi/glapi/gen-es/Makefile
@@ -11,8 +11,8 @@ OUTPUTS :=\
 COMMON = gl_and_es_API.xml gl_XML.py glX_XML.py license.py typeexpr.py
 COMMON := $(addprefix $(GLAPI)/, $(COMMON))
 
-ES1_APIXML := es1_API.xml
-ES2_APIXML := es2_API.xml
+ES1_APIXML := $(GLAPI)/gl_and_es_API.xml
+ES2_APIXML := $(GLAPI)/gl_and_es_API.xml
 ES1_OUTPUT_DIR := $(TOP)/src/mapi/es1api
 ES2_OUTPUT_DIR := $(TOP)/src/mapi/es2api
 
@@ -37,10 +37,12 @@ shared-glapi: $(SHARED_GLAPI_OUTPUTS)
 
 $(ES1_OUTPUTS): APIXML := $(ES1_APIXML)
 $(ES1_OUTPUTS): PRINTER := es1api
+$(ES1_OUTPUTS): GLES_VER := es1
 $(ES1_OUTPUTS): $(ES1_DEPS)
 
 $(ES2_OUTPUTS): APIXML := $(ES2_APIXML)
 $(ES2_OUTPUTS): PRINTER := es2api
+$(ES2_OUTPUTS): GLES_VER := es2
 $(ES2_OUTPUTS): $(ES2_DEPS)
 
 $(SHARED_GLAPI_OUTPUTS): APIXML := $(SHARED_GLAPI_APIXML)
@@ -49,7 +51,7 @@ $(SHARED_GLAPI_OUTPUTS): $(SHARED_GLAPI_DEPS)
 
 define gen-glapi
@mkdir -p $(dir $@)
-   $(PYTHON2) $(PYTHON_FLAGS) $< -f $(APIXML) $(1) > $@
+   $(PYTHON2) $(PYTHON_FLAGS) $< -f $(APIXML) -c $(GLES_VER) $(1) > $@
 endef
 
 %/glapi_mapi_tmp.h: $(MAPI)/mapi_abi.py $(COMMON)
@@ -58,7 +60,7 @@ endef
--printer $(PRINTER) --mode lib $(GLAPI)/gl_and_es_API.xml > $@
 
 %/main/dispatch.h: $(GLAPI)/gl_table.py $(COMMON)
-   $(call gen-glapi,-c -m remap_table)
+   $(call gen-glapi,-m remap_table)
 
 %/main/remap_helper.h: $(GLAPI)/remap_helper.py $(COMMON)
$(call gen-glapi)
diff --git a/src/mapi/glapi/gen/Makefile b/src/mapi/glapi/gen/Makefile
index 3e101f3..c386b87 100644
--- a/src/mapi/glapi/gen/Makefile
+++ b/src/mapi/glapi/gen/Makefile
@@ -180,10 +180,8 @@ $(MESA_GLAPI_DIR)/glapi_sparc.S: gl_SPARC_asm.py $(COMMON)
 
 ##
 
-$(MESA_DIR)/main/enums.c: gl_enums.py $(COMMON) $(ES_API)
-   $(PYTHON2) $(PYTHON_FLAGS) $< -f gl_API.xml \
-   -f $(MESA_GLAPI_DIR)/gen-es/es1_API.xml \
-   -f $(MESA_GLAPI_DIR)/gen-es/es2_API.xml > $@
+$(MESA_DIR)/main/enums.c: gl_enums.py $(COMMON_ES)
+   $(PYTHON2) $(PYTHON_FLAGS) $< -f gl_and_es_API.xml > $@
 
 $(MESA_DIR)/main/dispatch.h: gl_table.py $(COMMON)
$(PYTHON2) $(PYTHON_FLAGS) $< -m remap_table > $@
diff --git a/src/mapi/glapi/gen/gl_table.py b/src/mapi/glapi/gen/gl_table.py
index 05979e3..2cbbd97 100644
--- a/src/mapi/glapi/gen/gl_table.py
+++ b/src/mapi/glapi/gen/gl_table.py
@@ -211,28 +211,28 @@ class PrintRemapTable(gl_XML.gl_print_base):
 
 
 def show_usage():
-   print "Usage: %s [-f input_file_name] [-m mode] [-c]" % sys.argv[0]
+   print "Usage: %s [-f input_file_name] [-m mode] [-c ver]" % sys.argv[0]
print "-m mode   Mode can be 'table' or 'remap_table'."
-   print "-cEnable compatibility with OpenGL ES."
+   print "-c verVersion can be 'es1' or 'es2'."
sys.exit(1)
 
 if __name__ == '__main__':
file_name = "gl_API.xml"
 
try:
-   (args, trail) = getopt.getopt(sys.argv[1:], "f:m:c")
+   (args, trail) = getopt.getopt(sys.argv[1:], "f:m:c:")
except Exception,e:
show_usage()
 
mode = "table"
-   es = False
+   es = None
for (arg,val) in args:
if arg == "-f":
file_name = val
elif arg == "-m":
mode = val
elif arg == "-c":
-   es = True
+   es = val
 
if mode == "table":
printer = PrintGlTable(es)
@@ -243,4 +243,14 @@ if __name__ == '__main__':
 
api = gl_XML.parse_GL_API( file_name )
 
+   if es is not None:
+   import gles_api
+
+   api_map = {
+   'es1': gles_api.es1_api,
+   'es2': gles_api.es2_api,
+   }
+
+   api.filter_functions(api_map[es])
+
printer.Print( api )
diff --git a/src/mapi/glapi/gen/remap_helper.py 
b/src/mapi/glapi/gen/remap_helper.py
index 69b8e5e..367ae24 100644
--- a/src/mapi/glapi/gen/remap_helper.py
+++ b/src/

[Mesa-dev] [PATCH 4/6] glapi: add glapi_gen.mk to help header generation

2011-08-11 Thread Chia-I Wu
From: Chia-I Wu 

glapi_gen.mk is supposed to be included by glapi users to simplify
header generation.  This commit also makes es1api, es2api, and
shared-glapi use it.
---
 src/mapi/es1api/Makefile|   25 +++--
 src/mapi/glapi/gen/glapi_gen.mk |   44 +++
 src/mapi/shared-glapi/Makefile  |9 +++
 3 files changed, 61 insertions(+), 17 deletions(-)
 create mode 100644 src/mapi/glapi/gen/glapi_gen.mk

diff --git a/src/mapi/es1api/Makefile b/src/mapi/es1api/Makefile
index aef6948..df2a681 100644
--- a/src/mapi/es1api/Makefile
+++ b/src/mapi/es1api/Makefile
@@ -34,8 +34,6 @@ ESAPI = $(ES)api
 
 GLAPI := $(TOP)/src/mapi/glapi
 MAPI := $(TOP)/src/mapi/mapi
-# directory for generated sources/headers
-GEN := glapi
 
 esapi_CPPFLAGS := \
-I$(TOP)/include \
@@ -50,7 +48,7 @@ esapi_CPPFLAGS += -DMAPI_MODE_BRIDGE
 esapi_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB) $(esapi_LIB_DEPS)
 
 .PHONY: default
-default: depend $(TOP)/$(LIB_DIR)/$(esapi_LIB_NAME)
+default: depend $(TOP)/$(LIB_DIR)/$(esapi_LIB_NAME) main/dispatch.h 
main/remap_helper.h
 
 $(TOP)/$(LIB_DIR)/$(esapi_LIB_NAME): $(esapi_OBJECTS)
$(MKLIB) -o $(esapi_LIB) -linker '$(CC)' -ldflags '$(LDFLAGS)' \
@@ -68,13 +66,17 @@ lib$(ESAPI).a: $(esapi_OBJECTS)
 $(esapi_OBJECTS): %.o: $(MAPI)/%.c
$(CC) -c $(esapi_CPPFLAGS) $(CFLAGS) $< -o $@
 
-$(esapi_SOURCES): | glapi-stamp
+$(esapi_SOURCES): glapi_mapi_tmp.h
 
-.PHONY: glapi-stamp
-glapi-stamp:
-   @# generate sources/headers
-   @$(MAKE) -C $(GLAPI)/gen-es $(ES)
-   @touch $@
+include $(GLAPI)/gen/glapi_gen.mk
+glapi_mapi_tmp.h: $(GLAPI)/gen/gl_and_es_API.xml $(glapi_mapi_deps)
+   $(call glapi_mapi_gen,$<,$(ESAPI))
+
+main/dispatch.h: $(GLAPI)/gen/gl_and_es_API.xml $(glapi_dispatch_deps)
+   $(call glapi_dispatch_gen,$<,$(ES))
+
+main/remap_helper.h: $(GLAPI)/gen/gl_and_es_API.xml $(glapi_remap_helper_deps)
+   $(call glapi_remap_helper_gen,$<,$(ES))
 
 .PHONY: clean
 clean:
@@ -83,9 +85,8 @@ clean:
-rm -f lib$(ESAPI).a
-rm -f $(esapi_OBJECTS)
-rm -f depend depend.bak
-   -rm -f glapi-stamp
-   @# clean generated sources/headers
-   @$(MAKE) -C $(GLAPI)/gen-es clean-$(ES)
+   -rm -f glapi_mapi_tmp.h
+   -rm -rf main
 
 pcedit = \
-e 's,@INSTALL_DIR@,$(INSTALL_DIR),' \
diff --git a/src/mapi/glapi/gen/glapi_gen.mk b/src/mapi/glapi/gen/glapi_gen.mk
new file mode 100644
index 000..7def303
--- /dev/null
+++ b/src/mapi/glapi/gen/glapi_gen.mk
@@ -0,0 +1,44 @@
+# Helpers for glapi header generation
+
+ifndef TOP
+$(error TOP must be defined.)
+endif
+
+glapi_common_deps := \
+   $(wildcard $(TOP)/src/mapi/glapi/gen/*.xml) \
+   $(wildcard $(TOP)/src/mapi/glapi/gen/*.py)
+
+glapi_mapi_script := $(TOP)/src/mapi/mapi/mapi_abi.py
+glapi_mapi_deps := \
+   $(glapi_mapi_script) \
+   $(glapi_common_deps)
+
+# $(1): path to an XML file
+# $(2): name of the printer
+define glapi_mapi_gen
+@mkdir -p $(dir $@)
+$(PYTHON2) $(PYTHON_FLAGS) $(glapi_mapi_script) \
+   --mode lib --printer $(2) $(1) > $@
+endef
+
+glapi_dispatch_script := $(TOP)/src/mapi/glapi/gen/gl_table.py
+glapi_dispatch_deps := $(glapi_common_deps)
+
+# $(1): path to an XML file
+# $(2): empty, es1, or es2 for entry point filtering
+define glapi_dispatch_gen
+@mkdir -p $(dir $@)
+$(PYTHON2) $(PYTHON_FLAGS) $(glapi_dispatch_script) \
+   -f $(1) -m remap_table $(if $(2),-c $(2),) > $@
+endef
+
+glapi_remap_helper_script := $(TOP)/src/mapi/glapi/gen/remap_helper.py
+glapi_remap_helper_deps := $(glapi_common_deps)
+
+# $(1): path to an XML file
+# $(2): empty, es1, or es2 for entry point filtering
+define glapi_remap_helper_gen
+@mkdir -p $(dir $@)
+$(PYTHON2) $(PYTHON_FLAGS) $(glapi_remap_helper_script) \
+   -f $(1) $(if $(2),-c $(2),) > $@
+endef
diff --git a/src/mapi/shared-glapi/Makefile b/src/mapi/shared-glapi/Makefile
index c928f82..3f3f1ef 100644
--- a/src/mapi/shared-glapi/Makefile
+++ b/src/mapi/shared-glapi/Makefile
@@ -34,17 +34,16 @@ $(glapi_OBJECTS): %.o: $(MAPI)/%.c
 
 $(glapi_SOURCES): glapi_mapi_tmp.h
 
-.PHONY: glapi_mapi_tmp.h
-glapi_mapi_tmp.h:
-   @$(MAKE) -C $(GLAPI)/gen-es shared-glapi
+include $(GLAPI)/gen/glapi_gen.mk
+glapi_mapi_tmp.h: $(GLAPI)/gen/gl_and_es_API.xml $(glapi_mapi_deps)
+   $(call glapi_mapi_gen,$<,shared-glapi)
 
 .PHONY: clean
 clean:
-rm -f $(TOP)/$(LIB_DIR)/$(GLAPI_LIB_NAME)
-rm -f $(glapi_OBJECTS)
-rm -f depend depend.bak
-   @# clean generated sources/headers
-   @$(MAKE) -C $(GLAPI)/gen-es clean-shared-glapi
+   -rm -f glapi_mapi_tmp.h
 
 install:
$(INSTALL) -d $(DESTDIR)$(INSTALL_LIB_DIR)
-- 
1.7.5.4

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


[Mesa-dev] [PATCH 5/6] glapi: generate ES dispatch headers from core mesa

2011-08-11 Thread Chia-I Wu
From: Chia-I Wu 

GLESv1 and GLESv2 have their own dispatch.h and remap_helper.h.  These
headers are only used by api_exec_es1.c and api_exec_es2.c in core mesa.
Move the rules to generate them from glapi to core mesa.
---
 src/mapi/es1api/Makefile  |9 +
 src/mesa/Makefile |   19 +++
 src/mesa/main/es_generator.py |4 ++--
 3 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/src/mapi/es1api/Makefile b/src/mapi/es1api/Makefile
index df2a681..7e29e7a 100644
--- a/src/mapi/es1api/Makefile
+++ b/src/mapi/es1api/Makefile
@@ -48,7 +48,7 @@ esapi_CPPFLAGS += -DMAPI_MODE_BRIDGE
 esapi_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB) $(esapi_LIB_DEPS)
 
 .PHONY: default
-default: depend $(TOP)/$(LIB_DIR)/$(esapi_LIB_NAME) main/dispatch.h 
main/remap_helper.h
+default: depend $(TOP)/$(LIB_DIR)/$(esapi_LIB_NAME)
 
 $(TOP)/$(LIB_DIR)/$(esapi_LIB_NAME): $(esapi_OBJECTS)
$(MKLIB) -o $(esapi_LIB) -linker '$(CC)' -ldflags '$(LDFLAGS)' \
@@ -72,12 +72,6 @@ include $(GLAPI)/gen/glapi_gen.mk
 glapi_mapi_tmp.h: $(GLAPI)/gen/gl_and_es_API.xml $(glapi_mapi_deps)
$(call glapi_mapi_gen,$<,$(ESAPI))
 
-main/dispatch.h: $(GLAPI)/gen/gl_and_es_API.xml $(glapi_dispatch_deps)
-   $(call glapi_dispatch_gen,$<,$(ES))
-
-main/remap_helper.h: $(GLAPI)/gen/gl_and_es_API.xml $(glapi_remap_helper_deps)
-   $(call glapi_remap_helper_gen,$<,$(ES))
-
 .PHONY: clean
 clean:
-rm -f $(esapi_PC)
@@ -86,7 +80,6 @@ clean:
-rm -f $(esapi_OBJECTS)
-rm -f depend depend.bak
-rm -f glapi_mapi_tmp.h
-   -rm -rf main
 
 pcedit = \
-e 's,@INSTALL_DIR@,$(INSTALL_DIR),' \
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index 88f31b6..7e011f7 100644
--- a/src/mesa/Makefile
+++ b/src/mesa/Makefile
@@ -67,6 +67,25 @@ $(DRICORE_OBJ_DIR)/%.o: %.S
 # then convenience libs (.a) and finally the device drivers:
 default: $(DEPENDS) asm_subdirs $(MESA_LIBS) $(DRICORE_LIBS) driver_subdirs
 
+GLAPI := $(TOP)/src/mapi/glapi/gen
+include $(GLAPI)/glapi_gen.mk
+
+main/api_exec_es1_dispatch.h: $(GLAPI)/gl_and_es_API.xml $(glapi_dispatch_deps)
+   $(call glapi_dispatch_gen,$<,es1)
+
+main/api_exec_es1_remap_helper.h: $(GLAPI)/gl_and_es_API.xml 
$(glapi_remap_helper_deps)
+   $(call glapi_remap_helper_gen,$<,es1)
+
+main/api_exec_es1.o: main/api_exec_es1_dispatch.h 
main/api_exec_es1_remap_helper.h 
+
+main/api_exec_es2_dispatch.h: $(GLAPI)/gl_and_es_API.xml $(glapi_dispatch_deps)
+   $(call glapi_dispatch_gen,$<,es2)
+
+main/api_exec_es2_remap_helper.h: $(GLAPI)/gl_and_es_API.xml 
$(glapi_remap_helper_deps)
+   $(call glapi_remap_helper_gen,$<,es2)
+
+main/api_exec_es2.o: main/api_exec_es2_dispatch.h 
main/api_exec_es2_remap_helper.h 
+
 main/api_exec_es1.c: main/APIspec.xml main/es_generator.py main/APIspecutil.py 
main/APIspec.py
$(PYTHON2) $(PYTHON_FLAGS) main/es_generator.py -S main/APIspec.xml -V 
GLES1.1 > $@
 
diff --git a/src/mesa/main/es_generator.py b/src/mesa/main/es_generator.py
index c0b0a44..cad3dea 100644
--- a/src/mesa/main/es_generator.py
+++ b/src/mesa/main/es_generator.py
@@ -681,10 +681,10 @@ print """
 #if FEATURE_remap_table
 
 /* define esLocalRemapTable */
-#include "%sapi/main/dispatch.h"
+#include "main/api_exec_%s_dispatch.h"
 
 #define need_MESA_remap_table
-#include "%sapi/main/remap_helper.h"
+#include "main/api_exec_%s_remap_helper.h"
 
 static void
 init_remap_table(void)
-- 
1.7.5.4

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


[Mesa-dev] Re : [PATCH] Var packer optimisation.

2011-08-11 Thread Vincent Lejeune
Thanks for your reviews.

I'm taking note of your comments and I will have a new patch soon.
(btw, I must apologize because I forgot to add a commit when rebasing, so this 
new patch didn't have function comments to explain their role, and "break;" 
where not pushed t)



- Mail original -
> De : Paul Berry 
> À : Vincent Lejeune 
> Cc : mesa-dev@lists.freedesktop.org
> Envoyé le : Mercredi 10 Août 2011 22h04
> Objet : Re: [Mesa-dev] [PATCH] Var packer optimisation.
> 
> On 9 August 2011 14:19, Vincent Lejeune  wrote:
>>  From: vlj 
>> 
>>  This optimisation pass will look for and pack together vector (up to vec3) 
> and scalar in function body. It only concerns local variable, not temporary 
> which should however be packed as a side effect. It should reduce register 
> pressure.
>>  ---
>>   src/glsl/Makefile               |    1 +
>>   src/glsl/glsl_parser_extras.cpp |    1 +
>>   src/glsl/ir_optimization.h      |    1 +
>>   src/glsl/opt_var_packer.cpp     |  309 
> +++
>>   4 files changed, 312 insertions(+), 0 deletions(-)
>>   create mode 100644 src/glsl/opt_var_packer.cpp
>> 
>>  diff --git a/src/glsl/Makefile b/src/glsl/Makefile
>>  index 4100414..fff0dc7 100644
>>  --- a/src/glsl/Makefile
>>  +++ b/src/glsl/Makefile
>>  @@ -83,6 +83,7 @@ CXX_SOURCES = \
>>         opt_structure_splitting.cpp \
>>         opt_swizzle_swizzle.cpp \
>>         opt_tree_grafting.cpp \
>>  +       opt_var_packer.cpp \
>>         s_expression.cpp
>> 
>>   LIBS = \
>>  diff --git a/src/glsl/glsl_parser_extras.cpp 
> b/src/glsl/glsl_parser_extras.cpp
>>  index d9aa300..3b0e84a 100644
>>  --- a/src/glsl/glsl_parser_extras.cpp
>>  +++ b/src/glsl/glsl_parser_extras.cpp
>>  @@ -776,6 +776,7 @@ do_common_optimization(exec_list *ir, bool linked, 
> unsigned max_unroll_iteration
>>   {
>>     GLboolean progress = GL_FALSE;
>> 
>>  +   progress = do_var_packing(ir) || progress;
>>     progress = lower_instructions(ir, SUB_TO_ADD_NEG) || progress;
>> 
>>     if (linked) {
> 
> This optimization pass shouldn't come at the top of
> do_common_optimization, since it has the potential to decrease the
> effectiveness of  optimizations that follow.  For example, if it packs
> a dead variable with a live one, then dead code elimination won't be
> able to eliminate the dead variable any more.  I think it may
> interfere with constant propagation and algebraic simplification too,
> but I'm less certain of that.
> 
>>  diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
>>  index dd26567..83d124f 100644
>>  --- a/src/glsl/ir_optimization.h
>>  +++ b/src/glsl/ir_optimization.h
>>  @@ -71,3 +71,4 @@ bool lower_variable_index_to_cond_assign(exec_list 
> *instructions,
>>      bool lower_input, bool lower_output, bool lower_temp, bool 
> lower_uniform);
>>   bool lower_quadop_vector(exec_list *instructions, bool dont_lower_swz);
>>   bool optimize_redundant_jumps(exec_list *instructions);
>>  +bool do_var_packing(exec_list *instructions);
>>  diff --git a/src/glsl/opt_var_packer.cpp b/src/glsl/opt_var_packer.cpp
>>  new file mode 100644
>>  index 000..e7d0638
>>  --- /dev/null
>>  +++ b/src/glsl/opt_var_packer.cpp
>>  @@ -0,0 +1,309 @@
>>  +/*
>>  + * Copyright © 2011 Vincent Lejeune
>>  + *
>>  + * 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.
>>  + */
>>  +
>>  +#include "ir.h"
>>  +#include "ir_hierarchical_visitor.h"
>>  +#include "ir_rvalue_visitor.h"
>>  +#include 
>>  +
>>  +class box : public exec_node
>>  +{
>>  +public:
>>  +   void* content;
>>  +   box(void* c):content(c)
>>  +   {
>>  +
>>  +   }
>>  +};
>>  +
>>  +
>>  +
>>  +class boxed_exec_list : public exec_list
>>  +{
>>  +public:
>>  +   void push_tail(void *n)
>>  +   {
>>  +      box* b = new (this) box(n);
>>  +      exec_list::push_tail(b);
>>  +   }
>>  +
>> 

Re: [Mesa-dev] [PATCH 0/6] glapi: remove gen-es

2011-08-11 Thread Brian Paul
On Thu, Aug 11, 2011 at 3:44 AM, Chia-I Wu  wrote:
> Hi list,
>
> This patch series removes the gen-es subdirectory of glapi.  In
> gen-es/, there are two sets of GLAPI XMLs for GLESv1 and GLESv2
> respectively, and rules to generate headers for GLES on the fly.
>
> To be able to get rid of the two sets of GLAPI XMLs, a new python file
> is added to describe the names of GLESv2 and GLESv2 entry points.
> Ultimately, we want to incorporate that info into GLAPI XML.  But it
> is not trivial to do.  While this solution is not perfect, it is still
> far better than maintaining two more copies of GLAPI XMLs.
>
> And to get rid of the rules for header generation, a new helper file,
> glapi_gen.mk is added.  Users of glapi that need to generate the
> headers on the fly is supposed to include the helper file to simplify
> the task.
>
> The last patch is not sent out due to its size.  All it does is to removes
> gen-es subdirectory, which saves us
>
>  13 files changed, 0 insertions(+), 7703 deletions(-)
>
> Please review.

I skimmed over the patches and the look OK to me.  But you might want
to wait a day to see if anyone else comments.

Reviewed-by: Brian Paul 

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


Re: [Mesa-dev] [PATCH] swrast: initial multi-threaded span rendering

2011-08-11 Thread Brian Paul
These patches don't look too intrusive so I'm OK with them.  I'll 
apply them, test and push.


I've been meaning to write a new OSMesa interface for gallium for some 
time now.  That would probably be useful to a few people.


I'm tempted to redesign the OSMesa API a bit, but it's probably more 
important to keep it unchanged for the sake of existing apps.


-Brian


On 08/10/2011 03:49 AM, Andreas Fänger wrote:

Hi Keith,

you are right. The main purpose of this patch is to speedup osmesa rendering as 
there is no llvmpipe target at the moment. Also llvmpipe is currently missing 
some important features like aa/fsaa and anisotropic filtering, which is 
available in swrast now.
So I need to stick with the old rasterizer at the moment, with some 
improvements.

Andreas

-Ursprüngliche Nachricht-
Von: Keith Whitwell [mailto:kei...@vmware.com]
Gesendet: Mittwoch, 10. August 2011 11:17
An: Andreas Fänger
Cc: mesa-dev@lists.freedesktop.org
Betreff: Re: [Mesa-dev] [PATCH] swrast: initial multi-threaded span rendering

I'm not sure it makes a lot of sense to be optimizing swrast at this
stage.  Take a look at llvmpipe and perhaps consider improving the
multithreading already in place in that rasterizer, which is far better
optimized than swrast already.

Keith

On Wed, 2011-08-10 at 08:07 +, Andreas Fänger wrote:

Optional parallel rendering of spans using OpenMP.
Initial implementation for aa triangles. A new option for scons is
also provided to activate the openmp support (off by default).
---
  common.py  |1 +
  scons/gallium.py   |   12 +++
  src/mesa/swrast/s_aatritemp.h  |   68 ++-
  src/mesa/swrast/s_context.c|   26 ---
  src/mesa/swrast/s_texcombine.c |4 ++
  src/mesa/tnl/t_pipeline.c  |   12 +++
  6 files changed, 87 insertions(+), 36 deletions(-)

diff --git a/common.py b/common.py
index 8657030..cfee1b5 100644
--- a/common.py
+++ b/common.py
@@ -88,6 +88,7 @@ def AddOptions(opts):
opts.Add('toolchain', 'compiler toolchain', default_toolchain)
opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support', 
'no'))
opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
+   opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp 
(swrast)', 'no'))
opts.Add(BoolOption('debug', 'DEPRECATED: debug build', 'yes'))
opts.Add(BoolOption('profile', 'DEPRECATED: profile build', 'no'))
opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
diff --git a/scons/gallium.py b/scons/gallium.py
index 8cd3bc7..7135251 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -596,6 +596,18 @@ def generate(env):
  libs += ['m', 'pthread', 'dl']
  env.Append(LIBS = libs)

+# OpenMP
+if env['openmp']:
+if env['msvc']:
+env.Append(CCFLAGS = ['/openmp'])
+# When building openmp release VS2008 link.exe crashes with 
LNK1103 error.
+# Workaround: overwrite PDB flags with empty value as it isn't 
required anyways
+if env['build'] == 'release':
+env['PDB'] = ''
+if env['gcc']:
+env.Append(CCFLAGS = ['-fopenmp'])
+env.Append(LIBS = ['gomp'])
+
  # Load tools
  env.Tool('lex')
  env.Tool('yacc')
diff --git a/src/mesa/swrast/s_aatritemp.h b/src/mesa/swrast/s_aatritemp.h
index 91d4f7a..005d12c 100644
--- a/src/mesa/swrast/s_aatritemp.h
+++ b/src/mesa/swrast/s_aatritemp.h
@@ -181,13 +181,18 @@
const GLfloat *pMax = vMax->attrib[FRAG_ATTRIB_WPOS];
const GLfloat dxdy = majDx / majDy;
const GLfloat xAdj = dxdy<  0.0F ? -dxdy : 0.0F;
-  GLfloat x = pMin[0] - (yMin - iyMin) * dxdy;
GLint iy;
-  for (iy = iyMin; iy<  iyMax; iy++, x += dxdy) {
+  #pragma omp parallel for schedule(dynamic) private(iy) firstprivate(span)
+  for (iy = iyMin; iy<  iyMax; iy++) {
+ GLfloat x = pMin[0] - (yMin - iy) * dxdy;
   GLint ix, startX = (GLint) (x - xAdj);
   GLuint count;
   GLfloat coverage = 0.0F;

+#ifdef _OPENMP
+ /* each thread needs to use a different (global) SpanArrays variable 
*/
+ span.array = SWRAST_CONTEXT(ctx)->SpanArrays + omp_get_thread_num();
+#endif
   /* skip over fragments with zero coverage */
   while (startX<  MAX_WIDTH) {
  coverage = compute_coveragef(pMin, pMid, pMax, startX, iy);
@@ -228,13 +233,12 @@
  coverage = compute_coveragef(pMin, pMid, pMax, ix, iy);
   }

- if (ix<= startX)
-continue;
-
- span.x = startX;
- span.y = iy;
- span.end = (GLuint) ix - (GLuint) startX;
- _swrast_write_rgba_span(ctx,&span);
+ if (ix>  startX) {
+span.x = startX;
+span.y = iy;
+span.end = (GLuint) ix - (GLuint) startX;
+_swrast_write_rgba_span(ctx,&span);
+ }

[Mesa-dev] GPL'd vl_mpeg12_bitstream.c

2011-08-11 Thread Younes Manton
It's been brought to my attention that the source this is based on is
GPL'd, which means it needs to go before 7.12 is released since it's
incompatible with Mesa's MIT license.
___
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-11 Thread Ian Romanick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/04/2011 06:29 AM, Brian Paul wrote:
> 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.

This entire approach is wrong, and it will break GLX.  Page 28 (page 34
of the PDF) of the GLX 1.4 spec says (emphasis mine):

No error will be generated if the value of GL DRAW BUFFER in ctx
indicates a color buffer that is not supported by draw. In this
case, *all rendering will behave as if GL DRAW BUFFER was set to
NONE.* Also, no error will be generated if the value of GL READ
BUFFER in ctx does not correspond to a valid color buffer. Instead,
when an operation that reads from the color buffer is executed
(e.g., glReadPixels or glCopyPixels), the pixel values used will be
undefined until GL READ BUFFER is set to a color buffer that is
valid in read. Operations that query the value of GL READ BUFFER or
GL DRAW BUFFER (i.e., glGet, glPushAttrib) use the value set last
in the context, independent of whether it is a valid buffer in read
or draw.

Page 217 of the GL 3.3 spec says:

For the default framebuffer, in the initial state the draw buffer
for fragment color zero is BACK if there is a back buffer; FRONT
if there is no back buffer; and NONE if no default framebuffer is
associated with the context.

This seems a little ambiguous and perhaps in conflict with the GLX text.
 I think the right answer is that the context draw buffer (and read
buffer) setting is initialized based on the drawable the first time the
context is bound.  It seems like just changing _mesa_init_color to use
the double-buffer setting from the drawable (instead of the context)
should be sufficient.

I'm putting together a couple piglit GLX tests to exercise this.  I
don't plan to send them to the piglit list until I can test them on a
non-Mesa driver.  Since I'm still at SIGGRAPH, that won't be until next
week.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk5EDMkACgkQX1gOwKyEAw8vVACeMghE21gtQMYJgAkWXBDmz5zB
qgkAnRLyvNKzJwJuQTx1Yk4v7hLeohfz
=XZUQ
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2011-08-11 Thread Brian Paul

On 08/11/2011 11:09 AM, Ian Romanick wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/04/2011 06:29 AM, Brian Paul wrote:

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.


This entire approach is wrong, and it will break GLX.  Page 28 (page 34
of the PDF) of the GLX 1.4 spec says (emphasis mine):

 No error will be generated if the value of GL DRAW BUFFER in ctx
 indicates a color buffer that is not supported by draw. In this
 case, *all rendering will behave as if GL DRAW BUFFER was set to
 NONE.* Also, no error will be generated if the value of GL READ
 BUFFER in ctx does not correspond to a valid color buffer. Instead,
 when an operation that reads from the color buffer is executed
 (e.g., glReadPixels or glCopyPixels), the pixel values used will be
 undefined until GL READ BUFFER is set to a color buffer that is
 valid in read. Operations that query the value of GL READ BUFFER or
 GL DRAW BUFFER (i.e., glGet, glPushAttrib) use the value set last
 in the context, independent of whether it is a valid buffer in read
 or draw.

Page 217 of the GL 3.3 spec says:

 For the default framebuffer, in the initial state the draw buffer
 for fragment color zero is BACK if there is a back buffer; FRONT
 if there is no back buffer; and NONE if no default framebuffer is
 associated with the context.

This seems a little ambiguous and perhaps in conflict with the GLX text.
  I think the right answer is that the context draw buffer (and read
buffer) setting is initialized based on the drawable the first time the
context is bound.  It seems like just changing _mesa_init_color to use
the double-buffer setting from the drawable (instead of the context)
should be sufficient.


Yeah, this is all a bit tricky.

Suppose the context is initially in a double-buffered state and we're 
drawing to the back buffer.  Then we bind the context to a 
single-buffered window.  We need to make sure we don't try to render 
to the non-existant back buffer.  There may be a few places in Mesa 
where we're not prepared for that.


Anyway, from what I've gathered we should _not_ change the value of 
GL_DRAW_BUFFER in this situation either.




I'm putting together a couple piglit GLX tests to exercise this.  I
don't plan to send them to the piglit list until I can test them on a
non-Mesa driver.  Since I'm still at SIGGRAPH, that won't be until next
week.


I also started on a piglit test for this bug got sidetracked. NVIDIA's 
driver seems to do the following:


1. create double-buffered ctx and window, and make current.
2. query GL_DRAW_BUFFER returns GL_BACK
3. create single-buffered window and bind to the context.
4. query GL_DRAW_BUFFER still returns GL_BACK
5. drawing to the single-buffered window has no effect.

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


[Mesa-dev] [Bug 40028] New: warnings in glapitemp.h for glapi dispatch table return types

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

   Summary: warnings in glapitemp.h for glapi dispatch table
return types
   Product: Mesa
   Version: unspecified
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: e...@chromium.org


We encounter these warnings in the Chrome build.

In file included from third_party/mesa/MesaLib/src/mapi/glapi/glapi_nop.c:142:
third_party/mesa/MesaLib/src/mapi/glapi/glapitemp.h: In function
'NoOpGetString':
third_party/mesa/MesaLib/src/mapi/glapi/glapitemp.h:1462: warning:
return makes pointer from integer without a cast
third_party/mesa/MesaLib/src/mapi/glapi/glapitemp.h: In function
'NoOpMapBuffer':
third_party/mesa/MesaLib/src/mapi/glapi/glapitemp.h:3392: warning:
return makes pointer from integer without a cast
third_party/mesa/MesaLib/src/mapi/glapi/glapitemp.h: In function
'NoOpMapBufferARB':
third_party/mesa/MesaLib/src/mapi/glapi/glapitemp.h:3397: warning:
return makes pointer from integer without a cast
third_party/mesa/MesaLib/src/mapi/glapi/glapitemp.h: In function
'NoOpMapBufferRange':
third_party/mesa/MesaLib/src/mapi/glapi/glapitemp.h:3907: warning:
return makes pointer from integer without a cast
third_party/mesa/MesaLib/src/mapi/glapi/glapitemp.h: In function
'NoOpFenceSync':
third_party/mesa/MesaLib/src/mapi/glapi/glapitemp.h:3937: warning:
return makes pointer from integer without a cast

This is as a result of using the same No-op function for all return types.


See downstream bug:
http://code.google.com/p/chromium/issues/detail?id=92568

-- 
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: When assigning to a whole array, mark the array as accessed.

2011-08-11 Thread Eric Anholt
On Fri,  5 Aug 2011 21:48:53 -0700, Eric Anholt  wrote:
> The vs-varying-array-mat2-col-row-wr test writes a mat2[3] constant to
> a mat2[3] varying out array, and also statically accesses element 1 of
> it on the VS and FS sides.  At link time it would get trimmed down to
> just 2 elements, and then codegen of the VS would end up generating
> assignments to the unallocated last entry of the array.  On the new
> i965 VS backend, that happened to land on the vertex position.
> 
> Some issues remain in this test on softpipe, i965/old-vs and
> i965/new-vs on visual inspection, but i965 is passing because only one
> green pixel is probed, not the whole split green/red quad.
> ---
> 
> Note: This hasn't seen a full piglit run yet.

And, of course, because it hadn't seen a full piglit run, it's broken
(scoping1.frag crashes).


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


[Mesa-dev] [PATCH 1/4] i965/fs: Don't convert float/int/bool uniforms for GLSL 1.30.

2011-08-11 Thread Kenneth Graunke
Core Mesa now loads float/integer/boolean uniform data for drivers that
claim to support GLSL 1.30, thanks to Bryan Cain's recent work.  When we
run in "1.30 mode," we need to avoid double conversions.

Once we really support 1.30, we should just delete all this code.

Fixes piglit tests with INTEL_GLSL_VERSION=130 set:
- spec/glsl-1.10/fs-uniform-int-110.shader_test
- spec/glsl-1.30/fs-uniform-int-130.shader_test

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp |   36 ++---
 1 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index cafb709..e163d30 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -279,23 +279,27 @@ fs_visitor::setup_uniform_values(int loc, const glsl_type 
*type)
 
 assert(param < ARRAY_SIZE(c->prog_data.param));
 
-switch (type->base_type) {
-case GLSL_TYPE_FLOAT:
+if (ctx->Const.GLSLVersion >= 130) {
c->prog_data.param_convert[param] = PARAM_NO_CONVERT;
-   break;
-case GLSL_TYPE_UINT:
-   c->prog_data.param_convert[param] = PARAM_CONVERT_F2U;
-   break;
-case GLSL_TYPE_INT:
-   c->prog_data.param_convert[param] = PARAM_CONVERT_F2I;
-   break;
-case GLSL_TYPE_BOOL:
-   c->prog_data.param_convert[param] = PARAM_CONVERT_F2B;
-   break;
-default:
-   assert(!"not reached");
-   c->prog_data.param_convert[param] = PARAM_NO_CONVERT;
-   break;
+} else {
+   switch (type->base_type) {
+   case GLSL_TYPE_FLOAT:
+  c->prog_data.param_convert[param] = PARAM_NO_CONVERT;
+  break;
+   case GLSL_TYPE_UINT:
+  c->prog_data.param_convert[param] = PARAM_CONVERT_F2U;
+  break;
+   case GLSL_TYPE_INT:
+  c->prog_data.param_convert[param] = PARAM_CONVERT_F2I;
+  break;
+   case GLSL_TYPE_BOOL:
+  c->prog_data.param_convert[param] = PARAM_CONVERT_F2B;
+  break;
+   default:
+  assert(!"not reached");
+  c->prog_data.param_convert[param] = PARAM_NO_CONVERT;
+  break;
+   }
 }
 this->param_index[param] = loc;
 this->param_offset[param] = i;
-- 
1.7.6

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


[Mesa-dev] [PATCH 2/4] i965/fs: Initial refactoring for binary math operations other than POW.

2011-08-11 Thread Kenneth Graunke
Most math operations are unary operations; prior to this patch, POW was
the only binary operation we supported.  The next commit will introduce
integer quotient and remainder operations.  To facilitate that, this
patch simply generalizes POW checks into two-operand checks.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp  |8 +++-
 src/mesa/drivers/dri/i965/brw_fs_emit.cpp |4 +++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index e163d30..fd0d522 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -574,7 +574,13 @@ fs_visitor::emit_math(fs_opcodes opcode, fs_reg dst, 
fs_reg src0, fs_reg src1)
int base_mrf = 2;
fs_inst *inst;
 
-   assert(opcode == FS_OPCODE_POW);
+   switch (opcode) {
+   case FS_OPCODE_POW:
+  break;
+   default:
+  assert(!"not reached: unsupported binary math opcode");
+  return NULL;
+   }
 
if (intel->gen >= 6) {
   /* Can't do hstride == 0 args to gen6 math, so expand it out.
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
index e168e54..679bf05 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
@@ -147,6 +147,7 @@ fs_visitor::generate_math(fs_inst *inst,
  struct brw_reg dst, struct brw_reg *src)
 {
int op;
+   int num_operands = 1;
 
switch (inst->opcode) {
case FS_OPCODE_RCP:
@@ -166,6 +167,7 @@ fs_visitor::generate_math(fs_inst *inst,
   break;
case FS_OPCODE_POW:
   op = BRW_MATH_FUNCTION_POW;
+  num_operands = 2;
   break;
case FS_OPCODE_SIN:
   op = BRW_MATH_FUNCTION_SIN;
@@ -182,7 +184,7 @@ fs_visitor::generate_math(fs_inst *inst,
if (intel->gen >= 6) {
   assert(inst->mlen == 0);
 
-  if (inst->opcode == FS_OPCODE_POW) {
+  if (num_operands == 2) {
 brw_set_compression_control(p, BRW_COMPRESSION_NONE);
 brw_math2(p, dst, op, src[0], src[1]);
 
-- 
1.7.6

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


[Mesa-dev] [PATCH 3/4] i965/fs: Implement integer quotient and remainder math operations.

2011-08-11 Thread Kenneth Graunke
Prior to this patch, POW was the only two-operand math operation, so a
few cases needed to be updated.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_eu_emit.c|2 ++
 src/mesa/drivers/dri/i965/brw_fs.cpp   |5 +
 src/mesa/drivers/dri/i965/brw_fs.h |4 
 src/mesa/drivers/dri/i965/brw_fs_emit.cpp  |   10 ++
 .../dri/i965/brw_fs_schedule_instructions.cpp  |2 ++
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |   10 --
 6 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index e7370f3..b591324 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -1481,6 +1481,7 @@ void brw_math( struct brw_compile *p,
   assert(!src.abs);
 
   if (function != BRW_MATH_FUNCTION_INT_DIV_QUOTIENT &&
+ function != BRW_MATH_FUNCTION_INT_DIV_REMAINDER &&
  function != BRW_MATH_FUNCTION_INT_DIV_QUOTIENT_AND_REMAINDER) {
 assert(src.type == BRW_REGISTER_TYPE_F);
   }
@@ -1541,6 +1542,7 @@ void brw_math2(struct brw_compile *p,
assert(src1.hstride == BRW_HORIZONTAL_STRIDE_1);
 
if (function != BRW_MATH_FUNCTION_INT_DIV_QUOTIENT &&
+   function != BRW_MATH_FUNCTION_INT_DIV_REMAINDER &&
function != BRW_MATH_FUNCTION_INT_DIV_QUOTIENT_AND_REMAINDER) {
   assert(src0.type == BRW_REGISTER_TYPE_F);
   assert(src1.type == BRW_REGISTER_TYPE_F);
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index fd0d522..a24cef7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -152,6 +152,8 @@ fs_visitor::implied_mrf_writes(fs_inst *inst)
case FS_OPCODE_COS:
   return 1 * c->dispatch_width / 8;
case FS_OPCODE_POW:
+   case FS_OPCODE_INT_QUOTIENT:
+   case FS_OPCODE_INT_REMAINDER:
   return 2 * c->dispatch_width / 8;
case FS_OPCODE_TEX:
case FS_OPCODE_TXB:
@@ -577,6 +579,9 @@ fs_visitor::emit_math(fs_opcodes opcode, fs_reg dst, fs_reg 
src0, fs_reg src1)
switch (opcode) {
case FS_OPCODE_POW:
   break;
+   case FS_OPCODE_INT_QUOTIENT:
+   case FS_OPCODE_INT_REMAINDER:
+  break;
default:
   assert(!"not reached: unsupported binary math opcode");
   return NULL;
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
b/src/mesa/drivers/dri/i965/brw_fs.h
index 4ec6490..1ce9797 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -65,6 +65,8 @@ enum fs_opcodes {
FS_OPCODE_POW,
FS_OPCODE_SIN,
FS_OPCODE_COS,
+   FS_OPCODE_INT_QUOTIENT,
+   FS_OPCODE_INT_REMAINDER,
FS_OPCODE_DDX,
FS_OPCODE_DDY,
FS_OPCODE_PIXEL_X,
@@ -328,6 +330,8 @@ public:
  opcode == FS_OPCODE_LOG2 ||
  opcode == FS_OPCODE_SIN ||
  opcode == FS_OPCODE_COS ||
+ opcode == FS_OPCODE_INT_QUOTIENT ||
+ opcode == FS_OPCODE_INT_REMAINDER ||
  opcode == FS_OPCODE_POW);
}
 
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
index 679bf05..71ff513 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
@@ -175,6 +175,14 @@ fs_visitor::generate_math(fs_inst *inst,
case FS_OPCODE_COS:
   op = BRW_MATH_FUNCTION_COS;
   break;
+   case FS_OPCODE_INT_QUOTIENT:
+  op = BRW_MATH_FUNCTION_INT_DIV_QUOTIENT;
+  num_operands = 2;
+  break;
+   case FS_OPCODE_INT_REMAINDER:
+  op = BRW_MATH_FUNCTION_INT_DIV_REMAINDER;
+  num_operands = 2;
+  break;
default:
   assert(!"not reached: unknown math function");
   op = 0;
@@ -779,6 +787,8 @@ fs_visitor::generate_code()
   case FS_OPCODE_POW:
   case FS_OPCODE_SIN:
   case FS_OPCODE_COS:
+  case FS_OPCODE_INT_QUOTIENT:
+  case FS_OPCODE_INT_REMAINDER:
 generate_math(inst, dst, src);
 break;
   case FS_OPCODE_PIXEL_X:
diff --git a/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
index f1a88fc..062b408 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp
@@ -100,6 +100,8 @@ public:
 this->latency = 4 * chans * math_latency;
 break;
   case FS_OPCODE_POW:
+  case FS_OPCODE_INT_QUOTIENT:
+  case FS_OPCODE_INT_REMAINDER:
 this->latency = 8 * chans * math_latency;
 break;
   case FS_OPCODE_SIN:
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 2e3f9be..560956c 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -290,10 +290,16 @@ fs_visitor::visit(ir_expression *ir)
   emit(BRW_OPCODE_MUL, this->

[Mesa-dev] [PATCH 4/4] i965/fs: Use proper register type for MATH instruction GRF temporaries.

2011-08-11 Thread Kenneth Graunke
The MATH instruction unfortunately only operates on GRF registers with
an HStride of 1, so we often need to create a temporary GRF.  For
integer division and modulus, we need to use an integer register.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index a24cef7..e1de199 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -595,12 +595,14 @@ fs_visitor::emit_math(fs_opcodes opcode, fs_reg dst, 
fs_reg src0, fs_reg src1)
*/
   if (src0.file == UNIFORM || src0.abs || src0.negate) {
 fs_reg expanded = fs_reg(this, glsl_type::float_type);
+expanded.type = src0.type;
 emit(BRW_OPCODE_MOV, expanded, src0);
 src0 = expanded;
   }
 
   if (src1.file == UNIFORM || src1.abs || src1.negate) {
 fs_reg expanded = fs_reg(this, glsl_type::float_type);
+expanded.type = src1.type;
 emit(BRW_OPCODE_MOV, expanded, src1);
 src1 = expanded;
   }
-- 
1.7.6

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


Re: [Mesa-dev] [PATCH] swrast: initial multi-threaded span rendering

2011-08-11 Thread Andreas Fänger
OSMesa for gallium would be really helpful. Are there plans to implement some 
sort of antialising (GL_POLYGON_SMOOTH, fsaa) in softpipe/llvmpipe?

Andreas

-Ursprüngliche Nachricht-
Von: Brian Paul [mailto:bri...@vmware.com] 
Gesendet: Donnerstag, 11. August 2011 16:31
An: Andreas Fänger
Cc: mesa-dev@lists.freedesktop.org
Betreff: Re: [Mesa-dev] [PATCH] swrast: initial multi-threaded span rendering

These patches don't look too intrusive so I'm OK with them.  I'll 
apply them, test and push.

I've been meaning to write a new OSMesa interface for gallium for some 
time now.  That would probably be useful to a few people.

I'm tempted to redesign the OSMesa API a bit, but it's probably more 
important to keep it unchanged for the sake of existing apps.

-Brian


On 08/10/2011 03:49 AM, Andreas Fänger wrote:
> Hi Keith,
>
> you are right. The main purpose of this patch is to speedup osmesa rendering 
> as there is no llvmpipe target at the moment. Also llvmpipe is currently 
> missing some important features like aa/fsaa and anisotropic filtering, which 
> is available in swrast now.
> So I need to stick with the old rasterizer at the moment, with some 
> improvements.
>
> Andreas
>
> -Ursprüngliche Nachricht-
> Von: Keith Whitwell [mailto:kei...@vmware.com]
> Gesendet: Mittwoch, 10. August 2011 11:17
> An: Andreas Fänger
> Cc: mesa-dev@lists.freedesktop.org
> Betreff: Re: [Mesa-dev] [PATCH] swrast: initial multi-threaded span rendering
>
> I'm not sure it makes a lot of sense to be optimizing swrast at this
> stage.  Take a look at llvmpipe and perhaps consider improving the
> multithreading already in place in that rasterizer, which is far better
> optimized than swrast already.
>
> Keith
>
> On Wed, 2011-08-10 at 08:07 +, Andreas Fänger wrote:
>> Optional parallel rendering of spans using OpenMP.
>> Initial implementation for aa triangles. A new option for scons is
>> also provided to activate the openmp support (off by default).
>> ---
>>   common.py  |1 +
>>   scons/gallium.py   |   12 +++
>>   src/mesa/swrast/s_aatritemp.h  |   68 
>> ++-
>>   src/mesa/swrast/s_context.c|   26 ---
>>   src/mesa/swrast/s_texcombine.c |4 ++
>>   src/mesa/tnl/t_pipeline.c  |   12 +++
>>   6 files changed, 87 insertions(+), 36 deletions(-)
>>
>> diff --git a/common.py b/common.py
>> index 8657030..cfee1b5 100644
>> --- a/common.py
>> +++ b/common.py
>> @@ -88,6 +88,7 @@ def AddOptions(opts):
>>  opts.Add('toolchain', 'compiler toolchain', default_toolchain)
>>  opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support', 
>> 'no'))
>>  opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
>> +opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp 
>> (swrast)', 'no'))
>>  opts.Add(BoolOption('debug', 'DEPRECATED: debug build', 'yes'))
>>  opts.Add(BoolOption('profile', 'DEPRECATED: profile build', 'no'))
>>  opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
>> diff --git a/scons/gallium.py b/scons/gallium.py
>> index 8cd3bc7..7135251 100755
>> --- a/scons/gallium.py
>> +++ b/scons/gallium.py
>> @@ -596,6 +596,18 @@ def generate(env):
>>   libs += ['m', 'pthread', 'dl']
>>   env.Append(LIBS = libs)
>>
>> +# OpenMP
>> +if env['openmp']:
>> +if env['msvc']:
>> +env.Append(CCFLAGS = ['/openmp'])
>> +# When building openmp release VS2008 link.exe crashes with 
>> LNK1103 error.
>> +# Workaround: overwrite PDB flags with empty value as it isn't 
>> required anyways
>> +if env['build'] == 'release':
>> +env['PDB'] = ''
>> +if env['gcc']:
>> +env.Append(CCFLAGS = ['-fopenmp'])
>> +env.Append(LIBS = ['gomp'])
>> +
>>   # Load tools
>>   env.Tool('lex')
>>   env.Tool('yacc')
>> diff --git a/src/mesa/swrast/s_aatritemp.h b/src/mesa/swrast/s_aatritemp.h
>> index 91d4f7a..005d12c 100644
>> --- a/src/mesa/swrast/s_aatritemp.h
>> +++ b/src/mesa/swrast/s_aatritemp.h
>> @@ -181,13 +181,18 @@
>> const GLfloat *pMax = vMax->attrib[FRAG_ATTRIB_WPOS];
>> const GLfloat dxdy = majDx / majDy;
>> const GLfloat xAdj = dxdy<  0.0F ? -dxdy : 0.0F;
>> -  GLfloat x = pMin[0] - (yMin - iyMin) * dxdy;
>> GLint iy;
>> -  for (iy = iyMin; iy<  iyMax; iy++, x += dxdy) {
>> +  #pragma omp parallel for schedule(dynamic) private(iy) 
>> firstprivate(span)
>> +  for (iy = iyMin; iy<  iyMax; iy++) {
>> + GLfloat x = pMin[0] - (yMin - iy) * dxdy;
>>GLint ix, startX = (GLint) (x - xAdj);
>>GLuint count;
>>GLfloat coverage = 0.0F;
>>
>> +#ifdef _OPENMP
>> + /* each thread needs to use a different (global) SpanArrays 
>> variable */
>> + span.array = SWRAST_CONTEXT(ctx)->SpanArrays + 
>> omp_get_thread_num();
>> +#endif
>>/* skip