headers
John Lightsey | 1 Nov 2004 23:16
Favicon

Re: Re: Latest Mesa CVS (DRI) do not compile (since glx indirect?)

On Saturday 30 October 2004 15:19, Dieter Nützel wrote:
> Am Freitag, 29. Oktober 2004 21:36 schrieb Roland Scheidegger:
> > Dieter Nützel wrote:
> > > Addition:
> > >
> > > XFree86 DRI CVS build works, but libGLcore.a have unresolved symbols.
> > >
> > > Symbol _mesa_Uniform2iARB from
> > > module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved!
> >
> > I suspect you need to include shaderobjects.c/shaderobjects.o in the
> > Imakefile.inc of lib/GL/mesa/shader, but I'm really not sure. I'm not
> > familiar at all with that build system...
> > I think though it is expected that you can't build latest cvs Mesa in
> > the xorg/xfree86 directories.
>
> Good point!
>
> Brian pointed in the same direction.
>
> Here comes the patch for XFree86 DRI:
>

DRI build and starts with your patch, but there's another problem with r200 
cards.

john <at> lightning:~$ LIBGL_DEBUG=verbose glxinfo
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules-dri-trunk/dri/r200_dri.so
(Continue reading)

Permalink | Reply | 4 comments |
headers
SourceForge.net | 1 Nov 2004 23:17
Picon
Favicon

[ mesa3d-Bugs-1042464 ] doom3-demo error

Bugs item #1042464, was opened at 2004-10-07 13:13
Message generated for change (Settings changed) made by brianp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=1042464&group_id=3

Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: doom3-demo error

Initial Comment:
I got the following error when i tryed doom3-demo

DOOM 1.1.1282 linux-x86 Oct  4 2004 08:27:55

when usegin Mesa-6.2 downloaded from soruceforge.

using ARB_vertex_buffer_object memory
using ARB2 renderSystem
Mesa 6.2 implementation error: unexpected format in
_mesa_choose_tex_format()
Please report to the Mesa bug database at www.mesa3d.org
doom.x86: main/texstore.c:2276:
_mesa_store_compressed_teximage2d: Assertion
`texImage->TexFormat' failed.
signal caught: Aborted
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Nov 2004 23:17
Picon
Favicon

[ mesa3d-Bugs-1042444 ] doom3-demo error

Bugs item #1042444, was opened at 2004-10-07 12:43
Message generated for change (Settings changed) made by brianp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=1042444&group_id=3

Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: doom3-demo error

Initial Comment:
I got the following error when i tryed doom3-demo

DOOM 1.1.1282 linux-x86 Oct  4 2004 08:27:55

when usegin Mesa-6.2 downloaded from soruceforge.

using ARB_vertex_buffer_object memory
using ARB2 renderSystem
Mesa 6.2 implementation error: unexpected format in
_mesa_choose_tex_format()
Please report to the Mesa bug database at www.mesa3d.org
doom.x86: main/texstore.c:2276:
_mesa_store_compressed_teximage2d: Assertion
`texImage->TexFormat' failed.
signal caught: Aborted
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Nov 2004 23:18
Picon
Favicon

[ mesa3d-Bugs-1028405 ] Mesa implementation error

Bugs item #1028405, was opened at 2004-09-15 00:48
Message generated for change (Settings changed) made by brianp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=1028405&group_id=3

Category: mesa-core
Group: Fatal Error
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mesa implementation error

Initial Comment:
When running wine i get following error:

