glean-dev — Glean development discussions

Re: [glean-dev] new case for FBO

[He, S. <shu...@in...>]

He, Shuang wrote:
> Hi,
>        I've written a glean case for GL_EXT_framebuffer_object. The 
> test case is attached.
>
> The test case is categorized into following parts:
>
>                  Functionality:
>
>                     Sanity check (checks max number of supported color 
> attachment points, default framebuffer binding, max Renderbuffer Size)
>
>                     Render to texture through single Framebuffer 
> object (1D, 2D, 3D, Cube texture, combined with depth/stencil buffer).
>
>                     Render to multiple textures through 
> multiple/single Framebuffer object (test render to 2D texture in 
> different usage models).
>
>                     Render to depth texture without color buffer.
>
>                     Render to texture with manual mipmap generation.
>
>            Performance:
>
>                     Compare performance of new style texture through 
> FBO with previous glCopyTexImgage style texture
>
> Thanks
>    --Shuang
>
>
>
Updated test case attached. since I forgot to set the texture wrap 
modes. And test case can get pass/fail=8/0 for software rendering now.

Thanks
    --Shuang

[glean-dev] new case for FBO

[He, S. <shu...@in...>]

Hi,
        I've written a glean case for GL_EXT_framebuffer_object. The 
test case is attached.

The test case is categorized into following parts:

                  Functionality:

                     Sanity check (checks max number of supported color 
attachment points, default framebuffer binding, max Renderbuffer Size)

                     Render to texture through single Framebuffer object 
(1D, 2D, 3D, Cube texture, combined with depth/stencil buffer).

                     Render to multiple textures through multiple/single 
Framebuffer object (test render to 2D texture in different usage models).

                     Render to depth texture without color buffer.

                     Render to texture with manual mipmap generation.

            Performance:

                     Compare performance of new style texture through 
FBO with previous glCopyTexImgage style texture

Thanks
    --Shuang

 

[glean-dev] Investment in Property (Dubai, United Arab Emirates)

[Offers <ei...@bk...>]

Dear Sir / Madame
We are offering property: apartments, offices lands for construction and full buildings.
Biggest database, many offers from developers, professional consultants.
If, interesting for investment, living or set up your business in UAE.
Please, kindly contact to us:
Mobile: 00971508897750
Email: ei...@bk...
We are official real estate agency and developer.
Regards
Rustam Djanibekov
Property Consultant
 

Re: [glean-dev] patch for glean case pbo

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

He, Shuang wrote:
> As bug #13747 & #13749 fixed, I just found there’s a bug in pbo test 
> case. Here’s the patch to correct it

I fixed that problem last week.  Try the latest code from CVS.

-Brian

Re: [glean-dev] fix glean build

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

On Wed, Feb 20, 2008 at 09:26:55AM -0700, Brian Paul wrote:
| So the patch allows 'make' to work without doing 'make install' first? 

I believe that's the intent.  The side-effect is that you can no longer
do experimental or testing builds in a subdirectory, because all the
other subdirectories "see" the modified headers and libraries right
away, rather than only after a "make install".  But I suspect I'm the
only person who ever used that feature of the build system.  It was
intended for larger projects in the days of less-capable source code
management systems.

| Seems OK.

OK, I'll apply it.

| I generally don't object to a new build system either.  But TG (and 
| others, I suspect) will still need to run Glean on Windows.  Switching 
| to autoconf would be a problem in that regard.

Understood.

Allen

Re: [glean-dev] fix glean build

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

Allen Akin wrote:
> On Tue, Feb 19, 2008 at 05:20:57PM -0800, Eric Anholt wrote:
> |          ... instead I cargo-cult the following patch around to machines
> | to make glean build, since nothing ends up in glean/include/ or
> | glean/lib/.
> 
> Well, that breaks the way they were intended to be used, but since I've
> long ago given up on the general approach of the glean Makefiles, I
> don't have any compelling objections.  If Brian's OK with it I'll apply
> the patch.

So the patch allows 'make' to work without doing 'make install' first? 
Seems OK.


