Re: cvs compile trouble

chronoh <at> ya.com wrote:
> Hi!,
> 
> I have a Debian SID runing on hp-compaq nx9010 laptop with ATI
> Radeon
> Mobility IGP345M
> After a lots of tries to compile dri+drm+mesa I got the errors
> attached
> in this mail.

 > In file included from r200_context.h:41,
 >                  from r200_sanity.c:41:
 > /usr/src/graphic_card/mesa-cvs/src/mesa/tnl/t_vertex.h:127: error:
 > error sintáctico before "_tnl_codegen_emit"
 > /usr/src/graphic_card/mesa-cvs/src/mesa/tnl/t_vertex.h:127: warning:
 > type defaults to `int' in declaration of `_tnl_codegen_emit'

I believe the correct fix for that is to include t_context.h in t_vertex.h?

Roland

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
--

Re: Missing symbol _tnl_init_c_codegen

Thomas Hellström wrote:
> Hi!
> 
> I'm trying to compile the unichrome_dri.so driver in the xc tree with 
> latest Mesa cvs. When the driver is loaded I get a missing symbol 
> _tnl_init_c_codegen.
> 
> Something new I've left out?

I've get that for r200 too. Seems to be related to the t_vertex.c 
codegen addition. Maybe t_vertex_c.o doesn't get linked in?

Roland

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
--

Re: Missing symbol _tnl_init_c_codegen

Roland Scheidegger wrote:
> Thomas Hellström wrote:
> 
>> Hi!
>>
>> I'm trying to compile the unichrome_dri.so driver in the xc tree with 
>> latest Mesa cvs. When the driver is loaded I get a missing symbol 
>> _tnl_init_c_codegen.
>>
>> Something new I've left out?
> 
> 
> I've get that for r200 too. Seems to be related to the t_vertex.c 
> codegen addition. Maybe t_vertex_c.o doesn't get linked in?

Yes, it's my fault.  I can't wait until we can stop trying to track Mesa 
directly from DRI cvs.

I'll commit the fixes once I've rebuilt a DRI tree.

Keith

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

[Bug 814] New: Lock up

Please do not reply to this email: if you want to comment on the bug, go to     
the URL shown below and enter your comments there.  

http://freedesktop.org/bugzilla/show_bug.cgi?id=814   

           Summary: Lock up
           Product: Mesa
           Version: CVS
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Drivers/DRI/r200
        AssignedTo: dri-devel <at> lists.sourceforge.net
        ReportedBy: greisky <at> rogers.com

UT2003 hard locks my computer after a few minutes of play. I can play one level
and than it will freeze and I have to power off my system. UT2003 will run under
dri with the latest patch without S3TC. Even the demo was updated. You can get
the demo from here http://www.unrealtournament.com/ut2003/downloads.php   

--    
Configure bugmail: http://freedesktop.org/bugzilla/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 sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 

Re: Moving forward with the TLS work

Am Freitag, 25. Juni 2004 11:06 schrieb Dieter Nützel:
> Am Freitag, 25. Juni 2004 00:10 schrieb Ian Romanick:
> > Dieter Nützel wrote:
> > > Am Mittwoch, 23. Juni 2004 02:22 schrieb Ian Romanick:
> > >>This patch also still requires you to manually generate glapi_x86.S by
> > >>doing:
> > >>
> > >>cd src/mesa/glapi
> > >>python2 ./gl_x86_asm.py > ../x86/glapi_x86.S
> > >
> > > With and without I get this in _normal_ DRI CVS:
> >
> > You probably need to rebuild everything.
>
> That's my _daily_ work...

OK, this _one_ is SOLVED.

But TLS is VERY expensive.

quake3-smp do NOT work anylonger.
fps are down to 134 (from 173).

/opt/Mesa> quake3-smp &
[1] 9040
/opt/Mesa>
[1]    Fertig                        quake3-smp

Nothing remarkable in my log.
/opt/games/quake3/log is attached.

Progress on TDFX driver...

Re: Missing symbol _tnl_init_c_codegen

> >
> >
> > I've get that for r200 too. Seems to be related to the t_vertex.c codegen
> > addition. Maybe t_vertex_c.o doesn't get linked in?
>
> Yes, it's my fault.  I can't wait until we can stop trying to track Mesa
> directly from DRI cvs.
>
> I'll commit the fixes once I've rebuilt a DRI tree.

not sure if it is this but tdfx doesn't compile anymore, emit_func
conflicts... not sure what to do with it ...

Dave.
>
> Keith
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self
> defense, top technical experts, no vendor pitches, unmatched networking
> opportunities. Visit www.blackhat.com
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

--

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
--

Re: Free Test Suite for OpenGL?

Allen Akin wrote:

>On Wed, Jun 30, 2004 at 11:40:27AM +0900, Sasayama wrote:
>| How complete is it in regard to the OpenGL specification?
>
>I've managed the development of a couple of OpenGL test suites
>(including the official conformance test suite for the first several
>years of its existence).  A suite that aspires to full spec coverage
>needs about 20 engineer-years of effort to get started.  An
>industrial-strength suite needs considerably more than that.  Only a few
>graphics vendors have been willing to invest that much effort, and they
>aren't interested in open-sourcing the code because it would benefit
>their competitors.
>
>Even the official conformance tests don't cover enough of the
>specification to validate a commercial implementation.  That's one of
>the reasons vendors have developed test suites of their own.
>  
>
Thank you for the description.

>Glean consists of tests that have been contributed mostly by DRI and
>Mesa developers, so it reflects their particular needs and interests.  I
>think that's the right approach for an Open Source test suite.  Based on
>past experience, I don't think it's possible to generate enough interest
>from the graphics community to build a suite with full spec coverage,
>but it is possible to cover a useful subset.
>  
>
Two more questions.  First, is it clear on what is covered by each test 
of glean?  If so, it is very useful for out needs.

Second, is it easy to examine the output correctness of each test in 
glean?  It is very nice if it could make a summary report automatically.

Re: Re: Missing symbol _tnl_init_c_codegen

Dave Airlie wrote:
>>>
>>>I've get that for r200 too. Seems to be related to the t_vertex.c codegen
>>>addition. Maybe t_vertex_c.o doesn't get linked in?
>>
>>Yes, it's my fault.  I can't wait until we can stop trying to track Mesa
>>directly from DRI cvs.
>>
>>I'll commit the fixes once I've rebuilt a DRI tree.
> 
> 
> not sure if it is this but tdfx doesn't compile anymore, emit_func
> conflicts... not sure what to do with it ...

OK, fixed.  I'll migrate all the *_func declarations in t_context.h to 
tnl_*_func to try & avoid repeats.

Keith

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Progress on TDFX driver...

Am Donnerstag, 1. Juli 2004 13:42 schrieb Vykupitel:
>  Hello,
>  i'm interested if there is any progress on DRI TDFX driver. I think that
> we still doesn't have SLI support on Linux. I know that SLI support was
> planned and former 3dfx engineer have some idea how to implement it, but he
> didn't release any code to public. I'm not developer in any way. I'm only
> 3dfx user which suffer from lack of SLI support in Linux of my Voodoo5
> 5500PCI.

First, please STOP HTML mails. - Without there is a big chance to go directly 
into /dev/null...

If you're interested I have a 'late' copy of the tdfx SLI tree.

Cheers,
	Dieter

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
--