glean-dev — Glean development discussions

Re: [glean-dev] testing texgen, etc.

[Brian S. <br...@gl...>]

At 08:19 AM 12/12/00 -0700, you wrote:
> > Texgen and lighting are two things I'd like good tests for, given that lots
> > of drivers have problems with them where they all pretty much have the
> > basic vertex transforms solid at this point.
>
>I hadn't heard that many drivers were broken in this area.  Interesting.

I remember a certain driver I was working on was doing spheremap texgen 
wrong, and so I ran a test app on that driver, the MS OGL driver, the SGI 
OGL driver, and Mesa.  Each driver's result was completely different.

(Mesa was the only one that got it right :-) ).

.b

Re: [glean-dev] "paths" test too strict?

[Brian P. <br...@va...>]

Gareth Hughes wrote:
> 
> The paths test is failing at 16bpp due to rounding errors.  An RGB565
> pixel of 0xffff is being converted to approximately (0.97, 0.98, 0.97),
> which doesn't equal (1.0, 1.0, 1.0) and thus fails this test.
> 
> Brian, what would you like to do here?  Perhaps test for a pixel value
> greater than some threshold?

No, I think this is a genuine driver bug.

I purposely wrote the test so that only 100% white is sent through
OpenGL.  100% white should be in the framebuffer, and 100% white is
what you should get from glReadPixels.

In drv/r128/r128_span.c the 16bpp pixel read macro is:

#define READ_RGBA( rgba, _x, _y )					\
    do {								\
	GLushort p = *(GLushort *)(read_buf + _x*2 + _y*pitch);		\
	rgba[0] = (p >> 8) & 0xf8;					\
	rgba[1] = (p >> 3) & 0xfc;					\
	rgba[2] = (p << 3) & 0xf8;					\
	rgba[3] = 0xff;							\
    } while (0)

If the pixel value is 0xffff you're going to return red=0xf8, green=0xfc,
blue=0xf8.  It should be red=green=blue=0xff.

This was wrong in the tdfx driver for a while too.  The simple, but
slow solution is this (from the tdfx driver):

#define READ_RGBA( rgba, _x, _y )					\
    do {								\
	GLushort p = *(GLushort *)(read_buf + _x*2 + _y*pitch);		\
	rgba[0] = (((p >> 11) & 0x1f) * 255) / 31;			\
	rgba[1] = (((p >>  5) & 0x3f) * 255) / 63;			\
	rgba[2] = (((p >>  0) & 0x1f) * 255) / 31;			\
	rgba[3] = 0xff;							\
    } while (0)

The integer multiply and divide could be replaced by a table lookup
or a bit-twidling solution.

-Brian

[glean-dev] "paths" test too strict?

[Gareth H. <ga...@va...>]

The paths test is failing at 16bpp due to rounding errors.  An RGB565
pixel of 0xffff is being converted to approximately (0.97, 0.98, 0.97),
which doesn't equal (1.0, 1.0, 1.0) and thus fails this test.

Brian, what would you like to do here?  Perhaps test for a pixel value
greater than some threshold?

-- Gareth

Re: [glean-dev] testing texgen, etc.

[Brian P. <br...@va...>]

Brian Sharp wrote:
> 
> Heya,
> 
> What's the general way to test something like texture coordinate
> generation?  I don't want to kick the GL into feedback mode to see if the
> generated coordinates are correct, as many (most?) drivers use a totally
> different path for feedback than for actual rendering.  And yet the
> interpolation constraints are loose enough that I can't really do an image
> comparison; the difference between a perspective-correct and
> perspective-incorrect textured object would be too great to threshold
> between that and a truly broken rendering.

Finding the right balance between strict conformance and acceptable
variance really is tricky.  For something like texgen, I'd setup a
simple texture image (like half yellow, half blue), render a single
quad with texgen, and examine the pixels in a gross sense.  You
could set up linear texgen to color half the quad yellow and the
other half blue.  Move the coordinate system of the texgen around
the polygon to test different angles.  Sphere-gen would be harder
to test.

I'd keep the polygon nearly parallel to the projection plane to
minimize or eliminate the effects of perspective correction.  I'd
expect perspective correction and texgen to be pretty much unrelated
in drivers.

A separate test for perspective correction would be good.

Exercising the Q component of texture coordinates would be a very
good test too.


> Lighting has a similar kind of problem.

The GL conformance tests exercise lighting by drawing a single point
with a changing normal vector and changing material/light coefficients.
It basically just looks for a monotone change in pixel intensity as the
normal or coefficients change.

