Menu
▾
▴
glean-dev — Glean development discussions
You can subscribe to this list here.
| 1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2000 |
Jan
(17) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(8) |
Jul
|
Aug
(7) |
Sep
(8) |
Oct
(67) |
Nov
(32) |
Dec
(78) |
| 2001 |
Jan
(20) |
Feb
(5) |
Mar
(8) |
Apr
(9) |
May
(12) |
Jun
|
Jul
(2) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(5) |
Nov
(9) |
Dec
(4) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
(4) |
Jul
(2) |
Aug
(8) |
Sep
(25) |
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(3) |
Sep
|
Oct
(2) |
Nov
|
Dec
(3) |
| 2008 |
Jan
(2) |
Feb
(8) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(5) |
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(2) |
May
|
Jun
(4) |
Jul
(3) |
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(6) |
Dec
(9) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brian P. <br...@vm...> - 2012-05-30 13:38:38
|
On 05/29/2012 01:13 AM, Timothy Arceri wrote: > Hi there, > It's not a massive deal but I was interested in playing around with > glean and when looking at the GNU build page > (http://glean.sourceforge.net/buildgnu.html) some of the information > around getting the source was out of date. Anyway I'm not sure if this > is the best way to do it but I have attached an updated html file with > instructions on getting the source from the git repository rather than > the no longer existing cvs repo. You've also changed all the upper-case tags to lower-case. That kind of obscures the other content changes. All the other html files use upper-case tags, BTW. Would you be willing to provide a patch which just fixes the instructions and does not change all the other tags? BTW, there hasn't been much activity in Glean for a few years now. Piglit is where it's at now. It includes a copy of glean. -Brian |
|
From: Timothy A. <t_a...@ya...> - 2012-05-29 07:13:50
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html><head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <title>Building glean for GNU/Linux</title> <meta name="description" content="building glean for GNU/Linux"> <meta name="author" content="Allen Akin"> <link rev="made" href="mailto:ak...@po..."> </head> <body topmargin="10" bottommargin="10" leftmargin="10" rightmargin="10" marginheight="0" marginwidth="0" bgcolor="#FFFFFF"> <h1>Building <i>glean</i> for GNU/Linux</h1> <p> The present versions of <i>glean</i> Makefiles depend on features of GNU make. (In particular, the automatic re-scanning of all dependency files after any have changed.) If your version of make is known to be significantly incompatible with GNU make, then you will need to acquire a copy of GNU make or modify <i>glean</i>'s Makefiles. </p><p> <i>glean</i> makes extensive use of the C++ Standard Template Library. If your C++ compiler fails to compile <i>glean</i>, you may want to try <a href="http://gcc.gnu.org/">the latest version of gcc</a>. <i>glean</i> was originally developed with egcs 1.1.2; earlier versions are missing some features that <i>glean</i> uses, such as namespaces. </p><h2>Obtain the source code</h2> <p> Obtain the full source tree from the <a href="http://sourceforge.net/scm/?type=git&group_id=430">read-only GIT access page on SourceForge</a>. </p><p> Go to a directory where you want to checkout Glean and run the git command: <PRE> git clone git://glean.git.sourceforge.net/gitroot/glean/glean </PRE> This will create a new sub directory 'glean' containing the Glean source. </p> <h2>Set the GLEAN_ROOT environment variable</h2> <p> To compile or run <i>glean</i>, you will need to set the environment variable <kbd>GLEAN_ROOT</kbd> to the full pathname of the <i>glean</i> source directory. If you're following along, this is the glean directory created by the git clone, so first:</p> <pre> cd glean </pre> and this command should do the trick for users of csh and its descendants: </p><pre> setenv GLEAN_ROOT `pwd` </pre> and this command should work for users of sh and its descendants: <pre> GLEAN_ROOT=`pwd`; export GLEAN_ROOT </pre> Be sure to set the environment variable each time you want to compile or run <i>glean</i>. Perhaps the easiest way to do this is to set it in your shell's startup script. <h2>Set Makefile options</h2> <p> Edit $GLEAN_ROOT/make/common.mak and modify the configuration variables according to your preferences. Some of the variables that are most likely to need customization are: </p><dl> <dt>CONFIG</dt> <dd> This variable selects the operating system and window system for which <i>glean</i> will be compiled. The OS option must be either __UNIX__ or __MS__. The window-system option must be either __X11__ or __WIN__. (Yes, there is some ambiguity between the OS and the window system in Microsoft's case. However, there are X11 products that run under Windows, so the combination of __MS__ and __X11__ is possible.) By default, this variable is set to "-D__UNIX__ -D__X11__". </dd> <dt>CC</dt> <dd> This variable specifies the location of the C++ compiler. By default it is "g++". </dd> <dt>XINC, GLINC, GLUTINC, TIFFINC</dt> <dd> These variables specify the directories containing include files for X, OpenGL, GLUT, and libtiff, respectively. The defaults are /usr/include/X11, /usr/local/include, /usr/local/include, and /usr/include, respectively. </dd> <dt>XLIB, GLLIB, GLUTLIB, TIFFLIB</dt> <dd> These variables specify the directories containing libraries (libX11, libGL, libglut, and libtiff, respectively). The defaults are /usr/X11R6/lib, /usr/local/lib, /usr/local/lib, and /usr/lib, respectively. </dd> <dt>_INC, _OPT, _DBG, _WARN, _LIBDIR, _LIB, _PROF</dt> <dd> These variables define C++ command-line options for include-file directories, optimization, debugging, warnings, library directories, libraries, and profiling. These apply universally, to all <i>glean</i> compilations. Individual Makefiles can make local additions to these defaults by defining corresponding variables whose names do not have a leading underscore. Note that it is possible to configure your system so that the <i>order</i> of include-file or library-file directories is significant; for example, by having two versions of the same include file, one in /usr/include and one in /usr/local/include. In such cases, you'll need to make sure that the _INC and _LIB variables specify directories in precisely the order you require. </dd> </dl> <h2>Build <i>glean</i></h2> <p> When you've finished editing the Makefile, simply type </p><pre> cd src make install </pre> This will build <i>glean</i> and the other tools in the suite, and install everything in <kbd>$GLEAN_ROOT/bin</kbd>, <kbd>$GLEAN_ROOT/include</kbd>, and <kbd>$GLEAN_ROOT/lib</kbd>. Nothing will be altered outside the <kbd>$GLEAN_ROOT</kbd> directory hierarchy. <p> Note that you <b>must</b> use <kbd>make install</kbd> rather than plain <kbd>make</kbd>, otherwise the headers and libraries won't be copied to <kbd>$GLEAN_ROOT</kbd> and subsequent components will fail to build. </p><hr> <small> <ul type="DISC"> <li> <a href="http://glean.sourceforge.net/index.html"><i>glean</i> home</a> </li><li> <a href="http://glean.sourceforge.net/whatis.html">What is <i>glean</i>?</a> </li><li> <a href="http://glean.sourceforge.net/build.html">How do I build <i>glean</i>?</a> </li><li> <a href="http://glean.sourceforge.net/run.html">How do I run <i>glean</i>?</a> </li><li> <a href="http://glean.sourceforge.net/next.html">Where do we go from here?</a> <ul type="CIRCLE"> <li> <a href="http://glean.sourceforge.net/newtest.html">Adding new tests</a> </li><li> <a href="http://glean.sourceforge.net/newfeat.html">Adding new infrastructure features</a> </li><li> <a href="http://glean.sourceforge.net/overview.html">Overview of <i>glean</i> internals</a> </li><li> <a href="http://glean.sourceforge.net/repo.html">Creating a repository of results</a> </li><li> <a href="http://glean.sourceforge.net/port.html">Porting <i>glean</i></a> </li><li> <a href="http://glean.sourceforge.net/cleanup.html">Cleaning up loose ends</a> </li></ul> </li><li> <a href="http://glean.sourceforge.net/changes.html">What has changed recently?</a> </li></ul> </small> </body></html> |
|
From: Jose F. <jfo...@vm...> - 2011-07-15 15:19:27
|
I've made a new branch, "cmake", where I replace scons build system with cmake. Although cmake is less powerfull, in respect with convenience library support -- not needed by glean --, it requires much less costumization/maintainance effort, and is easier to use. So, in similarity with mesa demos, I've decided to replace scons with cmake as a cross-platform build system. I've tested this with linux, msvc, cross-mingw32, and mac os x. Let me know if there are any concerns before I merge this branch into master. Jose |
|
From: José F. <jfo...@vm...> - 2011-02-07 13:03:34
|
On Sun, 2011-02-06 at 09:27 -0800, Brian Paul wrote: > On 02/06/2011 04:04 AM, José Fonseca wrote: > > Using the same approach as texCombine. > > > > Logged all combinations and ensured that the frequencies match the desired. > > Looks good. Maybe the '1000' magic number should be replaced with a > #define HUGE_STEP 1000, or something like that. Yes, good point. Jose |
|
From: Brian P. <br...@vm...> - 2011-02-06 17:27:40
|
On 02/06/2011 04:04 AM, José Fonseca wrote: > Using the same approach as texCombine. > > Logged all combinations and ensured that the frequencies match the desired. Looks good. Maybe the '1000' magic number should be replaced with a #define HUGE_STEP 1000, or something like that. -Brian |
|
From: José F. <jfo...@vm...> - 2011-02-06 11:04:29
|
Using the same approach as texCombine.
Logged all combinations and ensured that the frequencies match the desired.
---
src/glean/tblend.cpp | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/src/glean/tblend.cpp b/src/glean/tblend.cpp
index 057ee4a..00f64e1 100644
--- a/src/glean/tblend.cpp
+++ b/src/glean/tblend.cpp
@@ -695,6 +695,7 @@ BlendFuncTest::runOne(BlendFuncResult& r, Window& w) {
unsigned numOperatorsRGB, numOperatorsA;
BlendFuncResult::PartialResult p;
bool allPassed = true;
+ unsigned testNo, testStride;
// test for features, get function pointers
if (GLUtils::getVersion() >= 1.4) {
@@ -770,6 +771,18 @@ BlendFuncTest::runOne(BlendFuncResult& r, Window& w) {
numOperatorsA = 1; // just ADD
}
+ // If quick mode, run fewer tests
+ if (env->options.quick) {
+ testStride = 11; // a prime number
+ assert(ELEMENTS(srcFactors) % testStride);
+ assert(ELEMENTS(dstFactors) % testStride);
+ assert(ELEMENTS(operators) % testStride);
+ }
+ else {
+ testStride = 1;
+ }
+ testNo = testStride - 1;
+
#if 0
// use this to test a single combination:
p.srcRGB = p.srcA = GL_SRC_ALPHA;
@@ -831,6 +844,15 @@ BlendFuncTest::runOne(BlendFuncResult& r, Window& w) {
needsBlendColor(p.dstA)))
continue;
+ // skip all but every testStride-th test
+ ++testNo;
+ if (testNo == testStride || step >= 1000) {
+ testNo = 0;
+ }
+ else {
+ continue;
+ }
+
if (!runCombo(r, w, p, *env)) {
allPassed = false;
}
--
1.7.2.3
|
|
From: Carl W. <cw...@cw...> - 2010-07-23 16:23:13
|
According to the latest GLSL specification, code without a #version
directive will be assumed to target GLSL version 1.10. And on the
topic of type conversion, the GLSL 1.10 specification says:
The assignment operator stores the value of expression into
lvalue. It will compile only if expression and lvalue have the
same type. All desired type-conversions must be specified
explicitly via a constructor. [Section 5.8]
Meanwhile, these three tests each have a construct in which an integer
rvalue is assigned to a float lvalue. This implicit conversion is
supported as of GLSL 1.20, so adding a "#version 120" directive makes
these tests conformant.
---
src/glean/tglsl1.cpp | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/glean/tglsl1.cpp b/src/glean/tglsl1.cpp
index 94ff477..54cb39c 100644
--- a/src/glean/tglsl1.cpp
+++ b/src/glean/tglsl1.cpp
@@ -494,6 +494,7 @@ static const ShaderProgram Programs[] = {
{
"integer, float arithmetic",
NO_VERTEX_SHADER,
+ "#version 120 \n"
"void main() { \n"
" int k = 100; \n"
" gl_FragColor.x = k * 0.01; \n"
@@ -521,6 +522,7 @@ static const ShaderProgram Programs[] = {
{
"integer division",
NO_VERTEX_SHADER,
+ "#version 120 \n"
"void main() { \n"
" int i = 15, j = 6; \n"
" int k = i / j; \n"
@@ -534,6 +536,7 @@ static const ShaderProgram Programs[] = {
{
"integer division with uniform var",
NO_VERTEX_SHADER,
+ "#version 120 \n"
"// as above, but prevent compile-time evaluation \n"
"uniform vec4 uniform1; \n"
"void main() { \n"
--
1.7.1.249.g74df7
|
|
From: Carl W. <cw...@cw...> - 2010-07-23 16:17:39
|
This allows the user to continue to type at other windows while glean tests are running. --- src/glean/dsurf.cpp | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/src/glean/dsurf.cpp b/src/glean/dsurf.cpp index f158921..2a3bea1 100644 --- a/src/glean/dsurf.cpp +++ b/src/glean/dsurf.cpp @@ -87,6 +87,7 @@ legacyMethod: // Create the window: XSetWindowAttributes xswa; + XWMHints *wmHints; xswa.background_pixmap = None; xswa.border_pixel = 0; xswa.colormap = ChooseColormap(winSys->dpy, config->vi); @@ -111,6 +112,15 @@ legacyMethod: XSetStandardProperties(winSys->dpy, xWindow, "glean", "glean", None, 0, 0, &sizeHints); + // Try to prevent test window from stealing focus + wmHints = XAllocWMHints(); + wmHints->flags |= InputHint; + wmHints->input = False; + + XSetWMHints(winSys->dpy, xWindow, wmHints); + + XFree(wmHints); + // Map the window and wait for it to appear: XMapWindow(winSys->dpy, xWindow); XEvent event; -- 1.7.1.249.g74df7 |
|
From: Eric A. <er...@an...> - 2010-05-14 20:21:35
|
Given that failure in blending is usually "I plugged in the wrong
factor, whoops", testing 64 different combos of random src/dst colors
instead of 1024 seems reasonable. Brings runtime down from 2 minutes
to 20 seconds on my system.
---
src/glean/tblend.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glean/tblend.h b/src/glean/tblend.h
index abf3c80..3080a26 100644
--- a/src/glean/tblend.h
+++ b/src/glean/tblend.h
@@ -35,7 +35,7 @@
namespace GLEAN {
-#define drawingSize 32 // We will check each pair of blend factors
+#define drawingSize 8 // We will check each pair of blend factors
// for each pixel in a square image of this
// dimension, so if you make it too large,
// the tests may take quite a while to run.
--
1.7.0.4
|
|
From: Eric A. <er...@an...> - 2010-05-14 20:21:35
|
This was a massive bottleneck: 5 * 5 * 12 * 12 * 13 * 13 or so is quite a few frames, especially when you're synced to vblank. Brings runtime down to 2 minutes on my system. --- src/glean/tblend.cpp | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/glean/tblend.cpp b/src/glean/tblend.cpp index 057ee4a..51d29fe 100644 --- a/src/glean/tblend.cpp +++ b/src/glean/tblend.cpp @@ -617,7 +617,8 @@ BlendFuncTest::runCombo(BlendFuncResult& r, Window& w, runFactorsResult res(runFactors(p.srcRGB, p.srcA, p.dstRGB, p.dstA, p.opRGB, p.opA, p.constColor, *(r.config), env)); - w.swap(); + if (!env.options.quick) + w.swap(); p.rbErr = res.readbackErrorBits; p.blErr = res.blendErrorBits; -- 1.7.0.4 |
|
From: Allen A. <ak...@ar...> - 2009-12-10 07:16:28
|
On Wed, Dec 09, 2009 at 09:08:51AM -0700, Brian Paul wrote: >> If ALL the other fields match, then the XID doesn't matter, right? The >> configs should be identical from the GL's point of view? > > Yes, except for the case I described below (there's some other attribute > that glean's not aware of). Yes. By "ALL" I meant everything, including the attributes that glean previously ignored. But I believe we're in agreement on that. > I don't have time for any major changes now. So here's a new patch > which simply looks for an exact match before doing the error-based match > algorithm. It fixes the readpixPerf problem. Looks good to me. Allen |
|
From: Brian P. <br...@vm...> - 2009-12-09 16:09:04
|
Allen Akin wrote: > On Tue, Dec 08, 2009 at 06:54:40PM -0700, Brian Paul wrote: > | In the case of readpixPerf, we only filter for rgb visuals. Buf if > | the visual also has Z (or stencil) we do extra tests (and produce > | additional test results). So, the ``A'' config and ``B'' config list > | were loosely filtered, but the test results are tied to specific > | configs. The 'looseness' of the match() function causes us to compare > | results from disparate configs. > > I guess I would have separated the tests -- one for color buffers, one > for depth buffers, one for stencil buffers, and so on. Not only would > that have solved the match() problem, but it would have allowed other > tests to depend on exactly the subset of readpixPerf tests that they > need. > > But that might not be expedient at this point. So one thing that really > makes sense to me is to ensure that exact matches take precedence over > any partial match. That ought to cover all the most common cases. > > | Right. But when the XIDs match AND ALL the other fields match, the > | configs should be identical (and the results comparable), even if the > | results come from different machines/drivers. > > If ALL the other fields match, then the XID doesn't matter, right? The > configs should be identical from the GL's point of view? Yes, except for the case I described below (there's some other attribute that glean's not aware of). > | But in the case where there's many configs with identical fields, but > | different XIDs, the equal() test should consider the XID. > | > | With GLX, for example, we can have two visuals which have identical > | attributes but one is TrueColor and the other is DirectColor. The > | DrawingSurfaceConfig code doesn't consider visual classes. This is > | where matching the XID is good. > > If that really matters, then maybe Visual class should be added to the > set of filterable attributes. I don't think I ever encountered a system > where the distinction between DirectColor and TrueColor mattered to the > GL, but maybe there are examples nowadays. I'm happy to defer to your > judgement there. I don't have time for any major changes now. So here's a new patch which simply looks for an exact match before doing the error-based match algorithm. It fixes the readpixPerf problem. -Brian |
|
From: Allen A. <ak...@ar...> - 2009-12-09 07:30:14
|
On Tue, Dec 08, 2009 at 06:54:40PM -0700, Brian Paul wrote: | In the case of readpixPerf, we only filter for rgb visuals. Buf if | the visual also has Z (or stencil) we do extra tests (and produce | additional test results). So, the ``A'' config and ``B'' config list | were loosely filtered, but the test results are tied to specific | configs. The 'looseness' of the match() function causes us to compare | results from disparate configs. I guess I would have separated the tests -- one for color buffers, one for depth buffers, one for stencil buffers, and so on. Not only would that have solved the match() problem, but it would have allowed other tests to depend on exactly the subset of readpixPerf tests that they need. But that might not be expedient at this point. So one thing that really makes sense to me is to ensure that exact matches take precedence over any partial match. That ought to cover all the most common cases. | Right. But when the XIDs match AND ALL the other fields match, the | configs should be identical (and the results comparable), even if the | results come from different machines/drivers. If ALL the other fields match, then the XID doesn't matter, right? The configs should be identical from the GL's point of view? | But in the case where there's many configs with identical fields, but | different XIDs, the equal() test should consider the XID. | | With GLX, for example, we can have two visuals which have identical | attributes but one is TrueColor and the other is DirectColor. The | DrawingSurfaceConfig code doesn't consider visual classes. This is | where matching the XID is good. If that really matters, then maybe Visual class should be added to the set of filterable attributes. I don't think I ever encountered a system where the distinction between DirectColor and TrueColor mattered to the GL, but maybe there are examples nowadays. I'm happy to defer to your judgement there. Allen |
|
From: Brian P. <br...@vm...> - 2009-12-09 01:54:53
|
Hi Allen, Allen Akin wrote: > On Tue, Dec 08, 2009 at 10:23:39AM -0700, Brian Paul wrote: >> ... >> In particular, this bit of code is used to compare the Z and stencil >> attributes: >> >> if (z && c.z) >> error += abs(z - c.z); >> if (s && c.s) >> error += abs(s - c.s); > > The (maybe too poorly documented) reason for this is mentioned in the > comments at the head of the function: > > // To keep this problem manageable, we'll assume that both the config > // to be matched (call it the ``A'' config) and the vector of configs to > // choose from (call them the ``B'' configs) were selected by a test > // using a single filter. Thus we can ignore any differences in buffer > // availability (because we know those are irrelevant to the test), and > // concentrate on picking configs for which the available buffers are > // (in some sense) closest in size. > > If a test must have depth and stencil buffers to produce meaningful > results, then its drawing surface filter should require a nonzero "z" > and "s". As a result, all drawing surface configs passed to match() for > that test will have nonzero "z" and "s" values. That eliminates the > case you ran into. > > On the flip side, if a test doesn't care whether it has depth or stencil > buffers, then its drawing surface filter won't specify anything for > those. As a result, some of the drawing surface configs passed to > match() will have zero "z" and "s" values, and some won't, but that > difference isn't significant. The code increments the error total only > if both surfaces have nonzero "z" or "s" values -- that is, a missing > buffer doesn't affect the error total one way or another, an exact match > doesn't increase the error total, but a failure to match two nonzero > depths increases the error total. > > So, my first guess is that the test that exhibits this problem doesn't > have a proper drawing surface filter. Does changing that fix the > glitch, or do we still need a better match()? In the case of readpixPerf, we only filter for rgb visuals. Buf if the visual also has Z (or stencil) we do extra tests (and produce additional test results). So, the ``A'' config and ``B'' config list were loosely filtered, but the test results are tied to specific configs. The 'looseness' of the match() function causes us to compare results from disparate configs. >> Furthermore, other fields like db and stereo weren't even compared. > > If any test requires db or stereo in its drawing surface filter, then > match() should check those. I don't remember that there were any such > tests, which may explain why match() didn't check those buffers. But if > you change it, it still needs to do the right thing (as above) for tests > that don't care about db or stereo. I think we also have some tests that check if the visual is single or double-buffered and produce different/additional results. I have a feeling this violates an assumption in Glean's infrastructure. >> To fix this, I modified the match function to first look for an _exact_ >> match where all fields (including X visual ID) were the same... > > The reason I didn't do this in the first place was that glean might be > applied to compare runs from two different driver versions or two > different drivers, so an XID match might be bogus. Right. But when the XIDs match AND ALL the other fields match, the configs should be identical (and the results comparable), even if the results come from different machines/drivers. But in the case where there's many configs with identical fields, but different XIDs, the equal() test should consider the XID. With GLX, for example, we can have two visuals which have identical attributes but one is TrueColor and the other is DirectColor. The DrawingSurfaceConfig code doesn't consider visual classes. This is where matching the XID is good. -Brian |
|
From: Allen A. <ak...@ar...> - 2009-12-09 01:54:30
|
On Tue, Dec 08, 2009 at 10:23:39AM -0700, Brian Paul wrote: >... > In particular, this bit of code is used to compare the Z and stencil > attributes: > > if (z && c.z) > error += abs(z - c.z); > if (s && c.s) > error += abs(s - c.s); The (maybe too poorly documented) reason for this is mentioned in the comments at the head of the function: // To keep this problem manageable, we'll assume that both the config // to be matched (call it the ``A'' config) and the vector of configs to // choose from (call them the ``B'' configs) were selected by a test // using a single filter. Thus we can ignore any differences in buffer // availability (because we know those are irrelevant to the test), and // concentrate on picking configs for which the available buffers are // (in some sense) closest in size. If a test must have depth and stencil buffers to produce meaningful results, then its drawing surface filter should require a nonzero "z" and "s". As a result, all drawing surface configs passed to match() for that test will have nonzero "z" and "s" values. That eliminates the case you ran into. On the flip side, if a test doesn't care whether it has depth or stencil buffers, then its drawing surface filter won't specify anything for those. As a result, some of the drawing surface configs passed to match() will have zero "z" and "s" values, and some won't, but that difference isn't significant. The code increments the error total only if both surfaces have nonzero "z" or "s" values -- that is, a missing buffer doesn't affect the error total one way or another, an exact match doesn't increase the error total, but a failure to match two nonzero depths increases the error total. So, my first guess is that the test that exhibits this problem doesn't have a proper drawing surface filter. Does changing that fix the glitch, or do we still need a better match()? > Furthermore, other fields like db and stereo weren't even compared. If any test requires db or stereo in its drawing surface filter, then match() should check those. I don't remember that there were any such tests, which may explain why match() didn't check those buffers. But if you change it, it still needs to do the right thing (as above) for tests that don't care about db or stereo. > To fix this, I modified the match function to first look for an _exact_ > match where all fields (including X visual ID) were the same... The reason I didn't do this in the first place was that glean might be applied to compare runs from two different driver versions or two different drivers, so an XID match might be bogus. Allen |
|
From: Brian P. <br...@vm...> - 2009-12-08 17:23:53
|
A coworker found that glean was hitten an assertion failure in
treadpixperf.cpp when doing results comparisons. I tracked the issue
down to a problem with the drawing surface config matching code.
A glean results file contains some number of drawing surface config
descriptions followed by test-specific results. When comparing
results, glean tries to finding matching ds configs in the two files
to compare. The DrawingSurfaceConfig::match() function was doing a
poor job of matching configs so we wound up trying to compare test
results from (very) different configs and failing.
In particular, this bit of code is used to compare the Z and stencil
attributes:
if (z && c.z)
error += abs(z - c.z);
if (s && c.s)
error += abs(s - c.s);
If z = 0 and c.z = 24 the error variable wasn't updated. I believe
the correct way to do this is simply:
error += abs(z - c.z);
error += abs(s - c.s);
Furthermore, other fields like db and stereo weren't even compared.
Even after I fixed this, however, the matching code sometimes found
that two configs were matches when there were in fact other, even
better/exact matches.
To fix this, I modified the match function to first look for an
_exact_ match where all fields (including X visual ID) were the same.
If that fails, then try the error-based matching algorithm.
Furthermore, I modifed the error-based comparison code to check more
fields and use different error weights for different fields.
The attached patch implements these changes. The treadpixperf
assertion no longer fails and everything else I've tested works properly.
If there are no concerns/objections I'll commit this later.
Be sure you grab the latest code from git. I just recently committed
some other fixes (uninitialized memory, etc).
-Brian
|
|
From: Brian P. <br...@vm...> - 2009-12-02 14:11:59
|
Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Paul wrote: >> Ian Romanick wrote: >>> This patch series fixes several cosmetic and functional issues with >>> the pointSprite test. The two primary functional issues are addressed >>> by patches 3 and 4. Patch 3 modifies the test failure logging to log >>> the correct sprite coordinate origin when a test fails. Patch 4 >>> modifies the test to only GL_POINT_SPRITE_COORD_ORIGIN if OpenGL 2.0 >>> is supported. >> I just scanned the patches and they look reasonable to me. > > Since sourceforge switched to GIT, I don't think I have commit access. > Could you commit these patches for me? Done. -Brian |
|
From: Ian R. <id...@fr...> - 2009-12-02 00:26:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > Ian Romanick wrote: >> This patch series fixes several cosmetic and functional issues with >> the pointSprite test. The two primary functional issues are addressed >> by patches 3 and 4. Patch 3 modifies the test failure logging to log >> the correct sprite coordinate origin when a test fails. Patch 4 >> modifies the test to only GL_POINT_SPRITE_COORD_ORIGIN if OpenGL 2.0 >> is supported. > > I just scanned the patches and they look reasonable to me. Since sourceforge switched to GIT, I don't think I have commit access. Could you commit these patches for me? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksVsqMACgkQX1gOwKyEAw9gVgCgkFe/GOqo1vNMTWrBo2vWX0uN IWwAnAwF8o/FYnuIHBwiMlT3kd+bXSXd =SPaS -----END PGP SIGNATURE----- |
|
From: Brian P. <br...@vm...> - 2009-12-01 18:13:06
|
Ian Romanick wrote: > This patch series fixes several cosmetic and functional issues with > the pointSprite test. The two primary functional issues are addressed > by patches 3 and 4. Patch 3 modifies the test failure logging to log > the correct sprite coordinate origin when a test fails. Patch 4 > modifies the test to only GL_POINT_SPRITE_COORD_ORIGIN if OpenGL 2.0 > is supported. I just scanned the patches and they look reasonable to me. -Brian |
|
From: Ian R. <id...@fr...> - 2009-11-30 21:22:24
|
From: Ian Romanick <ian...@in...>
Signed-off-by: Ian Romanick <ian...@in...>
---
src/glean/tpointsprite.cpp | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/glean/tpointsprite.cpp b/src/glean/tpointsprite.cpp
index 974bfc7..9c4ebee 100644
--- a/src/glean/tpointsprite.cpp
+++ b/src/glean/tpointsprite.cpp
@@ -55,9 +55,11 @@ static PFNGLPOINTPARAMETERFPROC glPointParameterf_func = NULL;
//background color
static GLfloat bgColor[4] = {0.0, 0.0, 0.0, 0.0};
-//mipmap texture's color, every texture partite to upper and lower part that
-//has different colors
-//for 1x1 texture, only lower part is used
+// Partition each mipmap into two halves. The top half gets one color, and
+// the bottom half gets a different color. Use a different pair of colors for
+// each LOD.
+//
+// For the 1x1 LOD, only lower part (second color in the table) is used.
static GLfloat texColor[6][2][4] = {
{{1.0, 0.0, 0.0, 1.0}, {0.0, 1.0, 0.0, 1.0}}, // 32x32
{{0.0, 0.0, 1.0, 1.0}, {1.0, 1.0, 0.0, 1.0}}, // 16x16
@@ -146,7 +148,7 @@ PointSpriteTest::CheckDefaultState(MultiTestResult &r)
if (enable != GL_FALSE)
{
env->log << name << "subcase FAIL: "
- << "PointSprite should be disabled defaultlly\n";
+ << "PointSprite should be disabled by default\n";
r.numFailed++;
} else {
r.numPassed++;
@@ -369,7 +371,8 @@ PointSpriteTest::runOne(MultiTestResult &r, Window &w)
if (maxPointSize > WINSIZE / 2)
maxPointSize = WINSIZE / 2;
- //primitive may be point or polygon which mode is GL_POINT
+ // Draw GL_POINTS primitives, and draw GL_POLYGON primitives with the
+ // polygon mode set to GL_POINT.
for (primType = 0; primType < 2; primType ++)
{
for (coordOrigin = 0; coordOrigin < 2; coordOrigin++)
--
1.6.2.5
|
|
From: Ian R. <id...@fr...> - 2009-11-30 21:14:46
|
From: Ian Romanick <ian...@in...>
GL_POINT_SPRITE_COORD_ORIGIN is not part of GL_ARB_point_sprite. It
was added when the functionality was merged into core OpenGL 2.0.
Therefore, if OpenGL 2.0 is not supported, don't test any state
related to GL_POINT_SPRITE_COORD_ORIGIN.
Signed-off-by: Ian Romanick <ian...@in...>
---
src/glean/tpointsprite.cpp | 48 ++++++++++++++++++++++++++-----------------
src/glean/tpointsprite.h | 1 +
2 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/src/glean/tpointsprite.cpp b/src/glean/tpointsprite.cpp
index 0aa8ddf..834ee7b 100644
--- a/src/glean/tpointsprite.cpp
+++ b/src/glean/tpointsprite.cpp
@@ -50,7 +50,7 @@
namespace GLEAN {
-static PFNGLPOINTPARAMETERFPROC glPointParameterf_func = NULL;
+static PFNGLPOINTPARAMETERIPROC glPointParameteri_func = NULL;
//background color
static GLfloat bgColor[4] = {0.0, 0.0, 0.0, 0.0};
@@ -166,19 +166,22 @@ PointSpriteTest::CheckDefaultState(MultiTestResult &r)
r.numPassed++;
}
- // check coordinate origin, default is UPPER_LEFT
- glEnable(GL_POINT_SPRITE);
- glGetIntegerv(GL_POINT_SPRITE_COORD_ORIGIN, &coordOrigin);
- if (coordOrigin != GL_UPPER_LEFT)
- {
- env->log << name << "subcase FAIL: "
- << "defult value of COORD_ORIGIN should be GL_UPPER_LEFT\n";
- r.numFailed++;
- } else {
- r.numPassed++;
- }
+ if (have_2_0) {
+ // check coordinate origin, default is UPPER_LEFT
+ glEnable(GL_POINT_SPRITE);
+ glGetIntegerv(GL_POINT_SPRITE_COORD_ORIGIN, &coordOrigin);
+ if (coordOrigin != GL_UPPER_LEFT)
+ {
+ env->log << name << "subcase FAIL: "
+ "defult value of COORD_ORIGIN "
+ "should be GL_UPPER_LEFT\n";
+ r.numFailed++;
+ } else {
+ r.numPassed++;
+ }
- glDisable(GL_POINT_SPRITE);
+ glDisable(GL_POINT_SPRITE);
+ }
}
GLboolean
@@ -341,8 +344,13 @@ PointSpriteTest::runOne(MultiTestResult &r, Window &w)
(void) w;
- glPointParameterf_func = (PFNGLPOINTPARAMETERFPROC) GLUtils::getProcAddress("glPointParameterf");
- assert(glPointParameterf_func);
+ have_2_0 = (strtod((const char *) glGetString(GL_VERSION), NULL) > 2.0);
+ if (have_2_0) {
+ glPointParameteri_func = (PFNGLPOINTPARAMETERIPROC)
+ GLUtils::getProcAddress("glPointParameteri");
+
+ assert(glPointParameteri_func);
+ }
CheckDefaultState(r);
@@ -375,6 +383,7 @@ PointSpriteTest::runOne(MultiTestResult &r, Window &w)
// polygon mode set to GL_POINT.
for (primType = 0; primType < 2; primType ++)
{
+ const unsigned numOrigin = (have_2_0) ? 2 : 1;
static const GLenum origin[2] = {
GL_UPPER_LEFT, GL_LOWER_LEFT
};
@@ -382,11 +391,12 @@ PointSpriteTest::runOne(MultiTestResult &r, Window &w)
"GL_UPPER_LEFT", "GL_LOWER_LEFT"
};
- for (coordOrigin = 0; coordOrigin < 2; coordOrigin++)
+ for (coordOrigin = 0; coordOrigin < numOrigin; coordOrigin++)
{
-
- glPointParameterf_func(GL_POINT_SPRITE_COORD_ORIGIN,
- origin[coordOrigin]);
+ if (have_2_0) {
+ glPointParameteri_func(GL_POINT_SPRITE_COORD_ORIGIN,
+ origin[coordOrigin]);
+ }
pointSize = 1.85;
for (; pointSize <= maxPointSize; pointSize += 2.0)
diff --git a/src/glean/tpointsprite.h b/src/glean/tpointsprite.h
index 90cd09f..089afa0 100644
--- a/src/glean/tpointsprite.h
+++ b/src/glean/tpointsprite.h
@@ -53,6 +53,7 @@ class PointSpriteTest: public MultiTest
private:
GLfloat *texImages[6];
GLfloat mTolerance[3];
+ bool have_2_0;
void GenMipmap();
void SetupMipmap(GLuint *texID);
--
1.6.2.5
|
|
From: Ian R. <id...@fr...> - 2009-11-30 21:14:44
|
From: Ian Romanick <ian...@in...>
Test the coordinate origin GL_UPPER_LEFT first. Also, log the correct origin
string when a test fails. Previously the log message was inverted, and this
was very misleading when debugging test failures.
Signed-off-by: Ian Romanick <ian...@in...>
---
src/glean/tpointsprite.cpp | 26 +++++++++++++++++---------
src/glean/tpointsprite.h | 2 +-
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/src/glean/tpointsprite.cpp b/src/glean/tpointsprite.cpp
index 9c4ebee..0aa8ddf 100644
--- a/src/glean/tpointsprite.cpp
+++ b/src/glean/tpointsprite.cpp
@@ -274,14 +274,14 @@ FindNonBlack(const GLfloat *buf, GLint w, GLint h, GLint *x0, GLint *y0)
* @param coordOrigin: coordinate origin--UPPER_LEFT or LOWER_LEFT
*/
GLboolean
-PointSpriteTest::ComparePixels(GLfloat *buf, int pSize, int coordOrigin)
+PointSpriteTest::ComparePixels(GLfloat *buf, int pSize, GLenum coordOrigin)
{
GLfloat *lowerColor, *upperColor, *expectedColor;
GLint i, j;
GLint x0, y0;
- lowerColor = GetTexColor(pSize, coordOrigin ? 0 : 1);
- upperColor = GetTexColor(pSize, coordOrigin ? 1 : 0);
+ lowerColor = GetTexColor(pSize, (coordOrigin == GL_UPPER_LEFT) ? 0 : 1);
+ upperColor = GetTexColor(pSize, (coordOrigin == GL_UPPER_LEFT) ? 1 : 0);
// Find first (lower-left) pixel that's not black.
// The pixels hit by sprite rasterization may vary from one GL to
@@ -375,13 +375,18 @@ PointSpriteTest::runOne(MultiTestResult &r, Window &w)
// polygon mode set to GL_POINT.
for (primType = 0; primType < 2; primType ++)
{
+ static const GLenum origin[2] = {
+ GL_UPPER_LEFT, GL_LOWER_LEFT
+ };
+ static const char *const origin_strings[2] = {
+ "GL_UPPER_LEFT", "GL_LOWER_LEFT"
+ };
+
for (coordOrigin = 0; coordOrigin < 2; coordOrigin++)
{
- if (coordOrigin)
- glPointParameterf_func(GL_POINT_SPRITE_COORD_ORIGIN, GL_UPPER_LEFT);
- else
- glPointParameterf_func(GL_POINT_SPRITE_COORD_ORIGIN, GL_LOWER_LEFT);
+ glPointParameterf_func(GL_POINT_SPRITE_COORD_ORIGIN,
+ origin[coordOrigin]);
pointSize = 1.85;
for (; pointSize <= maxPointSize; pointSize += 2.0)
@@ -408,10 +413,13 @@ PointSpriteTest::runOne(MultiTestResult &r, Window &w)
glReadPixels(0, 0, WINSIZE/2, WINSIZE/2, GL_RGB, GL_FLOAT, buf);
- if (!ComparePixels(buf, expectedSize, coordOrigin))
+ if (!ComparePixels(buf, expectedSize,
+ origin[coordOrigin]))
{
env->log << "\tPrimitive type: " << (primType ? "GL_POLYGON" : "GL_POINTS") << "\n";
- env->log << "\tCoord Origin at: " << (coordOrigin ? "GL_LOWER_LEFT" : "GL_UPPER_LEFT") << "\n";
+ env->log << "\tCoord Origin at: " <<
+ origin_strings[coordOrigin] <<
+ "\n";
env->log << "\tPointSize: " << pointSize << "\n";
r.numFailed++;
r.numPassed--;
diff --git a/src/glean/tpointsprite.h b/src/glean/tpointsprite.h
index ed04c8f..90cd09f 100644
--- a/src/glean/tpointsprite.h
+++ b/src/glean/tpointsprite.h
@@ -61,7 +61,7 @@ private:
GLboolean OutOfPoint(int x, int y, int pSize, int x0, int y0);
GLfloat *GetTexColor(int pSize, int dir);
GLboolean CompareColor(GLfloat *actual, GLfloat *expected);
- GLboolean ComparePixels(GLfloat *buf, int pSize, int coordOrigin);
+ GLboolean ComparePixels(GLfloat *buf, int pSize, GLenum coordOrigin);
}; // class PointSpriteTest
} // namespace GLEAN
--
1.6.2.5
|
|
From: Ian R. <id...@fr...> - 2009-11-30 21:14:43
|
This patch series fixes several cosmetic and functional issues with the pointSprite test. The two primary functional issues are addressed by patches 3 and 4. Patch 3 modifies the test failure logging to log the correct sprite coordinate origin when a test fails. Patch 4 modifies the test to only GL_POINT_SPRITE_COORD_ORIGIN if OpenGL 2.0 is supported. |
|
From: Ian R. <id...@fr...> - 2009-11-30 21:14:42
|
From: Ian Romanick <ian...@in...>
Previously the code used a mixture of, for example,
GL_POINT_SPRITE_ARB and GL_POINT_SPRITE.
Signed-off-by: Ian Romanick <ian...@in...>
---
src/glean/tpointsprite.cpp | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/glean/tpointsprite.cpp b/src/glean/tpointsprite.cpp
index 8cb2574..974bfc7 100644
--- a/src/glean/tpointsprite.cpp
+++ b/src/glean/tpointsprite.cpp
@@ -131,7 +131,7 @@ PointSpriteTest::SetupMipmap(GLuint *texID)
glTexImage2D(GL_TEXTURE_2D, 5, GL_RGBA, 1, 1, 0,
GL_RGBA, GL_FLOAT, texImages[5]);
- glTexEnvf(GL_POINT_SPRITE_ARB, GL_COORD_REPLACE_ARB, GL_TRUE);
+ glTexEnvf(GL_POINT_SPRITE, GL_COORD_REPLACE, GL_TRUE);
}
void
@@ -142,7 +142,7 @@ PointSpriteTest::CheckDefaultState(MultiTestResult &r)
GLint coordOrigin;
// check point sprite status, default is GL_FALSE
- enable = glIsEnabled(GL_POINT_SPRITE_ARB);
+ enable = glIsEnabled(GL_POINT_SPRITE);
if (enable != GL_FALSE)
{
env->log << name << "subcase FAIL: "
@@ -153,7 +153,7 @@ PointSpriteTest::CheckDefaultState(MultiTestResult &r)
}
// check coordinate replacement, default is GL_FALSE
- glGetTexEnviv(GL_POINT_SPRITE_ARB, GL_COORD_REPLACE_ARB, &coordReplace);
+ glGetTexEnviv(GL_POINT_SPRITE, GL_COORD_REPLACE, &coordReplace);
if (coordReplace != GL_FALSE)
{
@@ -362,10 +362,10 @@ PointSpriteTest::runOne(MultiTestResult &r, Window &w)
buf = (GLfloat *)malloc(3 * WINSIZE * WINSIZE / 4 * sizeof(GLfloat));
- // enable point_sprite_ARB
- glEnable(GL_POINT_SPRITE_ARB);
+ // Enable point sprite mode
+ glEnable(GL_POINT_SPRITE);
- glGetFloatv(GL_POINT_SIZE_MAX_ARB, &maxPointSize);
+ glGetFloatv(GL_POINT_SIZE_MAX, &maxPointSize);
if (maxPointSize > WINSIZE / 2)
maxPointSize = WINSIZE / 2;
@@ -420,7 +420,7 @@ PointSpriteTest::runOne(MultiTestResult &r, Window &w)
}
glDeleteTextures(1, &texID);
- glDisable(GL_POINT_SPRITE_ARB);
+ glDisable(GL_POINT_SPRITE);
free(buf);
for (i = 0; i < 6; i++)
free(texImages[i]);
--
1.6.2.5
|
|
From: leopard x. <leo...@li...> - 2009-11-23 04:39:23
|
Hello. I followed your instructions at the following Web link. It explains how to build Glean on Windows. http://glean.sourceforge.net/buildwin.html However, I encounter a bunch of errors associated with the prebuilt STLPort that I downloaded per the suggestion at the above link. Do you know how I can fix these errors? I must be overlooking some setting, but I do not have any idea about the setting that I am overlooking. I am using Microsoft Visual Studio .NET 2003 running on Windows XP Professional. At the end of this note, I pasted the output of a compilation run. Thanks, Leopard ------------ start of run ------------ C:\opengl\glean\src>nmake /f makefile.win Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. if not exist "/" mkdir "" if not exist "/" mkdir "" if not exist "/" mkdir "" cd glh nmake /nologo /f makefile.win CFG=release echo Copying Header Files Copying Header Files copy .\glwrap.h C:\opengl\glean\include 1 file(s) copied. cd .. cd libs nmake /nologo /f makefile.win CFG=release cd rand nmake /nologo /f makefile.win CFG=release echo Copying Header Files Copying Header Files copy .\rand.h C:\opengl\glean\include 1 file(s) copied. cd .. cd lex nmake /nologo /f makefile.win CFG=release cl.exe @C:\DOCUME~1\dsunada\LOCALS~1\Temp\nm1BF.tmp lex.cpp c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(163) : warning C4346: '_STL::basic_string<_CharT,_ Traits,_Alloc>::size_type' : dependent name is not a type prefix with 'typename' to indicate a type c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(163) : error C2146: syntax error : missing ')' bef ore identifier '__res_arg' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(163) : error C2182: 'reserve' : illegal use of typ e 'void' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(163) : error C2072: '_STL::basic_string<_CharT,_Tr aits,_Alloc>::reserve' : initialization of a function c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(163) : error C2059: syntax error : ')' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(186) : error C2065: '_CharT' : undeclared identifi er c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(186) : error C2065: '_Traits' : undeclared identif ier c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(186) : error C2065: '_Alloc' : undeclared identifi er c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(187) : error C3861: '_CharT': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(187) : error C3861: '_Traits': identifier not foun d, even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(187) : error C3861: '_Alloc': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(187) : error C2955: '_STL::basic_string' : use of class template requires template argument list c:\opengl\stlport-4.0-glean\stlport\stl\_string.h(1241) : see declaration of '_STL::basic_st ring' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(187) : error C3861: '_CharT': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(187) : error C3861: '_Traits': identifier not foun d, even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(187) : error C3861: '_Alloc': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(187) : error C2955: '_STL::basic_string' : use of class template requires template argument list c:\opengl\stlport-4.0-glean\stlport\stl\_string.h(1241) : see declaration of '_STL::basic_st ring' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(187) : error C2143: syntax error : missing ';' bef ore '{' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(187) : error C2447: '{' : missing function header (old-style formal list?) c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(252) : warning C4346: '_STL::basic_string<_CharT,_ Traits,_Alloc>::size_type' : dependent name is not a type prefix with 'typename' to indicate a type c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(252) : error C2146: syntax error : missing ')' bef ore identifier '__n' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(252) : error C2350: '_STL::basic_string<_CharT,_Tr aits,_Alloc>::assign' is not a static member c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(252) : error C2262: '_STL::basic_string<_CharT,_Tr aits,_Alloc>::assign' : cannot be destroyed c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(252) : error C2059: syntax error : ')' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(291) : error C3861: '_CharT': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(291) : error C3861: '_Traits': identifier not foun d, even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(291) : error C3861: '_Alloc': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(292) : error C2955: '_STL::basic_string' : use of class template requires template argument list c:\opengl\stlport-4.0-glean\stlport\stl\_string.h(1241) : see declaration of '_STL::basic_st ring' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(294) : error C2143: syntax error : missing ';' bef ore '{' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(294) : error C2447: '{' : missing function header (old-style formal list?) c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(327) : warning C4346: '_STL::basic_string<_CharT,_ Traits,_Alloc>::iterator' : dependent name is not a type prefix with 'typename' to indicate a type c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(327) : error C2146: syntax error : missing ')' bef ore identifier '__position' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(327) : error C2182: 'insert' : illegal use of type 'void' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(327) : error C2350: '_STL::basic_string<_CharT,_Tr aits,_Alloc>::insert' is not a static member c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(328) : error C2059: syntax error : ')' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(439) : error C3861: '_CharT': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(439) : error C3861: '_Traits': identifier not foun d, even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(439) : error C3861: '_Alloc': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(440) : error C3861: '_CharT': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(440) : error C3861: '_Traits': identifier not foun d, even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(440) : error C3861: '_Alloc': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(441) : error C2955: '_STL::basic_string' : use of class template requires template argument list c:\opengl\stlport-4.0-glean\stlport\stl\_string.h(1241) : see declaration of '_STL::basic_st ring' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(441) : error C2955: '_STL::iterator' : use of clas s template requires template argument list c:\opengl\stlport-4.0-glean\stlport\stl\_iterator_base.h(77) : see declaration of '_STL::ite rator' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(441) : error C3861: '_CharT': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(441) : error C3861: '_Traits': identifier not foun d, even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(441) : error C3861: '_Alloc': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(441) : error C2955: '_STL::basic_string' : use of class template requires template argument list c:\opengl\stlport-4.0-glean\stlport\stl\_string.h(1241) : see declaration of '_STL::basic_st ring' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(442) : error C2143: syntax error : missing ';' bef ore '{' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(442) : error C2447: '{' : missing function header (old-style formal list?) c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(483) : warning C4346: '_STL::basic_string<_CharT,_ Traits,_Alloc>::size_type' : dependent name is not a type prefix with 'typename' to indicate a type c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(483) : error C2143: syntax error : missing ';' bef ore '_STL::basic_string<_CharT,_Traits,_Alloc>::find' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(483) : error C2501: '_STL::basic_string<_CharT,_Tr aits,_Alloc>::size_type' : missing storage-class or type specifiers c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(483) : warning C4346: '_STL::basic_string<_CharT,_ Traits,_Alloc>::find' : dependent name is not a type prefix with 'typename' to indicate a type c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(483) : error C2143: syntax error : missing ',' bef ore '*' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(498) : warning C4346: '_STL::basic_string<_CharT,_ Traits,_Alloc>::size_type' : dependent name is not a type prefix with 'typename' to indicate a type c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(498) : error C2143: syntax error : missing ';' bef ore '_STL::basic_string<_CharT,_Traits,_Alloc>::find' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(498) : error C2501: '_STL::basic_string<_CharT,_Tr aits,_Alloc>::size_type' : missing storage-class or type specifiers c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(498) : error C3861: '_CharT': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(498) : warning C4346: '_STL::basic_string<_CharT,_ Traits,_Alloc>::find' : dependent name is not a type prefix with 'typename' to indicate a type c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(498) : error C2146: syntax error : missing ')' bef ore identifier '__c' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(498) : error C2501: '_STL::basic_string<_CharT,_Tr aits,_Alloc>::find' : missing storage-class or type specifiers c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(498) : error C2350: '_STL::basic_string<_CharT,_Tr aits,_Alloc>::find' is not a static member c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(498) : error C2059: syntax error : ')' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(511) : error C3861: '_CharT': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(511) : error C3861: '_Traits': identifier not foun d, even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(511) : error C3861: '_Alloc': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(511) : error C2955: '_STL::basic_string' : use of class template requires template argument list c:\opengl\stlport-4.0-glean\stlport\stl\_string.h(1241) : see declaration of '_STL::basic_st ring' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(512) : error C3861: '_CharT': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(512) : error C3861: '_Traits': identifier not foun d, even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(512) : error C3861: '_Alloc': identifier not found , even with argument-dependent lookup c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(513) : error C2955: '_STL::basic_string' : use of class template requires template argument list c:\opengl\stlport-4.0-glean\stlport\stl\_string.h(1241) : see declaration of '_STL::basic_st ring' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(514) : error C2143: syntax error : missing ';' bef ore '{' c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(514) : error C2447: '{' : missing function header (old-style formal list?) c:\opengl\stlport-4.0-glean\stlport\stl\_string.c(531) : fatal error C1903: unable to recover from p revious error(s); stopping compilation NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\nmake.exe"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\nmake.exe"' : return code '0x2' ---------- end of run ---------- _________________________________________________________________ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009 |
5 messages has been excluded from this view by a project administrator.
