headers
Mike A. Harris | 1 Jul 2003 08:33
Picon
Favicon

User reported bug in GL header files in 4.3.0

A user just reported the following bug to me in bugzilla:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97840

I'm not really willing to make bug fixes to Mesa in XFree86
however unless they're approved by the Mesa development team, or 
really obvious fixes.

Could someone look at this and comment on the issue, and state 
why it is or isn't a bug?

TIA

--

-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Permalink | Reply | 16 comments |
headers
Brian Paul | 1 Jul 2003 17:21

Re: User reported bug in GL header files in 4.3.0

Mike A. Harris wrote:
> A user just reported the following bug to me in bugzilla:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97840
> 
> I'm not really willing to make bug fixes to Mesa in XFree86
> however unless they're approved by the Mesa development team, or 
> really obvious fixes.

According to the bugzilla report, this was fixed in Mesa 4.1 and 
later.  The next time there's a DRI->XFree86 merge this'll be resolved.

> Could someone look at this and comment on the issue, and state 
> why it is or isn't a bug?

I guess I still don't see what the real issue is.  There's no harm in 
defining the GL_ARB_multitexture tokens, prototypes and function 
pointers in gl.h where they were (instead of in glext.h).

I also don't understand how this compile time issue with wine effects 
a game at runtime.

-Brian

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
(Continue reading)

Permalink | Reply | 15 comments |
headers
Ian Romanick | 1 Jul 2003 18:18
Picon
Favicon

Re: User reported bug in GL header files in 4.3.0

Brian Paul wrote:
> Mike A. Harris wrote:
> 
>> Could someone look at this and comment on the issue, and state why it 
>> is or isn't a bug?
> 
> I guess I still don't see what the real issue is.  There's no harm in 
> defining the GL_ARB_multitexture tokens, prototypes and function 
> pointers in gl.h where they were (instead of in glext.h).
> 
> I also don't understand how this compile time issue with wine effects a 
> game at runtime.

I don't think the problem was that the prototypes, et. al. were being 
defined in gl.h.  I think the problem was that they had a #ifdef around 
them that was causing them to not be defined.  It was effecting the app 
at run-time because Wine was being built using gl.h.  When Wine was 
built with the unpatched gl.h, they had problems.  When Wine was built 
with the patched gl.h or Nvidia's gl.h, it worked fine.

To me, this really smells like a case of "It happens to work with one 
but not the other, so it can't be our bug."  If they want the extension 
version of the prototypes, etc. they should include glext.h.  Could it 
be that the old version of gl.h also didn't have the core GL version of 
the multitexture stuff?

For my money, this feels like a Wine bug that could be fixed by putting 
'#include <GL/glext.h>' in the right places.  Having them make that 
change in their source code would also get the "fix" to their customers 
faster, and it would prevent the issue from coming back up from people
(Continue reading)

Permalink | Reply | 13 comments |
headers
Brian Paul | 1 Jul 2003 18:44

Re: User reported bug in GL header files in 4.3.0

Ian Romanick wrote:
> Brian Paul wrote:
> 
>> Mike A. Harris wrote:
>>
>>> Could someone look at this and comment on the issue, and state why it 
>>> is or isn't a bug?
>>
>>
>> I guess I still don't see what the real issue is.  There's no harm in 
>> defining the GL_ARB_multitexture tokens, prototypes and function 
>> pointers in gl.h where they were (instead of in glext.h).
>>
>> I also don't understand how this compile time issue with wine effects 
>> a game at runtime.
> 
> 
> I don't think the problem was that the prototypes, et. al. were being 
> defined in gl.h.  I think the problem was that they had a #ifdef around 
> them that was causing them to not be defined.

The code in question is:

#ifndef GL_ARB_multitexture
#define GL_ARB_multitexture 1

#define GL_TEXTURE0_ARB				0x84C0
#define GL_TEXTURE1_ARB				0x84C1
[...]
(Continue reading)

Permalink | Reply | 9 comments |
headers
Lionel Ulmer | 1 Jul 2003 19:50
Picon
Favicon

Re: Possible 'feature' in the Mesa header files ?

On Mon, Jun 30, 2003 at 03:37:19PM -0600, Brian Paul wrote:
> Right.  Unfortunately, NVIDIA has been shipping gl.h and glx.h headers 
> which don't follow the Linux ABI.  I've alerted them to the issues so 
> hopefully they'll get fixed.

Let's hope so too...

> What are "prototypes that are mandatory"?

From the OpenGL ABI site : 

"
 4.4. glx.h must include the prototype of the glXGetProcAddressARB extension
      described above.

4.5. All OpenGL 1.2 and ARB_multitexture, GLU 1.3, and GLX 1.3 entry points
     and enumerants must be present in the corresponding header files gl.h,
     glu.h, and glx.h, even if only OpenGL 1.1 is implemented at runtime by
     the associated runtime libraries.
"

So there is no mention at all in this section about having to define
'GL_GLEXT_PROTOTYPES' to have these specific prototypes defined.

My understanding of the ABI (I may be wrong though) is that these specific
extensions (glXGetProcAddressARB + ARB_multitexture) are to be handled in
the header files exactly as any other 'standard' OpenGL 1.2 entry point.