Lighting is pretty-well exercised in the GL conformance tests, and
since they're going to be open-sourced, it would be better to spend
our time writing tests for things the GL conformance tests don't
exercise.

I'd like to see Glean tests for some of the newer OpenGL extensions,
such as texture compression, cube mapping, new tex env modes, etc.
I haven't seen any indication that people are contributing tests for
these to the GL conformance suite.

I think Glean will become popular much more quickly if it's testing
the latest and greatest OpenGL features.


> Texgen and lighting are two things I'd like good tests for, given that lots
> of drivers have problems with them where they all pretty much have the
> basic vertex transforms solid at this point.

I hadn't heard that many drivers were broken in this area.  Interesting.

-Brian

[glean-dev] testing texgen, etc.

[Brian S. <br...@gl...>]

Heya,

What's the general way to test something like texture coordinate 
generation?  I don't want to kick the GL into feedback mode to see if the 
generated coordinates are correct, as many (most?) drivers use a totally 
different path for feedback than for actual rendering.  And yet the 
interpolation constraints are loose enough that I can't really do an image 
comparison; the difference between a perspective-correct and 
perspective-incorrect textured object would be too great to threshold 
between that and a truly broken rendering.

Lighting has a similar kind of problem.

Texgen and lighting are two things I'd like good tests for, given that lots 
of drivers have problems with them where they all pretty much have the 
basic vertex transforms solid at this point.

.b

Re: [glean-dev] tbasicperf

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

Rik covered all the important stuff; I just wanted to add one minor
comment.

|                                                    ...(for instance, I'm 
| working on one to tests speeds of various geometry paths for large numbers 
| of triangles) ...

Be sure to have a look at tvtxperf.cpp, both to avoid duplication of
effort and to see if there are utility functions (like those for
constructing random geometry and arbitrarily-long triangle strips)
that might be of use to you.

Allen

Re: [glean-dev] tbasicperf

[Rik F. <fa...@va...>]

On Mon 11 Dec 2000 19:02:19 -0500,
   Brian Sharp <br...@gl...> wrote:
> Did you intend for tbasicperf to provide a class that would be overriden 
> for other basic performance tests?  It seems like it serves a number of 
> purposes: first, didactic, as it demonstrates a simplistic performance 
> task, second, the task itself (I suppose it does make sure that sleep() 
> works), and third, it provides an infrastructure for other tests.

tbasicperf was implemented for all three of those reasons, and as a
demostration of a new timer routine.

> It would be straightforward to implement another test (for instance, I'm 
> working on one to tests speeds of various geometry paths for large numbers 
> of triangles) by subclassing BasicPerfTest and reimplementing runOne, I 
> think, but that seems wrong to me from an OO point of view, since 
> BasicPerfTest isn't an interface, but its own test...
> 
> Otherwise, it seems like there's chunks of code (in BasicPerfTest's run(), 
> for instance) that will get duplicated between tests.  Maybe there are 
> slight changes; I'll have to see.

I'm currently working on a branch (rik-0-1-branch) on ways to minimize
the amount of duplicated code we have in the tests.  The tbasicperf on
the trunk is only about half done because I think I've figured out a
better way to make it simpler and I stopped working on the current
tbasicperf for the moment.  I hope I'll have something on the branch to
show people in a few days.

That said, if you're writing a test that can derive from BasicPerfTest,
please do so, since that will minimize code copying.  I've noted your
comments about not liking that from an OO standpoint and I'll try to
make the work on the branch more straightforward in this regard.  We
should strive for ease of long-term maintainability via minimization of
code duplication -- so if you don't like deriving from a class, I think
we should fix it so that you'll be happy to derive from it.

[glean-dev] tbasicperf

[Brian S. <br...@gl...>]

Allen,

Did you intend for tbasicperf to provide a class that would be overriden 
for other basic performance tests?  It seems like it serves a number of 
purposes: first, didactic, as it demonstrates a simplistic performance 
task, second, the task itself (I suppose it does make sure that sleep() 
works), and third, it provides an infrastructure for other tests.

It would be straightforward to implement another test (for instance, I'm 
working on one to tests speeds of various geometry paths for large numbers 
of triangles) by subclassing BasicPerfTest and reimplementing runOne, I 
think, but that seems wrong to me from an OO point of view, since 
BasicPerfTest isn't an interface, but its own test...

Otherwise, it seems like there's chunks of code (in BasicPerfTest's run(), 
for instance) that will get duplicated between tests.  Maybe there are 
slight changes; I'll have to see.

.b

Re: [glean-dev] tbasicperf.cpp won't compile

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

On Mon, Dec 11, 2000 at 09:01:51AM -0600, Ed Peddycoart wrote:
| How do I unsubscribe?

