glean-dev — Glean development discussions

Re: [glean-dev] -march=pentiumpro option

[Brian P. <bri...@tu...>]

Jin, Gordon wrote:
> Brian Paul wrote:
>> If there's no objections, I'm going to remove the -march=pentiumpro
>> option from the common.mak file.  It seems to be an anachronism.
> 
> I'm a bit confused. Isn't that Akin already removed that option for
> x86-64 compatibility about half a year ago?
> http://glean.cvs.sourceforge.net/glean/glean/make/common.mak?r1=1.12&r2=
> 1.13

You're right.  I guess I haven't done a cvs update in that directory in 
a while!

-Brian

Re: [glean-dev] -march=pentiumpro option

[Jin, G. <gor...@in...>]

Brian Paul wrote:
> If there's no objections, I'm going to remove the -march=3Dpentiumpro
> option from the common.mak file.  It seems to be an anachronism.

I'm a bit confused. Isn't that Akin already removed that option for
x86-64 compatibility about half a year ago?
http://glean.cvs.sourceforge.net/glean/glean/make/common.mak?r1=3D1.12&r2=
=3D
1.13

-Gordon

Re: [glean-dev] -march=pentiumpro option

[Allen A. <ak...@ar...>]

On Fri, Mar 09, 2007 at 10:54:31AM -0700, Brian Paul wrote:
| If there's no objections, I'm going to remove the -march=pentiumpro 
| option from the common.mak file.  It seems to be an anachronism.

Keith's right that gcc tunes for the 386 by default.

We do need a better way to handle this option (and some others).  I've
thought about reworking glean's makefiles to use the mechanism that I've
been using recently for my own projects; it's more capable, and follows
the GNU makefile conventions more closely.  But it's a fairly drastic
change, and I haven't used it on anything other than recent Linux
distributions, so it might have portability problems.  Is it worth
pursuing?

(If you're curious, the main makefile I'm using now is appended below.)

Allen



########################################################################
# 
# Makefile - a nonrecursive infrastructure for using GNU make
# 
# This makefile implements an infrastructure for building modestly
# complex source trees without invoking make recursively.  It permits
# self-contained source directories to be moved in the tree without
# requiring any changes to their makefiles, handles
# dependency-generation and construction of object file lists
# automatically, compiles Qt meta-objects extracted from header files,
# and is intended to conform to the GNU makefile conventions described
# in the GNU Make Manual.
# 
# Place a copy of this makefile in the top directory of the source tree.
# Modify the default configuration variables that follow this comment
# block if needed.
# 
# In the top directory, and in all subdirectories where GNU make is to
# be run, create subordinate makefiles (by default named "Submakefile")
# with rules for each particular directory.  Each local filename
# mentioned in the rules must be prefixed by the variable "$.", which
# will be expanded to the name of the current directory.  Each rule
# takes one of the following forms:
# 
# 	CFLAGS_$. := flags
# 	CFLAGS_$./file.o := flags
# 
# 		Set C compiler flags for all the files in the directory
# 		(first form) or for the compilation of a particular
# 		object file (second form).  Note that CFLAGS may be
# 		specified on the GNU make command line, as usual, and
# 		flags specified by it might override some of those in
# 		the makefiles.
# 
# 	CXXFLAGS_$. := flags
# 	CXXFLAGS_$./file.o := flags
# 
# 		Similar to CFLAGS, but for C++ compilations.
# 
# 	CPPFLAGS_$. := flags
# 	CPPFLAGS_$./file.o := flags
# 
# 		Similar to CFLAGS, but for C preprocessor operation.
# 		This is where you should place include-file search
# 		flags; they will apply to both C and C++ compilations.
# 
# 	LDFLAGS_$. := flags
# 	LDFLAGS_$./file := flags
# 
# 		Similar to CFLAGS, but for linking executable programs.
# 
# 	$(call target.c,$./program-filename[,list-of-object-files])
# 	$(call target.cc,$./program-filename[,list-of-object-files])
# 	$(call target.a,$./library-filename[,list-of-object-files])
# 
# 		Build a C executable, a C++ executable, or a library
# 		archive.  If the list of object files is omitted, all
# 		the object files in the directory will be used.  When
# 		linking additional object files from other directories,
# 		you may find it convenient to use the expression
# 		$(OBJ_$.), which represents all the object files in the
# 		local directory.
# 
# 	$(call install.program,$./program-filename,directory-name)
# 	$(call install.data,$./non-program-filename,directory-name)
# 
# 		Declare where the given program or non-program file
# 		should be installed when "make install" is invoked.
# 		Typically the directory-name will be one of the
# 		conventional GNU make variables, such as $(bindir), but
# 		any directory can be named (this is useful when a single
# 		source tree installs more than one package.)  Any file
# 		in the directory can be installed, not just those that
# 		are built by calling one of the "target" functions; this
# 		is how to install header files, for example.
# 
# 	$./file: other-files...
# 
# 		Add dependencies for the target file.  This is necessary
# 		to express some dependencies across subtrees of the entire
# 		source tree, and may occasionally be useful to express
# 		dependencies on files completely outside the source
# 		tree.  When naming files elsewhere in the source tree,
# 		use filenames that are relative to the top level
# 		directory (where the main makefile resides).
# 
# A typical sub-makefile might look something like this:
# 
# 	CPPFLAGS_$. := -I$./include
# 	CXXFLAGS_$. := -Wall -Wextra
# 	LDFLAGS_$./foo := -lGL -lqt
# 	$(call target.cc,$./foo)
# 	$(call install.program,$./foo,$(bindir))
# 
# Invoke GNU make in the top-level directory.  The conventional targets
# "all", "clean", "install", and "uninstall" are supported (and of course
# you can build any target individually by specifying it on the GNU make
# command line).  Installation respects the setting of $(DESTDIR).
# 
# GNU make is required.  The current compilation rules also require gcc
# and g++ for automatic dependency generation, but that requirement would
# be fairly easy to relax.
# 
# This infrastructure was inspired by the author's previous recursive make
# infrastructures, Emile van Bergen's implementation of nonrecursive
# makefiles (http://www.xs4all.nl/~evbergen/nonrecursive-make.html) and
# Paul Smith's discussion of automatic dependency generation
# (http://make.paulandlesley.org/autodep.html).
# 
########################################################################

