headers
Brian Paul | 1 Mar 2005 01:55

Re: GLES packaging issues

Adam Jackson wrote:
> On Monday 28 February 2005 15:26, Brian Paul wrote:
> 
>>Adam Jackson wrote:
>>
>>>The packaging issues from the GLES spec need to be addressed if we're to
>>>move forward with EGL compatibility.  The spec requires egl.h to be
>>>available as <GLES/egl.h>, and that the library itself be linkable as
>>>libGLES_nn.z, where nn is either CM or CL for the common or common-lite
>>>profiles and .z is the platform's DSO suffix (.so for us).
>>>
>>>These requirements strike me as gratuitous change.  I'm tempted to just
>>>add magic symlinks to the install targets (ie, GLES/ to GL/ and libGL.so
>>>to libGLextranoise.so).  This of course fails on win32.
>>
>>Feel free to create an include/GLES directory and add the egl.h
>>header.  As for the symlink, perhaps an (ugly) work-around would be to
>>create a GLES/gl.h file that just #includes ../GL/gl.h
> 
> 
> AFAICT gl.h doesn't need to exist under GLES/.  eglinfo just does #include 
> <GLES/egl.h>, and the spec doesn't say anything about the location of gl.h 
> that I can find.

There is a gl.h for OpenGL ES: 
http://www.khronos.org/opengles/spec_headers/opengles1_1/gl.h

It's basically a subset of the regular gl.h.  I presume it would live 
in the GLES/ directory.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jon Smirl | 1 Mar 2005 18:47
Picon
Gravatar

First Public Review of Draft OpenGL® ES 2.0 Specification!

Just got this in the mail, may we can get mode and cursor APIs added....
I've been posting mode/cursor support patches to the fbdev list but
they are not finished yet.

--------------------------------------------------------------------------------------

Today Khronos announced that the first draft specification of the
OpenGL® ES 2.0 API standard is available for review by selected
developers.

Khronos invites any person or company that is interested in reviewing
the specification to submit and application consisting of a brief
statement of your qualifications as a reviewer, and an executed
Khronos Reviewer's Agreement in order to provide feedback and guidance
to the OpenGL ES Working Group.

If you would like the "official" details about this review phase, to
get the full details of the press release, or to see the Reviewer's
Agreement, please go to: http: //www.khronos.org/opengles/review

--

-- 
Jon Smirl
jonsmirl <at> gmail.com

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
(Continue reading)

Permalink | Reply | 2 comments |
headers
SourceForge.net | 2 Mar 2005 09:55
Picon
Favicon

[ mesa3d-Bugs-1154919 ] CRITICAL: Compile failure under cygwin

Bugs item #1154919, was opened at 2005-03-02 10:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=1154919&group_id=3

Category: mesa-core
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Jari Aalto (jaalto)
Assigned to: Nobody/Anonymous (nobody)
Summary: CRITICAL: Compile failure under cygwin

Initial Comment:
AS MESA does not have i686-cygwin onfigure or make 
target, I used  linux-x86 . However the compilaton fails on 
this error.

ENV

make is /usr/bin/make
make is /bin/make
GNU Make 3.80
gcc is /usr/bin/gcc
gcc is /bin/gcc
gcc (GCC) 3.3.3 (cygwin special)
libtool is /usr/bin/libtool
libtool is /bin/libtool
ltmain.sh (GNU libtool) 1.5.10 (1.1220.2.131 2004/09/19
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 2 Mar 2005 16:55

[Bug 2639] New: Shouldn't triangles be drawn where and only where containing "pixel centra"?

Please do not reply to this email: if you want to comment on the bug, go to    

the URL shown below and enter yourcomments there.     

https://bugs.freedesktop.org/show_bug.cgi?id=2639          

           Summary: Shouldn't triangles be drawn where and only where
                    containing "pixel centra"?
           Product: Mesa
           Version: 6.2.1
          Platform: PC
               URL: http://www.esat.kuleuven.ac.be/~sderoeck/triangle_test.t
                    gz
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Mesa core
        AssignedTo: mesa3d-dev <at> lists.sourceforge.net
        ReportedBy: stefaandr <at> hotmail.com

I have written a program that relies heavily on pixels being drawn if and only
if the given triangle contains the center of the pixel concerned.  This
assumption seems quite ok where I use the nvidia-gl-drivers.  When I try the
Mesa-drivers however, both the frequency of errors and the magnitude of the
errors is a lot higher (to the extent that my program can't cope with them).  

Is my assumption of when pixels should be drawn wrong?  Maybe my implementation
is somehow flaky?  Is this an accuracy problem concerninc Mesa?  Any feedback is
much appreciated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 2 Mar 2005 17:47

[Bug 2639] Shouldn't triangles be drawn where and only where containing "pixel centra"?

Please do not reply to this email: if you want to comment on the bug, go to    

the URL shown below and enter yourcomments there.     

https://bugs.freedesktop.org/show_bug.cgi?id=2639          

------- Additional Comments From brian.paul <at> tungstengraphics.com  2005-03-02 08:47 -------
If you want to hit specific pixels you have to very carefully set up your
modelview and projection matrices.  Appendix H of the OpenGL Programming Guide
explains the issue.  If you do a google search for "OpenGL correctness tips" you
should find what you need.          

     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 0 comments |
headers
SourceForge.net | 2 Mar 2005 17:54
Picon
Favicon

[ mesa3d-Bugs-1154919 ] CRITICAL: Compile failure under cygwin

Bugs item #1154919, was opened at 2005-03-02 01:55
Message generated for change (Comment added) made by brianp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=1154919&group_id=3

Category: mesa-core
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Jari Aalto (jaalto)
Assigned to: Nobody/Anonymous (nobody)
Summary: CRITICAL: Compile failure under cygwin

Initial Comment:
AS MESA does not have i686-cygwin onfigure or make 
target, I used  linux-x86 . However the compilaton fails on 
this error.

ENV

make is /usr/bin/make
make is /bin/make
GNU Make 3.80
gcc is /usr/bin/gcc
gcc is /bin/gcc
gcc (GCC) 3.3.3 (cygwin special)
libtool is /usr/bin/libtool
libtool is /bin/libtool
ltmain.sh (GNU libtool) 1.5.10 (1.1220.2.131 2004/09/19
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolai Haehnle | 2 Mar 2005 21:27
Picon

glean test "exactRGBA"

Hi,

while playing around with a Mesa-based driver, I noticed that pure Mesa 
software rendering (LIBGL_FORCE_XMESA) fails  the "exactRGBA" (in 
treadpix.cpp) test of glean:

exactRGBA:  FAIL rgb8, db, z16, s8, accrgba16, win+pmap, id 44
        Unsigned short worst-case error was 0x100 at (0, 0)
                expected (0xeb00, 0x5e00, 0xb300, 0x0)
                got (0xea00, 0x5e00, 0xb300, 0x0)
        Unsigned int   worst-case error was 0x1000000 at (2, 0)
                expected (0xd1000000, 0x66000000, 0x8000000, 0x0)
                got (0xd1000000, 0x66000000, 0x9000000, 0x0)

As you can see, the least significant bit in the framebuffer isn't what 
glean expects.

After some investigation, this seems to be due to a subtle rounding issue. 
The exactRGBA test does not round color values before submitting them via 
glColorusv/uiv. Mesa converts those unrounded fixed point values to floats 
using the USHORT_TO_FLOAT and UINT_TO_FLOAT macros, which divide by (2^n - 
1) where n = 16 or 32.

Glean, on the other hand, expects a rounding behaviour where the lower bits 
are basically truncated. But this "truncation" is exactly what the quoted 
paragraph from section 2.14.9 of the OpenGL 2.0 specification expects, even 
though the *same* section of the spec requires the division behaviour that 
Mesa implements.

So whose fault is this? Mesa, glean or even the spec itself?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tomas carnecky | 2 Mar 2005 22:03

Re: [Mesa3d-dev] First Public Review of Draft OpenGL® ES 2.0 Specification!

Jon Smirl wrote:
> Just got this in the mail, may we can get mode and cursor APIs added....
> I've been posting mode/cursor support patches to the fbdev list but
> they are not finished yet.
> 
> --------------------------------------------------------------------------------------
> 
> Today Khronos announced that the first draft specification of the
> OpenGL® ES 2.0 API standard is available for review by selected
> developers.
> 

Can both OpenGL and OpenGLES be used in one and the same application 
simultaneously? And will it be possible to have both libraries on the 
same system, one application using OpenGL and the other OpenGLES?

thanks
tom

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
Permalink | Reply | 1 comment |
headers
Allen Akin | 2 Mar 2005 23:18
Picon
Favicon

Re: glean test "exactRGBA"

On Wed, Mar 02, 2005 at 09:27:25PM +0100, Nicolai Haehnle wrote:
| So whose fault is this? Mesa, glean or even the spec itself?
| Personally, I'd say the truncation behaviour described in the second 
| paragraph of 2.14.9 is wrong; it should allow for upward rounding by the 
| implementation. However, I'd really appreciate your opinion in this matter.

In the olden days, it was surprisingly common for applications to demand
absolute control over the values written to the color buffer.  (Often
because they were going to use exclusive-or for reversible drawing, or
direct-color style color tables for color correction or animation, or
multiple color layers for ECAD, or things even more tricky.)

It also turns out to be very useful for testing the GL implementation if
tests can guarantee that the color values they specify will be written
into the color buffer without any modification.

The language in section 2.14.9 is there specifically to support those
uses.  However, it is a special case, and it requires special code paths
in most GL implementations.  Not everyone wants to bother with those.

The compromise that most developers seem to have made is that 8-bit
color channels have the special behavior, but deeper color channels
don't.  Implementing that is simple, and it preserves compatibility for
the few legacy applications that need it nowadays.

Glean tests the special case because it's useful to know if all the bits
in the color channel can be written reliably.  For example,
coloredLitPerf2 and coloredTexPerf2 don't bother running on visuals that
fail the color correctness test, because they can't tell whether the
final rendered image is correct.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nicolai Haehnle | 3 Mar 2005 01:00
Picon

Re: glean test "exactRGBA"

On Wednesday 02 March 2005 23:18, Allen Akin wrote:
> On Wed, Mar 02, 2005 at 09:27:25PM +0100, Nicolai Haehnle wrote:
> | So whose fault is this? Mesa, glean or even the spec itself?
> | Personally, I'd say the truncation behaviour described in the second 
> | paragraph of 2.14.9 is wrong; it should allow for upward rounding by the 
> | implementation. However, I'd really appreciate your opinion in this 
matter.
> 
> In the olden days, it was surprisingly common for applications to demand
> absolute control over the values written to the color buffer.  (Often
> because they were going to use exclusive-or for reversible drawing, or
> direct-color style color tables for color correction or animation, or
> multiple color layers for ECAD, or things even more tricky.)
> 
> It also turns out to be very useful for testing the GL implementation if
> tests can guarantee that the color values they specify will be written
> into the color buffer without any modification.
> 
> The language in section 2.14.9 is there specifically to support those
> uses.  However, it is a special case, and it requires special code paths
> in most GL implementations.  Not everyone wants to bother with those.
> 
> The compromise that most developers seem to have made is that 8-bit
> color channels have the special behavior, but deeper color channels
> don't.  Implementing that is simple, and it preserves compatibility for
> the few legacy applications that need it nowadays.

Thanks for the explanation.

> Glean tests the special case because it's useful to know if all the bits
(Continue reading)

Permalink | Reply | 1 comment |

Gmane