glean-dev — Glean development discussions

Re: [glean-dev] Scissor test

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

On Sat, Feb 03, 2001 at 11:41:10AM +1100, Gareth Hughes wrote:
| 
| In terms of floating-point color, Brian Paul made a pretty strong point
| that black should be black and white should be white (ie 0.0 and 1.0
| exactly), so I followed his test implementations and used those values
| as well.

He's right, they really should be 0 and 1 exactly, but if they're not
then all the tests depending on that behavior will fail.  Sometimes
this allows the true cause of a failure to hide behind a bunch of
spurious failures.  Particularly when the suite grows to include
hundreds of tests, it's hard for the driver developer to know which
failure to debug first.

I've made some provisions for dealing with this, but haven't discussed
them with anyone.  My theory was that we could write some simple tests
(e.g.  for readback capability).  The more sophisticated tests would
check the results from the simpler tests to verify that they passed
rather than making assumptions about which functions really work.

Basically each test would check the hasRun flag in the tests on which
it depends.  If hasRun is false, invoke the prerequisite test's run()
function.  This will propagate recursively until all the necessary
results have been accumulated, and the hasRun flag will be used to
make sure no test is run more than once.  Then check the result
structures (which have been carefully left in memory for just this
purpose) to make sure all the prerequisite functions actually work. 
Assuming everything is OK, then go ahead and run the requested test.

Putting together an example of how to do this is on my to-do list, but
it seemed low priority.  Maybe it should be higher.

Allen

Re: [glean-dev] Scissor test

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