package = YOUR_PACKAGE_NAME_HERE

# Default target is...

.PHONY: all
all:

# Package-wide compilation and linking flags, which may be overridden
# on the command line:

CFLAGS = -g -O -Wall -Wextra
CXXFLAGS = -g -O -Wall -Wextra
# (CPPFLAGS refers to the C preprocessor, not to C++)
CPPFLAGS =
LDFLAGS =
LFLAGS =
YFLAGS =

# GNU conventions for installation directories:

prefix = /usr/local
exec_prefix = $(prefix)
bindir = $(exec_prefix)/bin
sbindir = $(exec_prefix)/sbin
libexecdir = $(exec_prefix)/libexec
datarootdir = $(prefix)/share
datadir = $(datarootdir)
sysconfdir = $(prefix)/etc
sharedstatedir = $(prefix)/com
localstatedir = $(prefix)/var
includedir = $(prefix)/include
docdir = $(datarootdir)/doc/$(package)
infodir = $(datarootdir)/info
htmldir = $(docdir)
dvidir = $(docdir)
pdfdir = $(docdir)
psdir = $(docdir)
libdir = $(exec_prefix)/lib
lispdir = $(datarootdir)/emacs/site-lisp
localedir = $(datarootdir)/locale
mandir = $(datarootdir)/man
man1dir = $(mandir)/man1
man3dir = $(mandir)/man3
manext = .1
man1ext = .1
man3ext = .3

# GNU conventions for utility commands:

SHELL = /bin/sh
AR = ar
BISON = bison
CC = gcc
CXX = g++
CHGRP = chgrp
CHMOD = chmod
CHOWN = chown
ECHO = echo
FLEX = flex
INSTALL = install
INSTALL_PROGRAM = $(INSTALL)
INSTALL_DATA = $(INSTALL) -m 644
LD = ld
LDCONFIG = ldconfig
LEX = lex
MAKE = make
MAKEINFO = makeinfo
MKNOD = mknod
RANLIB = ranlib
RM = rm -f
TEXI2DVI = texi2dvi
YACC = yacc

# Other utilities:

MOC = moc
GREP = grep

# Files and subdirectories specific to this infrastructure:

submakefile_name := Submakefile

target_2_dep = $(1).mak

########################################################################
# Nothing below this comment needs to be changed unless you're extending
# the infrastructure itself.
########################################################################

# Compilation and linking methods:

.SUFFIXES:
.SUFFIXES: .a .c .cc .o

file_2_dir = $(patsubst %/,%,$(dir $(1)))
normalize_file = $(dir $(1))$(notdir $(1))

c_src_2_dep = $(call target_2_dep,$(patsubst %.c,%.o,$(1)))
cc_src_2_dep = $(call target_2_dep,$(patsubst %.cc,%.o,$(1)))

define deps_c
-include $(call c_src_2_dep,$(1))
endef
define deps_cc
-include $(call cc_src_2_dep,$(1))
endef

%.o: %.c
	$(CC) -MMD -MP -MF $(call target_2_dep,$@) $(CFLAGS_PACKAGE) $(CFLAGS_$(call file_2_dir,$@)) $(CFLAGS_$(call normalize_file,$@)) $(CFLAGS) $(CPPFLAGS_PACKAGE) $(CPPFLAGS_$(call file_2_dir,$@)) $(CPPFLAGS_$(call normalize_file,$@)) $(CPPFLAGS) -c $< -o $@
	@$(ECHO) $@":" Makefile $(dir $@)$(submakefile_name) >>$(call target_2_dep,$@)

%.o: %.cc
	$(CXX) -MMD -MP -MF $(call target_2_dep,$@) $(CXXFLAGS_PACKAGE) $(CXXFLAGS_$(call file_2_dir,$@)) $(CXXFLAGS_$(call normalize_file,$@)) $(CXXFLAGS) $(CPPFLAGS_PACKAGE) $(CPPFLAGS_$(call file_2_dir,$@)) $(CPPFLAGS_$(call normalize_file,$@)) $(CPPFLAGS) -c $< -o $@
	@$(ECHO) $@":" Makefile $(dir $@)$(submakefile_name) >>$(call target_2_dep,$@)


%_moc.cc: %.h
	$(MOC) $< -o $@

# Gather the names and dependencies for all the object files we know how
# to build.

