glean-dev — Glean development discussions

RE: [glean-dev] About CVS access

[LIAO, G. <gua...@in...>]

I have download the tarball and run it in my FC4 box.
In the middle of run test, one segmentation fault come out.=20
Do you have the same situation?
If no, I will give my log.

-----Original Message-----
From: Allen Akin [mailto:ak...@po...]=20
Sent: 2006=C4=EA4=D4=C226=C8=D5 10:47
To: LIAO, GUANGDENG
Cc: gle...@li...; bri...@tu...
Subject: Re: [glean-dev] About CVS access

On Wed, Apr 26, 2006 at 10:19:06AM +0800, LIAO, GUANGDENG wrote:
| I still can not get the CVS. Could u give me one tarball?

Sorry about the problem -- I don't know what's going at at SourceForge.

You can find a tarball at

	http://arden.org/glean.tar.bz2

Hopefully that'll help.

Allen

RE: [glean-dev] About CVS access

[LIAO, G. <gua...@in...>]

Thanks! I will have a try:)

Danny

-----Original Message-----
From: Allen Akin [mailto:ak...@po...]=20
Sent: 2006=C4=EA4=D4=C226=C8=D5 10:47
To: LIAO, GUANGDENG
Cc: gle...@li...; bri...@tu...
Subject: Re: [glean-dev] About CVS access

On Wed, Apr 26, 2006 at 10:19:06AM +0800, LIAO, GUANGDENG wrote:
| I still can not get the CVS. Could u give me one tarball?

Sorry about the problem -- I don't know what's going at at SourceForge.

You can find a tarball at

	http://arden.org/glean.tar.bz2

Hopefully that'll help.

Allen

Re: [glean-dev] About CVS access

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

On Wed, Apr 26, 2006 at 10:19:06AM +0800, LIAO, GUANGDENG wrote:
| I still can not get the CVS. Could u give me one tarball?

Sorry about the problem -- I don't know what's going at at SourceForge.

You can find a tarball at

	http://arden.org/glean.tar.bz2

Hopefully that'll help.

Allen

[glean-dev] About CVS access

[LIAO, G. <gua...@in...>]

Hi Brian,
>Anon CVS wasn't working for another project yesterday either.  If you=20
>still don't have luck today, let me know and I'll put together a=20
>tarball for you.

I still can not get the CVS. Could u give me one tarball?

TIA
Danny

Re: [glean-dev] Can not download glean from CVS

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

LIAO, GUANGDENG wrote:
> HI all,
> 
> Today I want to download glean for my play. However, it failed and
> reported as followings:
> No such directory: cvsroot/glean. CVS is broken? Or any other message?
> 
> The CVS instruction: 
> cvs -d:pserver:ano...@cv...:/cvsroot/glean login
>  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/glean co -P
> glean

Anon CVS wasn't working for another project yesterday either.  If you 
still don't have luck today, let me know and I'll put together a 
tarball for you.

-Brian

[glean-dev] Can not download glean from CVS

[LIAO, G. <gua...@in...>]

HI all,

Today I want to download glean for my play. However, it failed and
reported as followings:
No such directory: cvsroot/glean. CVS is broken? Or any other message?

The CVS instruction:=20
cvs -d:pserver:ano...@cv...:/cvsroot/glean login
 cvs -z3 -d:pserver:ano...@cv...:/cvsroot/glean co -P
glean

TIA
Danny

Re: [glean-dev] Downloads broken?

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

On Tue, Dec 20, 2005 at 10:28:51AM +0200, Kalle Raita wrote:
| I now succeeded in using the CVS. Maybe some transient problem or bad 
| copy-pasting by me. Anyways, thanks for the help.

I'm glad it finally worked!

| I'm actually writing my master's thesis about using image comparison in 
| graphics API testing. ...

You've chosen a challenging topic, but an important one.  Verification
often requires more effort than chip design.

I managed groups at SGI that worked on the OpenGL conformance tests and
on SGI's internal test suite (ogtst).  I guess I could sum up my
experience with image comparison this way:

	Image comparison works particularly well for regression testing
	on a single graphics device (or a family of devices with the
	same circuit design).

	Creating and maintaining the image database is a lot of work.

	Image comparison is less successful when you have to test a new
	device or compare two unrelated devices.  Even subtle
	implementation differences can cause image differences that may
	be hard to validate.

	Image analysis can produce more meaningful results (especially
	on unrelated devices) than simple comparison, if the graphics
	semantics are specified with sufficient care.

	Analysis code is *much* more difficult to write than comparison
	code.