> Just so everyone's clear, I think it would be a good idea to rework
> glean's build.  I've avoided it mainly because (1) there'll be a lot of
> conflict over which system to use, and (2) there are other (larger)
> organizational issues that really ought to be addressed at the same
> time, and I haven't spent the time to find the right solution for those.

I generally don't object to a new build system either.  But TG (and 
others, I suspect) will still need to run Glean on Windows.  Switching 
to autoconf would be a problem in that regard.

-Brian

Re: [glean-dev] testing for behavior with bad vertex programs

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

Eric Anholt wrote:
> We had an issue with the driver crashing in handling bad vertex program
> strings, so I wrote a little glean test for it and the associated GL
> errors that are supposed to be emitted when rendering with an invalid
> program active.  Mesa doesn't report errors for the rendering cases and
> thus fails the tests.

I've fixed things so GL_INVALID_OPERATION is raised for bad program strings.

But I think your glBegin-time test for a valid program is incorrect.  If 
glProgramString() is called with bad data, an error should be recorded, 
but the previously defined program should remain in effect.  That's 
consistant with other GL calls (if the call generates an error, don't 
change any GL state).  This is also what I see with NVIDIA's driver.

So, the glBegin-time test for GL_INVALID_OPERATION should be removed. 
Another way to test for that would be to bind a non-existant vertex 
program before drawing.

Finally, I think this code:

 > +		while (err != 0)
 > +			glGetError();

Should read:

     while (err != 0)
         err = glGetError();

-Brian

Re: [glean-dev] fix glean build

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

On Tue, Feb 19, 2008 at 05:20:57PM -0800, Eric Anholt wrote:
|          ... instead I cargo-cult the following patch around to machines
| to make glean build, since nothing ends up in glean/include/ or
| glean/lib/.

Well, that breaks the way they were intended to be used, but since I've
long ago given up on the general approach of the glean Makefiles, I
don't have any compelling objections.  If Brian's OK with it I'll apply
the patch.

Just so everyone's clear, I think it would be a good idea to rework
glean's build.  I've avoided it mainly because (1) there'll be a lot of
conflict over which system to use, and (2) there are other (larger)
organizational issues that really ought to be addressed at the same
time, and I haven't spent the time to find the right solution for those.

Allen

[glean-dev] fix glean build

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

I generally regard the glean build system as something to be avoided, to
the point where I was maintaining a mirror repo in git with an autotools
branch for some time.  I've since gotten lazier (and misplaced my
script), and instead I cargo-cult the following patch around to machines
to make glean build, since nothing ends up in glean/include/ or
glean/lib/.

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

[glean-dev] testing for behavior with bad vertex programs

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

We had an issue with the driver crashing in handling bad vertex program
strings, so I wrote a little glean test for it and the associated GL
errors that are supposed to be emitted when rendering with an invalid
program active.  Mesa doesn't report errors for the rendering cases and
thus fails the tests.

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

Re: [glean-dev] SIN/COS fp test extension

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

Eric Anholt wrote:
> I added a few more constants to test for the SIN/COS cases, as the
> existing tests didn't catch massive failure by i915's SIN/COS code.  The
> failures seemed like easy ones to make in emulating sin/cos and relevant
> for testing for the future.

Committed.  Thanks, Eric!

-Brian

[glean-dev] SIN/COS fp test extension

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

I added a few more constants to test for the SIN/COS cases, as the
existing tests didn't catch massive failure by i915's SIN/COS code.  The
failures seemed like easy ones to make in emulating sin/cos and relevant
for testing for the future.

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

Re: [glean-dev] new test case for PBO(OpenGL 2.1 GL_ARB_pixel_buffer_object)

[He, S. <shu...@in...>]