define gather_objs
ifeq ($$(OBJ_$$.),)
OBJ_$$. :=
# C:
SRC_C_$$. := $$(patsubst ./%,%,$$(wildcard $$./*.c))
$$(foreach src,$$(SRC_C_$$.),$$(eval $$(call deps_c,$$(src))))
$$(foreach src,$$(SRC_C_$$.),$$(eval dirt+=$$(call c_src_2_dep,$$(src))))
OBJ_$$. += $$(patsubst %.c,%.o,$$(SRC_C_$$.))
# Qt Meta-Objects:
SRC_MOC_$$. := $$(patsubst ./%,%,$$(patsubst %.h,%_moc.cc,$$(shell $$(GREP) -l Q_OBJECT $$(wildcard $$./*.h) </dev/null 2>/dev/null)))
dirt += $$(SRC_MOC_$$.)
# C++:
SRC_CC_$$. := $$(patsubst ./%,%,$$(wildcard $$./*.cc)) $$(SRC_MOC_$$.)
$$(foreach src,$$(SRC_CC_$$.),$$(eval $$(call deps_cc,$$(src))))
$$(foreach src,$$(SRC_CC_$$.),$$(eval dirt+=$$(call cc_src_2_dep,$$(src))))
OBJ_$$. += $$(patsubst %.cc,%.o,$$(SRC_CC_$$.))
dirt += $$(OBJ_$$.)
endif
endef

define declare_target.c
$(eval $(gather_objs))
targets += $(1)
ifeq ($(2),)
OBJ_$(1) := $(OBJ_$.)
else
OBJ_$(1) := $(patsubst ./%,%,$(2))
endif
$(1): $$(OBJ_$$(1))
	$$(CC) $$(CFLAGS_PACKAGE) $$(CFLAGS_$$(call file_2_dir,$$@)) $$(CFLAGS_$$(call normalize_file,$$@)) $$(CFLAGS) $$(CPPFLAGS_PACKAGE) $$(CPPFLAGS_$$(call file_2_dir $$@)) $$(CPPFLAGS_$$(call normalize_file,$$@)) $$(CPPFLAGS) $$(OBJ_$$(call normalize_file,$$@)) $$(LDFLAGS_PACKAGE) $$(LDFLAGS_$$(call file_2_dir,$$@)) $$(LDFLAGS_$$(call normalize_file,$$@)) $$(LDFLAGS) -o $$@
endef

target.c = $(eval $(call declare_target.c,$(1),$(2)))

define declare_target.cc
$(eval $(gather_objs))
targets += $(1)
ifeq ($(2),)
OBJ_$(1) := $(OBJ_$.)
else
OBJ_$(1) := $(patsubst ./%,%,$(2))
endif
$(1): $$(OBJ_$$(1))
	$$(CXX) $$(CXXFLAGS_PACKAGE) $$(CXXFLAGS_$$(call file_2_dir,$$@)) $$(CXXFLAGS_$$(call normalize_file,$$@)) $$(CXXFLAGS) $$(CPPFLAGS_PACKAGE) $$(CPPFLAGS_$$(call file_2_dir,$$@)) $$(CPPFLAGS_$$(call normalize_file,$$@)) $$(CPPFLAGS) $$(OBJ_$$(call normalize_file,$$@)) $$(LDFLAGS_PACKAGE) $$(LDFLAGS_$$(call file_2_dir,$$@)) $$(LDFLAGS_$$(call normalize_file,$$@)) $$(LDFLAGS) -o $$@
endef

target.cc = $(eval $(call declare_target.cc,$(1),$(2)))

define declare_target.a
$(eval $(gather_objs))
targets += $(1)
ifeq ($(2),)
$(1): $(OBJ_$.)
else
$(1): $(2)
endif
	$$(AR) rusv $$@ $$+
endef

target.a = $(eval $(call declare_target.a,$(1),$(2)))

# Define installation rules:

define declare_install.program
installations += $(DESTDIR)$(2)/$(notdir $(1))
INSTALL_LOC_$(call normalize_file,$(1)) := $(DESTDIR)$(2)
install:: $(1)
	$(INSTALL_PROGRAM) $$< $$(INSTALL_LOC_$$(call normalize_file,$$<))
endef

install.program = $(eval $(call declare_install.program,$(1),$(2)))

define declare_install.data
installations += $(DESTDIR)$(2)/$(notdir $(1))
INSTALL_LOC_$(call normalize_file,$(1)) := $(DESTDIR)$(2)
install:: $(1)
	$(INSTALL_DATA) $$< $$(INSTALL_LOC_$$(call normalize_file,$$<))
endef

install.data = $(eval $(call declare_install.data,$(1),$(2)))

# Initialize variables that accumulate targets, etc.:
targets :=
installations :=
dirt :=

# Gather all the sub-Makefile information for the initial directory
# and its subdirectories (all that are reachable through a path
# in which each directory contains a sub-Makefile, to be exact).
# Within each sub-Makefile, the value of the variable $. will be
# the path of the containing subdirectory, without a trailing slash.
#
# N.B.:  It is possible to do this recursively within make, to handle
# directory trees of arbitrary depth.  However, it's fragile (minor
# changes in the rules cause make to fail), and it requires some
# ugliness in the sub-Makefiles.  Another option is to use "find"
# to find all the sub-Makefiles; we've chosen not to do that here
# because the current method makes it easier to disable the building
# of entire subtrees (just by renaming the sub-Makefile in the topmost
# directory of the subtree).

l0_dirs := ./
l1_dirs := $(dir $(wildcard $(patsubst %,%*/$(submakefile_name),$(l0_dirs))))
l2_dirs := $(dir $(wildcard $(patsubst %,%*/$(submakefile_name),$(l1_dirs))))
l3_dirs := $(dir $(wildcard $(patsubst %,%*/$(submakefile_name),$(l2_dirs))))
l4_dirs := $(dir $(wildcard $(patsubst %,%*/$(submakefile_name),$(l3_dirs))))
l5_dirs := $(dir $(wildcard $(patsubst %,%*/$(submakefile_name),$(l4_dirs))))
l6_dirs := $(dir $(wildcard $(patsubst %,%*/$(submakefile_name),$(l5_dirs))))
l7_dirs := $(dir $(wildcard $(patsubst %,%*/$(submakefile_name),$(l6_dirs))))
l8_dirs := $(dir $(wildcard $(patsubst %,%*/$(submakefile_name),$(l7_dirs))))
l9_dirs := $(dir $(wildcard $(patsubst %,%*/$(submakefile_name),$(l8_dirs))))
subdirs := . $(patsubst ./%/,%,$(l1_dirs) $(l2_dirs) $(l3_dirs) \
 $(l4_dirs) $(l5_dirs) $(l6_dirs) $(l7_dirs) $(l8_dirs) $(l9_dirs))

define make_subdirectory
. := $(1)
include $(1)/$(submakefile_name)
endef

$(foreach subdir,$(subdirs),$(eval $(call make_subdirectory,$(subdir))))

# Define the top-level goals:
all:	$(targets)

.PHONY: clean
clean:
	$(RM) $(patsubst ./%,%,$(dirt) $(targets))

.PHONY: install

.PHONY: uninstall
uninstall:
	$(RM) $(installations)

# Prevent make from removing intermediate targets:
.SECONDARY: $(dirt)

Re: [glean-dev] -march=pentiumpro option

[Brian P. <bri...@tu...>]

