headers
SourceForge.net | 1 Jan 2004 09:57
Picon
Favicon

[ mesa3d-Bugs-868737 ] Fix suggestion for Solaris compile of MesaLib

Bugs item #868737, was opened at 2004-01-01 00:57
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=868737&group_id=3

Category: mesa-core
Group: Compile/Install
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix suggestion for Solaris compile of MesaLib

Initial Comment:
When linking a shared libGL on solaris this error occurs:
mklib: Making SunOS shared library:  libGL.so
mklib: linker is gcc -shared
Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x1d04      main/arbparse.o
<unknown>                           0x1d08      main/arbparse.o
<unknown>                           0x1d0c      main/arbparse.o
<snip />

This is because code is being compiled without PIC.
libtool would have been doing this for you previously.
I modified Make-config to fix.

Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Jan 2004 16:32
Picon
Favicon

[ mesa3d-Bugs-868737 ] Fix suggestion for Solaris compile of MesaLib

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

Category: mesa-core
Group: Compile/Install
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix suggestion for Solaris compile of MesaLib

Initial Comment:
When linking a shared libGL on solaris this error occurs:
mklib: Making SunOS shared library:  libGL.so
mklib: linker is gcc -shared
Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x1d04      main/arbparse.o
<unknown>                           0x1d08      main/arbparse.o
<unknown>                           0x1d0c      main/arbparse.o
<snip />

This is because code is being compiled without PIC.
libtool would have been doing this for you previously.
I modified Make-config to fix.

Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Felix Kühling | 2 Jan 2004 03:08
Picon
Picon

Re: [Dri-devel] Radeon vtxfmt code path is not working

I managed to get the vtxfmt path enabled and fixed a small problem that
didn't show up when vtxfmt wasn't enabled. Flightgear performance
increased only marginally since it draws most of its geometry using
vertex arrays which is a vtxfmt fallback. I was able improve the
situation by not installing radeon_fallback_DrawArrays but
_tnl_DrawArrays in the radeon vtxfmt api. This way, the tnl function is
used for submitting the vertex array, but the data is submitted through
the still installed radeon vtxfmt api. Now the frame rate in CPU bounded
situations (--visibility=100000 --geometry=640x480) has almost doubled.
:)

I attached a patch (mostly a hack).

Now there is still a bad interaction with the save API that I havn't
tracked down yet. You get a failed assertion with tuxracer or torcs for
example:

tuxracer: t_save_api.c:1182: _save_NotifyBegin: Assertion `i < tnl->save.prim_max' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 20472)]
0x40480a51 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x40480a51 in kill () from /lib/libc.so.6
#1  0x4027c24b in pthread_kill () from /lib/libpthread.so.0
#2  0x4027c521 in raise () from /lib/libpthread.so.0
#3  0x40481986 in abort () from /lib/libc.so.6
#4  0x4047aae9 in __assert_fail () from /lib/libc.so.6
#5  0x408e5b69 in _save_NotifyBegin (ctx=0x82c96c8, mode=6)
    at t_save_api.c:1193
(Continue reading)

Permalink | Reply | 0 comments |
headers
Felix Kühling | 2 Jan 2004 21:03
Picon
Picon

Re: HEADSUP: Mesa move to freedesktop.org

I just upgraded from the new CVS repo and got this warning:

cvs server: warning: cannot write to history file /cvs/mesa/CVSROOT/history: Permission denied

Also, for your convenience, I attached a script that I used to convert my
existing working copy to the new repository.

Regards,
  Felix

On Sun, 28 Dec 2003 15:05:25 -0800
Eric Anholt <eta <at> lclark.edu> wrote:

> I've moved Mesa CVS over to freedesktop.org, after more complaints about
> sf.net's CVS services today.  It looks like all the latest commits made
> it into the tarball.  I've tested anonymous checkouts, and hopefully all
> current Mesa developers with fd.o accounts are set up with write
> access.  Others should email me their name, preferred account name,
> email address, and ssh dsa public key.
> 
> To get mesa-newtree, now:
> cvs -d:pserver:anonymous <at> pdx.freedesktop.org:/cvs/mesa login
> (no password)
> cvs -d:pserver:anonymous <at> pdx.freedesktop.org:/cvs/mesa co Mesa
> 
> developers' ssh access is similar.  The old tree is in Mesa-oldtree. 
> CVSweb is at:
> http://www.freedesktop.org/cgi-bin/cvsweb/mesa/
> 
> A sample supfile to get the mesa repository with cvsup:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Anholt | 2 Jan 2004 23:26

Re: HEADSUP: Mesa move to freedesktop.org

On Fri, 2004-01-02 at 12:03, Felix Kühling wrote:
> I just upgraded from the new CVS repo and got this warning:
> 
> cvs server: warning: cannot write to history file /cvs/mesa/CVSROOT/history: Permission denied
> 
> Also, for your convenience, I attached a script that I used to convert my
> existing working copy to the new repository.

Yeah, sorry about that.  Should be fixed.

--

-- 
Eric Anholt                                eta <at> lclark.edu          
http://people.freebsd.org/~anholt/         anholt <at> FreeBSD.org

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Permalink | Reply | 0 comments |
headers
Felix Kühling | 3 Jan 2004 00:17
Picon
Picon

[patch] Radeon and R200 vtxfmt fixes

Hi,

I believe I got it right this time. :) I attached three small patches
that re-enabled the vtxfmt paths in the radeon and r200 drivers. One is
for _tnl_Begin to call the driver's NotifyBegin callback again.
Alternatively, if the drivers are supposed to work correctly without
this callback, then the NotifyBegin callback should be removed from the
respective struct and the drivers changed accordingly.

The other two patches install fallbacks for the VertexAttrib*NV
functions in the radeon and r200 drivers and _tnl_DrawArrays instead of
radeon/r200_fallback_DrawArrays. Also the drivers must not install their
own ctx->Driver.NewList callback. This would override _tnl_NewList
leading to the assertion failure in _save_NotifyBegin I reported
earlier. I tested both, calling _tnl_NewList in radeon_NewList and not
installing radeon_NewList at all. Both worked the same with the
applications I tested (see below) so a fallback does not appear to be
necessary with Keith's new display list compiler.

I tested these patches on a Radeon 7500 with flightgear, torcs, tuxracer
(and glxgears ;-) without noticing any problems. I can't test on R200
(yet). My CPU doesn't have a SSE unit, so the SSE codegen stuff may still
be broken, though I believe this is unlikely.

If these patches are ok I'd like to commit them. Keith, I think you
should know best. ;-)

Regards,
  Felix
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Whitwell | 3 Jan 2004 23:06

Re: Radeon vtxfmt code path is not working

Felix Kühling wrote:
> Hi,
> 
> I was wondering why flightgear was so slow so I did some profiling and
> debugging. And I found out that apperently the entire vtxfmt code path
> is not working. I believe the root cause is that radeonNotifyBegin is
> never called with current Mesa. So the driver's own vtxfmt functions are
> never installed into the exec API.
> 
> As evidence, when I run
> 
> RADEON_DEBUG=vfmt fgfs
> 
> I get no debugging output at all. Also profile output shows some
> functions that should never be used if vtxfmt was working (e.g.
> tnl_Vertex3fv).
> 
> I couldn't figure out how to fix this. Whatever I tried gave me
> segfaults :(. It's also hard to figure out where tnl->Driver.NotifyBegin
> should be called. I couldn't find any central _mesa_Begin function, only
> tnl_Begin which is a function of a different vtxfmt. Does anyone know
> how this is supposed to work?

Felix,

This is something that changed as a result of the recent rework in the tnl/ 
module in mesa.  The NotifyBegin thing was always a bit of a hack, and 
hopefully we can work out a better replacement.  It would be good to try and 
do this perhaps from the r200ValidateState() function.  Poke around, well done 
for spotting the bug, but it'll be a couple of days before I'm able to look at it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Whitwell | 3 Jan 2004 23:27

Re: [patch] Radeon and R200 vtxfmt fixes

Felix Kühling wrote:
> Hi,
> 
> I believe I got it right this time. :) I attached three small patches
> that re-enabled the vtxfmt paths in the radeon and r200 drivers. One is
> for _tnl_Begin to call the driver's NotifyBegin callback again.
> Alternatively, if the drivers are supposed to work correctly without
> this callback, then the NotifyBegin callback should be removed from the
> respective struct and the drivers changed accordingly.
> 
> The other two patches install fallbacks for the VertexAttrib*NV
> functions in the radeon and r200 drivers and _tnl_DrawArrays instead of
> radeon/r200_fallback_DrawArrays. Also the drivers must not install their
> own ctx->Driver.NewList callback. This would override _tnl_NewList
> leading to the assertion failure in _save_NotifyBegin I reported
> earlier. I tested both, calling _tnl_NewList in radeon_NewList and not
> installing radeon_NewList at all. Both worked the same with the
> applications I tested (see below) so a fallback does not appear to be
> necessary with Keith's new display list compiler.
> 
> I tested these patches on a Radeon 7500 with flightgear, torcs, tuxracer
> (and glxgears ;-) without noticing any problems. I can't test on R200
> (yet). My CPU doesn't have a SSE unit, so the SSE codegen stuff may still
> be broken, though I believe this is unlikely.

> If these patches are ok I'd like to commit them. Keith, I think you
> should know best. ;-)

I've got a couple of comments, but basically things look ok.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Felix Kühling | 4 Jan 2004 01:53
Picon
Picon

Re: Radeon vtxfmt code path is not working

On Sat, 03 Jan 2004 22:06:27 +0000
Keith Whitwell <keith <at> tungstengraphics.com> wrote:

> Felix Kühling wrote:
> > Hi,
> > 
> > I was wondering why flightgear was so slow so I did some profiling and
> > debugging. And I found out that apperently the entire vtxfmt code path
> > is not working. I believe the root cause is that radeonNotifyBegin is
> > never called with current Mesa. So the driver's own vtxfmt functions are
> > never installed into the exec API.
> > 
> > As evidence, when I run
> > 
> > RADEON_DEBUG=vfmt fgfs
> > 
> > I get no debugging output at all. Also profile output shows some
> > functions that should never be used if vtxfmt was working (e.g.
> > tnl_Vertex3fv).
> > 
> > I couldn't figure out how to fix this. Whatever I tried gave me
> > segfaults :(. It's also hard to figure out where tnl->Driver.NotifyBegin
> > should be called. I couldn't find any central _mesa_Begin function, only
> > tnl_Begin which is a function of a different vtxfmt. Does anyone know
> > how this is supposed to work?
> 
> Felix,
> 
> This is something that changed as a result of the recent rework in the tnl/ 
> module in mesa.  The NotifyBegin thing was always a bit of a hack, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Felix Kühling | 4 Jan 2004 17:45
Picon
Picon

Re: [patch] Radeon and R200 vtxfmt fixes

On Sat, 03 Jan 2004 22:27:53 +0000
Keith Whitwell <keith <at> tungstengraphics.com> wrote:

> Felix Kühling wrote:
[snip]
> > I tested these patches on a Radeon 7500 with flightgear, torcs, tuxracer
> > (and glxgears ;-) without noticing any problems. I can't test on R200
> > (yet). My CPU doesn't have a SSE unit, so the SSE codegen stuff may still
> > be broken, though I believe this is unlikely.
> 
> > If these patches are ok I'd like to commit them. Keith, I think you
> > should know best. ;-)
> 
> I've got a couple of comments, but basically things look ok.

Ok. I committed this with radeon/r200_fallback_DrawArrays instead of
_tnl_DrawArrays. It's a big improvement with little effort. I'll leave
getting rid of NotifyBegin to you. ;-)

> 
[snip]
> Keith

Felix

------------    __\|/__    ___     ___       -------------------------
 Felix       ___\_e -_/___/ __\___/ __\_____   You can do anything,
   Kühling  (_____\Ä/____/ /_____/ /________)  just not everything
 fxkuehl <at> gmx.de       \___/   \___/   U        at the same time.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane