headers
bugzilla-daemon | 1 Mar 2006 21:17

[Bug 6070] arb_vertex_program seems dependant on nv_vertex_program at least for glGet

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=6070          

------- Additional Comments From rscheidegger <at> gmx.ch  2006-03-02 07:17 -------
Created an attachment (id=4790)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=4790&action=view)
proposed fix

Ok, here's a patch. It's not 100% correct, as some enums are valid with not
only 2, but in principle 4 extensions (like GL_PROGRAM_ERROR_POSITION_ARB),
i.e. all of ARB/NV_fragment/vertex_program. That patch thus isn't correct when
the fragment_program extensions are supported but the vertex extensions aren't.

I changed the CHECK_EXT macros to return GL_INVALID_ENUM, same as when the enum
isn't known at all (I'm not sure, is it actually necessary to return an error
at all if the driver DOES know the enum, but doesn't announce the corresponding
extension? In particular quake4 still hits the
max_texture_image/max_texture_coord_units queries, which mesa relies on
internally anyway, though I'd guess that's just an app bug), it seems illogical
to return GL_INVALID_VALUE.
Changed some compile-time #ifs depending on NV_vertex_program too (not that I
tried compiling it that way...) which looked wrong.
Could the constant names be changed to the ARB ones instead of the NV ones? In
some cases the names are quite different (like MAX_TRACK_MATRICES_NV vs.
MAX_PROGRAM_MATRICES_ARB) which is confusing, and I'd think the standard names
should be used vs. the names from the pretty much deprecated nv extension.
Some code is a bit confusing too since the enums are shared, there is code like
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Mar 2006 21:28

[Bug 6070] arb_vertex_program seems dependant on nv_vertex_program at least for glGet

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=6070          

------- Additional Comments From brian.paul <at> tungstengraphics.com  2006-03-02 07:28 -------
The patch looks good.  Go ahead and check it in.

GL_INVALID_ENUM is the right error code, thanks for catching that.

If we need to check for 4 extensions for some enums, add a CHECK_EXT4() macro.

The NV extensions were implemented before the ARB ones.  That's why the NV
tokens are more prevalent.  Feel free to change that.  It would be good though
to put a comment where there's aliasing:

  case GL_VERTEX_PROGRAM_ARB:  /* == GL_VERTEX_PROGRAM_NV */          

     
--           
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.

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 2 Mar 2006 00:12

[Bug 6070] arb_vertex_program seems dependant on nv_vertex_program at least for glGet

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=6070          

rscheidegger <at> gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