Keith Whitwell wrote:
> Brian Paul wrote:
>> If there's no objections, I'm going to remove the -march=pentiumpro 
>> option from the common.mak file.  It seems to be an anachronism.
> 
> It's still a good approximation for modern cpu's.  If you remove it, 
> then gcc assumes you're running on an i386, which is more of an 
> anachronism...

OK, I assumed gcc defaulted to at least 586 nowadays.

-Brian

Re: [glean-dev] -march=pentiumpro option

[Keith W. <ke...@tu...>]

Brian Paul wrote:
> If there's no objections, I'm going to remove the -march=pentiumpro 
> option from the common.mak file.  It seems to be an anachronism.

It's still a good approximation for modern cpu's.  If you remove it, 
then gcc assumes you're running on an i386, which is more of an 
anachronism...

Keith

[glean-dev] -march=pentiumpro option

[Brian P. <bri...@tu...>]

If there's no objections, I'm going to remove the -march=pentiumpro 
option from the common.mak file.  It seems to be an anachronism.

-Brian

Re: [glean-dev] simple texrect test

[Eric A. <er...@an...>]

On Sat, 2006-10-21 at 15:53 -0600, Brian Paul wrote:
> Eric Anholt wrote:
> > Attached is a simple test for GL_ARB_texture_rectangle for review and
> > potentially committing.
>=20
> Hi Eric,
>=20
> I _finally_ committed this.  Sorry for the delay.  Catching up on=20
> Glean work today.
>=20
> You had one bug in your program:
>=20
> glClear(GL_BACK) is illegal - changed to glClear(GL_COLOR_BUFFER_BIT).
>=20
> -Brian

And now the world knows how little OpenGL I do.  Thanks for fixing.

--=20
Eric Anholt                             an...@Fr...
er...@an...                         eri...@in...

Re: [glean-dev] simple texrect test

[Brian P. <bri...@tu...>]

Eric Anholt wrote:
> Attached is a simple test for GL_ARB_texture_rectangle for review and
> potentially committing.

Hi Eric,

I _finally_ committed this.  Sorry for the delay.  Catching up on 
Glean work today.

You had one bug in your program:

glClear(GL_BACK) is illegal - changed to glClear(GL_COLOR_BUFFER_BIT).

-Brian

Re: [glean-dev] "pointAtten" not give case name in the log if it FAIL

[Allen A. <ak...@po...>]

On Mon, Sep 25, 2006 at 11:25:05AM +0800, Chong, Weiliang wrote:
|    ...
|    this formats is useful and clearly to analyze the test result, you can see
|    which test case FAIL or PASS.
| 
|    But "pointAtten" would give no "pointAtten" in the log if this case FAIL,
|    ...

Yes.  Fixing this sort of thing is on my "to-do" list, but I haven't
had much time to work on glean lately.  I apologize.  I will get around
to it eventually!

Allen

[glean-dev] "pointAtten" not give case name in the log if it FAIL

[Chong, W. <wei...@in...>]

Hi all,

Glean running log has this formats,

               basic:  PASS rgba8, db, win+pmap, id 35
               basicPerf:  PASS rgba8, db, win+pmap, id 35
                              Average =3D 0.105032              Range =
=3D
[0.104962, 0.105094]

polygonOffset:  FAIL rgba8, db, z24, s8, win+pmap, id 37

this formats is useful and clearly to analyze the test result, you can
see which test case FAIL or PASS.

But "pointAtten" would give no "pointAtten" in the log if this case
FAIL, I saw the source code, It will give FAILURE without case name
"pointAtten" if test FAIL, and the method logOne() in the classe

--------------------------------

void

PointAttenuationTest::logOne(BasicResult &r)

{

      if (r.pass) {-----------------------------------------//only
logPassFail() with the case name "pointAtten" when PASS

                logPassFail(r);

                logConcise(r);

      }

}

-------------------------------------

So, I suggest change the method like this, logPassFail() with case name
"pointAtten" no matter PASS or FAIL.

void

PointAttenuationTest::logOne(BasicResult &r)

{

//      if (r.pass) {

                logPassFail(r);

                logConcise(r);

//      }

}

=20

Thanks,

-Veelion

Re: [glean-dev] problems of glean compiling on 64-bit machine

[Allen A. <ak...@po...>]

On Tue, Sep 19, 2006 at 12:55:37PM +0800, Jin, Gordon wrote:
| This might be true for x86, but it doesn't work on x86-64...

Good point.  I'll remove it now, and we'll work out a more general fix
later.

Allen

Re: [glean-dev] problems of glean compiling on 64-bit machine

[Jin, G. <gor...@in...>]

Allen Akin wrote:
> On Tue, Sep 12, 2006 at 12:29:47PM +0800, Chong, Weiliang wrote:
>> ...
>>    When I compile glean on 64-bit machine, I found something wrong
>>    with the file make/common.mak, in the file,
>>=20
>>    ifeq ($(PLATFORM), Unix)
>>=20
>>    _OPT=3D\
>>=20
>>            -march=3Dpentiumpro \------------------------this march is
>>    not compatibility with 64-bit machine, so I delete this line, and
>>    then my compiling complete successfully.
>> ...
>>    I think march to pentiumpro is out of date, would you like to
>> change this?=20
>=20
> Were you using Intel's compiler, or g++?
>=20
> For g++, pentiumpro (equivalent to i686) looks like a good
> lowest-common-denominator choice, so I'm reluctant to change it.

This might be true for x86, but it doesn't work on x86-64:
main.cpp:1: error: CPU you selected does not support x86-64 instruction
set

Since x86-64 is becoming popular, and I don't see there's much benefit
of setting pentiumpro, I'm suggesting removing it.

Re: [glean-dev] git repository

[Allen A. <ak...@po...>]

On Fri, Sep 15, 2006 at 05:39:48PM -0700, Eric Anholt wrote:
| ...
| I've done the conversion to autotools for myself in my git mirror, and
| will continue to maintain it periodically.  ...

I'll take a look.  Can't be prompt, though.

|                      ...and lack of a reasonable install feature makes
| the current build system useless to me.