Allen Akin wrote:
> 
> Looks pretty good to me.  Only three things come to mind:
> compareOne() still needs to be implemented; testing floating-point
> color values for exact equality (rather than for 0.5LSB tolerance or
> something like it) might be risky; and you might want to use
> GLUtils::useScreenCoords() rather than setting up your own projection
> and viewport parameters (so that the test checks the setup people are
> most likely to use, because it's recommended in the Red Book).
> 
> Nice to have the test, though; scissoring is one of those things that
> are often overlooked.

Yes, I'll address all three of those issues over the weekend.  Thanks
for the feedback!

In terms of floating-point color, Brian Paul made a pretty strong point
that black should be black and white should be white (ie 0.0 and 1.0
exactly), so I followed his test implementations and used those values
as well.

-- Gareth

Re: [glean-dev] Scissor test

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

On Sat, Feb 03, 2001 at 02:19:03AM +1100, Gareth Hughes wrote:
| So I finally sat down and cleaned up my scissor test a bit.  I've just
| added it to the repository.  Comments welcome, but I'll probably ignore
| ones calling me a C hacker (yes, been doing lots of that lately...).

Looks pretty good to me.  Only three things come to mind: 
compareOne() still needs to be implemented; testing floating-point
color values for exact equality (rather than for 0.5LSB tolerance or
something like it) might be risky; and you might want to use
GLUtils::useScreenCoords() rather than setting up your own projection
and viewport parameters (so that the test checks the setup people are
most likely to use, because it's recommended in the Red Book).

Nice to have the test, though; scissoring is one of those things that
are often overlooked.

Allen

[glean-dev] Scissor test

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

So I finally sat down and cleaned up my scissor test a bit.  I've just
added it to the repository.  Comments welcome, but I'll probably ignore
ones calling me a C hacker (yes, been doing lots of that lately...).

-- Gareth

[glean-dev] Re: [glean-patches] 'glean/src/glean ttexcombine.cpp ttexcombine.h'

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

Leath Muller wrote:
> 
> > EXT_texture_env_dot3 extension test.
> 
> Whoa -- when did this sucker become available??? :)

It's in the latest Mesa CVS (both 3.4 and 3.5/main branches).  The
Radeon driver supports it in hardware.

-- Gareth

Re: [glean-dev] Compilation problems under RedHat7

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

On Thu  4 Jan 2001 16:55:15 -0800,
   Allen Akin <ak...@po...> wrote:
> On Thu, Jan 04, 2001 at 04:33:56PM -0800, Allen Akin wrote:
> | ...the putresult() methods segfault because they're passed a bogus
> | pointer to the output stream.  I haven't figured out yet whether this
> | is due to a compiler problem or memory corruption.
> 
> Looks like this is going to be one of those obnoxious ones.  The
> problem goes away when optimization is turned off (-O0) or when
> debugging assertions are added to the code in question.
> 
> In the meantime, if you want to run the current trunk code under
> RH7, I recommend you add the line
> 
> 	OPT=-O0
> 
> to the Makefile in src/glean, right before the line that reads
> 
> 	TARGET=glean

I wonder if this is really something trivially st00pid that I did that
isn't "proper" C++ and that works under g++ but can't be optimized well.
Would turning on more warnings help?  [I'm thinking that might be more
likely than a real compiler bug.]

Re: [glean-dev] Compilation problems under RedHat7

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

OK, problem solved.  It appears we've run into bug 19543 in the RH7
Bugzilla database.  Upgrading to the latest gcc packages (gcc-2.96-69
and friends, available from the usual RedHat mirrors and the RH7
errata page) makes everything work.

Allen

Re: [glean-dev] Compilation problems under RedHat7

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

On Thu, Jan 04, 2001 at 04:33:56PM -0800, Allen Akin wrote:
| ...the putresult() methods segfault because they're passed a bogus
| pointer to the output stream.  I haven't figured out yet whether this
| is due to a compiler problem or memory corruption.

Looks like this is going to be one of those obnoxious ones.  The
problem goes away when optimization is turned off (-O0) or when
debugging assertions are added to the code in question.

In the meantime, if you want to run the current trunk code under
RH7, I recommend you add the line

	OPT=-O0

to the Makefile in src/glean, right before the line that reads

	TARGET=glean

Allen

Re: [glean-dev] Compilation problems under RedHat7

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

On Thu, Jan 04, 2001 at 03:17:14PM -0500, Rik Faith wrote:
| 
| I think the main problem is that I called BaseTest in teh macro in
| tbase.h instead of some templated contructor.  If you fix the macro, it
| should fix many instances of errors.

My latest set of commits includes that change, as well as some other
trivial ones.  Everything compiles and links now, but unfortunately
the putresult() methods segfault because they're passed a bogus
pointer to the output stream.  I haven't figured out yet whether this
is due to a compiler problem or memory corruption.

Allen

Re: [glean-dev] Compilation problems under RedHat7

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

On Thu  4 Jan 2001 11:46:38 -0800,
   Allen Akin <ak...@po...> wrote:
> This is just an FYI.  I grabbed a fresh copy of the trunk this
> morning, and it fails to compile on my RedHat 7.0 system.  This may be
> related to some of the compilation problems Windows users have been
> seeing.  I'll take a look at it shortly.

I think the main problem is that I called BaseTest in teh macro in
tbase.h instead of some templated contructor.  If you fix the macro, it
should fix many instances of errors.

[glean-dev] Compilation problems under RedHat7

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

This is just an FYI.  I grabbed a fresh copy of the trunk this
morning, and it fails to compile on my RedHat 7.0 system.  This may be
related to some of the compilation problems Windows users have been
seeing.  I'll take a look at it shortly.

Allen

Re: [glean-dev] newbie questions.

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

I can't answer the questions about Windows build and STL issues,
but I can say something about this one:

On Thu, Jan 04, 2001 at 12:04:34PM -0700, Mark Mueller wrote:
| 
| There are two .cpp files that test for defined __MS__ and a great number
| that test for __WIN__ (I believe that the standard for Microsoft is usually
| WIN32). Are __MS__ and __WIN__ synonymous? For consistency is it acceptable
| to use only __WIN__ or WIN32?

There exist implementations of X that run natively on Windows, and
implementations of Windows APIs (e.g.  Wine) that run natively on
UNIX.  Since any combination of window system and underlying OS is
possible, there must be two separate conditional compilation controls: 
One for the window system and one for the non-window-system services
provided by the OS.

The window-system controls are __WIN__ and __X11__; only one of those
may be "true" at a given time.  Similarly for the non-window-system
controls, __MS__ and __UNIX__.

So whenever you need conditional compilation, you ask yourself:

	1.  Is this a window-system function?  That is, if I were
	running an X11 server on Windows or a Win32 emulator on UNIX,
	would that matter to me, or would I use the same OS-dependent
	code regardless of which window system was available?  If it
	matters, then go to step 2; otherwise, go to step 3.

	2.  For window-system functions, use __X11__ to guard X code,
	and __WIN__ to guard Win32 code.

	3.  For non-window-system functions, use __UNIX__ to guard
	UNIX code, and __MS__ to guard Win32 code.

Allen

[glean-dev] newbie questions.

[Mark M. <mmu...@va...>]

Hi,
I am new to the building of glean but have been following the mail list for
a couple months. Nonetheless I have lots of newbie questions.

 When I do a windows build I see some problems:

1       The top level makefile.win, in src, does not have a statement to
include common.win though it is assuming that GLEAN_BIN_DIR, etc have
values. This doesn't look right.

2       INTDIR is used to setup LIB32_OBJS in the makefile.win files before
it is assigned a value.

Are those that are building on windows not using the make files but instead
using their own project files? The makefile.win files look like hand edited
project files. As I recall the reason for not having project files in the
repository was to avoid a separate make structure for the windows platform
but isn't that the case with the makefile.win files anyway? Once I fixed the
above problems I was able to build with fine nmake until Rik merged his
branch in : ).