> > PS: now another question, how does GL developpers out there handle the
> >     absolute mess that are GL headers ?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Lionel Ulmer | 1 Jul 2003 19:53
Picon
Favicon

Re: User reported bug in GL header files in 4.3.0

> For my money, this feels like a Wine bug that could be fixed by putting 
> '#include <GL/glext.h>' in the right places.  Having them make that 
> change in their source code would also get the "fix" to their customers 
> faster, and it would prevent the issue from coming back up from people 
> who either don't run RedHat or run RedHat but don't have the right patch 
> installed.

Well, if you want to blame someone, blame me (I did most of the code in Wine
to support OpenGL).

See the other thread I just started (about the header issue) to understand
my reasonning in not including <GL/glext.h> for this specific case.

This means that the users were building without prototypes and as some
functions that HalfLife used must have used 'double' arguments => garbled
textures.

Now I think I will use the easiest solution to fix all this : as the
incriminated file is auto-generated anyway, do not include any GL headers at
all, but auto-generate the prototypes too of the standard GL functions.

          Lionel

--

-- 
		 Lionel Ulmer - http://www.bbrox.org/

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefanus Du Toit | 1 Jul 2003 20:37
Picon
Picon
Favicon

ARB_{vertex,fragment}_program

Hello,

Is anyone currently working on ARB_{vertex,fragment}_program support in
Mesa? I'm somewhat tempted to work on it (I'm currently working on a
high-level shading language, soon to be released, and having a software
renderer capable of supporting these would be neat - we do have a
simulator which is somewhat like the ARB and NV specs, but it's not
OpenGL and there are some significant differences).

Of course, I realize that this is probably quite a non-trivial task, in
particular the fragment shader, although I would imagine the vertex
shader might not be too bad given the existing NV_vertex_program
support.

Thanks,

Stefanus

--

-- 
Stefanus Du Toit; http://3.141592.org/; gpg 4bf2e217; #include <iostream>
template<int i,int j=i-1>struct I{I(){if(i%j)I<i,j-1>();else I<i-1>();}};
template<int i>struct I<i,1>{I(){std::cout<<i<<'\n';I<i-1>();}};template<
>struct I<1,0>{I(){}};int main(){I<50>();}/* Use -ftemplate-depth-5000 */

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
(Continue reading)

Permalink | Reply | 503 comments |
headers
Philip Brown | 1 Jul 2003 21:28
Favicon

Re: User reported bug in GL header files in 4.3.0

On Tue, Jul 01, 2003 at 10:44:05AM -0600, Brian Paul wrote:
> 
> GL/glext.h should be included by GL/gl.h as specified in the Linux ABI 
> specification.

What business does Linux have to specify OpenGL header file include order,
or usage? Isnt that up to the OpenGL board?

Whereabouts in the OpenGL spec does it mention the existance of
glext.h?

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Permalink | Reply | 8 comments |
headers
Brian Paul | 1 Jul 2003 21:56

Re: User reported bug in GL header files in 4.3.0

Lionel Ulmer wrote:
>>For my money, this feels like a Wine bug that could be fixed by putting 
>>'#include <GL/glext.h>' in the right places.  Having them make that 
>>change in their source code would also get the "fix" to their customers 
>>faster, and it would prevent the issue from coming back up from people 
>>who either don't run RedHat or run RedHat but don't have the right patch 
>>installed.
> 
> 
> Well, if you want to blame someone, blame me (I did most of the code in Wine
> to support OpenGL).
> 
> See the other thread I just started (about the header issue) to understand
> my reasonning in not including <GL/glext.h> for this specific case.
> 
> This means that the users were building without prototypes and as some
> functions that HalfLife used must have used 'double' arguments => garbled
> textures.

Calling C functions that haven't been prototyped or previously defined 
is dangerous in general.  You can catch that easily enough if you 
enable the appropriate compiler warning options.  (It's amazing how 
seldom people use -ansi, -Wall, -pedantic, etc. in the case of gcc).

To be flexible, apps should use glXGetProcAddressARB with function 
pointers and not rely on extension function prototypes at all.

Ex:

PFNGLACTIVETEXTUREARBPROC glActiveTextureARBptr;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Paul | 1 Jul 2003 21:38

Re: ARB_{vertex,fragment}_program

Stefanus Du Toit wrote:
> Hello,
> 
> Is anyone currently working on ARB_{vertex,fragment}_program support in
> Mesa? I'm somewhat tempted to work on it (I'm currently working on a
> high-level shading language, soon to be released, and having a software
> renderer capable of supporting these would be neat - we do have a
> simulator which is somewhat like the ARB and NV specs, but it's not
> OpenGL and there are some significant differences).
> 
> Of course, I realize that this is probably quite a non-trivial task, in
> particular the fragment shader, although I would imagine the vertex
> shader might not be too bad given the existing NV_vertex_program
> support.

The Mesa CVS trunk has both GL_NV_vertex_program and 
GL_NV_fragment_program.

Karl Rasche has been working on and off on GL_ARB_vertex_program. 
Anything to report, Karl?

The biggest task is implementing the parsers.  Also, there's some 
effort to supporting GL state fetches from within programs. 
Otherwise, the existing NV vertex/fragment execution engines should be 
largely reused for the ARB extensions.

-Brian

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
(Continue reading)

Permalink | Reply | 503 comments |

Gmane