Another intent of the current system is not to affect any directories
outside the glean hierarchy.  That's why installation "installs"
everything locally.  What are you looking for in the way of
installation?

Allen

[glean-dev] Has anyone compiled Glean with Vc7.1 under Windows ?

[tscmga <ts...@gm...>]

SGkhDQpIYXMgYW55b25lIGNvbXBpbGVkICJHbGVhbiIgd2l0aCBWYzcuMSB1bmRlciBXaW5kb3dz
ID8gQ2FuIHNvbWVvbmUgZ2l2ZSBtZSBzb21lIHRpcHMgb24gaG93IHRvIGJ1aWxkIGl0ID8=

Re: [glean-dev] git repository

[Eric A. <er...@an...>]

Oops, dropped this mail on the floor for a long time.

On Sat, 2006-07-22 at 16:19 -0700, Allen Akin wrote:
> On Sat, Jul 22, 2006 at 04:52:45PM -0400, Eric Anholt wrote:
> | Would there be any interest by glean developers in moving to the git
> | revision control system?  ...
>=20
> I'm certainly open to that.  My expectation was that the glean
> repository would move out of CVS eventually.  I've been experimenting
> with git, and I think it's a reasonable choice.
>=20
> Occasionally I still get requests for glean from Windows users.  Is
> there a git client that can be used on Windows?  (Things based on CygWin
> or equivalent are problematic for some people.)
>=20
> Anyone else have thoughts on the matter?

It can be run on Windows from what I understand, not that I use it.
However, due to being shell-heavy, I would expect performance on Windows
to be bad.

There's also the potential to hook up snapshot scripts if people just
want to get the code and not do development on it.

> | I've also put in that repository the start of a conversion to autotools=
,
> | on the autotools branch.  ...
>=20
> I'm not opposed to that on general principles, but there were two
> specific problems that stopped me the last time I considered it:
>=20
> 	(1) The current system is heavily oriented toward maintaining
> 	build correctness with zero Makefile/configfile maintenance when
> 	source files are added, and I'd like to retain that property in
> 	any new system.  I don't know enough about autotools to know
> 	whether things could be set up that way.

Not with automake.  You could retain that using just autoconf, though.

> 	(2) It looks to me like a switch to autotools would really want
> 	to include a directory structure reorganization, as well as a
> 	major change to more standardized concepts of
> 	source/build/lib/destination directories.  In other words, it's
> 	a thrash big enough that I haven't had time to deal with it.

Yeah, a reorg wouldn't hurt for autotoolsing.

I've done the conversion to autotools for myself in my git mirror, and
will continue to maintain it periodically.  The inability to build out
of the box on non-linux and lack of a reasonable install feature makes
the current build system useless to me.

--=20
Eric Anholt                             an...@Fr...
er...@an...                         eri...@in...

[glean-dev] simple texrect test

[Eric A. <er...@an...>]

Attached is a simple test for GL_ARB_texture_rectangle for review and
potentially committing.

-- 
Eric Anholt                             an...@Fr...
er...@an...                         eri...@in...

Re: [glean-dev] request for readpixPerf results

[Keith W. <kei...@ya...>]

Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Keith Whitwell wrote:
>> Brian Paul wrote:
>>> Keith Whitwell wrote:
>>>> Also note, when SumOut is false, a clever driver could notice that 
>>>> nothing has changed and the readpixels need only be performed on the 
>>>> first iteration through the loop.  In fact, a clever driver could note 
>>>> that the data is never Mapped or otherwise requested by the CPU and 
>>>> eliminate all copying...
>>> I don't think that could ever be safely implemented by a driver.  An 
>>> example would be one thread doing glReadPixels and another thread 
>>> touching the data we read back.
>> The driver would only have to delay issuing the transfer request until 
>> the application tried to map the data.  If a second ReadPixels is 
>> received before there a call to MapBuffer, the transfer could be 
>> aborted/never issued.  The data isn't available for any thread to look 
>> at until MapBuffer or GetData is called.
> 
> Uhh....what about:
> 
> glReadPixels(...);
> glDrawArrays(...);
> glMapBuffer(...);
> 
> It seems like an optimization that would have a lot of corner cases to
> avoid while not providing a lot of benefit to real applications.  It
> gets even worse, as Brian mentions, if the glDrawArrays is in a
> different thread.

Don't worry, it's not a serious proposal...  It would only be of benefit 
to degenerate applications and not help the important usages...

Keith

Re: [glean-dev] request for readpixPerf results