There are two .cpp files that test for defined __MS__ and a great number
that test for __WIN__ (I believe that the standard for Microsoft is usually
WIN32). Are __MS__ and __WIN__ synonymous? For consistency is it acceptable
to use only __WIN__ or WIN32?

Rik, there are conflicts with using vectors in STL lib that is being used
for the Windows. I am looking into this and will provide an update when I
learn something useful.

Mark

Re: [glean-dev] texcombine again

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

On Thu, Jan 04, 2001 at 09:54:25AM -0700, Brian Paul wrote:
| The whole issue of tolerance in the texcombine test should probably be
| examined.

I've added a reminder to the JOBS file.

Allen

Re: [glean-dev] texcombine again

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

Brian Paul wrote:
> 
> You mean inside the Radeon driver?

I was thinking of using.

	glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA,
		     4, 4, 0, GL_RGBA8, GL_UNSIGNED_BYTE, image);

inside the test.  If that's even a legal call...  You get the idea.

> If the Radeon supports 32bpt textures while using a 16bpp framebuffer
> then we should do that.  When you specify a generic internal texture
> format like GL_RGBA the driver should use the deepest texel format
> available.

Is this true in the general case?  It probably won't make much
difference in this case, but on hardware that takes a bigger performance
hit using 32bpp textures do you really want to do that?  Off topic
again, I suppose.

> The whole issue of tolerance in the texcombine test should probably be
> examined.  We should probably take into account the framebuffer depth,
> texel depth, and error bounds of the various combine modes to determine
> the pass/fail threshold.  I've been too lazy to do that.

Okay, maybe we can look into this later.

-- Gareth

Re: [glean-dev] texcombine again

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

Gareth Hughes wrote:
> 
> I'm seeing problems at 16bpp due to ARGB4444 textures being used for the
> tests.  Again, the Radeon passes all ~500,000 tests at 32bpp, but fails
> the first one at 16bpp.  Could we change the texture format so that
> 32bpp textures are used, irrespective of the framebuffer depth?

You mean inside the Radeon driver?

If the Radeon supports 32bpt textures while using a 16bpp framebuffer
then we should do that.  When you specify a generic internal texture
format like GL_RGBA the driver should use the deepest texel format
available.


>  An
> internal format of GL_RGBA8 should be enough.  Brian, your choice of
> texColors should be fairly easy to convert into ubytes instead of
> floats.  Objections?

The whole issue of tolerance in the texcombine test should probably be
examined.  We should probably take into account the framebuffer depth,
texel depth, and error bounds of the various combine modes to determine
the pass/fail threshold.  I've been too lazy to do that.

-Brian

Re: [glean-dev] blendFunc test

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