Brian Paul wrote:
> He, Shuang wrote:
>> A new test case has been developed to help testing PBO. This test
>> case basically includes tests about:
>>=20
>> Functionality:
>>=20
>>                      Sanity check (checks default pixel buffer
>> binding, pixel buffer object generation/destruction)
>>=20
>>                      DrawPixels/ReadPixels/PixelMap(combination
>> with/without PBO).=20
>>=20
>>                       Bitmap/ReadPixels(combination with/without PBO)
>>=20
>>                      TexImage/GetTexImage(combination with/without
>> PBO).=20
>>=20
>>                       TexSubImage/GetTexImage(combination
>> with/without PBO).=20
>>=20
>>                       PolygonStiple
>>=20
>>                       Error handling
>>=20
>>              Performance:
>>=20
>>                      Compare performance of new style texture through
>> PBO with old style texture
>=20
> I'll check in the new test, but there seems to be some failures with
> Mesa s/w rendering (and NVIDIA's libGL, BTW).
>=20
> If you set the MESA_DEBUG env var, you'll see:
>=20
> Mesa: User error: GL_INVALID_OPERATION in glDrawPixels(invalid PBO
> access) Mesa: User error: GL_INVALID_OPERATION in
> glReadPixels(invalid PBO access) Mesa: User error: GL_INVALID_VALUE
> in glTexImage2D(internalFormat=3D0x80e1) Mesa: User error:
> GL_INVALID_OPERATION in glTexSubImage2D=20
> Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D
> [...]
>=20
> I don't have time to investigate though so I don't know if it's the
> test or GLs that are at fault.
>=20
> -Brian

Thanks for your feedback.
I'd like to look into these failures, but how can I run PBO with Mesa
s/w rendering?
It seems GL_ARB_pixel_buffer_object is not supported by Mesa s/w
rendering.

Thanks
    --Shuang

Re: [glean-dev] new test case for PBO(OpenGL 2.1 GL_ARB_pixel_buffer_object)

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

He, Shuang wrote:
> A new test case has been developed to help testing PBO. This test case 
> basically includes tests about:
> 
> Functionality:
> 
>                      Sanity check (checks default pixel buffer binding, 
> pixel buffer object generation/destruction)
> 
>                      DrawPixels/ReadPixels/PixelMap(combination 
> with/without PBO).
> 
>                       Bitmap/ReadPixels(combination with/without PBO)
> 
>                      TexImage/GetTexImage(combination with/without PBO).
> 
>                       TexSubImage/GetTexImage(combination with/without PBO).
> 
>                       PolygonStiple
> 
>                       Error handling
> 
>              Performance:
> 
>                      Compare performance of new style texture through 
> PBO with old style texture

I'll check in the new test, but there seems to be some failures with 
Mesa s/w rendering (and NVIDIA's libGL, BTW).

If you set the MESA_DEBUG env var, you'll see:

Mesa: User error: GL_INVALID_OPERATION in glDrawPixels(invalid PBO access)
Mesa: User error: GL_INVALID_OPERATION in glReadPixels(invalid PBO access)
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(internalFormat=0x80e1)
Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D
Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D
[...]

I don't have time to investigate though so I don't know if it's the test 
or GLs that are at fault.

-Brian

Re: [glean-dev] API2Test::testStencilFuncSeparate doesn't detect how many bits we have for stencil

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

He, Shuang wrote:
> Here’s a small patch may fix this:

Thanks.  I've committed the patch.

-Brian

[glean-dev] API2Test::testStencilFuncSeparate doesn't detect how many bits we have for stencil

[He, S. <shu...@in...>]

Here's a small patch may fix this:

=20

--- a.cpp       2007-12-10 14:27:08.000000000 +0800

+++ b.cpp       2007-12-10 14:38:37.000000000 +0800

@@ -772,12 +772,17 @@

        return true;

 }

=20

-

+#define CLAMP( X, MIN, MAX )  ( (X)<(MIN) ? (MIN) : ((X)>(MAX) ? (MAX)
: (X)) )

 bool

 API2Test::testStencilFuncSeparate(void)

 {

        GLint val;

=20

+       int stencilBits;

+       int stencilMax;

+       glGetIntegerv(GL_STENCIL_BITS, &stencilBits);

+       stencilMax =3D (1 << stencilBits) - 1;

+

        glStencilFuncSeparate_func(GL_FRONT, GL_LEQUAL, 12, 0xf);

        glStencilFuncSeparate_func(GL_BACK, GL_GEQUAL, 13, 0xe);

=20

@@ -794,13 +799,13 @@

        }