[Ian R. <id...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Keith Whitwell wrote:
> Brian Paul wrote:
>> Keith Whitwell wrote:
>>> Also note, when SumOut is false, a clever driver could notice that 
>>> nothing has changed and the readpixels need only be performed on the 
>>> first iteration through the loop.  In fact, a clever driver could note 
>>> that the data is never Mapped or otherwise requested by the CPU and 
>>> eliminate all copying...
>> I don't think that could ever be safely implemented by a driver.  An 
>> example would be one thread doing glReadPixels and another thread 
>> touching the data we read back.
> 
> The driver would only have to delay issuing the transfer request until 
> the application tried to map the data.  If a second ReadPixels is 
> received before there a call to MapBuffer, the transfer could be 
> aborted/never issued.  The data isn't available for any thread to look 
> at until MapBuffer or GetData is called.

Uhh....what about:

glReadPixels(...);
glDrawArrays(...);
glMapBuffer(...);

It seems like an optimization that would have a lot of corner cases to
avoid while not providing a lot of benefit to real applications.  It
gets even worse, as Brian mentions, if the glDrawArrays is in a
different thread.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFFBuv1X1gOwKyEAw8RAj1IAJsHrISJfNwRIW7KpJhjyaMvfCmMrACffKcJ
NHjTnWtqhHqI8LtpaavKs64=
=vS27
-----END PGP SIGNATURE-----

Re: [glean-dev] request for readpixPerf results

[Brian P. <bri...@tu...>]

Keith Whitwell wrote:
> Brian Paul wrote:
> 
>> Keith Whitwell wrote:
>>
>>> Allen Akin wrote:
>>>
>>>> On Thu, Sep 07, 2006 at 04:32:43PM -0600, Brian Paul wrote:
>>>> | ...
>>>> | Looks like a rare case where PBOs are faster!  ...
>>>>
>>>> Yep.  Although on an AGP system, I thought PBOs might be more of a win
>>>> for DrawPixels and TexImage than for ReadPixels. | ... though, when 
>>>> the pixel data is actually touched, performance drops | with PBOs.
>>>>
>>>> There's always a catch. :-)
>>>
>>>
>>> I had a quick look at the test and I wonder if you are getting the 
>>> maximum benefit from PBO's.
>>>
>>> It seems like you're making an attept to get asynchronous transfers 
>>> going, but I don't think that full pipelining is possible with the 
>>> usage in the test, at least when the SumOut flag is true.
>>>
>>> In particular, the chain of events:
>>>
>>>     1) Render
>>>     2) Issue ReadPixels for top half to pbo0
>>>     2a) Issue ReadPixels for bottom half
>>>     3) Map pbo0
>>>
>>> On theoretic/perfect hardware, I believe you are going to be hitting 
>>> an unnecessary stall at (3) because the ReadPixels calls should 
>>> return instantaneously - they just make a request and will not 
>>> block.  Hence the request to Map pbo0 will almost certainly occur 
>>> before the transfer has completed, and maybe even before rendering 
>>> has completed.
>>>
>>> To get full asynchronous behaviour, something like the following 
>>> might be better.  Note that I am not preserving the top/bottom split:
>>>
>>>     i = 0;
>>>     Render Frame
>>>     Bind PBO(i)
>>>     Issue ReadPixels
>>>
>>>
>>>     while (1) {
>>>         Render Frame
>>>         Bind PBO(i ^ 1)
>>>         Issue Readpixels
>>>
>>>         Bind PBO(i)
>>>         MapBuffer
>>>         process data
>>>
>>>         i = i^1;
>>>     }
>>>
>>>
>>> The hope is that rendering and transfer overlaps with the CPU 
>>> processing of data and that we don't have any path that attempts to 
>>> pull data back to the CPU and map it immediately without some 
>>> processing step inbetween.
>>
>>
>> I was thinking of that too, but I was intentionally following the 
>> suggested example for asynchronous readback seen at the end of the 
>> GL_ARB_pixel_buffer_object spec.  I figured if anyone was implementing 
>> true asynchronous readback they'd support the model seen there.
> 
> 
> Drivers will be able to optimize/overlap the second transfer, but the 
> first one is going to force a stall as I mentioned.

Yup.

> The example in the spec is a pretty pared down demonstration that will 
> get some benefit by overlapping the second transfer while the CPU is 
> processing the results from the first.  It won't get the most out of the 
> technique, but it is an easy chunk of code to drop into an existing 
> application if it happens to fit the usage model.
> 
> For really big transfers, assuming you can't go to the fully asyncronous 
> model, there might be a benefit in splitting the transfer into 3 or more 
> pieces.

For the VNC SPU, there's potentially many glReadPixels needed per 
frame when bounding boxes are used.  It would be nice to get some 
degree of asynchronous readback going.


>> I could code-up your approach as well though.  However, I don't think 
>> it would work with the Chromium VNC SPU (which is where I'm probably 
>> going to use this).
> 
> 
> It's certainly worthwhile to try and avoid stalls where possible.  If 
> it's not possible, the approach from the spec has merit.
> 
>>
>>> Also note, when SumOut is false, a clever driver could notice that 
>>> nothing has changed and the readpixels need only be performed on the 
>>> first iteration through the loop.  In fact, a clever driver could 
>>> note that the data is never Mapped or otherwise requested by the CPU 
>>> and eliminate all copying...
>>
>>
>> I don't think that could ever be safely implemented by a driver.  An 
>> example would be one thread doing glReadPixels and another thread 
>> touching the data we read back.
> 
> 
> The driver would only have to delay issuing the transfer request until 
> the application tried to map the data.  If a second ReadPixels is 
> received before there a call to MapBuffer, the transfer could be 
> aborted/never issued.  The data isn't available for any thread to look 
> at until MapBuffer or GetData is called.

Right.  I guess I was just thinking of the non-PBO case.

-Brian

Re: [glean-dev] request for readpixPerf results

[Keith W. <kei...@ya...>]

Brian Paul wrote:
> Keith Whitwell wrote:
>> Allen Akin wrote:
>>
>>> On Thu, Sep 07, 2006 at 04:32:43PM -0600, Brian Paul wrote:
>>> | ...
>>> | Looks like a rare case where PBOs are faster!  ...
>>>
>>> Yep.  Although on an AGP system, I thought PBOs might be more of a win
>>> for DrawPixels and TexImage than for ReadPixels. 
>>> | ... though, when the pixel data is actually touched, performance 
>>> drops | with PBOs.
>>>
>>> There's always a catch. :-)
>>
>> I had a quick look at the test and I wonder if you are getting the 
>> maximum benefit from PBO's.
>>
>> It seems like you're making an attept to get asynchronous transfers 
>> going, but I don't think that full pipelining is possible with the usage 
>> in the test, at least when the SumOut flag is true.
>>
>> In particular, the chain of events:
>>
>>     1) Render
>>     2) Issue ReadPixels for top half to pbo0
>>     2a) Issue ReadPixels for bottom half
>>     3) Map pbo0
>>
>> On theoretic/perfect hardware, I believe you are going to be hitting an 
>> unnecessary stall at (3) because the ReadPixels calls should return 
>> instantaneously - they just make a request and will not block.  Hence 
>> the request to Map pbo0 will almost certainly occur before the transfer 
>> has completed, and maybe even before rendering has completed.
>>
>> To get full asynchronous behaviour, something like the following might 
>> be better.  Note that I am not preserving the top/bottom split:
>>
>>     i = 0;
>>     Render Frame
>>     Bind PBO(i)
>>     Issue ReadPixels
>>
>>
>>     while (1) {
>>         Render Frame
>>         Bind PBO(i ^ 1)
>>         Issue Readpixels
>>
>>         Bind PBO(i)
>>         MapBuffer
>>         process data
>>
>>         i = i^1;
>>     }
>>
>>
>> The hope is that rendering and transfer overlaps with the CPU processing 
>> of data and that we don't have any path that attempts to pull data back 
>> to the CPU and map it immediately without some processing step inbetween.
> 
> I was thinking of that too, but I was intentionally following the 
> suggested example for asynchronous readback seen at the end of the 
> GL_ARB_pixel_buffer_object spec.  I figured if anyone was implementing 
> true asynchronous readback they'd support the model seen there.