Glean and the conformance tests are intended to run on many unrelated
devices, so both of those suites rely more on analysis than comparison.
ogtst relied more heavily on comparison (and I would guess the same is
true of most vendors' test suites).

Please let us know when your thesis is done.  I'd like to read your
conclusions!

By the way, if you find books or papers on testing that you can
recommend, I'd like to hear about those, too.  One that I used as an
introduction for the ogtst project group at SGI was "The Art of Software
Testing" by Glenford Myers.

|                   ... I thought that Glean might be good reference 
| material on how conformance testing can be done. ...

It's a start, anyway.  Glean doesn't attempt to test the API
comprehensively, because that's far too large a project to attempt with
volunteers.  But it illustrates the basic techniques.

|                                              ... Referring to actual API 
| conformance tests might be a bit problematic as they are not publicly 
| available and discussing the techniques used might be a violation of the 
| licensing terms.

I would hope not, but it's hard to say.  You'd need to talk to the legal
folks at SGI.

| By the way, have you thought about porting your work to OpenGL ES?

A little.  I haven't put much effort into glean lately because the
hardware vendors have their own test suites that are much more complete.
I'd expect the same to be true for OpenGL ES.  But Brian Paul tells me
that glean is still useful, so maybe some more effort would be
worthwhile.

Allen

Re: [glean-dev] Downloads broken?

[Kalle R. <kr...@hy...>]

Hi,

I now succeeded in using the CVS. Maybe some transient problem or bad 
copy-pasting by me. Anyways, thanks for the help.

I'm actually writing my master's thesis about using image comparison in 
graphics API testing. I thought that Glean might be good reference 
material on how conformance testing can be done. Referring to actual API 
conformance tests might be a bit problematic as they are not publicly 
available and discussing the techniques used might be a violation of the 
licensing terms.

By the way, have you thought about porting your work to OpenGL ES?

Yours,

-  Kalle Raita

Allen Akin wrote:

>On Mon, Dec 19, 2005 at 12:30:55PM +0200, Kalle Raita wrote:
>| I tried to download the Glean source from the Source Forge website as 
>| well as from the CVS. Download sections says File Not Found and login to 
>| the CVS server fails with time out. Ping goes through, though.
>| Any help appreciated.
>
>Looks like there's a stale link in the glean homepage that's causing the
>"File Not Found" error.  I'll look into that.  But currently there are
>no packages available for download, anyway; I removed them some time ago
>because they were way out-of-date.
>
>CVS checkout worked fine for me just two minutes ago, using the
>instructions on the glean CVS page:
>
> cvs -d:pserver:ano...@cv...:/cvsroot/glean login
> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/glean co -P glean
>
>Is your problem specific to glean?  (That is, are you able to use CVS
>for any other Sourceforge-hosted projects?)
>
>Allen
>  
>


-- 
o Kalle Raita, 3D programmer
o Hybrid Graphics, Ltd.
o Email: Kal...@hy...
o Web: www.hybrid.fi

Re: [glean-dev] Downloads broken?

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

On Mon, Dec 19, 2005 at 12:30:55PM +0200, Kalle Raita wrote:
| I tried to download the Glean source from the Source Forge website as 
| well as from the CVS. Download sections says File Not Found and login to 
| the CVS server fails with time out. Ping goes through, though.
| Any help appreciated.

Looks like there's a stale link in the glean homepage that's causing the
"File Not Found" error.  I'll look into that.  But currently there are
no packages available for download, anyway; I removed them some time ago
because they were way out-of-date.

CVS checkout worked fine for me just two minutes ago, using the
instructions on the glean CVS page:

 cvs -d:pserver:ano...@cv...:/cvsroot/glean login
 cvs -z3 -d:pserver:ano...@cv...:/cvsroot/glean co -P glean

Is your problem specific to glean?  (That is, are you able to use CVS
for any other Sourceforge-hosted projects?)

Allen

[glean-dev] Downloads broken?

[Kalle R. <kr...@hy...>]

Hi!

I tried to download the Glean source from the Source Forge website as 
well as from the CVS. Download sections says File Not Found and login to 
the CVS server fails with time out. Ping goes through, though.
Any help appreciated.

Yours,
 - Kalle Raita

-- 
o Kalle Raita, 3D programmer
o Hybrid Graphics, Ltd.
o Email: Kal...@hy...
o Web: www.hybrid.fi

Re: [glean-dev] catching FP exceptions in C++

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

Brian Paul wrote:
> Keith Whitwell wrote:
> 
>> Brian Paul wrote:
>>
>>> Keith Whitwell wrote:
>>>
>>>> Brian Paul wrote:
>>>>
>>>>> Allen Akin wrote:
>>>>>
>>>>>> On Tue, Nov 08, 2005 at 04:08:19PM -0700, Brian Paul wrote:
>>>>>> | I'm going to be writing a new glean test to see how OpenGL 
>>>>>> handles | infinite/nan/denorm/etc floating point values.
>>>>>>
>>>>>> You're a braver man than I am. :-)
>>>>>>
>>>>>> | My experience with exception handling in C++ is pretty slim and 
>>>>>> I'm | not even sure if there's a standard way to handle them.
>>>>>>
>>>>>> I'm not either.  I've checked my printed references and done a few 
>>>>>> web
>>>>>> searches, and I haven't found anything that claims to work 
>>>>>> universally.
>>>>>>
>>>>>> I suspect the most portable thing we could do would be to use the C99
>>>>>> standard IEEE exception mechanism.  (See "man fetestexcept", 
>>>>>> etc.)  It
>>>>>> depends on the ANSI C signal-catching utilities, but nothing
>>>>>> *nix-specific as far as I can tell.
>>>>>>
>>>>>> However, I don't have any experience with it, so I don't know for 
>>>>>> sure
>>>>>> that it'll do the job.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks, Allen.  I wasn't even aware of those functions.
>>>>>
>>>>> I'm checking in what I have so far.  There's no attempt at trapping 
>>>>> exceptions yet.
>>>>>
>>>>> Both Mesa and NVIDIA's driver pass the test in that FP exceptions 
>>>>> aren't raised by default.  If I enable FP exceptions in Mesa with 
>>>>> export MESA_DEBUG=FP things blow up as soon as I do this assignment:
>>>>>
>>>>> 285:        v[1][0] = make_signaling_nan();
>>>>>
>>>>> I guess the various make_*() functions should take a pointer to the 
>>>>> destination float and store the bit pattern as an integer to avoid 
>>>>> blowing up in Glean before we even get into OpenGL.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> It does make me question whether having the traps enabled is going 
>>>> to work - if you can't even handle the values without provoking an 
>>>> exception, it would mean that all the gl entrypoints will also 
>>>> provoke the exceptions.  You may get out of glean, but you'll get 
>>>> caught in the libGL.so dispatch functions...
>>>
>>>
>>>
>>>
>>> I was thinking about that too.
>>>
>>> Here's a sneaky approach: only enable exceptions before calling 
>>> glEnd.  In Mesa (and probably other OpenGLs) we don't actually do 
>>> anything with the vertex data until glEnd, or some other state-change 
>>> command.
>>>
>>> If exceptions are enabled at that point, only the exceptions 
>>> generated inside OpenGL should get caught.
>>
>>
>>
>> If this is to be the case, GL will have to examine every floating 
>> point input for NaN and/or Inf, and take some action if appropriate.  
>> Is that the specified behaviour?  What should be done if someone 
>> passes an Inf or NaN in a matrix or light parameter?
>>
>> I'm not sure that we should be trying to move towards a GL that 
>> religiously guards against these values entering inside it, and then 
>> equally religoiusly guards against their ever being created 
>> internally.  But I do want to make sure that they are coped with 
>> appropriately, which I felt meant that the library should function, 
>> perhaps with undefined results, but without crashing.  I would qualify 
>> that by saying that turning fp exceptions on isn't fair game...
>>
>> Of course if the GL spec says "you shall never create a NaN floating 
>> point value" or "you shall never create an Inf", and "you shall never 
>> load a user-supplied floating point value into the FPU without 
>> checking if it is an inf or nan", that's a different matter...
>>
>> It seems like the implementation cost of that would be pretty high, 
>> and I don't know if it would be a sensible thing to do, or what would 
>> motivate such a requirement.
>>
>> I would however like to see some confidence that, eg. passing inf/nan 
>> vertex values doesn't cause the rasterization engine to blow up and 
>> segfault, etc.
>>
>> Maybe this is more like a "crashme" test where we write an application 
>> that deliberately does random nasty stuff to GL in the hope of causing 
>> a failure rather than something which belongs in a visual correctness 
>> test like glean?
> 
> 
> The OpenGL spec says that even if NaN, infinity, etc are passed to 
> OpenGL (or a divide by zero happens) that it "must not lead to GL 
> interruption or termination". (sec 2.1.1)
> 
> Since exceptions are silently ignored by default (on most systems 
> anyway) we can get away with ignoring a lot of potential error 
> conditions.  Still, we do occasionally have to deal with some 
> rasterization overflow/underflow issues, like you mention.  Over the 
> years, I've just been fixing those as they're discovered.

In fact the biggest problems we have (ie Jouk's vax system) arise (I think!) 
because there is no representation for inf or nan on that hardware, and so 
floating point operations which would on an ieee system happily evaluate to inf 
or nan, instead are forced(?) to raise exceptions.  That hardware design 
predates IEEE floating point...

Keith

Re: [glean-dev] catching FP exceptions in C++

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

Brian Paul wrote:

> Getting back to the Glean test, I think it might be OK as-is: pass some 
> inf/nan values into GL and pass if we don't crash.  But if someone wants 
> to dig deeper, having an option to enable exceptions in particular cases 
> might be useful.

It is also useful from the perspective of someone trying to figure out
	- does a hardware rasterizer or tnl engine lock up if passed a NaN?
	- what about other aspects of hardware state?

Of course execptions don't help a lot for those questions...

For hardware tnl, it would be interesting to see if it is possible to 
characterize the hardware's floating point characteristics from outside - if we 
set up state so that at some point in the pipeline, vertex attributes are forced 
  so close to zero that they would have to be represented as denormals, does the 
hardware preserve their values or flush them to zero?  Does it appear that 
values are represented with less than 32 bit floats internally?

I guess these aren't correctness issues, so probably quite a low priority...

Keith

Re: [glean-dev] catching FP exceptions in C++

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

Keith Whitwell wrote:
> Brian Paul wrote:
> 
>> Keith Whitwell wrote:
>>
>>> Brian Paul wrote:
>>>
>>>> Allen Akin wrote:
>>>>
>>>>> On Tue, Nov 08, 2005 at 04:08:19PM -0700, Brian Paul wrote:
>>>>> | I'm going to be writing a new glean test to see how OpenGL 
>>>>> handles | infinite/nan/denorm/etc floating point values.
>>>>>
>>>>> You're a braver man than I am. :-)
>>>>>
>>>>> | My experience with exception handling in C++ is pretty slim and 
>>>>> I'm | not even sure if there's a standard way to handle them.
>>>>>
>>>>> I'm not either.  I've checked my printed references and done a few web
>>>>> searches, and I haven't found anything that claims to work 
>>>>> universally.
>>>>>
>>>>> I suspect the most portable thing we could do would be to use the C99
>>>>> standard IEEE exception mechanism.  (See "man fetestexcept", etc.)  It
>>>>> depends on the ANSI C signal-catching utilities, but nothing
>>>>> *nix-specific as far as I can tell.
>>>>>
>>>>> However, I don't have any experience with it, so I don't know for sure
>>>>> that it'll do the job.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks, Allen.  I wasn't even aware of those functions.
>>>>
>>>> I'm checking in what I have so far.  There's no attempt at trapping 
>>>> exceptions yet.
>>>>
>>>> Both Mesa and NVIDIA's driver pass the test in that FP exceptions 
>>>> aren't raised by default.  If I enable FP exceptions in Mesa with 
>>>> export MESA_DEBUG=FP things blow up as soon as I do this assignment:
>>>>
>>>> 285:        v[1][0] = make_signaling_nan();
>>>>
>>>> I guess the various make_*() functions should take a pointer to the 
>>>> destination float and store the bit pattern as an integer to avoid 
>>>> blowing up in Glean before we even get into OpenGL.
>>>
>>>
>>>
>>>
>>> It does make me question whether having the traps enabled is going to 
>>> work - if you can't even handle the values without provoking an 
>>> exception, it would mean that all the gl entrypoints will also 
>>> provoke the exceptions.  You may get out of glean, but you'll get 
>>> caught in the libGL.so dispatch functions...
>>
>>
>>
>> I was thinking about that too.
>>
>> Here's a sneaky approach: only enable exceptions before calling glEnd. 
>>  In Mesa (and probably other OpenGLs) we don't actually do anything 
>> with the vertex data until glEnd, or some other state-change command.
>>
>> If exceptions are enabled at that point, only the exceptions generated 
>> inside OpenGL should get caught.
> 
> 
> If this is to be the case, GL will have to examine every floating point 
> input for NaN and/or Inf, and take some action if appropriate.  Is that 
> the specified behaviour?  What should be done if someone passes an Inf 
> or NaN in a matrix or light parameter?
> 
> I'm not sure that we should be trying to move towards a GL that 
> religiously guards against these values entering inside it, and then 
> equally religoiusly guards against their ever being created internally.  
> But I do want to make sure that they are coped with appropriately, which 
> I felt meant that the library should function, perhaps with undefined 
> results, but without crashing.  I would qualify that by saying that 
> turning fp exceptions on isn't fair game...
> 
> Of course if the GL spec says "you shall never create a NaN floating 
> point value" or "you shall never create an Inf", and "you shall never 
> load a user-supplied floating point value into the FPU without checking 
> if it is an inf or nan", that's a different matter...
> 
> It seems like the implementation cost of that would be pretty high, and 
> I don't know if it would be a sensible thing to do, or what would 
> motivate such a requirement.
> 
> I would however like to see some confidence that, eg. passing inf/nan 
> vertex values doesn't cause the rasterization engine to blow up and 
> segfault, etc.
> 
> Maybe this is more like a "crashme" test where we write an application 
> that deliberately does random nasty stuff to GL in the hope of causing a 
> failure rather than something which belongs in a visual correctness test 
> like glean?

The OpenGL spec says that even if NaN, infinity, etc are passed to 
OpenGL (or a divide by zero happens) that it "must not lead to GL 
interruption or termination". (sec 2.1.1)

Since exceptions are silently ignored by default (on most systems 
anyway) we can get away with ignoring a lot of potential error 
conditions.  Still, we do occasionally have to deal with some 
rasterization overflow/underflow issues, like you mention.  Over the 
years, I've just been fixing those as they're discovered.

I don't want to begin bullet-proofing the code against all exceptions.

Getting back to the Glean test, I think it might be OK as-is: pass 
some inf/nan values into GL and pass if we don't crash.  But if 
someone wants to dig deeper, having an option to enable exceptions in 
particular cases might be useful.

-Brian

Re: [glean-dev] catching FP exceptions in C++

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

Brian Paul wrote:
> Keith Whitwell wrote:
> 
>> Brian Paul wrote:
>>
>>> Allen Akin wrote:
>>>
>>>> On Tue, Nov 08, 2005 at 04:08:19PM -0700, Brian Paul wrote:
>>>> | I'm going to be writing a new glean test to see how OpenGL handles 
>>>> | infinite/nan/denorm/etc floating point values.
>>>>
>>>> You're a braver man than I am. :-)
>>>>
>>>> | My experience with exception handling in C++ is pretty slim and 
>>>> I'm | not even sure if there's a standard way to handle them.
>>>>
>>>> I'm not either.  I've checked my printed references and done a few web
>>>> searches, and I haven't found anything that claims to work universally.
>>>>
>>>> I suspect the most portable thing we could do would be to use the C99
>>>> standard IEEE exception mechanism.  (See "man fetestexcept", etc.)  It
>>>> depends on the ANSI C signal-catching utilities, but nothing
>>>> *nix-specific as far as I can tell.
>>>>
>>>> However, I don't have any experience with it, so I don't know for sure
>>>> that it'll do the job.
>>>
>>>
>>>
>>>
>>> Thanks, Allen.  I wasn't even aware of those functions.
>>>
>>> I'm checking in what I have so far.  There's no attempt at trapping 
>>> exceptions yet.
>>>
>>> Both Mesa and NVIDIA's driver pass the test in that FP exceptions 
>>> aren't raised by default.  If I enable FP exceptions in Mesa with 
>>> export MESA_DEBUG=FP things blow up as soon as I do this assignment:
>>>
>>> 285:        v[1][0] = make_signaling_nan();
>>>
>>> I guess the various make_*() functions should take a pointer to the 
>>> destination float and store the bit pattern as an integer to avoid 
>>> blowing up in Glean before we even get into OpenGL.
>>
>>
>>
>> It does make me question whether having the traps enabled is going to 
>> work - if you can't even handle the values without provoking an 
>> exception, it would mean that all the gl entrypoints will also provoke 
>> the exceptions.  You may get out of glean, but you'll get caught in 
>> the libGL.so dispatch functions...
> 
> 
> I was thinking about that too.
> 
> Here's a sneaky approach: only enable exceptions before calling glEnd. 
>  In Mesa (and probably other OpenGLs) we don't actually do anything with 
> the vertex data until glEnd, or some other state-change command.
> 
> If exceptions are enabled at that point, only the exceptions generated 
> inside OpenGL should get caught.

If this is to be the case, GL will have to examine every floating point input 
for NaN and/or Inf, and take some action if appropriate.  Is that the specified 
behaviour?  What should be done if someone passes an Inf or NaN in a matrix or 
light parameter?

I'm not sure that we should be trying to move towards a GL that religiously 
guards against these values entering inside it, and then equally religoiusly 
guards against their ever being created internally.  But I do want to make sure 
that they are coped with appropriately, which I felt meant that the library 
should function, perhaps with undefined results, but without crashing.  I would 
qualify that by saying that turning fp exceptions on isn't fair game...

Of course if the GL spec says "you shall never create a NaN floating point 
value" or "you shall never create an Inf", and "you shall never load a 
user-supplied floating point value into the FPU without checking if it is an inf 
or nan", that's a different matter...

It seems like the implementation cost of that would be pretty high, and I don't 
know if it would be a sensible thing to do, or what would motivate such a 
requirement.

I would however like to see some confidence that, eg. passing inf/nan vertex 
values doesn't cause the rasterization engine to blow up and segfault, etc.

Maybe this is more like a "crashme" test where we write an application that 
deliberately does random nasty stuff to GL in the hope of causing a failure 
rather than something which belongs in a visual correctness test like glean?

Keith

Re: [glean-dev] catching FP exceptions in C++

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

Keith Whitwell wrote:
> Brian Paul wrote:
> 
>> Allen Akin wrote:
>>
>>> On Tue, Nov 08, 2005 at 04:08:19PM -0700, Brian Paul wrote:
>>> | I'm going to be writing a new glean test to see how OpenGL handles 
>>> | infinite/nan/denorm/etc floating point values.
>>>
>>> You're a braver man than I am. :-)
>>>
>>> | My experience with exception handling in C++ is pretty slim and I'm 
>>> | not even sure if there's a standard way to handle them.
>>>
>>> I'm not either.  I've checked my printed references and done a few web
>>> searches, and I haven't found anything that claims to work universally.
>>>
>>> I suspect the most portable thing we could do would be to use the C99
>>> standard IEEE exception mechanism.  (See "man fetestexcept", etc.)  It
>>> depends on the ANSI C signal-catching utilities, but nothing
>>> *nix-specific as far as I can tell.
>>>
>>> However, I don't have any experience with it, so I don't know for sure
>>> that it'll do the job.
>>
>>
>>
>> Thanks, Allen.  I wasn't even aware of those functions.
>>
>> I'm checking in what I have so far.  There's no attempt at trapping 
>> exceptions yet.
>>
>> Both Mesa and NVIDIA's driver pass the test in that FP exceptions 
>> aren't raised by default.  If I enable FP exceptions in Mesa with 
>> export MESA_DEBUG=FP things blow up as soon as I do this assignment:
>>
>> 285:        v[1][0] = make_signaling_nan();
>>
>> I guess the various make_*() functions should take a pointer to the 
>> destination float and store the bit pattern as an integer to avoid 
>> blowing up in Glean before we even get into OpenGL.
> 
> 
> It does make me question whether having the traps enabled is going to 
> work - if you can't even handle the values without provoking an 
> exception, it would mean that all the gl entrypoints will also provoke 
> the exceptions.  You may get out of glean, but you'll get caught in the 
> libGL.so dispatch functions...

I was thinking about that too.

Here's a sneaky approach: only enable exceptions before calling glEnd. 
  In Mesa (and probably other OpenGLs) we don't actually do anything 
with the vertex data until glEnd, or some other state-change command.

If exceptions are enabled at that point, only the exceptions generated 
inside OpenGL should get caught.

-Brian

Re: [glean-dev] catching FP exceptions in C++

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

Brian Paul wrote:
> Allen Akin wrote:
> 
>> On Tue, Nov 08, 2005 at 04:08:19PM -0700, Brian Paul wrote:
>> | I'm going to be writing a new glean test to see how OpenGL handles | 
>> infinite/nan/denorm/etc floating point values.
>>
>> You're a braver man than I am. :-)
>>
>> | My experience with exception handling in C++ is pretty slim and I'm 
>> | not even sure if there's a standard way to handle them.
>>
>> I'm not either.  I've checked my printed references and done a few web
>> searches, and I haven't found anything that claims to work universally.
>>
>> I suspect the most portable thing we could do would be to use the C99
>> standard IEEE exception mechanism.  (See "man fetestexcept", etc.)  It
>> depends on the ANSI C signal-catching utilities, but nothing
>> *nix-specific as far as I can tell.
>>
>> However, I don't have any experience with it, so I don't know for sure
>> that it'll do the job.
> 
> 
> Thanks, Allen.  I wasn't even aware of those functions.
> 
> I'm checking in what I have so far.  There's no attempt at trapping 
> exceptions yet.
> 
> Both Mesa and NVIDIA's driver pass the test in that FP exceptions aren't 
> raised by default.  If I enable FP exceptions in Mesa with export 
> MESA_DEBUG=FP things blow up as soon as I do this assignment:
> 
> 285:        v[1][0] = make_signaling_nan();
> 
> I guess the various make_*() functions should take a pointer to the 
> destination float and store the bit pattern as an integer to avoid 
> blowing up in Glean before we even get into OpenGL.

It does make me question whether having the traps enabled is going to work - if 
you can't even handle the values without provoking an exception, it would mean 
that all the gl entrypoints will also provoke the exceptions.  You may get out 
of glean, but you'll get caught in the libGL.so dispatch functions...

Keith

Re: [glean-dev] catching FP exceptions in C++

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

Allen Akin wrote:
> On Tue, Nov 08, 2005 at 04:08:19PM -0700, Brian Paul wrote:
> | I'm going to be writing a new glean test to see how OpenGL handles 
> | infinite/nan/denorm/etc floating point values.
> 
> You're a braver man than I am. :-)
> 
> | My experience with exception handling in C++ is pretty slim and I'm 
> | not even sure if there's a standard way to handle them.
> 
> I'm not either.  I've checked my printed references and done a few web
> searches, and I haven't found anything that claims to work universally.
> 
> I suspect the most portable thing we could do would be to use the C99
> standard IEEE exception mechanism.  (See "man fetestexcept", etc.)  It
> depends on the ANSI C signal-catching utilities, but nothing
> *nix-specific as far as I can tell.
> 
> However, I don't have any experience with it, so I don't know for sure
> that it'll do the job.

Thanks, Allen.  I wasn't even aware of those functions.

I'm checking in what I have so far.  There's no attempt at trapping 
exceptions yet.

Both Mesa and NVIDIA's driver pass the test in that FP exceptions 
aren't raised by default.  If I enable FP exceptions in Mesa with 
export MESA_DEBUG=FP things blow up as soon as I do this assignment:

285:		v[1][0] = make_signaling_nan();

I guess the various make_*() functions should take a pointer to the 
destination float and store the bit pattern as an integer to avoid 
blowing up in Glean before we even get into OpenGL.

-Brian

Re: [glean-dev] catching FP exceptions in C++

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

On Tue, Nov 08, 2005 at 04:08:19PM -0700, Brian Paul wrote:
| I'm going to be writing a new glean test to see how OpenGL handles 
| infinite/nan/denorm/etc floating point values.

You're a braver man than I am. :-)

| My experience with exception handling in C++ is pretty slim and I'm 
| not even sure if there's a standard way to handle them.

I'm not either.  I've checked my printed references and done a few web
searches, and I haven't found anything that claims to work universally.

I suspect the most portable thing we could do would be to use the C99
standard IEEE exception mechanism.  (See "man fetestexcept", etc.)  It
depends on the ANSI C signal-catching utilities, but nothing
*nix-specific as far as I can tell.

However, I don't have any experience with it, so I don't know for sure
that it'll do the job.

Allen

[glean-dev] catching FP exceptions in C++

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

I'm going to be writing a new glean test to see how OpenGL handles 
infinite/nan/denorm/etc floating point values.

At the extreme, the test will pass if you don't crash. :)  It would be 
nicer to catch any floating point exceptions and try to recover.

My experience with exception handling in C++ is pretty slim and I'm 
not even sure if there's a standard way to handle them.

I could add twiddle with the x86 floating point control register to 
generate the exceptions and install a unix-style exception handler, 
but that'll tie it to x86/Unix.

Any ideas?

-Brian

Re: [glean-dev] --overwrite option

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

Good point.  I hadn't considered the debugging process when I originally
chose that behavior.

The reason simple overwrite wasn't allowed was that subsequent runs
might overwrite different files in the results directory, leaving it in
an inconsistent state.  

Johan and I talked about allowing overwrite, and we had decided that the
right behavior was to do just as you did -- delete the entire existing
results directory tree, then create the new one as usual.  But we never
got around to implementing it.

So, bottom line is that I think this is the right approach.  Using
system() is a little sleazy, but not enough to worry about.  There
probably ought to be an assertion in the Windows version of the code to
complain if the overwrite option is used there, since it isn't
implemented.

Allen

[glean-dev] --overwrite option

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

When debugging test failures I typically need to run the same glean 
test over and over.  Each time, I either have to provide a new results 
directory, or remove the previous one.  Otherwise, glean refuses to 
run/overwrite an existing results directory/file.  This is pretty 
inconvenient when you're in gdb.

The attached patch adds a -o/--overwrite option that'll erase the 
named results database if it exists.

I'm not sure it's the right approach though.  The other approach would 
be to do --run without naming a results directory (no results would be 
logged).  But it looks a little harder to implement that.  Can we 
create a /dev/null-like output stream?  That might make it easy.

Comments?

-Brian

Re: [glean-dev] fragment program test

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

On Wed, Oct 26, 2005 at 10:31:33AM -0600, Brian Paul wrote:
| I've checked in a test program for GL_ARB_fragment_program.

Thanks!  Looks like a good approach.

Allen

[glean-dev] fragment program test

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

I've checked in a test program for GL_ARB_fragment_program.

There's a number of different approaches you could take for testing 
this extension.  This one is probably the simplest.  A series of 
simple programs are executed, we read back the framebuffer color and 
compare it to the expected result.  A more sophisticated test would 
generate fragment programs automatically, testing all the different 
combinations of operands, operators, masks, swizzles, etc.

What the current test needs now is a whole bunch of test cases. 
There's only about 6 right now.

-Brian

[glean-dev] glean compile error

[Roland S. <rsc...@hi...>]

To get glean to compile, I needed to include <assert.h> in both the new 
tdepthstencil.cpp and tpointatten.cpp tests (otherwise got "'assert' 
undeclared").

Roland

Re: [glean-dev] Question about building 'glean'

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

Judith Lebzelter wrote:
> Hello,
> 
> I had a bit of difficulty getting 'glean' to compile.  It would not 
> compile until I edited:
> 
> # diff -Nur glean_cvs/src/glean/tvertattrib.cpp glean/src/glean/tvertattrib.cpp
> --- glean_cvs/src/glean/tvertattrib.cpp 2005-09-19 13:16:28.020440201-0700
> +++ glean/src/glean/tvertattrib.cpp     2005-09-20 13:16:16.195697571-0700
> @@ -1524,7 +1524,7 @@
>         for (int i = 0; i < NUM_2_0_ATTRIB_FUNCS; i++) {
>                 int attribFunc = NUM_NV_ATTRIB_FUNCS + NUM_ARB_ATTRIB_FUNCS+ i;
>                 bool b;
> -               b = TestAttribs(r, attribFunc, getAttribfv, aliasing, numAttribs);
> +               b = TestAttribs(r, attribFunc, getAttribfv, REQUIRED, numAttribs);
>                 if (!b)
>                         result = false;
>                 r.num20tested++;
> 
> 
> ---------------------------------
> The error message said the variable 'aliasing' was not declared in that 
> function.  Is the value 'REQUIRED' okay, or should it be something else 
> at this point?  I pulled from the CVS head on sourceforge.  Is that the 
> latest source?

REQUIRED is the correct value.  I've checked in the fix to CVS.

-Brian