Gareth Hughes wrote:
> 
> Brian Paul wrote:
> >
> > Check the call to Mesa's gl_create_framebuffer() function and make sure
> > you're not telling Mesa to maintain a software alpha channel.
> >
> > That could cause trouble.
> 
> Yep, that would be it.  You're a champion.  Looks like the other drivers
> are doing the same, so we should update them.  One would assume the DRI
> driver's exported visuals would only include an alpha channel if there
> was hardware support for it.

Right.  There's no need to use software alpha channels with our
hardware drivers.  We're getting off-topic for this list, so let's
move any follow-ups to DRI-devel.

-Brian

[glean-dev] texcombine again

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

I'm seeing problems at 16bpp due to ARGB4444 textures being used for the
tests.  Again, the Radeon passes all ~500,000 tests at 32bpp, but fails
the first one at 16bpp.  Could we change the texture format so that
32bpp textures are used, irrespective of the framebuffer depth?  An
internal format of GL_RGBA8 should be enough.  Brian, your choice of
texColors should be fairly easy to convert into ubytes instead of
floats.  Objections?

-- Gareth

Re: [glean-dev] blendFunc test

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

Brian Paul wrote:
> 
> Check the call to Mesa's gl_create_framebuffer() function and make sure
> you're not telling Mesa to maintain a software alpha channel.
> 
> That could cause trouble.

Yep, that would be it.  You're a champion.  Looks like the other drivers
are doing the same, so we should update them.  One would assume the DRI
driver's exported visuals would only include an alpha channel if there
was hardware support for it.

-- Gareth

Re: [glean-dev] blendFunc test

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

Gareth Hughes wrote:
> 
> Here's a good one.  I'm running the blendFunc test with the Radeon
> driver, it's passing just fine at 16bpp, and failing at 32bpp.  All of
> the errors are on the alpha channel, but the pixels being read back
> contain the expected values.  I'm suspecting the problem lies somewhere
> after the driver reads the pixels from the framebuffer in the span
> functions, and before glean gets the pixel values back.
> 
> Here's the (0,0) pixel data being read back, obviously containing alpha
> values (in ARGB8888 format):
> 
>    x=1 y=1 p=0x6fb39c21
>    x=1 y=1 p=0x00000000
>    x=1 y=1 p=0x6fb39c21
>    x=1 y=1 p=0x6fb39c21
>    x=1 y=1 p=0x6fb39c21
>    x=1 y=1 p=0x18974e06
>    x=1 y=1 p=0x6fb39c21
>    x=1 y=1 p=0x561b4e1a
>    x=1 y=1 p=0x6fb39c21
>    x=1 y=1 p=0x18272207
>    x=1 y=1 p=0x6fb39c21
>    x=1 y=1 p=0x568b7919
>    x=1 y=1 p=0x6fb39c21
>    x=1 y=1 p=0x304e440e
> 
> And here's the test failure message:
> 
> blendFunc:  FAIL rgba8, db, z24, win+pmap, id 0
>         source factor = GL_ZERO, dest factor = GL_ZERO
>         Readback had 8 bits in error; blending had 0 bits in error.
> 
> First failing pixel is at row 0 column 0
> Actual values are (0.698039, 0.678431, 0.678431, 0)
> Expected values are (0.698039, 0.678431, 0.678431, 0.239216)
> Errors are (0, 0, 0, 0.239216)
> Source values are (0.176471, 0.886275, 0.988235, 0.252338)
> Destination values are (0.698039, 0.678431, 0.678431, 0.239216)
> 
> Any ideas?  This doesn't appear to be a driver error, and I haven't seen
> anything like this before.

Check the call to Mesa's gl_create_framebuffer() function and make sure
you're not telling Mesa to maintain a software alpha channel.

That could cause trouble.

-Brian

[glean-dev] blendFunc test

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

Here's a good one.  I'm running the blendFunc test with the Radeon
driver, it's passing just fine at 16bpp, and failing at 32bpp.  All of
the errors are on the alpha channel, but the pixels being read back
contain the expected values.  I'm suspecting the problem lies somewhere
after the driver reads the pixels from the framebuffer in the span
functions, and before glean gets the pixel values back.

Here's the (0,0) pixel data being read back, obviously containing alpha
values (in ARGB8888 format):

   x=1 y=1 p=0x6fb39c21
   x=1 y=1 p=0x00000000
   x=1 y=1 p=0x6fb39c21
   x=1 y=1 p=0x6fb39c21
   x=1 y=1 p=0x6fb39c21
   x=1 y=1 p=0x18974e06
   x=1 y=1 p=0x6fb39c21
   x=1 y=1 p=0x561b4e1a
   x=1 y=1 p=0x6fb39c21
   x=1 y=1 p=0x18272207
   x=1 y=1 p=0x6fb39c21
   x=1 y=1 p=0x568b7919
   x=1 y=1 p=0x6fb39c21
   x=1 y=1 p=0x304e440e

And here's the test failure message:

blendFunc:  FAIL rgba8, db, z24, win+pmap, id 0
	source factor = GL_ZERO, dest factor = GL_ZERO
	Readback had 8 bits in error; blending had 0 bits in error.

First failing pixel is at row 0 column 0
Actual values are (0.698039, 0.678431, 0.678431, 0)
Expected values are (0.698039, 0.678431, 0.678431, 0.239216)
Errors are (0, 0, 0, 0.239216)
Source values are (0.176471, 0.886275, 0.988235, 0.252338)
Destination values are (0.698039, 0.678431, 0.678431, 0.239216)

Any ideas?  This doesn't appear to be a driver error, and I haven't seen
anything like this before.

-- Gareth

Re: [glean-dev] tbasic.h, tbase.h, and MS VC++

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

I thought I'd built it pretty recently, but I guess not quite that 
recently.  I'm seeing all the same problems you are, which I assume is a 
result of a big branch merge that happened recently; I guess it hasn't been 
built under Win32 since then.  I'll check out the errors and see what I can do.

.b

Re: [glean-dev] tbasic.h, tbase.h, and MS VC++

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

On Tue  2 Jan 2001 13:58:07 -0600,
   Jeffrey Mehlhorn <Jef...@3D...> wrote:
>    I can forward the errors that the compiler is
>    reporting, but I'm not sure that would be of
>    much help if you are using an alternate compiler.

They'll help, yes, especially the first few lines.  (If you forward tons
of them, just send them to me instead of the list.)

[glean-dev] tbasic.h, tbase.h, and MS VC++

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

   Allen and Co.

   As recently as, 12/22/2000 I pulled down the
   glean source tree and tried to compile the
   source under MS Visual C++ 6.0.  I soon found
   out that some changes had been made to the
   BasicTest class.  The Visual C++ 6.0 compiler
   seems to be rather rigorous about template
   class definitions because when it tried to
   compile a file that included tbasic.h, several
   compiler errors began to appear.

   Please understand that I am not an Object Oriented
   C++ expert.  In fact, I'm a beginner at best, and
   I find the complexity and abstractness of the glean
   source code to boarder on Object Oriented black
   magic.

   Could one of you C++ gurus take a look at what
   has changed in recent months and see if you can
   determine what needs to happen to make MS Visual
   C++ compile the glean source.

   regards, Jeff

   PS.

   I can forward the errors that the compiler is
   reporting, but I'm not sure that would be of
   much help if you are using an alternate compiler.

[glean-dev] Updates to ttexcombine.cpp

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

I've added tests for EXT_texture_env_dot3 to this glean test.  I check
the availability extension manually and if it's available do tests with
GL_DOT3_RGB_EXT and GL_DOT3_RGBA_EXT combining.  This test, and the
accompanying Mesa implementation, can be trivially updated to the ARB
extension when it becomes available.  The EXT extension has a constant
scale factor of 4, while the ARB one will likely remove this
restriction.

We have the whole glext.h header file update issue to deal with, of
course.  Allen, I wasn't sure if glwrap.h was the right place for the
two enums, so I've just conditionally defined them at the start of this
file.  Any suggestions of a nicer way of handling this would be
appreciated.

I will commit this sometime soon (very busy at the moment).

-- Gareth