=20

        glGetIntegerv(GL_STENCIL_BACK_REF, &val);

-       if (val !=3D 13) {

+       if (val !=3D CLAMP(13, 0, stencilMax)) {

                REPORT_FAILURE("GL_STENCIL_BACK_REF query returned wrong
value");

                return false;

        }

=20

        glGetIntegerv(GL_STENCIL_REF, &val);

-       if (val !=3D 12) {

+       if (val !=3D CLAMP(12, 0, stencilMax)) {

                REPORT_FAILURE("GL_STENCIL_REF (front) query returned
wrong value");

                return false;

        }

=20

Thanks

    --Shuang

=20

Re: [glean-dev] floating tolerance in tglsl1.cpp

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

Jin, Gordon wrote:
> Hi,
> 
> glean/tglsl1.cpp doesn't consider floating point tolerance when
> comparing float variable. Attached is the patch.

Committed.  Thanks.

-Brian

[glean-dev] floating tolerance in tglsl1.cpp

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

Hi,

glean/tglsl1.cpp doesn't consider floating point tolerance when
comparing float variable. Attached is the patch.

Thanks
Gordon=20

[glean-dev] GLSL and API2 tests unsuccessful on XP + GeForce 7

[Victor H. <sh...@gm...>]

I ran glsl1 on an XP system with GeForce 7600, which supports OpenGL 2.0.
However, I got many of the following error:

Unable to get pointer to an OpenGL 2.0 API function
glsl1:  NOTE rgb8, aux4, z24, accrgba16, win, id 1
        Test skipped/non-applicable

This seems to happen because GLSLTest::getFunctions() are failing when
getting address for function pointers to OpenGL 2.0 API's via
wglGetProcAddress(). Maybe this is related to the fact that api2 test also
doesn't fully pass with errors like the following:

FAILURE: GL_STENCIL_BACK_REF query returned wrong value (at tapi2.cpp:798)


Is there anything special I need to have on the system in order for
the 2.0API's to work? I have loaded the lastest NVidia driver for XP,
but other
than that I have no clue.

Thanks.

Re: [glean-dev] Basic test case for ARB_point_sprite

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

On 8/15/07, Wu Nian <ni...@in...> wrote:
> Hi list:
>
> The attached tests case is for extension "ARB_point_sprite".
> Please review it and help to commit if possible.

Looks good.  I've added it to CVS.

-Brian

[glean-dev] Basic test case for ARB_point_sprite

[Wu N. <ni...@in...>]

Hi list:

The attached tests case is for extension "ARB_point_sprite".
Please review it and help to commit if possible.

Thanks,
Nian Wu

Re: [glean-dev] Test construction [Was: Basic tests on ARB_Occlusion_Query]

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

Allen Akin wrote:
> On Tue, Jul 10, 2007 at 11:27:48AM +0800, Wang, Wei Z wrote:
> | The attached files are for some basic conformance tests on extension 
> | "ARB_Occlusion_Query".
> 
> Thanks for submitting the tests!
> 
> I see Brian's already checked them in.  (Thanks, Brian.)
> 
> I have a few thoughts about how an ideal test should be constructed.
> I'll mention them here so everyone has a chance to consider them.  I
> won't have reliable net access for a couple of weeks, so I can't
> guarantee that I can participate in a discussion right away,
> unfortunately.
> 
> One good goal is to make sure each test has a meaningful compareOne()
> method.  As the number of tests grows larger, and as individual tests
> get more complex, it gets harder to see how results change from run to
> run.  For any OpenGL test suite that's even close to complete, a test
> log is enormous; it isn't practical to look for meaningful differences
> in warnings that are written to stderr, or determine whether numerical
> changes are statistically significant.  Good compareOne() methods make
> it possible to automate checking for changes, and allow the author of
> the test to determine whether a change is significant (something that
> might be hard for another glean user to determine if he doesn't know the
> test well).
> 
> A consequence of wanting meaningful compareOne() methods is that a glean
> test should record *everything* that's needed to interpret the result in
> its Result structure.  Not just pass/fail, but numerical results,
> diagnostic information, consistency problems (like GL errors that
> shouldn't occur), etc.
> 
> One thing I didn't do originally, but I wish I had, was to generate log
> messages only from Result structures, not from program logic during the
> run of a test.  That would make it possible to regenerate a log from a
> results database.  Then you wouldn't need to keep the log *and* the
> database to compare two runs; you'd only need the database.  Keeping
> this idea in mind is also a good way to decide whether you've put
> everything into the Result structure that a given test really needs.
> 
> That's it for the moment.  I hope it's good food for thought!

Yeah, unifying the logs and databases would be great.  As it is now, the 
database/test result is usually just some numeric information like 
pass/fail counts, perf numbers, etc. while the log is more 
verbose/interesting with explanations for failures, etc.  Truth is, I 
seldom look at the database files.  I usually just monitor the logging 
output.

Suppose we added a freeform text/log field to the BaseResult or 
BasicResult class that could accumulate arbitrary text messages.  A 
BaseResult::log(string) method would both append the string to the 
result log and emit it to stdout.

The putresults() method would write both the pass/fail/numeric info and 
text log to the file, perhaps separated by a special token that 
getresults() could use to determine where one section ends and the next 
begins.

compareOne() would ignore the log text.

How does that sound good?  I think it would be a step in the right 
direction and not too hard to implement.

-Brian

[glean-dev] Test construction [Was: Basic tests on ARB_Occlusion_Query]

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

On Tue, Jul 10, 2007 at 11:27:48AM +0800, Wang, Wei Z wrote:
| The attached files are for some basic conformance tests on extension 
| "ARB_Occlusion_Query".

Thanks for submitting the tests!

I see Brian's already checked them in.  (Thanks, Brian.)

I have a few thoughts about how an ideal test should be constructed.
I'll mention them here so everyone has a chance to consider them.  I
won't have reliable net access for a couple of weeks, so I can't
guarantee that I can participate in a discussion right away,
unfortunately.

One good goal is to make sure each test has a meaningful compareOne()
method.  As the number of tests grows larger, and as individual tests
get more complex, it gets harder to see how results change from run to
run.  For any OpenGL test suite that's even close to complete, a test
log is enormous; it isn't practical to look for meaningful differences
in warnings that are written to stderr, or determine whether numerical
changes are statistically significant.  Good compareOne() methods make
it possible to automate checking for changes, and allow the author of
the test to determine whether a change is significant (something that
might be hard for another glean user to determine if he doesn't know the
test well).

A consequence of wanting meaningful compareOne() methods is that a glean
test should record *everything* that's needed to interpret the result in
its Result structure.  Not just pass/fail, but numerical results,
diagnostic information, consistency problems (like GL errors that
shouldn't occur), etc.

One thing I didn't do originally, but I wish I had, was to generate log
messages only from Result structures, not from program logic during the
run of a test.  That would make it possible to regenerate a log from a
results database.  Then you wouldn't need to keep the log *and* the
database to compare two runs; you'd only need the database.  Keeping
this idea in mind is also a good way to decide whether you've put
everything into the Result structure that a given test really needs.

That's it for the moment.  I hope it's good food for thought!

Allen

Re: [glean-dev] Basic tests on ARB_Occlusion_Query

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

Wang, Wei Z wrote:
> Hi list:
> 
> The attached files are for some basic conformance tests on extension 
> "ARB_Occlusion_Query".
> Pls. review it and help to commit if possible.

Looks good.  I've added it to glean CVS.  Thanks!

-Brian

[glean-dev] Basic tests on ARB_Occlusion_Query

[Wang, W. Z <wei...@in...>]

Hi list:

The attached files are for some basic conformance tests on extension=20
"ARB_Occlusion_Query".
Pls. review it and help to commit if possible.

Thanks
-Wei