At the bottom of every message distributed by the listserver the
following lines appear:

	glean-dev mailing list
	gle...@li...
	http://lists.sourceforge.net/mailman/listinfo/glean-dev

If you go to the web page mentioned on the last of these lines, you
can modify your subscription or unsubscribe.

I'd rather not unsubscribe someone when an email request appears on
the list, because I can't readily verify that they are the person they
claim to be.  If you use the listserver web page, at least the
password required there provides some authentication.

Allen

[glean-dev] Re: unsubscribing

[Gareth H. <ga...@va...>]

Ed Peddycoart wrote:
> 
> How do I unsubscribe?

Probably the same way you subscribed...

http://lists.sourceforge.net/mailman/listinfo/glean-dev/

-- Gareth

RE: [glean-dev] tbasicperf.cpp won't compile

[Ed P. <epe...@cg...>]

How do I unsubscribe?
Ed

>-----Original Message-----
>From: gle...@li...
>[mailto:gle...@li...]On Behalf Of Allen Akin
>Sent: Saturday, December 09, 2000 1:39 AM
>To: gle...@li...
>Subject: Re: [glean-dev] tbasicperf.cpp won't compile
>
>
>On Sat, Dec 09, 2000 at 02:01:47PM +1100, Gareth Hughes wrote:
>| 
>| No worries.  Must try reading the instructions every now and then ;-)
>
>You're not the first to run into this problem.  Nathan and Rik have
>been thinking about simplifying things.
>
>Allen
>_______________________________________________
>glean-dev mailing list
>gle...@li...
>http://lists.sourceforge.net/mailman/listinfo/glean-dev

Re: [glean-dev] tbasicperf.cpp won't compile

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

On Sat, Dec 09, 2000 at 02:01:47PM +1100, Gareth Hughes wrote:
| 
| No worries.  Must try reading the instructions every now and then ;-)

You're not the first to run into this problem.  Nathan and Rik have
been thinking about simplifying things.

Allen

Re: [glean-dev] tbasicperf.cpp won't compile

[Gareth H. <ga...@va...>]

Gareth Hughes wrote:
> 
> Oops :-)  I'll try again now...

No worries.  Must try reading the instructions every now and then ;-)

-- Gareth

Re: [glean-dev] tbasicperf.cpp won't compile

[Gareth H. <ga...@va...>]

Allen Akin wrote:
> 
> On Sat, Dec 09, 2000 at 01:33:42PM +1100, Gareth Hughes wrote:
> | It's not picking up perf.h from src/libs/timer.  Similarly, tchgperf.cpp
> | isn't picking up src/libs/timer/timer.h I think.
> 
> Did you do "make install" from src?  If not, the .h files don't get
> copied from their source directories into the include directory,
> and the tests can't find them.

Oops :-)  I'll try again now...

-- Gareth

Re: [glean-dev] tbasicperf.cpp won't compile

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

On Sat, Dec 09, 2000 at 01:33:42PM +1100, Gareth Hughes wrote:
| It's not picking up perf.h from src/libs/timer.  Similarly, tchgperf.cpp
| isn't picking up src/libs/timer/timer.h I think.

Did you do "make install" from src?  If not, the .h files don't get
copied from their source directories into the include directory,
and the tests can't find them.

Allen

[glean-dev] tbasicperf.cpp won't compile

[Gareth H. <ga...@va...>]

It's not picking up perf.h from src/libs/timer.  Similarly, tchgperf.cpp
isn't picking up src/libs/timer/timer.h I think.

-- Gareth

Re: [glean-dev] Win32 building

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

Rik Faith wrote:
| assert() is defined in ANSI C -- all you should have to do it to include
| the assert.h header file.

Jeffrey Mehlhorn wrote:
| Assert() is being used in the file ttexcombine.cpp.

It's not a big problem.  ttexcombine.cpp just isn't including <assert.h>.
We get away with this on Linux because some other header file includes
it indirectly.  I'll fix it shortly.

Allen

RE: [glean-dev] Win32 building

[Jeffrey M. <Jef...@3D...>]

Assert() is being used in the file ttexcombine.cpp.