Drivers will be able to optimize/overlap the second transfer, but the 
first one is going to force a stall as I mentioned.

The example in the spec is a pretty pared down demonstration that will 
get some benefit by overlapping the second transfer while the CPU is 
processing the results from the first.  It won't get the most out of the 
technique, but it is an easy chunk of code to drop into an existing 
application if it happens to fit the usage model.

For really big transfers, assuming you can't go to the fully asyncronous 
model, there might be a benefit in splitting the transfer into 3 or more 
pieces.


> I could code-up your approach as well though.  However, I don't think 
> it would work with the Chromium VNC SPU (which is where I'm probably 
> going to use this).

It's certainly worthwhile to try and avoid stalls where possible.  If 
it's not possible, the approach from the spec has merit.

> 
>> Also note, when SumOut is false, a clever driver could notice that 
>> nothing has changed and the readpixels need only be performed on the 
>> first iteration through the loop.  In fact, a clever driver could note 
>> that the data is never Mapped or otherwise requested by the CPU and 
>> eliminate all copying...
> 
> I don't think that could ever be safely implemented by a driver.  An 
> example would be one thread doing glReadPixels and another thread 
> touching the data we read back.

The driver would only have to delay issuing the transfer request until 
the application tried to map the data.  If a second ReadPixels is 
received before there a call to MapBuffer, the transfer could be 
aborted/never issued.  The data isn't available for any thread to look 
at until MapBuffer or GetData is called.

Keith

Re: [glean-dev] request for readpixPerf results

[Brian P. <bri...@tu...>]

Keith Whitwell wrote:
> Allen Akin wrote:
> 
>> On Thu, Sep 07, 2006 at 04:32:43PM -0600, Brian Paul wrote:
>> | ...
>> | Looks like a rare case where PBOs are faster!  ...
>>
>> Yep.  Although on an AGP system, I thought PBOs might be more of a win
>> for DrawPixels and TexImage than for ReadPixels. 
>> | ... though, when the pixel data is actually touched, performance 
>> drops | with PBOs.
>>
>> There's always a catch. :-)
> 
> 
> I had a quick look at the test and I wonder if you are getting the 
> maximum benefit from PBO's.
> 
> It seems like you're making an attept to get asynchronous transfers 
> going, but I don't think that full pipelining is possible with the usage 
> in the test, at least when the SumOut flag is true.
> 
> In particular, the chain of events:
> 
>     1) Render
>     2) Issue ReadPixels for top half to pbo0
>     2a) Issue ReadPixels for bottom half
>     3) Map pbo0
> 
> On theoretic/perfect hardware, I believe you are going to be hitting an 
> unnecessary stall at (3) because the ReadPixels calls should return 
> instantaneously - they just make a request and will not block.  Hence 
> the request to Map pbo0 will almost certainly occur before the transfer 
> has completed, and maybe even before rendering has completed.
> 
> To get full asynchronous behaviour, something like the following might 
> be better.  Note that I am not preserving the top/bottom split:
> 
>     i = 0;
>     Render Frame
>     Bind PBO(i)
>     Issue ReadPixels
> 
> 
>     while (1) {
>         Render Frame
>         Bind PBO(i ^ 1)
>         Issue Readpixels
> 
>         Bind PBO(i)
>         MapBuffer
>         process data
> 
>         i = i^1;
>     }
> 
> 
> The hope is that rendering and transfer overlaps with the CPU processing 
> of data and that we don't have any path that attempts to pull data back 
> to the CPU and map it immediately without some processing step inbetween.

I was thinking of that too, but I was intentionally following the 
suggested example for asynchronous readback seen at the end of the 
GL_ARB_pixel_buffer_object spec.  I figured if anyone was implementing 
true asynchronous readback they'd support the model seen there.

I could code-up your approach as well though.  However, I don't think 
it would work with the Chromium VNC SPU (which is where I'm probably 
going to use this).


> Also note, when SumOut is false, a clever driver could notice that 
> nothing has changed and the readpixels need only be performed on the 
> first iteration through the loop.  In fact, a clever driver could note 
> that the data is never Mapped or otherwise requested by the CPU and 
> eliminate all copying...

I don't think that could ever be safely implemented by a driver.  An 
example would be one thread doing glReadPixels and another thread 
touching the data we read back.

-Brian

Re: [glean-dev] request for readpixPerf results

[Keith W. <kei...@ya...>]

Allen Akin wrote:
> On Thu, Sep 07, 2006 at 04:32:43PM -0600, Brian Paul wrote:
> | ...
> | Looks like a rare case where PBOs are faster!  ...
> 
> Yep.  Although on an AGP system, I thought PBOs might be more of a win
> for DrawPixels and TexImage than for ReadPixels.  
> 
> | ... though, when the pixel data is actually touched, performance drops 
> | with PBOs.
> 
> There's always a catch. :-)

I had a quick look at the test and I wonder if you are getting the 
maximum benefit from PBO's.

It seems like you're making an attept to get asynchronous transfers 
going, but I don't think that full pipelining is possible with the usage 
in the test, at least when the SumOut flag is true.

In particular, the chain of events:

	1) Render
	2) Issue ReadPixels for top half to pbo0
	2a) Issue ReadPixels for bottom half
	3) Map pbo0