------- Additional Comments From rscheidegger <at> gmx.ch  2006-03-02 10:12 -------
(In reply to comment #3)
> If we need to check for 4 extensions for some enums, add a CHECK_EXT4() macro.
Ok, done & commited (even CHECK_EXT3 was needed...)

> The NV extensions were implemented before the ARB ones.  That's why the NV
> tokens are more prevalent.  Feel free to change that.  It would be good though
> to put a comment where there's aliasing:
> 
>   case GL_VERTEX_PROGRAM_ARB:  /* == GL_VERTEX_PROGRAM_NV */
Ok, later.

     

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

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 2 Mar 2006 14:30

[Bug 6098] New: Wrong normals with GL_AUTO_NORMAL

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=6098          

           Summary: Wrong normals with GL_AUTO_NORMAL
           Product: Mesa
           Version: 6.4
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Mesa core
        AssignedTo: mesa3d-dev <at> lists.sourceforge.net
        ReportedBy: tdz <at> users.sourceforge.net

Hi,

i use 2d evaluators to draw a grid. The grid points are arranged, so that the
parameter u walks along +x and v walks along -z. Calling glEvalMesh() renders a
grid with front faces pointing upwards. (I tested this by explicitly culling
back faces.)
The grid patches normals where generated with GL_AUTO_NORMAL. I guess normals
should also point upwards, but the lighting in the scene behaves, as if normals
where pointing downwards.
Calling glFrontFace(GL_CW) reverses normals as expected, but they still point
into the wrong direction.
(Continue reading)

Permalink | Reply | 0 comments |
headers
pfgshield-freebsd | 2 Mar 2006 18:43
Picon
Favicon

Problems building with the freebsd target (with patch)

Hi;

I tried building Mesa 6.4.2 on FreeBSD 6.0R-amd64 with the simple freebsd
target but it failed miserably:
____
...
mklib: Making FreeBSD shared library:  libGL.so.1
/usr/bin/ld: cannot find -lX11
mklib: Installing libGL.so.1 libGL.so in ../../lib
mv: rename libGL.so.1 to ../../lib/libGL.so.1: No such file or directory
gmake[1]: *** [../../lib/libGL.so] Error 1
______

So, I "learned" some things from the linux config and I got this conservative
patch (no PTHREADS, no TLS), which I think cleans up the build:

cheers,

    Pedro.

--- configs/freebsd.orig	Mon Aug 29 17:44:20 2005
+++ configs/freebsd	Thu Mar  2 12:09:13 2006
 <at>  <at>  -5,12 +5,24  <at>  <at> 
 CONFIG_NAME = FreeBSD

 # Compiler and flags
-CC = gcc
-CXX = g++
+CC = cc
+CXX = c++
(Continue reading)

Permalink | Reply | 2 comments |
headers
SourceForge.net | 2 Mar 2006 18:55
Picon
Favicon

[ mesa3d-Patches-1441921 ] FreeBSD configuration cleanup

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pedro F. Giffuni (giffunip)
Assigned to: Nobody/Anonymous (nobody)
Summary: FreeBSD configuration cleanup

Initial Comment:
Hi;

The freebsd target was not working so I made this
attempt to clean it up. I personally think the dri
target shouldn't override so many things and this
should be built with pthreads but not everyone might
agree so I was  very conservative,

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300003&aid=1441921&group_id=3
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 2 Mar 2006 19:37

[Bug 3050] BadLength error when running Xglx on top of software Mesa

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=3050          

erik.andren <at> gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

------- Additional Comments From erik.andren <at> gmail.com  2006-03-03 05:37 -------
Is this bug still valid?          

     
--           
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.

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Mar 2006 10:36

[Bug 3050] BadLength error when running glitz apps on top of software Mesa

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=3050          

patrakov <at> ums.usu.ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|BadLength error when running|BadLength error when running
                   |Xglx on top of software Mesa|glitz apps on top of
                   |                            |software Mesa

------- Additional Comments From patrakov <at> ums.usu.ru  2006-03-03 20:36 -------
Yes, although I am too lazy to build Xglx now. What bugs me is that the only way
to trigger it is to use glitz.

$ LIBGL_ALWAYS_INDIRECT=1 rendertest_glitz_glx -s 0
X Error of failed request:  BadLength (poly request too large or internal Xlib
length error)
  Major opcode of failed request:  157 (GLX)
  Minor opcode of failed request:  1 (X_GLXRender)
  Serial number of failed request:  76
  Current serial number in output stream:  77

That's with Mesa-6.4.1. Will retest with the latest CVS shortly.          

     
--
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Mar 2006 13:52

[Bug 3050] BadLength error when running glitz apps on top of software Mesa

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=3050          

------- Additional Comments From patrakov <at> ums.usu.ru  2006-03-03 23:52 -------
Latest CVS also has this bug          

     
--           
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.

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Mar 2006 13:57

[Bug 3050] BadLength error when running glitz apps on top of software Mesa

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=3050          

------- Additional Comments From patrakov <at> ums.usu.ru  2006-03-03 23:57 -------
Printing pname results in the following:

pname is 805F
pname is 805F
pname is 805F
pname is 805F
pname is 805C
pname is 805D
pname is 805E
pname is 805C
pname is 805C
pname is 805D
pname is 805E
pname is 805C
pname is 805D
pname is 805E
pname is 805C
pname is 805C
pname is 805C
pname is 805C
pname is 805C
pname is 805D
pname is 805E
(Continue reading)

Permalink | Reply | 0 comments |

Gmane