> ----------
> From: 	Rik Faith[SMTP:fa...@va...]
> Reply To: 	gle...@li...
> Sent: 	Friday, December 08, 2000 8:21 AM
> To: 	Lea...@en...
> Cc: 	gle...@li...
> Subject: 	Re: [glean-dev] Win32 building
> 
> On Fri  8 Dec 2000 11:06:00 +1000,
>    Leath Muller <Lea...@en...> wrote:
> > > Oh, assert() may be a different matter; possibly a header file isn't
> > > included properly under Windows.
> > 
> > I've always had trouble with assert() with VC -- but ASSERT() works
> fine...
> > maybe a conditional could be added in there??? (I have two months leave
> > starting at the end of today... lotsa coding time... :)
> 
> assert() is defined in ANSI C -- all you should have to do it to include
> the assert.h header file.
> 
> Indeed, assert() is highly recommended in the Microsoft Press book
> "Writing Solid Code", so I can't imagine why there's any problem with
> it under VC.
> 
> That said, I can't find any uses of assert is the glean source tree --
> where are we using it?
> _______________________________________________
> glean-dev mailing list
> gle...@li...
> http://lists.sourceforge.net/mailman/listinfo/glean-dev
> 

Re: [glean-dev] Win32 building

[Rik F. <fa...@va...>]

On Fri  8 Dec 2000 11:06:00 +1000,
   Leath Muller <Lea...@en...> wrote:
> > Oh, assert() may be a different matter; possibly a header file isn't
> > included properly under Windows.
> 
> I've always had trouble with assert() with VC -- but ASSERT() works fine...
> maybe a conditional could be added in there??? (I have two months leave
> starting at the end of today... lotsa coding time... :)

assert() is defined in ANSI C -- all you should have to do it to include
the assert.h header file.

Indeed, assert() is highly recommended in the Microsoft Press book
"Writing Solid Code", so I can't imagine why there's any problem with
it under VC.

That said, I can't find any uses of assert is the glean source tree --
where are we using it?

Re: [glean-dev] Win32 building

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

On Fri, Dec 08, 2000 at 12:39:40PM +1000, Leath Muller wrote:
| 
| Sorry, can't help much more than that... :|

Well, it's a good start. :-)

Allen

Re: [glean-dev] Win32 building

[<Lea...@en...>]

> Well, I'm mystified.  Unless VC is putting #define's into namespaces,
> the code in glwrap.h looks fine to me.  Whenever GL_VERSION_1_2 is
> undefined, all the OpenGL 1.2 enumerants should be defined.

I wasn't sure either -- and the fact it worked fine on Brian's compiler
was weirder...
 
> Can you tell me what changes you made that solved the problem?

It was a while ago, but hang on...

[. . . checking . . .]

In tvtxperf.cpp:

	GLUtils::LightModel lm;
	lm.ambient(0, 0, 0, 0);
	lm.localViewer(false);
	lm.twoSide(false);

>	//! LDM
>	#ifndef GL_SINGLE_COLOR
>	#define GL_SINGLE_COLOR GL_SINGLE_COLOR_EXT
>	#endif

	lm.colorControl(GL_SINGLE_COLOR);


In glutils.cpp:

void
LightModel::twoSide(bool v) {
	glLightModeli(GL_LIGHT_MODEL_TWO_SIDE, static_cast<GLint>(v));
} // LightModel::twoSide

>	#ifndef GL_LIGHT_MODEL_COLOR_CONTROL
>	#define GL_LIGHT_MODEL_COLOR_CONTROL GL_LIGHT_MODEL_COLOR_CONTROL_EXT
>	#endif

void
LightModel::colorControl(GLenum e) {
	glLightModeli(GL_LIGHT_MODEL_COLOR_CONTROL, e);
} // LightModel::colorControl


Other than the fact that both of these defines are directly after each
other in glwrap.h (sorry, getting desperate... ;) I can't see any reason
they aren't included in the compile...

The MS GL headers on this machine don't previously define them, and the
define values aren't used either so it's not confusing them with something
else...

Sorry, can't help much more than that... :|

Leathal.

Re: [glean-dev] Win32 building

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

On Fri, Dec 08, 2000 at 11:06:00AM +1000, Leath Muller wrote:
| > These are OpenGL 1.2 constants, which is why they're not defined in
| > glext.h.  However, they *are* included in the current version of
| > glwrap.h, just so that glean will compile in OpenGL 1.1 environments.
| 
| I discussed this originally and the glwrap.h definately isn't doin' it's
| job... I fixed it extremely easily with some in-code ifdefs, but Brian
| was working on this last I heard so I haven't done anything with the
| repository.

Well, I'm mystified.  Unless VC is putting #define's into namespaces,
the code in glwrap.h looks fine to me.  Whenever GL_VERSION_1_2 is
undefined, all the OpenGL 1.2 enumerants should be defined.

Can you tell me what changes you made that solved the problem?

Allen

Re: [glean-dev] Win32 building

[<Lea...@en...>]