Mesa implementation error: unexpected texture format in
r200ChooseTextureFormat
Please report to the Mesa bug database at www.mesa3d.org
wine: texstore.c:2260:
_mesa_store_compressed_teximage2d: Assertion
`texImage->TexFormat' failed.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-10-05 19:18

Message:
(Continue reading)

Permalink | Reply | 6 comments |
headers
SourceForge.net | 1 Nov 2004 23:20
Picon
Favicon

[ mesa3d-Bugs-889305 ] SIGFPE in _mesa_test_os_sse_exception_support

Bugs item #889305, was opened at 2004-02-02 14:39
Message generated for change (Settings changed) made by brianp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=889305&group_id=3

Category: mesa-core
Group: Fatal Error
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Britton Leo Kerin (bkerin)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIGFPE in _mesa_test_os_sse_exception_support

Initial Comment:
I get a SIGFPE with a couple of different programs I
have under 5.0.2, 5.1, and 6.0 when building with the
new make linux-x86 command.  When I rebuild with the
old configure system in 5.0.2 the problem goes away.  I
haven't yet tried building with just 'make linux' but I
can do so if you think it would help.

Here is a backtrace:

(gdb) run
Starting program:
/home/bkerin/courses/present/advanced_graphics_second_attempt/hw_2/hw2

[New Thread 16384 (LWP 17447)]
(Continue reading)

Permalink | Reply | 1 comment |
headers
SourceForge.net | 1 Nov 2004 23:21
Picon
Favicon

[ mesa3d-Bugs-529034 ] no install target for Makefile.X11

Bugs item #529034, was opened at 2002-03-12 10:33
Message generated for change (Settings changed) made by brianp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100003&aid=529034&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: no install target for Makefile.X11

Initial Comment:
As configure;make;make install doesn't appear to work
for Mesa 4.01 under Solaris 8 I tried cp Makefile.X11
Makefile;make sunos5-gcc.  This seemed OK but there is
no install target in that Makefile (well there is
something for linux/GGI).  How should I install Mesa
having compiled it?

Cheers,
Raphael

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

>Comment By: Brian Paul (brianp)
Date: 2004-11-01 15:21
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland Scheidegger | 2 Nov 2004 00:41
Picon

Re: R200 / ext_fog_coord

Ian Romanick wrote:
>> Ok, here's another bit. This fixes the normal tcl path
>> (tcl_mode=1), but it is ugly. It just uses a different emit_vector
>> function for the fog coords. The fog factor calculations are
>> shamelessly ripped from t_vb_fog.c (woud be nice if that could get
>> called directly I think).
> 
> 
> That patch isn't as ugly as I was expecting.  You made it sound
> really bad on IRC.  The only issue I have is the variables defined
> in-line with code.  Won't that cause warnings / errors on some
> compilers?
I didn't get any warnings, though you're right it's not nice (and easy
to fix ;-).
When I said ugly, I didn't primarily mean the code as such, just the 
fact that the same code already exists as a pipeline stage in core mesa, 
so I'd consider it nothing but code bloat. But if there's no other way 
to use that code, so be it!

> As it turns out, there is no vtxfmt codegen for fogcoord.  There are
> a couple things that would be required to do so.
> 
> 1. All of the SecondaryColor routines need to be modified to not
> write 0xff to the secondary alpha value (aka fog).
> 
> 2. The vtxfmt fog routines would have to write the calculated fog
> factor to the secondary alpha and write the "raw" fog coord to 
> ctx->CurrentAttrib[VERT_ATTRIB_FOG][0].
> 
> 3. r200_copy_to_current, VFMT_FALLBACK, and check_vtx_fmt would need
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric Anholt | 2 Nov 2004 00:54

Re: R200 / ext_fog_coord

On Fri, 2004-10-29 at 18:26, Ian Romanick wrote:
> Roland Scheidegger wrote:
> >>> For the immediate mode calls, we'd need to calculate the fog factor 
> >>> and store that to the vertex array, and store the fog coord to the 
> >>> Mesa state.  That part is pretty easy.  The part that I'm a little 
> >>> unsure about is handling FOG_COORD_ARRAY.
> >>
> >>
> >> hmm, ok. Sounds troublesome enough.
> > 
> > Ok, here's another bit.
> > This fixes the normal tcl path (tcl_mode=1), but it is ugly. It just 
> > uses a different emit_vector function for the fog coords. The fog factor 
> > calculations are shamelessly ripped from t_vb_fog.c (woud be nice if 
> > that could get called directly I think).
> 
> That patch isn't as ugly as I was expecting.  You made it sound really 
> bad on IRC.  The only issue I have is the variables defined in-line with 
> code.  Won't that cause warnings / errors on some compilers?

It's legal C99 afaik, so it won't be complained about.  However, the
current code still works on gcc 2.95, which doesn't support that, so it
would be nice to not break it.

--

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

-------------------------------------------------------
This SF.Net email is sponsored by:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland Scheidegger | 2 Nov 2004 18:28
Picon

Re: R200 / ext_fog_coord

Roland Scheidegger wrote:
>> As it turns out, there is no vtxfmt codegen for fogcoord.  There are
>> a couple things that would be required to do so.
>>
>> 1. All of the SecondaryColor routines need to be modified to not
>> write 0xff to the secondary alpha value (aka fog).
>>
>> 2. The vtxfmt fog routines would have to write the calculated fog
>> factor to the secondary alpha and write the "raw" fog coord to 
>> ctx->CurrentAttrib[VERT_ATTRIB_FOG][0].
>>
>> 3. r200_copy_to_current, VFMT_FALLBACK, and check_vtx_fmt would need
>> to be updated to copy in / copy out the fog data.
>>
>> 4. r200VtxfmtInit and r200VtxfmtDestroy (and associated data
>> structures) need to be updated.
> 
> I'm looking into it...

ok, here's the next version, hopefully reaching final version soon. If 
that's done, radeon should be very easy to support it - interestingly 
though radeon actually uses FOG_USE_DEPTH instead of the r200 which uses 
FOG_USE_SPEC_ALPHA for fragment depth based fog, so the setup is 
presumably a bit different.

I've reverted the swtcl path to emit fog as the specular alpha value 
(there just seems to be not much point in changing this). tcl and vtxfmt 
path will still emit it as discrete fog value.
Also, should have got rid of potential compiler warnings, and tried to 
fix vtxfmt path. I hope I catched all initialization funcs...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Keith Whitwell | 2 Nov 2004 19:19
Picon
Favicon

Re: R200 / ext_fog_coord

Roland Scheidegger wrote:
> Roland Scheidegger wrote:
> 
>>> As it turns out, there is no vtxfmt codegen for fogcoord.  There are
>>> a couple things that would be required to do so.
>>>
>>> 1. All of the SecondaryColor routines need to be modified to not
>>> write 0xff to the secondary alpha value (aka fog).
>>>
>>> 2. The vtxfmt fog routines would have to write the calculated fog
>>> factor to the secondary alpha and write the "raw" fog coord to 
>>> ctx->CurrentAttrib[VERT_ATTRIB_FOG][0].
>>>
>>> 3. r200_copy_to_current, VFMT_FALLBACK, and check_vtx_fmt would need
>>> to be updated to copy in / copy out the fog data.
>>>
>>> 4. r200VtxfmtInit and r200VtxfmtDestroy (and associated data
>>> structures) need to be updated.
>>
>>
>> I'm looking into it...
> 
> 
> ok, here's the next version, hopefully reaching final version soon. If 
> that's done, radeon should be very easy to support it - interestingly 
> though radeon actually uses FOG_USE_DEPTH instead of the r200 which uses 
> FOG_USE_SPEC_ALPHA for fragment depth based fog, so the setup is 
> presumably a bit different.
> 
> I've reverted the swtcl path to emit fog as the specular alpha value
(Continue reading)

Permalink | Reply | 0 comments |

Gmane