On theoretic/perfect hardware, I believe you are going to be hitting an 
unnecessary stall at (3) because the ReadPixels calls should return 
instantaneously - they just make a request and will not block.  Hence 
the request to Map pbo0 will almost certainly occur before the transfer 
has completed, and maybe even before rendering has completed.

To get full asynchronous behaviour, something like the following might 
be better.  Note that I am not preserving the top/bottom split:

	i = 0;
	Render Frame
	Bind PBO(i)
	Issue ReadPixels


	while (1) {
		Render Frame
		Bind PBO(i ^ 1)
		Issue Readpixels

		Bind PBO(i)
		MapBuffer
		process data

		i = i^1;
	}


The hope is that rendering and transfer overlaps with the CPU processing 
of data and that we don't have any path that attempts to pull data back 
to the CPU and map it immediately without some processing step inbetween.


Also note, when SumOut is false, a clever driver could notice that 
nothing has changed and the readpixels need only be performed on the 
first iteration through the loop.  In fact, a clever driver could note 
that the data is never Mapped or otherwise requested by the CPU and 
eliminate all copying...

Keith		

Re: [glean-dev] problems of glean compiling on 64-bit machine

[Brian P. <bri...@tu...>]

Allen Akin wrote:
> On Tue, Sep 12, 2006 at 12:29:47PM +0800, Chong, Weiliang wrote:
> | ...
> |    When I compile glean on 64-bit machine, I found something wrong with the
> |    file make/common.mak, in the file,
> | 
> |    ifeq ($(PLATFORM), Unix)
> | 
> |    _OPT=\
> | 
> |            -march=pentiumpro \------------------------this march is not
> |    compatibility with 64-bit machine, so I delete this line, and then my
> |    compiling complete successfully.
> | ...
> |    I think march to pentiumpro is out of date, would you like to change this?
> 
> Were you using Intel's compiler, or g++?
> 
> For g++, pentiumpro (equivalent to i686) looks like a good
> lowest-common-denominator choice, so I'm reluctant to change it.
> 
> However, I agree that it should be easier to change the default
> compilation options, so I'd argue that what you've found is a
> shortcoming in the makefiles.  It would be better if they could pick up
> site-specific options without requiring you to edit the source.  
> 
> The best solution is probably to move to automake/autoconfig, but that's
> too big a job for me at the moment.

Personally, I'm not a big fan of autoconfig/automake.  I happily 
removed it from Mesa a few years ago.

The big problem is it seems to seldom work correctly on non-GNU-based 
systems.  I was constantly getting reports of problems on AIX, HPUX, 
IRIX, etc.  I realize those platforms aren't too popular nowadays, but 
they're still important to some Mesa users.  Also, autoconf is fairly 
complicated and I didn't have the know-how or patience to fix it when 
things broke.  I never found a reliable volunteer to babysit autoconf 
either.

However, since Glean doesn't make any shared libraries, libtool (which 
was especially bad) shouldn't be an issue.

I guess you have to weigh the pros and cons.  For a lot of people 
autoconf may work great, but for others it may be worse than the 
current makefile system.

There are other build tools (like cmake, scons, etc) that may be worth 
looking at.

-Brian

Re: [glean-dev] problems of glean compiling on 64-bit machine

[Chong, W. <wei...@in...>]

I am using g++ to compile glean.
Moving to automake/autoconfig is the best way, I also think so. When I =
compile glean at first, I met some problems with make/common.mak, so I =
had to change the file to make it work.=20

Thanks,
--Veelion
-----Original Message-----
From: Allen Akin [mailto:ak...@po...]=20
Sent: 2006=C4=EA9=D4=C212=C8=D5 12:58
To: Chong, Weiliang
Cc: gle...@li...
Subject: Re: [glean-dev] problems of glean compiling on 64-bit machine

On Tue, Sep 12, 2006 at 12:29:47PM +0800, Chong, Weiliang wrote:
| ...
|    When I compile glean on 64-bit machine, I found something wrong =
with the
|    file make/common.mak, in the file,
|=20
|    ifeq ($(PLATFORM), Unix)
|=20
|    _OPT=3D\
|=20
|            -march=3Dpentiumpro \------------------------this march is =
not
|    compatibility with 64-bit machine, so I delete this line, and then =
my
|    compiling complete successfully.
| ...
|    I think march to pentiumpro is out of date, would you like to =
change this?

Were you using Intel's compiler, or g++?

For g++, pentiumpro (equivalent to i686) looks like a good
lowest-common-denominator choice, so I'm reluctant to change it.

However, I agree that it should be easier to change the default
compilation options, so I'd argue that what you've found is a
shortcoming in the makefiles.  It would be better if they could pick up
site-specific options without requiring you to edit the source. =20

The best solution is probably to move to automake/autoconfig, but that's
too big a job for me at the moment.  Would it be acceptable if the
makefiles were changed to pick up options from a local options file, if
one exists?

Allen

Re: [glean-dev] problems of glean compiling on 64-bit machine

[Allen A. <ak...@po...>]

On Tue, Sep 12, 2006 at 12:29:47PM +0800, Chong, Weiliang wrote:
| ...
|    When I compile glean on 64-bit machine, I found something wrong with the
|    file make/common.mak, in the file,
| 
|    ifeq ($(PLATFORM), Unix)
| 
|    _OPT=\
| 
|            -march=pentiumpro \------------------------this march is not
|    compatibility with 64-bit machine, so I delete this line, and then my
|    compiling complete successfully.
| ...
|    I think march to pentiumpro is out of date, would you like to change this?

Were you using Intel's compiler, or g++?

For g++, pentiumpro (equivalent to i686) looks like a good
lowest-common-denominator choice, so I'm reluctant to change it.

However, I agree that it should be easier to change the default
compilation options, so I'd argue that what you've found is a
shortcoming in the makefiles.  It would be better if they could pick up
site-specific options without requiring you to edit the source.  

The best solution is probably to move to automake/autoconfig, but that's
too big a job for me at the moment.  Would it be acceptable if the
makefiles were changed to pick up options from a local options file, if
one exists?

Allen