> These are OpenGL 1.2 constants, which is why they're not defined in
> glext.h.  However, they *are* included in the current version of
> glwrap.h, just so that glean will compile in OpenGL 1.1 environments.

I discussed this originally and the glwrap.h definately isn't doin' it's
job... I fixed it extremely easily with some in-code ifdefs, but Brian
was working on this last I heard so I haven't done anything with the
repository.
 
> >From looking at the log, it appears that the necessary changes went
> into glwrap.h on November 15th.  Could you verify that they're in your
> copy of glwrap.h?  Possibly there's a build-order problem that's
> preventing the correct copy of glwrap.h from being used for the
> compilation.  Or maybe we messed up the conditional-compilation
> directives somehow.

Or maybe something else??? Brian sent me his working copy of the repos.
(my CVS doesn't work through this proxy) and it compiled on his machine
but died on mine -- maybe other includes are hanging around on a per
machine basis like yours and Brians?
 
> Oh, assert() may be a different matter; possibly a header file isn't
> included properly under Windows.

I've always had trouble with assert() with VC -- but ASSERT() works fine...
maybe a conditional could be added in there??? (I have two months leave
starting at the end of today... lotsa coding time... :)
 
Leathal.

Re: [glean-dev] Win32 building

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

On Thu, Dec 07, 2000 at 01:55:48PM -0600, Jeffrey Mehlhorn wrote:
| 
|     In the file glutils.cpp, there is a reference to a
|     constant, GL_LIGHT_MODEL_COLOR_CONTROL, and the
|     definition for this constant does not appear anywhere
|     in the source tree.
| 
|     Likewise, in tvtxperf.cpp, there is a reference to a
|     constant, GL_SINGLE_COLOR, that is not defined.

These are OpenGL 1.2 constants, which is why they're not defined in
glext.h.  However, they *are* included in the current version of
glwrap.h, just so that glean will compile in OpenGL 1.1 environments.

From looking at the log, it appears that the necessary changes went
into glwrap.h on November 15th.  Could you verify that they're in your
copy of glwrap.h?  Possibly there's a build-order problem that's
preventing the correct copy of glwrap.h from being used for the
compilation.  Or maybe we messed up the conditional-compilation
directives somehow.

|     Finally, in the file ttexcombine.cpp, I found three
|     functions that the linker was unable to resolve.
|     They are assert(), glActiveTextureARB() and
|     glMultiTexCoord2fARB().  This was an eyebrow raiser,
|     because my understanding is that these are extensions
|     that may or may not be supported by the client driver.
| 
|     Shouldn't there be #ifdef MULTI_TEXTURE_ARB tokens
|     around the calls to these functions?

Yes, as a quick hack that would take care of the problem.  What really
needs to be done is to query the function pointers, as Brian noted. 
That way you can compile an executable even on a system that doesn't
support the extension.  I'll put it on my to-do list, since it
should be a fairly quick fix.

Oh, assert() may be a different matter; possibly a header file isn't
included properly under Windows.

Allen

Re: [glean-dev] Win32 building

[Brian P. <br...@va...>]

Brian Sharp wrote:
> 
> At 01:55 PM 12/7/00 -0600, you wrote:
> >     In the file glutils.cpp, there is a reference to a
> >     constant, GL_LIGHT_MODEL_COLOR_CONTROL, and the
> >     definition for this constant does not appear anywhere
> >     in the source tree.
> >
> >     Likewise, in tvtxperf.cpp, there is a reference to a
> >     constant, GL_SINGLE_COLOR, that is not defined.
> 
> This was mentioned; I'm not entirely sure why it builds on my system
> without these.  I think glext.h defines those enums with a _EXT suffix, but
> not without, and that's the problem; I haven't gotten around to fixing that
> yet.
> 
> >     Finally, in the file ttexcombine.cpp, I found three
> >     functions that the linker was unable to resolve.
> >     They are assert(), glActiveTextureARB() and
> >     glMultiTexCoord2fARB().  This was an eyebrow raiser,
> >     because my understanding is that these are extensions
> >     that may or may not be supported by the client driver.
> >
> >     Shouldn't there be #ifdef MULTI_TEXTURE_ARB tokens
> >     around the calls to these functions?
> 
> Interesting; I didn't realize those functions weren't being queried for,
> but were being explicitly used.  Rather than an #ifdef block, those
> functions should be queried using the wglGetProcAddress or the
> glXGetProcAddress, and not used if the extension isn't found.  Good catch;
> I guess nobody who's built glean has yet done so on an OpenGL
> implementation without multitexture support.

This is my fault.  I've been too busy to update the code to use
GetProcAddress().  I may not get to it anymore this year.

-Brian