Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)

[Adam K Kirchhoff]

On Thu, 21 Nov 2002, Ian Romanick wrote:

> On Thu, Nov 21, 2002 at 01:27:03PM -0500, Adam K Kirchhoff wrote:
>
> > Hmmm... Well, line 592 of scene.cpp (in glaxium 0.5, just downloaded from
> > the website) seems to be:
> >
> > glEnable(GL_TEXTURE_2D);
> >
> > Line 586, though, makes reference to GL_DOT3_RGB_EXT.  I've made the
> > change there.
> >
> > Now, with the unpatched driver and the patched game, the results look
> > exactly look they did with the patched driver and the unpatched game!
>
> I believe that we may have discovered one of the subtle differences between
> the R100 family of chips and the R200 family.  On the R100, when DOT3
> bumpmapping is selected the driver has to manually select the implicit 4X
> multiplier required by the ARB & EXT specs.  It seems that when the R200
> this is not needed.
>
> The unpatched driver programs the chip to do DOT3 and a 4X scale.  It seems
> that the result is a 4X + 4X scale, or a 16X scale.  The result is that all
> fragments end up saturated to white.  If this theory is correct, then this
> patch should fix it.
>
> I'm crossing my fingers...

Well, it looks better than your last patch, but still not right, and
worse than it does with the unpatched driver.

http://memory.visualtech.com/glaxium.png

Adam




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48)

[Ian Romanick]

On Thu, Nov 21, 2002 at 01:27:03PM -0500, Adam K Kirchhoff wrote:

> Hmmm... Well, line 592 of scene.cpp (in glaxium 0.5, just downloaded from
> the website) seems to be:
> 
>   glEnable(GL_TEXTURE_2D);
> 
> Line 586, though, makes reference to GL_DOT3_RGB_EXT.  I've made the 
> change there.
> 
> Now, with the unpatched driver and the patched game, the results look
> exactly look they did with the patched driver and the unpatched game!

I believe that we may have discovered one of the subtle differences between
the R100 family of chips and the R200 family.  On the R100, when DOT3
bumpmapping is selected the driver has to manually select the implicit 4X
multiplier required by the ARB & EXT specs.  It seems that when the R200
this is not needed.

The unpatched driver programs the chip to do DOT3 and a 4X scale.  It seems
that the result is a 4X + 4X scale, or a 16X scale.  The result is that all
fragments end up saturated to white.  If this theory is correct, then this
patch should fix it.

I'm crossing my fingers...

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html



r200_DOT3_EXT.patch.gz
Description: application/gunzip

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Ingo Molnar]

On Wed, 20 Nov 2002, Linus Torvalds wrote:

> On Thu, 21 Nov 2002, Dieter Nützel wrote:
> >
> >   Option   "AGPFastWrite" "1"
> 
> This just makes the machine lock up for me at X startup.

same here, instant and nasty lockup.

Ingo



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)

[Adam K Kirchhoff]

On Thu, 21 Nov 2002, Ian Romanick wrote:

> On Thu, Nov 21, 2002 at 11:57:32AM -0500, Adam K Kirchhoff wrote:
> > 
> > Unfortunately, that only seemed to make things worse.  If you check out 
> > the same URL I posted above, you'll see what I mean.
> 
> Hmm...could you try two quick tests for me?  Both would be with an unpatched
> driver.
> 
> 1. Try running with LIBGL_ALWAYS_INDIRECT=1.  I expect that will produce the
> same results I see on a Radeon M6.

http://memory.visualtech.com/glaxium.png

I do believe that's what the game is supposed to look like :-)

> 2. Replace GL_DOT3_RGB_EXT on line 592 of scene.cpp (in glaxium 0.5) with
> GL_DOT3_RGB and rebuild glaxium.  If that doesn't work, then dot3
> bumpmapping is totally hosed in the R200 driver.  I expect that this will
> also produce correct results.

Hmmm... Well, line 592 of scene.cpp (in glaxium 0.5, just downloaded from
the website) seems to be:

glEnable(GL_TEXTURE_2D);

Line 586, though, makes reference to GL_DOT3_RGB_EXT.  I've made the 
change there.

Now, with the unpatched driver and the patched game, the results look
exactly look they did with the patched driver and the unpatched game!

Adam




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48)

[Ian Romanick]

On Thu, Nov 21, 2002 at 11:57:32AM -0500, Adam K Kirchhoff wrote:
> 
> On Thu, 21 Nov 2002, Ian Romanick wrote:
> 
> > On Thu, Nov 21, 2002 at 08:28:01AM -0500, Adam K Kirchhoff wrote:
> > > 
> > > > On Wed, 20 Nov 2002, Ian Romanick wrote:
> > > > > The problem is that it uses EXT_texture_env_dot3 (which the driver does
> > > > > advertise), but the driver doesn't actually implement only implements
> > > > > EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly.  I noted this in an
> > > > > earlier thread about glaxium, but I haven't posted a fix yet.
> > > > > 
> > > > > I have attached a patch to the DRI CVS trunk that should fix the problem.  I
> > > > > don't have access to an 8500, so I haven't actually tested it.  I would
> > > > > really appreciate it if people with 8500 (or 9000) cards could try this
> > > > > patch and tell me if it works.  If I get a few positive results and no
> > > > > negatives, I'll commit the patch.
> > > 
> > > I've applied the patch to two machines, one running Linux and one running 
> > > FreeBSD.  I compiled on both machines and installed.  Unfortunately, I 
> > > won't be able to test the Linux box till I get home, but I'm going to 
> > > assume that the results are going to be the same :-)
> > > 
> > > http://memory.visualtech.com/glaxium.png
> > > 
> > > Unfortunately, it doesn't look like the patch worked :-(
> > 
> > My bad!  Change the && at the end of line 1082 in r200_texstate.c to ||.
> > The if-statement that compares against GL_DOT3_{RGB,RGBA}_EXT should match
> > the one that compares against GL_DOT3_{RGB,RGBA}.  Sorry.
> 
> Unfortunately, that only seemed to make things worse.  If you check out 
> the same URL I posted above, you'll see what I mean.

Hmm...could you try two quick tests for me?  Both would be with an unpatched
driver.

1. Try running with LIBGL_ALWAYS_INDIRECT=1.  I expect that will produce the
same results I see on a Radeon M6.

2. Replace GL_DOT3_RGB_EXT on line 592 of scene.cpp (in glaxium 0.5) with
GL_DOT3_RGB and rebuild glaxium.  If that doesn't work, then dot3
bumpmapping is totally hosed in the R200 driver.  I expect that this will
also produce correct results.

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)

[Adam K Kirchhoff]

On Thu, 21 Nov 2002, Ian Romanick wrote:

> On Thu, Nov 21, 2002 at 08:28:01AM -0500, Adam K Kirchhoff wrote:
> > 
> > > On Wed, 20 Nov 2002, Ian Romanick wrote:
> > > > The problem is that it uses EXT_texture_env_dot3 (which the driver does
> > > > advertise), but the driver doesn't actually implement only implements
> > > > EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly.  I noted this in an
> > > > earlier thread about glaxium, but I haven't posted a fix yet.
> > > > 
> > > > I have attached a patch to the DRI CVS trunk that should fix the problem.  I
> > > > don't have access to an 8500, so I haven't actually tested it.  I would
> > > > really appreciate it if people with 8500 (or 9000) cards could try this
> > > > patch and tell me if it works.  If I get a few positive results and no
> > > > negatives, I'll commit the patch.
> > 
> > I've applied the patch to two machines, one running Linux and one running 
> > FreeBSD.  I compiled on both machines and installed.  Unfortunately, I 
> > won't be able to test the Linux box till I get home, but I'm going to 
> > assume that the results are going to be the same :-)
> > 
> > http://memory.visualtech.com/glaxium.png
> > 
> > Unfortunately, it doesn't look like the patch worked :-(
> 
> My bad!  Change the && at the end of line 1082 in r200_texstate.c to ||.
> The if-statement that compares against GL_DOT3_{RGB,RGBA}_EXT should match
> the one that compares against GL_DOT3_{RGB,RGBA}.  Sorry.

Unfortunately, that only seemed to make things worse.  If you check out 
the same URL I posted above, you'll see what I mean.

Adam




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48)

[Ian Romanick]

On Thu, Nov 21, 2002 at 08:28:01AM -0500, Adam K Kirchhoff wrote:
> 
> > On Wed, 20 Nov 2002, Ian Romanick wrote:
> > 
> > > On Tue, Nov 19, 2002 at 11:06:16PM -0800, Linus Torvalds wrote:
> > > > 
> > > > On Wed, 20 Nov 2002, Dieter Nützel wrote:
> > > > > Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:
> > > > > > >
> > > > > > > Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do
> > > > > > > some testing.
> > > > > 
> > > > > No go so far.
> > > > > 
> > > > > Modules are somewhat broken in 2.5.48.
> > > > 
> > > > One approach is to not use modules, just compile the thing in. Works for
> > > > me (damn, I'd like to see how the commercial tuxracer looks with bump 
> > > > mapping. But apparently DRI doesn't support the right extension or 
> > > > something ;)
> > > 
> > > The problem is that it uses EXT_texture_env_dot3 (which the driver does
> > > advertise), but the driver doesn't actually implement only implements
> > > EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly.  I noted this in an
> > > earlier thread about glaxium, but I haven't posted a fix yet.
> > > 
> > > I have attached a patch to the DRI CVS trunk that should fix the problem.  I
> > > don't have access to an 8500, so I haven't actually tested it.  I would
> > > really appreciate it if people with 8500 (or 9000) cards could try this
> > > patch and tell me if it works.  If I get a few positive results and no
> > > negatives, I'll commit the patch.
> 
> I've applied the patch to two machines, one running Linux and one running 
> FreeBSD.  I compiled on both machines and installed.  Unfortunately, I 
> won't be able to test the Linux box till I get home, but I'm going to 
> assume that the results are going to be the same :-)
> 
> http://memory.visualtech.com/glaxium.png
> 
> Unfortunately, it doesn't look like the patch worked :-(

My bad!  Change the && at the end of line 1082 in r200_texstate.c to ||.
The if-statement that compares against GL_DOT3_{RGB,RGBA}_EXT should match
the one that compares against GL_DOT3_{RGB,RGBA}.  Sorry.

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)

[Xavier Hosxe]

> > 
> > http://memory.visualtech.com/glaxium.png
> > 
> > Unfortunately, it doesn't look like the patch worked :-(
> 
> I'm not sure what it's supposed to look like.  Can you try software
> rendering, just to get a screen-shot.?
> 
> -Brian
> 
> 

I'm happy to see that my game is usefull for serious people ;-)

You can get screenshots at glaxium web site :
http://xhosxe.free.fr/glaxium

Quick link:
http://xhosxe.free.fr/glaxium/shot05_6.jpg

On the floor the bumpmap is calculated with the light position set equal
to the main spaceship...See screen shot above.

GL_EXT_texture_env_combine is used to merge the 3D bumpmap effect with a
flat texture.

Xavier




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)

[Brian Paul]

Adam K Kirchhoff wrote:

On Wed, 20 Nov 2002, Ian Romanick wrote:



On Tue, Nov 19, 2002 at 11:06:16PM -0800, Linus Torvalds wrote:


On Wed, 20 Nov 2002, Dieter N?tzel wrote:


Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:


Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do
some testing.



No go so far.

Modules are somewhat broken in 2.5.48.


One approach is to not use modules, just compile the thing in. Works for
me (damn, I'd like to see how the commercial tuxracer looks with bump 
mapping. But apparently DRI doesn't support the right extension or 
something ;)

The problem is that it uses EXT_texture_env_dot3 (which the driver does
advertise), but the driver doesn't actually implement only implements
EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly.  I noted this in an
earlier thread about glaxium, but I haven't posted a fix yet.

I have attached a patch to the DRI CVS trunk that should fix the problem.  I
don't have access to an 8500, so I haven't actually tested it.  I would
really appreciate it if people with 8500 (or 9000) cards could try this
patch and tell me if it works.  If I get a few positive results and no
negatives, I'll commit the patch.




I've applied the patch to two machines, one running Linux and one running 
FreeBSD.  I compiled on both machines and installed.  Unfortunately, I 
won't be able to test the Linux box till I get home, but I'm going to 
assume that the results are going to be the same :-)

http://memory.visualtech.com/glaxium.png

Unfortunately, it doesn't look like the patch worked :-(

I'm not sure what it's supposed to look like.  Can you try software
rendering, just to get a screen-shot.?

-Brian





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)

[Adam K Kirchhoff]

> On Wed, 20 Nov 2002, Ian Romanick wrote:
> 
> > On Tue, Nov 19, 2002 at 11:06:16PM -0800, Linus Torvalds wrote:
> > > 
> > > On Wed, 20 Nov 2002, Dieter Nützel wrote:
> > > > Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:
> > > > > >
> > > > > > Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do
> > > > > > some testing.
> > > > 
> > > > No go so far.
> > > > 
> > > > Modules are somewhat broken in 2.5.48.
> > > 
> > > One approach is to not use modules, just compile the thing in. Works for
> > > me (damn, I'd like to see how the commercial tuxracer looks with bump 
> > > mapping. But apparently DRI doesn't support the right extension or 
> > > something ;)
> > 
> > The problem is that it uses EXT_texture_env_dot3 (which the driver does
> > advertise), but the driver doesn't actually implement only implements
> > EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly.  I noted this in an
> > earlier thread about glaxium, but I haven't posted a fix yet.
> > 
> > I have attached a patch to the DRI CVS trunk that should fix the problem.  I
> > don't have access to an 8500, so I haven't actually tested it.  I would
> > really appreciate it if people with 8500 (or 9000) cards could try this
> > patch and tell me if it works.  If I get a few positive results and no
> > negatives, I'll commit the patch.

I've applied the patch to two machines, one running Linux and one running 
FreeBSD.  I compiled on both machines and installed.  Unfortunately, I 
won't be able to test the Linux box till I get home, but I'm going to 
assume that the results are going to be the same :-)

http://memory.visualtech.com/glaxium.png

Unfortunately, it doesn't look like the patch worked :-(

Adam




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Keith Whitwell]

Its a known issue for me, thats why i do prefer the GLUT demos.

I made it to bring the Mesa demos to life on DRI by just editing
the libGL and other references to the systems defaults rather than
to the libs in the project. As far as i do remember, it all turned
out to be rather "static" in linking.

To my knowledge there is no simple way with this project build system
for getting what we both do think of.


Hmm.  Howabout 'make -f Makefile.X11 linux' from the demos directory?  May 
need to 'make -f Makefile.X11 realclean' first to clean up.

Keith





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Linus Torvalds]

On Thu, 21 Nov 2002, Dieter Nützel wrote:
>
>   Option   "AGPFastWrite" "1"

This just makes the machine lock up for me at X startup.

>   Option   "EnablePageflip"

But this brings glxgears up to 2420 fps. Whee.

Linus



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Dieter Nützel]

Am Donnerstag, 21. November 2002 04:03 schrieb Alexander Stohr:
> > > 
> > >
> > > > GL_RENDERER: Mesa X11
> > > > GL_VENDOR: Brian Paul
> > >
> > > 
> >
> > Yeah, that seems to be true for the mesa test programs I installed.
> >
> > Doing a regular glxinfo shows
> >
> > OpenGL renderer string: Mesa DRI R200 20021009 AGP 4x
> > x86/MMX/SSE TCL
> > OpenGL version string: 1.2 Mesa 5.0
> >
> > > You are running Software Mesa 5.0 :-O
> >
> > Naah, just the MesaDemos seem to use it for some reason,
> > probably because
> > I didn't know how to configure the build there correctly ..
> >
> > How do people build the Mesa demo package? It clearly doesn't build
> > standalone, and apparently if you build it together with the MesaLib
> > package it does the sw rendering thing).
> >
> > Linus
>
> Its a known issue for me, thats why i do prefer the GLUT demos.
>
> I made it to bring the Mesa demos to life on DRI by just editing
> the libGL and other references to the systems defaults rather than
> to the libs in the project. As far as i do remember, it all turned
> out to be rather "static" in linking.
>
> To my knowledge there is no simple way with this project build system
> for getting what we both do think of.

Works here for ages.

My "makefile":
time nice +19 make -j20 -f Makefile.X11 realclean
time nice +19 make -j20 -f Makefile.X11 linux-x86

After ~00:01:24 I got all what I need.

Mesa/demos> pwd
/opt/Mesa/demos
Mesa/demos> ldd ./glinfo
libglut.so.3 => /usr/X11R6/lib/libglut.so.3 (0x40015000)
libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x40053000)
libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x400ec000)
libm.so.6 => /lib/libm.so.6 (0x4016b000)
libc.so.6 => /lib/libc.so.6 (0x4018c000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x402ac000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4039f000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x403b5000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40403000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 
(0x4040b000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40458000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4046e000)
libdl.so.2 => /lib/libdl.so.2 (0x4047c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40481000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4048b000)
Mesa/demos> ./glinfo
r200CreateScreen
GL_VERSION: 1.2 Mesa 4.0.4
GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_env_add 
GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_transpose_matrix 
GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_logic_op 
GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint 
GL_EXT_convolution GL_EXT_compiled_vertex_array GL_EXT_histogram 
GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal 
GL_EXT_secondary_color GL_EXT_stencil_wrap GL_EXT_texture3D 
GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 
GL_EXT_texture_filter_anisotropic GL_EXT_texture_object 
GL_EXT_texture_lod_bias GL_EXT_vertex_array GL_IBM_rasterpos_clip 
GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos 
GL_NV_texgen_reflection GL_NV_texture_rectangle GL_SGI_color_matrix 
GL_SGI_color_table
GL_RENDERER: Mesa DRI R200 20020827 AGP 4x x86/MMX/3DNow!/SSE TCL
GL_VENDOR: Tungsten Graphics, Inc.
GLU_VERSION: 1.3
GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
GLUT_API_VERSION: 5
GLUT_XLIB_IMPLEMENTATION: 15

-Dieter


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Dieter Nützel]

Am Donnerstag, 21. November 2002 03:43 schrieb Linus Torvalds:
> On Thu, 21 Nov 2002, Dieter Nützel wrote:
> > 
> >
> > > GL_RENDERER: Mesa X11
> > > GL_VENDOR: Brian Paul
> >
> > 
>
> Yeah, that seems to be true for the mesa test programs I installed.
>
> Doing a regular glxinfo shows
>
>   OpenGL renderer string: Mesa DRI R200 20021009 AGP 4x x86/MMX/SSE TCL
>   OpenGL version string: 1.2 Mesa 5.0

Very nice, but no OpenGL 1.3/1.4 string, yet.
Some functions are currently missing in the r100/r200 driver.

> > You are running Software Mesa 5.0 :-O
>
> Naah, just the MesaDemos seem to use it for some reason, probably because
> I didn't know how to configure the build there correctly ..

Yes, came to my mind during hitting send...

> How do people build the Mesa demo package? It clearly doesn't build
> standalone, and apparently if you build it together with the MesaLib
> package it does the sw rendering thing).

Remove or move away the Mesa-5.0 "lib" folder or have a look into 
LD_LIBRARY_PATH. Should be enough.

Good night.
Dieter


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

RE: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Alexander Stohr]

Title: RE: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48





> > 
> > > GL_RENDERER: Mesa X11
> > > GL_VENDOR: Brian Paul
> > 
> 
> Yeah, that seems to be true for the mesa test programs I installed.
> 
> Doing a regular glxinfo shows 
> 
>   OpenGL renderer string: Mesa DRI R200 20021009 AGP 4x 
> x86/MMX/SSE TCL
>   OpenGL version string: 1.2 Mesa 5.0
> 
> > You are running Software Mesa 5.0 :-O
> 
> Naah, just the MesaDemos seem to use it for some reason, 
> probably because 
> I didn't know how to configure the build there correctly .. 
> 
> How do people build the Mesa demo package? It clearly doesn't build
> standalone, and apparently if you build it together with the MesaLib 
> package it does the sw rendering thing).
> 
>       Linus


Its a known issue for me, thats why i do prefer the GLUT demos.


I made it to bring the Mesa demos to life on DRI by just editing
the libGL and other references to the systems defaults rather than
to the libs in the project. As far as i do remember, it all turned
out to be rather "static" in linking.


To my knowledge there is no simple way with this project build system
for getting what we both do think of.


-Alex.

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Linus Torvalds]

On Thu, 21 Nov 2002, Dieter Nützel wrote:
> 
> 
> > GL_RENDERER: Mesa X11
> > GL_VENDOR: Brian Paul
> 

Yeah, that seems to be true for the mesa test programs I installed.

Doing a regular glxinfo shows 

OpenGL renderer string: Mesa DRI R200 20021009 AGP 4x x86/MMX/SSE TCL
OpenGL version string: 1.2 Mesa 5.0

> You are running Software Mesa 5.0 :-O

Naah, just the MesaDemos seem to use it for some reason, probably because 
I didn't know how to configure the build there correctly .. 

How do people build the Mesa demo package? It clearly doesn't build
standalone, and apparently if you build it together with the MesaLib 
package it does the sw rendering thing).

Linus



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Dieter Nützel]

Am Donnerstag, 21. November 2002 00:49 schrieb Linus Torvalds:
> On Wed, 20 Nov 2002, Dieter Nützel wrote:
> > > It's _really_ really slow, though, reporting a frame rate of 1.95 - 2.0
> > > fps or so when viewing the thing (whatever it is) head on.
> >
> > What do you get with LIBGL_DEBUG=verbose?
> > glinfo?
>
> GL_VERSION: 1.4 Mesa 5.0
> GL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_imaging GL_ARB_multisample
> GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_shadow
> GL_ARB_shadow_ambient GL_ARB_texture_border_clamp
> GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add
> GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar
> GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat
> GL_ARB_transpose_matrix GL_ARB_window_pos GL_ATI_texture_mirror_once
> GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate
> GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract
> GL_EXT_clip_volume_hint GL_EXT_convolution GL_EXT_compiled_vertex_array
> GL_EXT_fog_coord GL_EXT_histogram GL_EXT_multi_draw_arrays
> GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_point_parameters
> GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color
> GL_EXT_shadow_funcs GL_EXT_shared_texture_palette GL_EXT_stencil_wrap
> GL_EXT_stencil_two_side GL_EXT_texture3D GL_EXT_texture_edge_clamp
> GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3
> GL_EXT_texture_object GL_EXT_texture_lod_bias GL_EXT_vertex_array
> GL_HP_occlusion_test GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat
> GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_resize_buffers
> GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square
> GL_NV_point_sprite GL_NV_texture_rectangle GL_NV_texgen_reflection
> GL_NV_vertex_program GL_NV_vertex_program1_1 GL_SGI_color_matrix
> GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_pixel_texture
> GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp
> GL_SGIX_depth_texture GL_SGIX_pixel_texture GL_SGIX_shadow
> GL_SGIX_shadow_ambient


> GL_RENDERER: Mesa X11
> GL_VENDOR: Brian Paul


> GLU_VERSION: 1.3
> GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
> GLUT_API_VERSION: 5
> GLUT_XLIB_IMPLEMENTATION: 15
>
> > Is DRI (glx/dri) really working?
>
> Absolutely. Trust me, tuxracer isn't playable if DRI isn't working ;)

I can't. See above :-)))

You are running Software Mesa 5.0 :-O

Mesa/demos> ./glinfo
r200CreateScreen
GL_VERSION: 1.2 Mesa 4.0.4
GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_env_add 
GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_transpose_matrix 
GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_logic_op 
GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint 
GL_EXT_convolution GL_EXT_compiled_vertex_array GL_EXT_histogram 
GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal 
GL_EXT_secondary_color GL_EXT_stencil_wrap GL_EXT_texture3D 
GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 
GL_EXT_texture_filter_anisotropic GL_EXT_texture_object 
GL_EXT_texture_lod_bias GL_EXT_vertex_array GL_IBM_rasterpos_clip 
GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos 
GL_NV_texgen_reflection GL_NV_texture_rectangle GL_SGI_color_matrix 
GL_SGI_color_table

!
GL_RENDERER: Mesa DRI R200 20020827 AGP 4x x86/MMX/3DNow!/SSE TCL
GL_VENDOR: Tungsten Graphics, Inc.
!

GLU_VERSION: 1.3
GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
GLUT_API_VERSION: 5
GLUT_XLIB_IMPLEMENTATION: 15

> And interrupts etc are working:
>
>CPU0   CPU1   CPU2   CPU3
>  22:3104889313105630846243136987   IO-APIC-level 
> radeon@PCI:1:0:0
>
> so everything looks fine.

Here, yes.

> > Didn't have commercial tuxracer but gears (MesaDemo, glxgears is the
> > same) should run at ~2995 fps. I heard from over ~5000 fps with a
> > Geforce4 4600 on a system like yours.
>
> I've never gotten more than ~1700 fps on this system on glxgears. Oh,
> well. I've never tried to bump AGPMode up from the default "1", though, so
> it may be something simple like that.

AGPMode help somewhat but not really much.
Pageflipping is worth it.

Section "Device"
  BoardName"ATI Radeon 8500 QL"
  BusID"1:5:0"
  Driver   "radeon"
  Identifier   "Device[0]"
  Option   "AGPMode" "4"
  Option   "AGPFastWrite" "1"
  Option   "EnablePageflip"
  Option   "dpms"
  Screen   0
  VendorName   "ATI"
EndSection

When your machine is Right (TM) configured it should scream :-)

-Dieter

PS What do "cat /proc/dri/0/*" show?


---
This SF.net email is sponsored by: The Sourceforge Network Survey
Take Our Survey and You Could Win a $500 Gift Certificate!
http://ugamsolutions.com/psurvey/osdn/SourceForge/index_sourceforge.htm
___
Dri-devel mailing list
[EMAIL PROTECTED]
https:/

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Linus Torvalds]

On Wed, 20 Nov 2002, Dieter Nützel wrote:
> >
> > It's _really_ really slow, though, reporting a frame rate of 1.95 - 2.0
> > fps or so when viewing the thing (whatever it is) head on.
> 
> What do you get with LIBGL_DEBUG=verbose?
> glinfo?

GL_VERSION: 1.4 Mesa 5.0
GL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_imaging GL_ARB_multisample 
GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_shadow 
GL_ARB_shadow_ambient GL_ARB_texture_border_clamp 
GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add 
GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar 
GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat 
GL_ARB_transpose_matrix GL_ARB_window_pos GL_ATI_texture_mirror_once 
GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate 
GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract 
GL_EXT_clip_volume_hint GL_EXT_convolution GL_EXT_compiled_vertex_array 
GL_EXT_fog_coord GL_EXT_histogram GL_EXT_multi_draw_arrays 
GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_point_parameters 
GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color 
GL_EXT_shadow_funcs GL_EXT_shared_texture_palette GL_EXT_stencil_wrap 
GL_EXT_stencil_two_side GL_EXT_texture3D GL_EXT_texture_edge_clamp 
GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 
GL_EXT_texture_object GL_EXT_texture_lod_bias GL_EXT_vertex_array 
GL_HP_occlusion_test GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat 
GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_resize_buffers 
GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square 
GL_NV_point_sprite GL_NV_texture_rectangle GL_NV_texgen_reflection 
GL_NV_vertex_program GL_NV_vertex_program1_1 GL_SGI_color_matrix 
GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_pixel_texture 
GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp 
GL_SGIX_depth_texture GL_SGIX_pixel_texture GL_SGIX_shadow 
GL_SGIX_shadow_ambient
GL_RENDERER: Mesa X11
GL_VENDOR: Brian Paul
GLU_VERSION: 1.3
GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess 
GLUT_API_VERSION: 5
GLUT_XLIB_IMPLEMENTATION: 15

> Is DRI (glx/dri) really working?

Absolutely. Trust me, tuxracer isn't playable if DRI isn't working ;)

And interrupts etc are working:

   CPU0   CPU1   CPU2   CPU3   
 22:3104889313105630846243136987   IO-APIC-level  radeon@PCI:1:0:0

so everything looks fine.

> Didn't have commercial tuxracer but gears (MesaDemo, glxgears is the same) 
> should run at ~2995 fps. I heard from over ~5000 fps with a Geforce4 4600 on 
> a system like yours.

I've never gotten more than ~1700 fps on this system on glxgears. Oh,
well. I've never tried to bump AGPMode up from the default "1", though, so 
it may be something simple like that.

Linus



---
This SF.net email is sponsored by: The Sourceforge Network Survey
Take Our Survey and You Could Win a $500 Gift Certificate!
http://ugamsolutions.com/psurvey/osdn/SourceForge/index_sourceforge.htm
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Dieter Nützel]

Am Mittwoch, 20. November 2002 21:18 schrieben Sie:

Sorry, I watched Germany vs. Netherlands.
"We" lost... 1:3 ;-)

> Hmm.. As far as I can tell, I'm now running the mesa-4-1-branch here, and
> ipers seems to work. But I have no way to tell what the version is,
> XF86_CUSTOM_VERSION is still set to "DRI trunk":
>
>   XFree86 Version 4.2.99.2 (DRI trunk) / X Window System
>   (protocol Version 11, revision 0, vendor release 6600)
>   Release Date: 21 October 2002
>
> It's _really_ really slow, though, reporting a frame rate of 1.95 - 2.0
> fps or so when viewing the thing (whatever it is) head on.

What do you get with LIBGL_DEBUG=verbose?
glinfo?

Is DRI (glx/dri) really working?

> Turning off textures seems to speed it up a lot (8 fps). Is it supposed to
> be that slow?

NO.

~30 fps in window mode (normal) on a 1280x1024x24 screen with all ON.

> Other things are definitely hw-accelerated, ie I get fine frame rates on
> tuxracer and glxgears etc.

Didn't have commercial tuxracer but gears (MesaDemo, glxgears is the same) 
should run at ~2995 fps. I heard from over ~5000 fps with a Geforce4 4600 on 
a system like yours.

> "cubemap" seems to work, although I have no idea what it's really supposed
> to look like (I can imagine that it looks right, though - reflections in a
> sphere of the cube outside of it).

Me too, 'cause it isn't running, now ;-)

-Dieter


---
This sf.net email is sponsored by:
Battle your brains against the best in the Thawte Crypto
Challenge. Be the first to crack the code - register now:
http://www.gothawte.com/rd521.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48)

[Ian Romanick]

On Tue, Nov 19, 2002 at 11:06:16PM -0800, Linus Torvalds wrote:
> 
> On Wed, 20 Nov 2002, Dieter Nützel wrote:
> > Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:
> > > >
> > > > Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do
> > > > some testing.
> > 
> > No go so far.
> > 
> > Modules are somewhat broken in 2.5.48.
> 
> One approach is to not use modules, just compile the thing in. Works for
> me (damn, I'd like to see how the commercial tuxracer looks with bump 
> mapping. But apparently DRI doesn't support the right extension or 
> something ;)

The problem is that it uses EXT_texture_env_dot3 (which the driver does
advertise), but the driver doesn't actually implement only implements
EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly.  I noted this in an
earlier thread about glaxium, but I haven't posted a fix yet.

I have attached a patch to the DRI CVS trunk that should fix the problem.  I
don't have access to an 8500, so I haven't actually tested it.  I would
really appreciate it if people with 8500 (or 9000) cards could try this
patch and tell me if it works.  If I get a few positive results and no
negatives, I'll commit the patch.

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html



r200_DOT3_EXT.patch.gz
Description: application/gunzip

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Dieter Nützel]

Am Mittwoch, 20. November 2002 19:52 schrieb Andrew Morton:
> Dieter Nützel wrote:
> > Am Mittwoch, 20. November 2002 19:44 schrieb Alan Cox:
> > > On Wed, 2002-11-20 at 17:30, Dieter Nützel wrote:
> > > > System lookup immediately when I try to start "ipers", "isosurf" or
> > > > switch the screen. Sadly even when I try the Mesa-4-1-branch with
> > > > 2.5.47-mm1 or 2.4.19-ck5 (radeon.o 1.6.0).
> > >
> > > Are you using scsi - any measuable amount of scsi I/O also hangs 2.5.48
> > > 8(

> > Some progress with KDE (3.1 beta/rc) and shared pagetables.
> > Normal startup hangs but I had some luck with running the KDE progs by
> > hand.
> >
> > More about it in another post.
> > So that we can take DRI-Devel out.
>
> (wonders what this email is really about.  oh well)

Several things together like "I put in my bag"... :-)))

We started with DRI devel, Alan attached "SCSI" and then I came with 
KDE/shared pagetables.

Now, we have to STOP here and I will seperate things, again.

Regards,
Dieter


---
This sf.net email is sponsored by:
Battle your brains against the best in the Thawte Crypto
Challenge. Be the first to crack the code - register now:
http://www.gothawte.com/rd521.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Dieter Nützel]

Am Mittwoch, 20. November 2002 19:46 schrieb Linus Torvalds:
> On Wed, 20 Nov 2002, Dieter Nützel wrote:
> > Can you please try "ipers" and "isosurf" from the Mesa-Demo package, too?
> > Q3A and UT are sometimes "broken" even if the above works right.
>
> Well, I don't have the 3D apps, which is why I test with glxgears and
> tuxracer (the first because it's th eonly GL app installed by default, the
> second because the kids like it).

Your three daughters? Brave ;-)
I'm only a "good" uncle for my two nephews.
They like there penguins, too...

> And I have no idea where the Mesa demos are.

http://sourceforge.net/projects/mesa3d
Download

> (Also note that I only check the DRI head CVS, unlike the subject. So I
> can only say that the kernel side seems to work, but maybe the mesa branch
> triggers something special..)

OK, that makes things clearer.

DRI CVS trunk works for me, too.
So you can't have "cubemap" etc. currently.

-Dieter


---
This sf.net email is sponsored by:
Battle your brains against the best in the Thawte Crypto
Challenge. Be the first to crack the code - register now:
http://www.gothawte.com/rd521.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Andrew Morton]

Dieter Nützel wrote:
> 
> Am Mittwoch, 20. November 2002 19:44 schrieb Alan Cox:
> > On Wed, 2002-11-20 at 17:30, Dieter Nützel wrote:
> > > System lookup immediately when I try to start "ipers", "isosurf" or
> > > switch the screen. Sadly even when I try the Mesa-4-1-branch with
> > > 2.5.47-mm1 or 2.4.19-ck5 (radeon.o 1.6.0).
> >
> > Are you using scsi - any measuable amount of scsi I/O also hangs 2.5.48
> > 8(

Here's James's fix:

 drivers/scsi/scsi_lib.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

--- 25/drivers/scsi/scsi_lib.c~jejb-scsi-fixWed Nov 20 09:45:08 2002
+++ 25-akpm/drivers/scsi/scsi_lib.c Wed Nov 20 09:45:08 2002
@@ -1021,10 +1021,11 @@ void scsi_request_fn(request_queue_t * q
break;
 
if(!req) {
-   /* can happen if the prep fails 
-* FIXME: elv_next_request() should be plugging the
-* queue */
-   blk_plug_device(q);
+   /* If the device is busy, a returning I/O
+* will restart the queue.  Otherwise, we have
+* to plug the queue */
+   if(SDpnt->device_busy == 0)
+   blk_plug_device(q);
break;
}
 

> Yes, didn't have ATA at all.
> Only if some friends have problems with bad Win disks (bad sectors etc. =>
> dd_rescue)...;-)
> 
> No hangs but slower.
> I'll have a second look at it.
> 2.5.48-mm1 have additional IO scheduler hacks.

It has a different fix to the scsi thing.

> Some progress with KDE (3.1 beta/rc) and shared pagetables.
> Normal startup hangs but I had some luck with running the KDE progs by hand.
> 
> More about it in another post.
> So that we can take DRI-Devel out.
> 

(wonders what this email is really about.  oh well)


---
This sf.net email is sponsored by:
Battle your brains against the best in the Thawte Crypto
Challenge. Be the first to crack the code - register now:
http://www.gothawte.com/rd521.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Linus Torvalds]

On Wed, 20 Nov 2002, Dieter Nützel wrote:
> 
> Can you please try "ipers" and "isosurf" from the Mesa-Demo package, too?
> Q3A and UT are sometimes "broken" even if the above works right.

Well, I don't have the 3D apps, which is why I test with glxgears and 
tuxracer (the first because it's th eonly GL app installed by default, the 
second because the kids like it). 

And I have no idea where the Mesa demos are. 

(Also note that I only check the DRI head CVS, unlike the subject. So I 
can only say that the kernel side seems to work, but maybe the mesa branch 
triggers something special..)

Linus



---
This sf.net email is sponsored by:
Battle your brains against the best in the Thawte Crypto
Challenge. Be the first to crack the code - register now:
http://www.gothawte.com/rd521.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Dieter Nützel]

Am Mittwoch, 20. November 2002 19:44 schrieb Alan Cox:
> On Wed, 2002-11-20 at 17:30, Dieter Nützel wrote:
> > System lookup immediately when I try to start "ipers", "isosurf" or
> > switch the screen. Sadly even when I try the Mesa-4-1-branch with
> > 2.5.47-mm1 or 2.4.19-ck5 (radeon.o 1.6.0).
>
> Are you using scsi - any measuable amount of scsi I/O also hangs 2.5.48
> 8(

Yes, didn't have ATA at all.
Only if some friends have problems with bad Win disks (bad sectors etc. => 
dd_rescue)...;-)

No hangs but slower.
I'll have a second look at it.
2.5.48-mm1 have additional IO scheduler hacks.

Some progress with KDE (3.1 beta/rc) and shared pagetables.
Normal startup hangs but I had some luck with running the KDE progs by hand.

More about it in another post.
So that we can take DRI-Devel out.

-Dieter


---
This sf.net email is sponsored by:
Battle your brains against the best in the Thawte Crypto
Challenge. Be the first to crack the code - register now:
http://www.gothawte.com/rd521.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Dieter Nützel]

Am Mittwoch, 20. November 2002 18:45 schrieb Linus Torvalds:
> On Wed, 20 Nov 2002, Dieter Nützel wrote:
> > Linus, Alan are you running SMP during your tests?
>
> Yup. I'm running with a dual P4 HT (ie 4 virtual CPU's to software),

Yes, yes... Grumpf. I want a 8x Hammer...;-)))

> and I
> check with glxgears and the commercial tuxracer with a Radeon 8500. I've
> also verified it on a UP machine with a Radeon 7500.

Can you please try "ipers" and "isosurf" from the Mesa-Demo package, too?
Q3A and UT are sometimes "broken" even if the above works right.

I'll try viewperf (sorry 6.1.2 currently) when I have something running.

> But yeah, on plain 2.5.48 you need to enable module support, but then
> build everything into the kernel to get a working setup. With the
> snapshots, I've got reports of success with modules (needs the new module
> utils, of course).

I have it.
module-init-tools-0.7.tar.gz ?

OK, I'll try with 2.5.48-mmX and -bk, again.

Thank very much!

-Dieter


---
This sf.net email is sponsored by:
Battle your brains against the best in the Thawte Crypto
Challenge. Be the first to crack the code - register now:
http://www.gothawte.com/rd521.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Linus Torvalds]

On 20 Nov 2002, Alan Cox wrote:
> 
> Are you using scsi - any measuable amount of scsi I/O also hangs 2.5.48
> 8(

Only for you, Alan, only for you. I've got SCSI at home, so it must be
some specific controller driver being broken rather than general breakage.

Linus



---
This sf.net email is sponsored by: 
Battle your brains against the best in the Thawte Crypto 
Challenge. Be the first to crack the code - register now: 
http://www.gothawte.com/rd521.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Alan Cox]

On Wed, 2002-11-20 at 17:30, Dieter Nützel wrote:
> System lookup immediately when I try to start "ipers", "isosurf" or switch the 
> screen. Sadly even when I try the Mesa-4-1-branch with 2.5.47-mm1 or 
> 2.4.19-ck5 (radeon.o 1.6.0).

Are you using scsi - any measuable amount of scsi I/O also hangs 2.5.48
8(



---
This sf.net email is sponsored by:
Battle your brains against the best in the Thawte Crypto
Challenge. Be the first to crack the code - register now:
http://www.gothawte.com/rd521.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Linus Torvalds]

On Wed, 20 Nov 2002, Dieter Nützel wrote:
> 
> Linus, Alan are you running SMP during your tests?

Yup. I'm running with a dual P4 HT (ie 4 virtual CPU's to software), and I
check with glxgears and the commercial tuxracer with a Radeon 8500. I've
also verified it on a UP machine with a Radeon 7500.

But yeah, on plain 2.5.48 you need to enable module support, but then
build everything into the kernel to get a working setup. With the
snapshots, I've got reports of success with modules (needs the new module
utils, of course).

Linus



---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Dieter Nützel]

Am Mittwoch, 20. November 2002 08:06 schrieb Linus Torvalds:
> On Wed, 20 Nov 2002, Dieter Nützel wrote:
> > Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:
> > > > Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should
> > > > do some testing.
> >
> > No go so far.
> >
> > Modules are somewhat broken in 2.5.48.
>
> One approach is to not use modules, just compile the thing in. Works for
> me (damn, I'd like to see how the commercial tuxracer looks with bump
> mapping. But apparently DRI doesn't support the right extension or
> something ;)
>
> I don't know what badness there is in AGP/DRM modules, if somebody wants
> to help hunt that down it would be good (I'm not a module user myself).

I know and I expected your advice...;-)
Will try, again.

Linus, Alan are you running SMP during your tests?

All below is valid on my SMP system.

dual Athlon MP 1900+
MSI K7D Master-L, AMD 768MPX
1 GB DDR266 SDRAM, CL2 (2x 512 MB), HIGHMEM (!!!)
ATI powered Radeon 8500 QL

2.4.19-ck5 and
2.5.47-mm1
2.5.48-mm1 (with new 1.7.0 Radeon DRM module)

Mesa-4-1-branch (Mesa 5.0)

System lookup immediately when I try to start "ipers", "isosurf" or switch the 
screen. Sadly even when I try the Mesa-4-1-branch with 2.5.47-mm1 or 
2.4.19-ck5 (radeon.o 1.6.0).

Any hints.

I'll try with "-nosmp"

Cheers,
Dieter


---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Alan Cox]

On Wed, 2002-11-20 at 07:06, Linus Torvalds wrote:
> 
> On Wed, 20 Nov 2002, Dieter Nützel wrote:
> > Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:
> > > >
> > > > Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do
> > > > some testing.
> > 
> > No go so far.
> > 
> > Modules are somewhat broken in 2.5.48.
> 
> One approach is to not use modules, just compile the thing in. Works for

You need a kernel patch to 2.5.48 to make it build without module
support. So you have to build it with module support and no modules


---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Michel Dänzer]

On Die, 2002-11-19 at 16:30, Brian Paul wrote: 
> David Dawes wrote:
> > On Wed, Nov 06, 2002 at 03:43:02PM -0800, Ian Romanick wrote:
> > 
> >>>Is this hammered in stone?
> >>>When will we see the next XFree86 release (4.4.0), then.
> >>>Shouldn't OpenGL 1.4 better go in sooner then later?
> >>
> >>Would the Mesa 5.x merge be too large of a change for XFree86 4.3.1?  There
> > 
> > 
> > Yes, it would be.  A 4.3.1 (if there ever is one) would only be for
> > stability/security-related fixes.  New stuff that doesn't make 4.3 should
> > target 4.4.
> > 
> > However, the decision on which version of Mesa to include in XFree86
> > 4.3 hasn't been finalised yet.  That depends on how things with Mesa
> > 5.0 go before the XFree86 feature freeze date (30 November).
> 
> The DRI mesa41-branch branch now has the Mesa 5.0 sources in xc/extras/Mesa.
> (No need to set MesaSrcDir in host.def).
> 
> It would be good to have more people test the branch.  That's the only thing
> needed before merging to the trunk.

Preliminary testing hasn't shown any problems here, good work.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast


---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Garry Reisky]

It's a go here. I just installed 2.5.48 and I'm using mesa-4-1-branch. I just got done 
a wolfenstein session :) .

On (20/11/02 07:20), Dieter N?tzel wrote:
> No go so far.
> 
> Modules are somewhat broken in 2.5.48.
> I saw radeon 1.7.0 20020828 but no go, yet ;-(
> 
> [drm] Initialized radeon 1.7.0 20020828 on minor 0
> [drm:radeon_unlock] *ERROR* Process 1016 using kernel context 0
> 
> Linux agpgart interface v0.99 (c) Jeff Hartmann
> driver pci:agpgart: registering
> kobject agpgart: registering
> bus pci: add driver agpgart
> agpgart: Maximum main memory to use for agp memory: 816M
> agpgart: Detected AMD 760MP chipset
> agpgart: AGP aperture is 64M @ 0xe800
> bound device '00:00.0' to driver 'agpgart'
> 
> [drm:radeon_unlock] *ERROR* Process 1687 using kernel context 0
> 
> /home/nuetzel> cat /proc/dri/0/*
> a dev   piduid  magic ioctls
> 
>   total counts   |outstanding
> type   alloc freed fail bytes  freed | allocs  bytes
> 
> system0 001035148 kB |
> locked0 00  0 kB |
> 
> dmabufs   0 00  0  0 |  0  0
> sareas0 00  0  0 |  0  0
> driver8 80   6150   6150 |  0  0
> magic 0 00  0  0 |  0  0
> ioctltab  0 00  0  0 |  0  0
> maplist  13120196192 |  1  4
> vmalist   2 20 24 24 |  0  0
> buflist   0 00  0  0 |  0  0
> seglist   0 00  0  0 |  0  0
> pagelist  0 00  0  0 |  0  0
> files 4 40160160 |  0  0
> queues0 00  0  0 |  0  0
> commands  0 00  0  0 |  0  0
> mappings  2 20  134217728  134217728 |  0  0
> buflists  0 00  0  0 |  0  0
> agplist   0 00  0  0 |  0  0
> totalagp  0 00  0  0 |  0  0
> boundagp  0 00  0  0 |  0  0
> ctxbitmap 1 00   4096  0 |  1   4096
> stub  1 00192  0 |  1192
> radeon 0xe200
>   ctx/flags   use   fin   blk/rw/rwf  waitflushed  queued  locks
> 
> slot offset   size type flagsaddress mtrr
> 
> vma use count: 0, high_memory = f800, 0x3800
> 
> 
> II) Loading sub module "xaa"
> (II) LoadModule: "xaa"
> (II) Loading /usr/X11R6/lib/modules/libxaa.a
> (II) Module xaa: vendor="The XFree86 Project"
> compiled for 4.2.99.2, module version = 1.1.0
> ABI class: XFree86 Video Driver, version 0.6
> (**) RADEON(0): Using AGP 4x mode
> (**) RADEON(0): Enabling AGP Fast Write
> (II) RADEON(0): Depth moves disabled by default
> (II) Loading sub module "shadow"
> (II) LoadModule: "shadow"
> (II) Loading /usr/X11R6/lib/modules/libshadow.a
> (II) Module shadow: vendor="The XFree86 Project"
> compiled for 4.2.99.2, module version = 1.0.0
> ABI class: XFree86 ANSI C Emulation, version 0.1
> (II) RADEON(0): Page flipping enabled
> (!!) RADEON(0): For information on using the multimedia capabilities
>  of this adapter, please see http://gatos.sf.net.
> (--) Depth 24 pixmap format is 32 bpp
> 
> (==) RADEON(0): Write-combining range (0xe000,0x400)
> drmOpenDevice: minor is 0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 6, (OK)
> drmOpenDevice: minor is 0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 6, (OK)
> drmOpenDevice: minor is 0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 6, (OK)
> drmGetBusid returned ''
> (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:5:0"
> (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf90dc000
> (II) RADEON(0): [drm] mapped SAREA 0xf90dc000 to 0x40015000
> (II) RADEON(0): [drm] framebuffer handle = 0xe000
> (II) RADEON(0): [drm] added 1 reserved context for kernel
> (WW) RADEON(0): [agp] AGP not available
> (II) RADEON(0): [drm] removed 1 reserved context for kernel
> (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xf90dc000 at 0x40015000
> (II) RADEON(0): Memory manager initialized to (0,0) (1280,8191)
> (II) RADEON(0): Reserved area from (0,1024) to (1280,1026)
> (II) RADEON(0): Largest offscreen area available: 1280 x 7165
> (==) RADEON(0): Silken mouse enabled
> (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
> Screen to screen bit blits
> Solid filled rectangles
> 8x8 mono pattern filled rectangles
> Indirect CPU to Scree

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Linus Torvalds]

On Wed, 20 Nov 2002, Dieter Nützel wrote:
> Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:
> > >
> > > Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do
> > > some testing.
> 
> No go so far.
> 
> Modules are somewhat broken in 2.5.48.

One approach is to not use modules, just compile the thing in. Works for
me (damn, I'd like to see how the commercial tuxracer looks with bump 
mapping. But apparently DRI doesn't support the right extension or 
something ;)

I don't know what badness there is in AGP/DRM modules, if somebody wants 
to help hunt that down it would be good (I'm not a module user myself).

Linus



---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48

[Dieter Nützel]

Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:
> On Tue, 19 Nov 2002 20:50:50 +0100
>
> Dieter Nützel <[EMAIL PROTECTED]> wrote:
> > > Thats my birthday! :)
> >
> > Hey, mine comes first :-)
> >
> > Hopefully with Mesa-5.x.
> > Going into mesa-4-1-branch testing mode, now.
> >
> > Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do
> > some testing.

No go so far.

Modules are somewhat broken in 2.5.48.
I saw radeon 1.7.0 20020828 but no go, yet ;-(

[drm] Initialized radeon 1.7.0 20020828 on minor 0
[drm:radeon_unlock] *ERROR* Process 1016 using kernel context 0

Linux agpgart interface v0.99 (c) Jeff Hartmann
driver pci:agpgart: registering
kobject agpgart: registering
bus pci: add driver agpgart
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: Detected AMD 760MP chipset
agpgart: AGP aperture is 64M @ 0xe800
bound device '00:00.0' to driver 'agpgart'

[drm:radeon_unlock] *ERROR* Process 1687 using kernel context 0

/home/nuetzel> cat /proc/dri/0/*
a dev   piduid  magic ioctls

  total counts   |outstanding
type   alloc freed fail bytes  freed | allocs  bytes

system0 001035148 kB |
locked0 00  0 kB |

dmabufs   0 00  0  0 |  0  0
sareas0 00  0  0 |  0  0
driver8 80   6150   6150 |  0  0
magic 0 00  0  0 |  0  0
ioctltab  0 00  0  0 |  0  0
maplist  13120196192 |  1  4
vmalist   2 20 24 24 |  0  0
buflist   0 00  0  0 |  0  0
seglist   0 00  0  0 |  0  0
pagelist  0 00  0  0 |  0  0
files 4 40160160 |  0  0
queues0 00  0  0 |  0  0
commands  0 00  0  0 |  0  0
mappings  2 20  134217728  134217728 |  0  0
buflists  0 00  0  0 |  0  0
agplist   0 00  0  0 |  0  0
totalagp  0 00  0  0 |  0  0
boundagp  0 00  0  0 |  0  0
ctxbitmap 1 00   4096  0 |  1   4096
stub  1 00192  0 |  1192
radeon 0xe200
  ctx/flags   use   fin   blk/rw/rwf  waitflushed  queued  locks

slot offset   size type flagsaddress mtrr

vma use count: 0, high_memory = f800, 0x3800


II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Loading /usr/X11R6/lib/modules/libxaa.a
(II) Module xaa: vendor="The XFree86 Project"
compiled for 4.2.99.2, module version = 1.1.0
ABI class: XFree86 Video Driver, version 0.6
(**) RADEON(0): Using AGP 4x mode
(**) RADEON(0): Enabling AGP Fast Write
(II) RADEON(0): Depth moves disabled by default
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /usr/X11R6/lib/modules/libshadow.a
(II) Module shadow: vendor="The XFree86 Project"
compiled for 4.2.99.2, module version = 1.0.0
ABI class: XFree86 ANSI C Emulation, version 0.1
(II) RADEON(0): Page flipping enabled
(!!) RADEON(0): For information on using the multimedia capabilities
 of this adapter, please see http://gatos.sf.net.
(--) Depth 24 pixmap format is 32 bpp

(==) RADEON(0): Write-combining range (0xe000,0x400)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmGetBusid returned ''
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:5:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xf90dc000
(II) RADEON(0): [drm] mapped SAREA 0xf90dc000 to 0x40015000
(II) RADEON(0): [drm] framebuffer handle = 0xe000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(WW) RADEON(0): [agp] AGP not available
(II) RADEON(0): [drm] removed 1 reserved context for kernel
(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xf90dc000 at 0x40015000
(II) RADEON(0): Memory manager initialized to (0,0) (1280,8191)
(II) RADEON(0): Reserved area from (0,1024) to (1280,1026)
(II) RADEON(0): Largest offscreen area available: 1280 x 7165
(==) RADEON(0): Silken mouse enabled
(II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
8x8 mono pattern filled rectangles
Indir

Re: [Dri-devel] mesa 4.1 branch

[Dieter Nützel]

Am Dienstag, 19. November 2002 09:55 schrieb Ian Molton:
> On Mon, 18 Nov 2002 21:35:44 -0500
>
> David Dawes <[EMAIL PROTECTED]> wrote:
> > That depends on how things with Mesa
> > 5.0 go before the XFree86 feature freeze date (30 November).
>
> Thats my birthday! :)

Hey, mine comes first :-)

Hopefully with Mesa-5.x.
Going into mesa-4-1-branch testing mode, now.

Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do some 
testing.

Cheers,
Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
@home: Dieter.Nuetzel at hamburg.de (replace at with @)


---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Brian Paul]

David Dawes wrote:

On Wed, Nov 06, 2002 at 03:43:02PM -0800, Ian Romanick wrote:



Is this hammered in stone?
When will we see the next XFree86 release (4.4.0), then.
Shouldn't OpenGL 1.4 better go in sooner then later?


Would the Mesa 5.x merge be too large of a change for XFree86 4.3.1?  There



Yes, it would be.  A 4.3.1 (if there ever is one) would only be for
stability/security-related fixes.  New stuff that doesn't make 4.3 should
target 4.4.

However, the decision on which version of Mesa to include in XFree86
4.3 hasn't been finalised yet.  That depends on how things with Mesa
5.0 go before the XFree86 feature freeze date (30 November).


The DRI mesa41-branch branch now has the Mesa 5.0 sources in xc/extras/Mesa.
(No need to set MesaSrcDir in host.def).

It would be good to have more people test the branch.  That's the only thing
needed before merging to the trunk.

-Brian



---
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Ian Molton]

On Mon, 18 Nov 2002 21:35:44 -0500
David Dawes <[EMAIL PROTECTED]> wrote:

> That depends on how things with Mesa
> 5.0 go before the XFree86 feature freeze date (30 November).

Thats my birthday! :)


---
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[David Dawes]

On Wed, Nov 06, 2002 at 03:43:02PM -0800, Ian Romanick wrote:

>> Is this hammered in stone?
>> When will we see the next XFree86 release (4.4.0), then.
>> Shouldn't OpenGL 1.4 better go in sooner then later?
>
>Would the Mesa 5.x merge be too large of a change for XFree86 4.3.1?  There

Yes, it would be.  A 4.3.1 (if there ever is one) would only be for
stability/security-related fixes.  New stuff that doesn't make 4.3 should
target 4.4.

However, the decision on which version of Mesa to include in XFree86
4.3 hasn't been finalised yet.  That depends on how things with Mesa
5.0 go before the XFree86 feature freeze date (30 November).

David


---
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Alan Hourihane]

On Wed, Nov 06, 2002 at 04:29:35PM -0700, Brian Paul wrote:
> Alan Hourihane wrote:
> >On Wed, Nov 06, 2002 at 03:26:45PM -0700, Brian Paul wrote:
> >
> >>Michel Dänzer wrote:
> >>
> >>>On Mit, 2002-11-06 at 01:39, Brian Paul wrote: 
> >>>
> >>>
> Bret Towe wrote:
> 
> 
> >i recently grabed the mesa 4.1 branch to test out
> >mainly to see if the multitexture problem with
> >celestia was fixed also to see how it looked anyhow after
> >seeing celestia crash as per the norm i tried using the
> >LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
> >everytime for me
> 
> >>>On a related note, the celestia demo used to be one of the more reliable
> >>>ways to provoke a hard lockup on top of incorrect rendering, but those
> >>>problems seem to be gone with the texmem branch, and it seems to run
> >>>smoother than ever! Great work everybody, can't wait for the texmem and
> >>>mesa-4-1 branches to be merged on the trunk. :)
> >>
> >>Just FYI:
> >>
> >>Mesa 4.1 has been rev'd to 5.0 in CVS (the 5 indicates OpenGL 1.4 support
> >>and the 0 indicates a stable release).  I hope to get it released by
> >>Saturday.
> >>
> >>Then, I'll bring that into the mesa-4-1 branch in CVS, and merge the
> >>trunk DRI changes into the mesa-4-1 branch.  Once that seems solid, I'll
> >>merge to the DRI trunk. (probably a few weeks away)
> >
> >
> >Brian,
> >
> >Can you give me the heads up before you merge that back into the trunk.
> 
> Will do.
> 
> 
> >I'd like to pick up any final fixes before XFree86 4.3.0
> 
> Is there an ETA for XFree86 4.3.0?

Not concrete yet. But any new significant features will probably be
held back now.

Alan.


---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Brian Paul]

Ian Romanick wrote:

On Wed, Nov 06, 2002 at 11:46:53PM +0100, Dieter Nützel wrote:


Am Mittwoch, 6. November 2002 23:26 schrieb Brian Paul:


Michel Dänzer wrote:



I'm not sure when the texmem work will get pulled into the trunk.


Maybe before your Mesa-5.0 pull into the Mesa-4.1 branch?



Probably not, but the two branches are unrelated.  The real question is,
"When will both branches be merged in with the trunk?"  I know that there
will be some difficulties there wrt cube map support in the R200 (and
hopefully R100!) driver.  I don't think that should be too horrible to work
out, though.



XFree86 4.3 will have Mesa 4.0.4.  The timing was just too tight to get
5.0 into XFree86 4.3.  Besides, the DRI drivers and indirect GLX code
don't enable all the extensions needed for OpenGL 1.4 anyway.


Is this hammered in stone?
When will we see the next XFree86 release (4.4.0), then.
Shouldn't OpenGL 1.4 better go in sooner then later?



Would the Mesa 5.x merge be too large of a change for XFree86 4.3.1?  There
are going to be quite a few changes going in "shortly" after that merge that
will really improve OpenGL support on XFree86...



I don't know.  I think we'll have to play it by ear.

-Brian




---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Ian Romanick]

On Wed, Nov 06, 2002 at 11:46:53PM +0100, Dieter Nützel wrote:
> Am Mittwoch, 6. November 2002 23:26 schrieb Brian Paul:
> > Michel Dänzer wrote:
> 
> > I'm not sure when the texmem work will get pulled into the trunk.
> 
> Maybe before your Mesa-5.0 pull into the Mesa-4.1 branch?

Probably not, but the two branches are unrelated.  The real question is,
"When will both branches be merged in with the trunk?"  I know that there
will be some difficulties there wrt cube map support in the R200 (and
hopefully R100!) driver.  I don't think that should be too horrible to work
out, though.

> > XFree86 4.3 will have Mesa 4.0.4.  The timing was just too tight to get
> > 5.0 into XFree86 4.3.  Besides, the DRI drivers and indirect GLX code
> > don't enable all the extensions needed for OpenGL 1.4 anyway.
> 
> Is this hammered in stone?
> When will we see the next XFree86 release (4.4.0), then.
> Shouldn't OpenGL 1.4 better go in sooner then later?

Would the Mesa 5.x merge be too large of a change for XFree86 4.3.1?  There
are going to be quite a few changes going in "shortly" after that merge that
will really improve OpenGL support on XFree86...

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html


---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Brian Paul]

Alan Hourihane wrote:

On Wed, Nov 06, 2002 at 03:26:45PM -0700, Brian Paul wrote:


Michel Dänzer wrote:


On Mit, 2002-11-06 at 01:39, Brian Paul wrote: 


Bret Towe wrote:



i recently grabed the mesa 4.1 branch to test out
mainly to see if the multitexture problem with
celestia was fixed also to see how it looked anyhow after
seeing celestia crash as per the norm i tried using the
LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
everytime for me



On a related note, the celestia demo used to be one of the more reliable
ways to provoke a hard lockup on top of incorrect rendering, but those
problems seem to be gone with the texmem branch, and it seems to run
smoother than ever! Great work everybody, can't wait for the texmem and
mesa-4-1 branches to be merged on the trunk. :)


Just FYI:

Mesa 4.1 has been rev'd to 5.0 in CVS (the 5 indicates OpenGL 1.4 support
and the 0 indicates a stable release).  I hope to get it released by
Saturday.

Then, I'll bring that into the mesa-4-1 branch in CVS, and merge the
trunk DRI changes into the mesa-4-1 branch.  Once that seems solid, I'll
merge to the DRI trunk. (probably a few weeks away)



Brian,

Can you give me the heads up before you merge that back into the trunk.


Will do.



I'd like to pick up any final fixes before XFree86 4.3.0


Is there an ETA for XFree86 4.3.0?

-Brian




---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Alan Hourihane]

On Wed, Nov 06, 2002 at 03:26:45PM -0700, Brian Paul wrote:
> Michel Dänzer wrote:
> >On Mit, 2002-11-06 at 01:39, Brian Paul wrote: 
> >
> >>Bret Towe wrote:
> >>
> >>>i recently grabed the mesa 4.1 branch to test out
> >>>mainly to see if the multitexture problem with
> >>>celestia was fixed also to see how it looked anyhow after
> >>>seeing celestia crash as per the norm i tried using the
> >>>LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
> >>>everytime for me
> >>
> >
> >On a related note, the celestia demo used to be one of the more reliable
> >ways to provoke a hard lockup on top of incorrect rendering, but those
> >problems seem to be gone with the texmem branch, and it seems to run
> >smoother than ever! Great work everybody, can't wait for the texmem and
> >mesa-4-1 branches to be merged on the trunk. :)
> 
> Just FYI:
> 
> Mesa 4.1 has been rev'd to 5.0 in CVS (the 5 indicates OpenGL 1.4 support
> and the 0 indicates a stable release).  I hope to get it released by
> Saturday.
> 
> Then, I'll bring that into the mesa-4-1 branch in CVS, and merge the
> trunk DRI changes into the mesa-4-1 branch.  Once that seems solid, I'll
> merge to the DRI trunk. (probably a few weeks away)

Brian,

Can you give me the heads up before you merge that back into the trunk.

I'd like to pick up any final fixes before XFree86 4.3.0

Alan.


---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Dieter Nützel]

Am Mittwoch, 6. November 2002 23:26 schrieb Brian Paul:
> Michel Dänzer wrote:

> I'm not sure when the texmem work will get pulled into the trunk.

Maybe before your Mesa-5.0 pull into the Mesa-4.1 branch?

> XFree86 4.3 will have Mesa 4.0.4.  The timing was just too tight to get
> 5.0 into XFree86 4.3.  Besides, the DRI drivers and indirect GLX code
> don't enable all the extensions needed for OpenGL 1.4 anyway.

Is this hammered in stone?
When will we see the next XFree86 release (4.4.0), then.
Shouldn't OpenGL 1.4 better go in sooner then later?

-Dieter


---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Brian Paul]

Michel Dänzer wrote:

On Mit, 2002-11-06 at 01:39, Brian Paul wrote: 

Bret Towe wrote:


i recently grabed the mesa 4.1 branch to test out
mainly to see if the multitexture problem with
celestia was fixed also to see how it looked anyhow after
seeing celestia crash as per the norm i tried using the
LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
everytime for me




On a related note, the celestia demo used to be one of the more reliable
ways to provoke a hard lockup on top of incorrect rendering, but those
problems seem to be gone with the texmem branch, and it seems to run
smoother than ever! Great work everybody, can't wait for the texmem and
mesa-4-1 branches to be merged on the trunk. :)


Just FYI:

Mesa 4.1 has been rev'd to 5.0 in CVS (the 5 indicates OpenGL 1.4 support
and the 0 indicates a stable release).  I hope to get it released by
Saturday.

Then, I'll bring that into the mesa-4-1 branch in CVS, and merge the
trunk DRI changes into the mesa-4-1 branch.  Once that seems solid, I'll
merge to the DRI trunk. (probably a few weeks away)

I'm not sure when the texmem work will get pulled into the trunk.

XFree86 4.3 will have Mesa 4.0.4.  The timing was just too tight to get
5.0 into XFree86 4.3.  Besides, the DRI drivers and indirect GLX code
don't enable all the extensions needed for OpenGL 1.4 anyway.

-Brian



---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Michel Dänzer]

On Mit, 2002-11-06 at 01:39, Brian Paul wrote: 
> Bret Towe wrote:
> > i recently grabed the mesa 4.1 branch to test out
> > mainly to see if the multitexture problem with
> > celestia was fixed also to see how it looked anyhow after
> > seeing celestia crash as per the norm i tried using the
> > LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
> > everytime for me

On a related note, the celestia demo used to be one of the more reliable
ways to provoke a hard lockup on top of incorrect rendering, but those
problems seem to be gone with the texmem branch, and it seems to run
smoother than ever! Great work everybody, can't wait for the texmem and
mesa-4-1 branches to be merged on the trunk. :)


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast


---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Brian Paul]

Dieter Nützel wrote:

Am Mittwoch, 6. November 2002 16:46 schrieb Brian Paul:


Bret Towe wrote:


On Tue, 2002-11-05 at 16:39, Brian Paul wrote:


Bret Towe wrote:


i recently grabed the mesa 4.1 branch to test out
mainly to see if the multitexture problem with
celestia was fixed also to see how it looked anyhow after
seeing celestia crash as per the norm i tried using the
LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
everytime for me i would of tested more apps to see
how consistent it is but i get sick of x dieing like that
for very long so i left it alone
in the mornin(for me anyhow) ill try out a few more apps
if you need more info or logs etc let me know ill see it
when i check my mail in the morn


I just tried celestia with the 4.1 branch (indirect rendering).
It came up fine and I pressed 'd' to run the demo.  Eventually,
celestia crashed.  Looks like a problem in celestia, not Mesa
or GLX or DRI.


that crash was prob the multitexture problem that somethin has no clue
what any more


What???



The text in the corners of the window isn't legible.  I don't
know if it's drawn with glBitmap or texture or what so I'm
not sure what the problem is.

-Brian


i dunno maybe its just cause im using some optimization under gcc 3.2
(-mcpu=athlon -march=athlon -pipe)


In any case, I found a few problems.  Celestia is now working with
indirect rendering perfectly.  Here's the story:

1. A few functions in Mesa were no-ops, such as glGenTexturesEXT and
   glIsTextureEXT.  The non-EXT versions were fine.  The net effect was
   that the array of texture object IDs was left uninitialized.  Many
   were zero so texture images (the Celestia text) was clobbering each
   other.

   I've checked in the fix for this to the Mesa and DRI cvs trees.



Brian could you run your Mesa-4.1 "test apps" through valgrind (maybe purify 
or the like), please?

Maybe someday.  I don't have time now and there's a lot of other things
on my to-do list.

-Brian





---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Bret Towe]

On Wed, 2002-11-06 at 07:46, Brian Paul wrote:
> Bret Towe wrote:
> > On Tue, 2002-11-05 at 16:39, Brian Paul wrote:
> > 
> >>Bret Towe wrote:
> >>
> >>>i recently grabed the mesa 4.1 branch to test out
> >>>mainly to see if the multitexture problem with
> >>>celestia was fixed also to see how it looked anyhow after
> >>>seeing celestia crash as per the norm i tried using the
> >>>LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
> >>>everytime for me i would of tested more apps to see
> >>>how consistent it is but i get sick of x dieing like that
> >>>for very long so i left it alone
> >>>in the mornin(for me anyhow) ill try out a few more apps
> >>>if you need more info or logs etc let me know ill see it
> >>>when i check my mail in the morn
> >>
> >>I just tried celestia with the 4.1 branch (indirect rendering).
> >>It came up fine and I pressed 'd' to run the demo.  Eventually,
> >>celestia crashed.  Looks like a problem in celestia, not Mesa
> >>or GLX or DRI.
> >>
> > 
> > that crash was prob the multitexture problem that somethin has no clue
> > what any more
> 
> What???
> 

ignore me im just a confused luser ;P

> 
> >>The text in the corners of the window isn't legible.  I don't
> >>know if it's drawn with glBitmap or texture or what so I'm
> >>not sure what the problem is.
> >>
> >>-Brian
> > 
> > i dunno maybe its just cause im using some optimization under gcc 3.2
> > (-mcpu=athlon -march=athlon -pipe) 
> 
> 
> In any case, I found a few problems.  Celestia is now working with
> indirect rendering perfectly.  Here's the story:
> 
> 1. A few functions in Mesa were no-ops, such as glGenTexturesEXT and
> glIsTextureEXT.  The non-EXT versions were fine.  The net effect was
> that the array of texture object IDs was left uninitialized.  Many
> were zero so texture images (the Celestia text) was clobbering each
> other.
> 
> I've checked in the fix for this to the Mesa and DRI cvs trees.
> 
> 2. Celestia declares function pointers such as glActiveTextureARB that
> are identical to OpenGL function names.  Somewhere along the line
> the linker gets them confused, leading to segfaults.
> 

ahh now that i know whats causing the problem i can see about making a
patch for it :)

Thanks for the help
> I think it's imperative that we get the word out to OpenGL developers:
> "Do NOT declare function pointers which are identical to OpenGL function
> names".  You're asking for trouble if you do.
> 
> You wouldn't declare a function pointer called "printf", would you?
> It's the same issue.
> 
> I'll send a note to the Celestia people to see if they'll fix this.
> 
> -Brian
 




---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Dieter Nützel]

Am Mittwoch, 6. November 2002 16:46 schrieb Brian Paul:
> Bret Towe wrote:
> > On Tue, 2002-11-05 at 16:39, Brian Paul wrote:
> >>Bret Towe wrote:
> >>>i recently grabed the mesa 4.1 branch to test out
> >>>mainly to see if the multitexture problem with
> >>>celestia was fixed also to see how it looked anyhow after
> >>>seeing celestia crash as per the norm i tried using the
> >>>LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
> >>>everytime for me i would of tested more apps to see
> >>>how consistent it is but i get sick of x dieing like that
> >>>for very long so i left it alone
> >>>in the mornin(for me anyhow) ill try out a few more apps
> >>>if you need more info or logs etc let me know ill see it
> >>>when i check my mail in the morn
> >>
> >>I just tried celestia with the 4.1 branch (indirect rendering).
> >>It came up fine and I pressed 'd' to run the demo.  Eventually,
> >>celestia crashed.  Looks like a problem in celestia, not Mesa
> >>or GLX or DRI.
> >
> > that crash was prob the multitexture problem that somethin has no clue
> > what any more
>
> What???
>
> >>The text in the corners of the window isn't legible.  I don't
> >>know if it's drawn with glBitmap or texture or what so I'm
> >>not sure what the problem is.
> >>
> >>-Brian
> >
> > i dunno maybe its just cause im using some optimization under gcc 3.2
> > (-mcpu=athlon -march=athlon -pipe)
>
> In any case, I found a few problems.  Celestia is now working with
> indirect rendering perfectly.  Here's the story:
>
> 1. A few functions in Mesa were no-ops, such as glGenTexturesEXT and
> glIsTextureEXT.  The non-EXT versions were fine.  The net effect was
> that the array of texture object IDs was left uninitialized.  Many
> were zero so texture images (the Celestia text) was clobbering each
> other.
>
> I've checked in the fix for this to the Mesa and DRI cvs trees.

Brian could you run your Mesa-4.1 "test apps" through valgrind (maybe purify 
or the like), please?

e.g.: r200 trunk
Mesa/demos> valgrind ./gears
[-]
==2635== Warning: noted but unhandled ioctl 0x6452 with no size/direction 
hints
==2635==This could cause spurious value errors to appear.
==2635==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.
==2635== Warning: noted but unhandled ioctl 0x6452 with no size/direction 
hints
==2635==This could cause spurious value errors to appear.
==2635==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a 
proper wrapper.
==2635==
==2635== ERROR SUMMARY: 3 errors from 13 contexts (suppressed: 0 from 0)
==2635== malloc/free: in use at exit: 2720212 bytes in 1028 blocks.
==2635== malloc/free: 1461 allocs, 433 frees, 2752410 bytes allocated.
==2635== For a detailed leak analysis,  rerun with: --leak-check=yes
==2635== For counts of detected errors, rerun with: -v


This time with "-v":
[-]
==3581== Invalid write of size 4
==3581==at 0x43502BA1: emit_vec12 (in 
/usr/X11R6/lib/modules/dri/r200_dri.so)
==3581==Address 0x4C1B6008 is not stack'd, malloc'd or free'd
==3581==
==3581== 5028 errors in context 11 of 13:
==3581== Invalid write of size 4
==3581==at 0x43502B9B: emit_vec12 (in 
/usr/X11R6/lib/modules/dri/r200_dri.so)
==3581==Address 0x4C1B6004 is not stack'd, malloc'd or free'd
==3581==
==3581== 5028 errors in context 12 of 13:
==3581== Invalid write of size 4
==3581==at 0x43502B96: emit_vec12 (in 
/usr/X11R6/lib/modules/dri/r200_dri.so)
==3581==Address 0x4C1B6000 is not stack'd, malloc'd or free'd
==3581==
==3581== 14853 errors in context 13 of 13:
==3581== Invalid write of size 4
==3581==at 0x43502B89: emit_vec12 (in 
/usr/X11R6/lib/modules/dri/r200_dri.so)
==3581==Address 0x4C1B69C4 is not stack'd, malloc'd or free'd
==3581== IN SUMMARY: 3 errors from 13 contexts (suppressed: 0 from 0)
==3581==
==3581== malloc/free: in use at exit: 2720196 bytes in 1027 blocks.
==3581== malloc/free: 1367 allocs, 340 frees, 2741917 bytes allocated.
==3581== For a detailed leak analysis,  rerun with: --leak-check=yes
==3581==
--3581--   lru: 175 epochs, 0 clearings.
--3581-- translate: new 11194 (19 -> 2481173), discard 0 (0 -> 0).
--3581--  dispatch: 875 basic blocks, 181/155160 sched events, 99894 
tt_fast misses.
--3581-- reg-alloc: 3575 t-req-spill, 444995+27565 orig+spill uis, 56220 
total-reg-r.
--3581--sanity: 180 cheap, 8 expensive checks.


And now with "-v --leak-check=yes":
[-]
==3729== 14853 errors in context 13 of 13:
==3729== Invalid write of size 4
==3729==at 0x43502B89: emit_vec12 (in 
/usr/X11R6/lib/modules/dri/r200_dri.so)
==3729==Address 0x4C2869C4 is not stack'd, malloc'd or free'd
==3729== IN SUMMARY: 3 errors from 13 contexts (suppressed: 0 from 0)
==3729==
==3729== malloc/free: in use at exit: 2720196 bytes in 1027 blocks.
==3729== malloc/free: 1307 allocs, 280 frees, 2741437 bytes allocated.
==3729==
==3729== searching for pointers to 1027 not-freed blocks.
==3729== checked 83156860 byt

Re: [Dri-devel] mesa 4.1 branch

[Brian Paul]

Bret Towe wrote:

On Tue, 2002-11-05 at 16:39, Brian Paul wrote:


Bret Towe wrote:


i recently grabed the mesa 4.1 branch to test out
mainly to see if the multitexture problem with
celestia was fixed also to see how it looked anyhow after
seeing celestia crash as per the norm i tried using the
LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
everytime for me i would of tested more apps to see
how consistent it is but i get sick of x dieing like that
for very long so i left it alone
in the mornin(for me anyhow) ill try out a few more apps
if you need more info or logs etc let me know ill see it
when i check my mail in the morn


I just tried celestia with the 4.1 branch (indirect rendering).
It came up fine and I pressed 'd' to run the demo.  Eventually,
celestia crashed.  Looks like a problem in celestia, not Mesa
or GLX or DRI.



that crash was prob the multitexture problem that somethin has no clue
what any more


What???



The text in the corners of the window isn't legible.  I don't
know if it's drawn with glBitmap or texture or what so I'm
not sure what the problem is.

-Brian


i dunno maybe its just cause im using some optimization under gcc 3.2
(-mcpu=athlon -march=athlon -pipe) 


In any case, I found a few problems.  Celestia is now working with
indirect rendering perfectly.  Here's the story:

1. A few functions in Mesa were no-ops, such as glGenTexturesEXT and
   glIsTextureEXT.  The non-EXT versions were fine.  The net effect was
   that the array of texture object IDs was left uninitialized.  Many
   were zero so texture images (the Celestia text) was clobbering each
   other.

   I've checked in the fix for this to the Mesa and DRI cvs trees.

2. Celestia declares function pointers such as glActiveTextureARB that
   are identical to OpenGL function names.  Somewhere along the line
   the linker gets them confused, leading to segfaults.

I think it's imperative that we get the word out to OpenGL developers:
"Do NOT declare function pointers which are identical to OpenGL function
names".  You're asking for trouble if you do.

You wouldn't declare a function pointer called "printf", would you?
It's the same issue.

I'll send a note to the Celestia people to see if they'll fix this.

-Brian



---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Bret Towe]

On Tue, 2002-11-05 at 16:39, Brian Paul wrote:
> Bret Towe wrote:
> > i recently grabed the mesa 4.1 branch to test out
> > mainly to see if the multitexture problem with
> > celestia was fixed also to see how it looked anyhow after
> > seeing celestia crash as per the norm i tried using the
> > LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
> > everytime for me i would of tested more apps to see
> > how consistent it is but i get sick of x dieing like that
> > for very long so i left it alone
> > in the mornin(for me anyhow) ill try out a few more apps
> > if you need more info or logs etc let me know ill see it
> > when i check my mail in the morn
> 
> I just tried celestia with the 4.1 branch (indirect rendering).
> It came up fine and I pressed 'd' to run the demo.  Eventually,
> celestia crashed.  Looks like a problem in celestia, not Mesa
> or GLX or DRI.
> 
that crash was prob the multitexture problem that somethin has no clue
what any more

> The text in the corners of the window isn't legible.  I don't
> know if it's drawn with glBitmap or texture or what so I'm
> not sure what the problem is.
> 
> -Brian
i dunno maybe its just cause im using some optimization under gcc 3.2
(-mcpu=athlon -march=athlon -pipe) 



---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch

[Brian Paul]

Bret Towe wrote:

i recently grabed the mesa 4.1 branch to test out
mainly to see if the multitexture problem with
celestia was fixed also to see how it looked anyhow after
seeing celestia crash as per the norm i tried using the
LIBGL_ALWAYS_INDIRECT=1 with celestia and it crashs x
everytime for me i would of tested more apps to see
how consistent it is but i get sick of x dieing like that
for very long so i left it alone
in the mornin(for me anyhow) ill try out a few more apps
if you need more info or logs etc let me know ill see it
when i check my mail in the morn


I just tried celestia with the 4.1 branch (indirect rendering).
It came up fine and I pressed 'd' to run the demo.  Eventually,
celestia crashed.  Looks like a problem in celestia, not Mesa
or GLX or DRI.

The text in the corners of the window isn't legible.  I don't
know if it's drawn with glBitmap or texture or what so I'm
not sure what the problem is.

-Brian



---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa 4.1 branch broken for now

[Brian Paul]

Brian Paul wrote:


I've checked in a bunch of changes to Mesa CVS but haven't yet updated
the DRI mesa-4-1 branch to compensate - so it won't compile.  I'll check
in my fixes (plus a new R200 feature) tomorrow.


OK, the mesa-4-1 branch should compile and work again.

I've implemented hardware cube mapping in the R200 driver.  This required
adding support for some new registers to the radeon.o kernel module.  So
you'll need that in order to get GL_ARB_texture_cube_map.  If you use an
older kernel module, GL_ARB_texture_cube_map will be silently disabled.
I bumped the radeon kernel module version to 1.7.

-Brian



---
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Stefan Lange wrote:

I cvs-updated both Mesa and mesa-4-1-branch today, and I don't get any
more FPE's with R200_NO_TCL=1. Thanks!


Hmmm, I don't recall changing anything that would account for this.
Bugs that magically go away always make me nervous.

-Brian




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Stefan Lange]

I cvs-updated both Mesa and mesa-4-1-branch today, and I don't get any
more FPE's with R200_NO_TCL=1. Thanks!

Stefan




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Stefan Lange]

[...]
>> hmm, that's odd. I still get floating point exceptions for almost 
>> every GL-app. with TCL disabled.
>>
>> Demos that _do_ work with TCL disabled include:
>> clearspd, drawpix, gamma, glinfo, lodbias, readpix, winpos
>>
>> Maybe this can give you a clue, why some are working and some aren't?
>>
>> Could I have messed something up during checking 
>> out/compiling/installing that is causing these FPE's?
> 
> 
> Can you run with gdb and find where the FP exception is happening?
> 

Well, first I gotta admit that I don't have any experience in debugging, 
so this log might be completely useless. If that's the case, I'd 
appreciate if anyone can give me a quick howto in basic debugging.


harkpabst [../MESA-CVS/Mesa/demos] $ export R200_NO_TCL=1
harkpabst [../MESA-CVS/Mesa/demos] $ gdb ./gears
GNU gdb 2002-08-18-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...(no debugging symbols found)...
(gdb) run
Starting program: /mnt/hdc1/benutzer/src/dri/MESA-CVS/Mesa/demos/gears
[New Thread 1024 (LWP 27531)]

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 1024 (LWP 27531)]
0x406452df in _mesa_test_os_sse_exception_support () from 
/usr/X11R6-DRI/lib/modules/dri/r200_dri.so
(gdb) c
Continuing.
disabling TCL support

Program received signal SIGFPE, Arithmetic exception.
0x4064872a in _mesa_sse_transform_points3_general () from 
/usr/X11R6-DRI/lib/modules/dri/r200_dri.so
(gdb) bt
#0  0x4064872a in _mesa_sse_transform_points3_general () from 
/usr/X11R6-DRI/lib/modules/dri/r200_dri.so
#1  0x08055e10 in ?? ()
#2  0x40644e01 in init_vertex_stage (ctx=0x805ba68, stage=0x81da6cc) at 
t_vb_vertex.c:286
#3  0x4060b704 in _tnl_run_pipeline (ctx=0x805ba68) at t_pipeline.c:155
#4  0x40653ddc in r200WrapRunPipeline (ctx=0x805ba68) at r200_state.c:2088
#5  0x40608eb5 in _tnl_run_cassette (ctx=0x805ba68, IM=0x81e14a0) at 
t_imm_exec.c:400
#6  0x405fe5f4 in execute_compiled_cassette (ctx=0x805ba68, 
data=0x81f372c) at t_imm_dlist.c:377
#7  0x404cd6a0 in execute_list (ctx=0x805ba68, list=1) at dlist.c:4218
#8  0x404d0556 in _mesa_CallList (list=1) at dlist.c:5095
#9  0x4055ac4a in neutral_CallList (i=1) at 
/mnt/hdc1/benutzer/src/dri/MESA-CVS/Mesa/src/vtxfmt_tmp.h:339
#10 0x0804cad7 in draw ()
#11 0x40030d55 in processWindowWorkList (window=0x64) at glut_event.c:1297
#12 0x4019a0bf in __libc_start_main () from /lib/libc.so.6
(gdb) quit
A debugging session is active.
Do you still want to close the debugger?(y or n) y
harkpabst [../MESA-CVS/Mesa/demos] $


Do you require backtraces from more different demos?

One other thing that might be worth noting:
Starting quake3.x86 from text console within gdb (switch to vt with 
C-M-F1, export DISPLAY=:0, gdb ./quake3.x86, run, c) does work with TCL 
disabled, for some reason.

I attached some info about my system (cpuinfo, compiler-version etc.)

Stefan

> -Brian
> 
> 



sysinfo.bz2
Description: Binary data

Re: [Dri-devel] Mesa 4.1 branch

[Keith Whitwell]

> hmm, that's odd. I still get floating point exceptions for almost every 
> GL-app. with TCL disabled.
> 
> Demos that _do_ work with TCL disabled include:
> clearspd, drawpix, gamma, glinfo, lodbias, readpix, winpos
> 
> Maybe this can give you a clue, why some are working and some aren't?
> 
> Could I have messed something up during checking 
> out/compiling/installing that is causing these FPE's?

Try running under gdb & posting a strack trace.  Note that there will be an 
initial fpe during sse detection -- this is normal and you have to hit 'c' to 
continue past it.

Keith



---
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Stefan Lange wrote:
> Brian Paul wrote:
>>
>> The merge is done.
>>
> 
> OK, so I just updated from CVS and recompiled.
> as expected: the speed problem in q3a is solved ;-)

Great.


>> Setting R200_NO_TCL works for me - no signals or FP exceptions.
>> However, with R200_NO_TCL I'm seeing some flashing/missing textures
>> in RTCW.
>>
> 
> 
> hmm, that's odd. I still get floating point exceptions for almost every 
> GL-app. with TCL disabled.
> 
> Demos that _do_ work with TCL disabled include:
> clearspd, drawpix, gamma, glinfo, lodbias, readpix, winpos
> 
> Maybe this can give you a clue, why some are working and some aren't?
> 
> Could I have messed something up during checking 
> out/compiling/installing that is causing these FPE's?

Can you run with gdb and find where the FP exception is happening?

-Brian




---
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Stefan Lange]

Brian Paul wrote:
> Brian Paul wrote:
> 
>> Stefan Lange wrote:
>>
>>> My experiences from testing:
>>>
>>> Wolfenstein (single-player): works, about same speed as dri-trunk, 
>>> but not completely stable (exited with Signal 4 in one run, and 
>>> Signal 11 in another, and once I got a complete lockup of the system)
>>>
>>> Q3A: stable (at least for the time I tested), but not very fast. In 
>>> fact it shows the same symptoms I got with earlier versions of 
>>> DRI-trunk (before around 2002-10-11): poor overall speed, and a 
>>> framerate that maxes out at 50 FPS. Is the r200-code in your branch 
>>> from before that date? If yes, that would explain the behaviour.
>>
>>
>> I made the branch on Oct 9.  I'll do a merge from the trunk in a bit.
>> Hopefully that'll clear up the speed problem.
> 
> 
> The merge is done.
> 

OK, so I just updated from CVS and recompiled.
as expected: the speed problem in q3a is solved ;-)


> 
>>> small stuff like gl-screensavers, mesa-demos seems to run fine
>>>
>>> one more thing: If I disable hardware-TCL (R200_NO_TCL=1), then some 
>>> GL-apps won't start ( Signal 8 / FPE ). At least q3a, wolfsp and 
>>> gears are affected, probably others too. Disabling hw-TCL does work 
>>> with current trunk-code for me.
>>
>>
>>
>> I'll test this after updating from the trunk.
> 
> 
> Setting R200_NO_TCL works for me - no signals or FP exceptions.
> However, with R200_NO_TCL I'm seeing some flashing/missing textures
> in RTCW.
>


hmm, that's odd. I still get floating point exceptions for almost every 
GL-app. with TCL disabled.

Demos that _do_ work with TCL disabled include:
clearspd, drawpix, gamma, glinfo, lodbias, readpix, winpos

Maybe this can give you a clue, why some are working and some aren't?

Could I have messed something up during checking 
out/compiling/installing that is causing these FPE's?

I attached the output of glxinfo, in case that's any helpful.

Regards, and thanks for your quick help and patience,
Stefan




> -Brian
> 
> 



glxinfo.bz2
Description: Binary data

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Brian Paul wrote:
> Stefan Lange wrote:
> 
>> My experiences from testing:
>>
>> Wolfenstein (single-player): works, about same speed as dri-trunk, but 
>> not completely stable (exited with Signal 4 in one run, and Signal 11 
>> in another, and once I got a complete lockup of the system)
>>
>> Q3A: stable (at least for the time I tested), but not very fast. In 
>> fact it shows the same symptoms I got with earlier versions of 
>> DRI-trunk (before around 2002-10-11): poor overall speed, and a 
>> framerate that maxes out at 50 FPS. Is the r200-code in your branch 
>> from before that date? If yes, that would explain the behaviour.
> 
> I made the branch on Oct 9.  I'll do a merge from the trunk in a bit.
> Hopefully that'll clear up the speed problem.

The merge is done.


>> small stuff like gl-screensavers, mesa-demos seems to run fine
>>
>> one more thing: If I disable hardware-TCL (R200_NO_TCL=1), then some 
>> GL-apps won't start ( Signal 8 / FPE ). At least q3a, wolfsp and gears 
>> are affected, probably others too. Disabling hw-TCL does work with 
>> current trunk-code for me.
> 
> 
> I'll test this after updating from the trunk.

Setting R200_NO_TCL works for me - no signals or FP exceptions.
However, with R200_NO_TCL I'm seeing some flashing/missing textures
in RTCW.

-Brian



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Stefan Lange]

Keith Whitwell wrote:
> Russ Dill wrote:
> 
>> On Tue, 2002-10-15 at 10:01, Stefan Lange wrote:
>>
>>
>>> Q3A: stable (at least for the time I tested), but not very fast. In 
>>> fact it shows the same symptoms I got with earlier versions of 
>>> DRI-trunk (before around 2002-10-11): poor overall speed, and a 
>>> framerate that maxes out at 50 FPS. Is the r200-code in your branch 
>>> from before that date? If yes, that would explain the behaviour.
>>>
>>
>> This speed problem is somehow related to displaying the players weapon,
>> or status. If you are playing q3a, and switch to free fly mode, the fps
>> jumps to around 100-250fps
> 
> 
> That makes sense.  The speed problem comes from agressively throttling 
> glClear() operations.  Q3 does multiple clears of the backbuffer for 
> drawing the little floating head and I don't know what else in the 
> status bar.  So, I expect the speed to go up after a trunk merge.
> 

I just checked, that's exactly the case: With "cg_drawStatus 0" I'll get 
 >50 FPS also with pre-October-11 code. It seems like those 
"on-screen-display" things are indeed causing this effect. Drawing or 
not drawing the gun doesn't make a change for me, however.

> Keith
> 
> 



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Keith Whitwell]

Russ Dill wrote:
> On Tue, 2002-10-15 at 10:01, Stefan Lange wrote:
> 
> 
>>Q3A: stable (at least for the time I tested), but not very fast. In fact 
>>it shows the same symptoms I got with earlier versions of DRI-trunk 
>>(before around 2002-10-11): poor overall speed, and a framerate that 
>>maxes out at 50 FPS. Is the r200-code in your branch from before that 
>>date? If yes, that would explain the behaviour.
>>
> 
> This speed problem is somehow related to displaying the players weapon,
> or status. If you are playing q3a, and switch to free fly mode, the fps
> jumps to around 100-250fps

That makes sense.  The speed problem comes from agressively throttling 
glClear() operations.  Q3 does multiple clears of the backbuffer for drawing 
the little floating head and I don't know what else in the status bar.  So, I 
expect the speed to go up after a trunk merge.

Keith



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Russ Dill]

On Tue, 2002-10-15 at 10:01, Stefan Lange wrote:

> Q3A: stable (at least for the time I tested), but not very fast. In fact 
> it shows the same symptoms I got with earlier versions of DRI-trunk 
> (before around 2002-10-11): poor overall speed, and a framerate that 
> maxes out at 50 FPS. Is the r200-code in your branch from before that 
> date? If yes, that would explain the behaviour.

This speed problem is somehow related to displaying the players weapon,
or status. If you are playing q3a, and switch to free fly mode, the fps
jumps to around 100-250fps



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Stefan Lange wrote:
> Brian Paul wrote:
> 
> [...]
> 
> I did some testing with the mesa-4-1-branch today on my r200. Compiling 
> was less trouble than I expected, everything was pretty much straight 
> forward ;-)
> 
>>
>> I'd appreciate it if people could start testing this branch, esp the
>> drivers I haven't tested.  One thing in particular to check is the
>> Mesa/demos/readpix program - make sure front/back buffer rendering is
>> working.  That's something that I've had to change in all the drivers.
>>
> 
> I don't know what exactly readpix is supposed to do, but I think it 
> works fine. Switching between front and backbuffer doesn't affect the 
> displayed pictures. The benchmark result is:
> 
> Benchmarking...
> Result:  325 reads in 4.009000 seconds = 2956697.430781 pixels/sec

If you saw the images in both front and back-buffer mode it's OK.
A blank window would indicate a problem.


> My experiences from testing:
> 
> Wolfenstein (single-player): works, about same speed as dri-trunk, but 
> not completely stable (exited with Signal 4 in one run, and Signal 11 in 
> another, and once I got a complete lockup of the system)
> 
> Q3A: stable (at least for the time I tested), but not very fast. In fact 
> it shows the same symptoms I got with earlier versions of DRI-trunk 
> (before around 2002-10-11): poor overall speed, and a framerate that 
> maxes out at 50 FPS. Is the r200-code in your branch from before that 
> date? If yes, that would explain the behaviour.

I made the branch on Oct 9.  I'll do a merge from the trunk in a bit.
Hopefully that'll clear up the speed problem.


> small stuff like gl-screensavers, mesa-demos seems to run fine
> 
> one more thing: If I disable hardware-TCL (R200_NO_TCL=1), then some 
> GL-apps won't start ( Signal 8 / FPE ). At least q3a, wolfsp and gears 
> are affected, probably others too. Disabling hw-TCL does work with 
> current trunk-code for me.

I'll test this after updating from the trunk.


> My system is a AMD 1800+ on a KT266A-mobo, with a Radeon 8500 QL, 
> linux-2.4.19, agpmode is set to 1, page-flipping is enabled

Thanks!

-Brian




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Stefan Lange]

Brian Paul wrote:

[...]

I did some testing with the mesa-4-1-branch today on my r200. Compiling 
was less trouble than I expected, everything was pretty much straight 
forward ;-)

> 
> I'd appreciate it if people could start testing this branch, esp the
> drivers I haven't tested.  One thing in particular to check is the
> Mesa/demos/readpix program - make sure front/back buffer rendering is
> working.  That's something that I've had to change in all the drivers.
> 

I don't know what exactly readpix is supposed to do, but I think it 
works fine. Switching between front and backbuffer doesn't affect the 
displayed pictures. The benchmark result is:

Benchmarking...
Result:  325 reads in 4.009000 seconds = 2956697.430781 pixels/sec


My experiences from testing:

Wolfenstein (single-player): works, about same speed as dri-trunk, but 
not completely stable (exited with Signal 4 in one run, and Signal 11 in 
another, and once I got a complete lockup of the system)

Q3A: stable (at least for the time I tested), but not very fast. In fact 
it shows the same symptoms I got with earlier versions of DRI-trunk 
(before around 2002-10-11): poor overall speed, and a framerate that 
maxes out at 50 FPS. Is the r200-code in your branch from before that 
date? If yes, that would explain the behaviour.

small stuff like gl-screensavers, mesa-demos seems to run fine

one more thing: If I disable hardware-TCL (R200_NO_TCL=1), then some 
GL-apps won't start ( Signal 8 / FPE ). At least q3a, wolfsp and gears 
are affected, probably others too. Disabling hw-TCL does work with 
current trunk-code for me.

My system is a AMD 1800+ on a KT266A-mobo, with a Radeon 8500 QL, 
linux-2.4.19, agpmode is set to 1, page-flipping is enabled

[...]

> -Brian
> 



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Brian Paul wrote:
> Brian Paul wrote:
> 
>> Brian Paul wrote:
>>
>>>
>>> I've created a new DRI branch: mesa-4-1-branch
>>>
>>> I'm in the process of porting all the DRI drivers to the new Mesa 4.1 
>>> code.
>>> I'll be checking in changes soon, but don't expect anything to run or 
>>> even
>>> compile.  I'll post again when I think it's usable.
>>
>>
>>
>> OK, it's compiling and the r200 driver seems to be working (though I
>> only ran a few Mesa demos so far).
>>
>> If you want to try the branch you'll need to check out a Mesa CVS trunk
>> tree and the DRI mesa-4-1-branch branch.  Edit xc/config/cf/host.def to
>> set the MesaSrcDir to point into the Mesa tree.
>>
>> Disclaimer: you're on your own if you try it and have trouble.  I've got
>> a lot of testing to do yet to iron out any obvious problems.
> 
> 
> 
> I've tested the radeon, r200 and tdfx drivers and they seem OK.
> 
> I can't test the i810, i830, r128, mga, etc drivers (either because I don't
> have the right hardware or mine's broke).  Some of the other drivers (like
> sis, ffb, etc) aren't enabled in the build process and haven't been ported.
> I'm not sure what the status of those drivers is.
> 
> I'd appreciate it if people could start testing this branch, esp the
> drivers I haven't tested.  One thing in particular to check is the
> Mesa/demos/readpix program - make sure front/back buffer rendering is
> working.  That's something that I've had to change in all the drivers.

Actually, I'm not done with this yet.  I've found more changes (simplifications)
to make to the glDraw/ReadBuffer code.  I should check it all in within a few
hours.

-Brian



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Keith Whitwell]

> I've tested the radeon, r200 and tdfx drivers and they seem OK.
> 
> I can't test the i810, i830, r128, mga, etc drivers (either because I don't
> have the right hardware or mine's broke).  Some of the other drivers (like
> sis, ffb, etc) aren't enabled in the build process and haven't been ported.
> I'm not sure what the status of those drivers is.

I've got most of these.  I'll have a test fest later on.  If I'm lucky I can 
do Ian's changes at the same time.

Keith



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Brian Paul wrote:
> Brian Paul wrote:
> 
>>
>> I've created a new DRI branch: mesa-4-1-branch
>>
>> I'm in the process of porting all the DRI drivers to the new Mesa 4.1 
>> code.
>> I'll be checking in changes soon, but don't expect anything to run or 
>> even
>> compile.  I'll post again when I think it's usable.
> 
> 
> OK, it's compiling and the r200 driver seems to be working (though I
> only ran a few Mesa demos so far).
> 
> If you want to try the branch you'll need to check out a Mesa CVS trunk
> tree and the DRI mesa-4-1-branch branch.  Edit xc/config/cf/host.def to
> set the MesaSrcDir to point into the Mesa tree.
> 
> Disclaimer: you're on your own if you try it and have trouble.  I've got
> a lot of testing to do yet to iron out any obvious problems.


I've tested the radeon, r200 and tdfx drivers and they seem OK.

I can't test the i810, i830, r128, mga, etc drivers (either because I don't
have the right hardware or mine's broke).  Some of the other drivers (like
sis, ffb, etc) aren't enabled in the build process and haven't been ported.
I'm not sure what the status of those drivers is.

I'd appreciate it if people could start testing this branch, esp the
drivers I haven't tested.  One thing in particular to check is the
Mesa/demos/readpix program - make sure front/back buffer rendering is
working.  That's something that I've had to change in all the drivers.

Anyone who's interested in the changes from Mesa 4.0.x to 4.1 should
read the Mesa-4.1/docs/RELNOTES-4.1 file.  It explains all the major
changes.

For porting DRI drivers, you can actually depend on the compiler to find
almost everything that needs updating.  Almost all of the significant
Mesa changes will trigger compilation errors - that makes it easy.

The only subtle thing to double-check is the DrawBuffer, ReadBuffer
and SetBuffer functions.  They work a bit differently now (simpler, actually).
This is covered in the RELNOTES-4.1 file.  It's pretty well commented in
the r200 driver too.

-Brian



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Michel Dänzer]

On Fre, 2002-10-11 at 00:54, Brian Paul wrote:
> Brian Paul wrote:
> > Michel Dänzer wrote:
> > 
> > OK, I see the problem now (on x86).  I'll see what I can do.
> 
> I've checked in the fix.

I saw your commit and tried it already. Great work!


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Brian Paul wrote:
> Michel Dänzer wrote:
> 
>> On Don, 2002-10-10 at 02:36, Brian Paul wrote:
>>
>>> Michel Dänzer wrote:
>>
> 
 And there are new endianness bugs. :/ The infamous gears pulsate 
 between
 the two states seen in
 http://penguinppc.org/~daenzer/DRI/gears-thick.png and
 http://www.penguinppc.org/~daenzer/DRI/gears-thin.png .
>>>
>>>
>>> Hmmm, PowerPC?
>>
>>
>>
>> Yep, always unless I state otherwise.
>>
>>
>>> It might be interesting to test stand-alone Mesa 4.1 since you're 
>>> software
>>> rendering.
>>
>>
>>
>> No, that's with direct rendering. With RADEON_NO_RAST it looks good.
> 
> 
> OK, I see the problem now (on x86).  I'll see what I can do.

I've checked in the fix.

-Brian




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Michel Dänzer wrote:
> On Don, 2002-10-10 at 02:36, Brian Paul wrote:
> 
>>Michel Dänzer wrote:

>>>And there are new endianness bugs. :/ The infamous gears pulsate between
>>>the two states seen in
>>>http://penguinppc.org/~daenzer/DRI/gears-thick.png and
>>>http://www.penguinppc.org/~daenzer/DRI/gears-thin.png .
>>
>>Hmmm, PowerPC?
> 
> 
> Yep, always unless I state otherwise.
> 
> 
>>It might be interesting to test stand-alone Mesa 4.1 since you're software
>>rendering.
> 
> 
> No, that's with direct rendering. With RADEON_NO_RAST it looks good.

OK, I see the problem now (on x86).  I'll see what I can do.

-Brian




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Michel Dänzer]

On Don, 2002-10-10 at 02:36, Brian Paul wrote:
> Michel Dänzer wrote:
> > On Don, 2002-10-10 at 01:31, Brian Paul wrote:
> > 
> > I only get direct rendering with the libGL from the branch, this happens
> > with the one from the trunk:

[...]

> Fixed. Do another CVS update of Mesa and the DRI.  CVS updates will be
> frequent so if something's not working, wait an hour, do an update and try
> again.

Okay, I thought this might be a non-obvious problem. Just ignore me when
I state the obvious. :)


> > And there are new endianness bugs. :/ The infamous gears pulsate between
> > the two states seen in
> > http://penguinppc.org/~daenzer/DRI/gears-thick.png and
> > http://www.penguinppc.org/~daenzer/DRI/gears-thin.png .
> 
> Hmmm, PowerPC?

Yep, always unless I state otherwise.

> It might be interesting to test stand-alone Mesa 4.1 since you're software
> rendering.

No, that's with direct rendering. With RADEON_NO_RAST it looks good.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Michel Dänzer wrote:
> On Don, 2002-10-10 at 01:31, Brian Paul wrote:
> 
>>I missed one check-in.  The gl.h file needed updating.  Try again.
> 
> 
> Builds now, thanks.
> 
> 
> I only get direct rendering with the libGL from the branch, this happens
> with the one from the trunk:
> 
> daenzer@tibook>
> LIBGL_DRIVERS_PATH=~/src/dri-cvs/xc-mesa-4-1/exports/lib/modules/dri
> LIBGL_DEBUG=verbose glxinfo
> name of display: :0.0
> libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0)
> libGL: OpenDriver: trying
> /home/michdaen/src/dri-cvs/xc-mesa-4-1/exports/lib/modules/dri/radeon_dri.so
> libGL error: dlopen
> /home/michdaen/src/dri-cvs/xc-mesa-4-1/exports/lib/modules/dri/radeon_dri.so failed
> libGL error: unable to find driver: radeon_dri.so
> libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0)
> libGL: OpenDriver: trying
> /home/michdaen/src/dri-cvs/xc-mesa-4-1/exports/lib/modules/dri/radeon_dri.so
> libGL error: dlopen
> /home/michdaen/src/dri-cvs/xc-mesa-4-1/exports/lib/modules/dri/radeon_dri.so failed
> libGL error: unable to find driver: radeon_dri.so
> display: :0  screen: 0
> direct rendering: No

Fixed. Do another CVS update of Mesa and the DRI.  CVS updates will be
frequent so if something's not working, wait an hour, do an update and try
again.


> And there are new endianness bugs. :/ The infamous gears pulsate between
> the two states seen in
> http://penguinppc.org/~daenzer/DRI/gears-thick.png and
> http://www.penguinppc.org/~daenzer/DRI/gears-thin.png .

Hmmm, PowerPC?

It might be interesting to test stand-alone Mesa 4.1 since you're software
rendering.

-Brian




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Michel Dänzer]

On Don, 2002-10-10 at 01:31, Brian Paul wrote:
> 
> I missed one check-in.  The gl.h file needed updating.  Try again.

Builds now, thanks.


I only get direct rendering with the libGL from the branch, this happens
with the one from the trunk:

daenzer@tibook>
LIBGL_DRIVERS_PATH=~/src/dri-cvs/xc-mesa-4-1/exports/lib/modules/dri
LIBGL_DEBUG=verbose glxinfo
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0)
libGL: OpenDriver: trying
/home/michdaen/src/dri-cvs/xc-mesa-4-1/exports/lib/modules/dri/radeon_dri.so
libGL error: dlopen
/home/michdaen/src/dri-cvs/xc-mesa-4-1/exports/lib/modules/dri/radeon_dri.so failed
libGL error: unable to find driver: radeon_dri.so
libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0)
libGL: OpenDriver: trying
/home/michdaen/src/dri-cvs/xc-mesa-4-1/exports/lib/modules/dri/radeon_dri.so
libGL error: dlopen
/home/michdaen/src/dri-cvs/xc-mesa-4-1/exports/lib/modules/dri/radeon_dri.so failed
libGL error: unable to find driver: radeon_dri.so
display: :0  screen: 0
direct rendering: No


And there are new endianness bugs. :/ The infamous gears pulsate between
the two states seen in
http://penguinppc.org/~daenzer/DRI/gears-thick.png and
http://www.penguinppc.org/~daenzer/DRI/gears-thin.png .


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Michel Dänzer wrote:
> On Don, 2002-10-10 at 00:42, Brian Paul wrote:
> 
>>Brian Paul wrote:
>>
>>>I've created a new DRI branch: mesa-4-1-branch
>>>
>>>I'm in the process of porting all the DRI drivers to the new Mesa 4.1 code.
>>>I'll be checking in changes soon, but don't expect anything to run or even
>>>compile.  I'll post again when I think it's usable.
>>
>>OK, it's compiling and the r200 driver seems to be working (though I
>>only ran a few Mesa demos so far).
>>
>>If you want to try the branch you'll need to check out a Mesa CVS trunk
>>tree and the DRI mesa-4-1-branch branch.  Edit xc/config/cf/host.def to
>>set the MesaSrcDir to point into the Mesa tree.
>>
>>Disclaimer: you're on your own if you try it and have trouble.  I've got
>>a lot of testing to do yet to iron out any obvious problems.
> 
> 
> I hope you don't mind feedback though; it fails to build here:
> 
> make[1]: Entering directory
> `/home/michdaen/src/dri-cvs/xc-mesa-4-1/lib/GL/glx'
> rm -f dispatch.o
> gcc -c -O2 -mcpu=7450  -ansi -Wall -Wpointer-arith -Wstrict-prototypes
> -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe 
> -I../../../exports/include-I../../../exports/include/X11
>   -I../../../include/extensions   -I../../../exports/include/GL
>   -I../../../lib/GL/glx   
> -I/home/michdaen/src/mesa-cvs/Mesa/src
>   -I/home/michdaen/src/mesa-cvs/Mesa/src/X
>   -I/home/michdaen/src/mesa-cvs/Mesa/src/
>   -I/home/michdaen/src/mesa-cvs/Mesa/include  
>-I../../../lib/GL/include
>   -I../../../lib/GL/dri  -I../../.. -I../../../exports/include
> -I/usr/local/X11R6-DRI.reinit/include  -Dlinux -D__powerpc__
> -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE
> -D_SVID_SOURCE  -D_GNU_SOURCE   -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS 
> -D_REENTRANT -DXUSE_MTSAFE_API-DGLXEXT -DXF86DRI
> -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA   -fPIC
> dispatch.c
> In file included from dispatch.c:67:
> /home/michdaen/src/mesa-cvs/Mesa/src/glapitemp.h:1907: conflicting types
> for `glTexImage3D'
> ../../../exports/include/GL/gl.h:1696: previous declaration of
> `glTexImage3D'
> 
> 
> Anything I'm doing wrong? Anything special I'm supposed to do with the
> Mesa tree?

I missed one check-in.  The gl.h file needed updating.  Try again.

-Brian




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Michel Dänzer]

On Don, 2002-10-10 at 00:42, Brian Paul wrote:
> Brian Paul wrote:
> > 
> > I've created a new DRI branch: mesa-4-1-branch
> > 
> > I'm in the process of porting all the DRI drivers to the new Mesa 4.1 code.
> > I'll be checking in changes soon, but don't expect anything to run or even
> > compile.  I'll post again when I think it's usable.
> 
> OK, it's compiling and the r200 driver seems to be working (though I
> only ran a few Mesa demos so far).
> 
> If you want to try the branch you'll need to check out a Mesa CVS trunk
> tree and the DRI mesa-4-1-branch branch.  Edit xc/config/cf/host.def to
> set the MesaSrcDir to point into the Mesa tree.
> 
> Disclaimer: you're on your own if you try it and have trouble.  I've got
> a lot of testing to do yet to iron out any obvious problems.

I hope you don't mind feedback though; it fails to build here:

make[1]: Entering directory
`/home/michdaen/src/dri-cvs/xc-mesa-4-1/lib/GL/glx'
rm -f dispatch.o
gcc -c -O2 -mcpu=7450  -ansi -Wall -Wpointer-arith -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe 
-I../../../exports/include  -I../../../exports/include/X11
-I../../../include/extensions   -I../../../exports/include/GL
-I../../../lib/GL/glx   
-I/home/michdaen/src/mesa-cvs/Mesa/src
-I/home/michdaen/src/mesa-cvs/Mesa/src/X
-I/home/michdaen/src/mesa-cvs/Mesa/src/
-I/home/michdaen/src/mesa-cvs/Mesa/include  
-I../../../lib/GL/include
-I../../../lib/GL/dri  -I../../.. -I../../../exports/include
-I/usr/local/X11R6-DRI.reinit/include  -Dlinux -D__powerpc__
-D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE
-D_SVID_SOURCE  -D_GNU_SOURCE   -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS 
-D_REENTRANT -DXUSE_MTSAFE_API-DGLXEXT -DXF86DRI
-DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA   -fPIC
dispatch.c
In file included from dispatch.c:67:
/home/michdaen/src/mesa-cvs/Mesa/src/glapitemp.h:1907: conflicting types
for `glTexImage3D'
../../../exports/include/GL/gl.h:1696: previous declaration of
`glTexImage3D'


Anything I'm doing wrong? Anything special I'm supposed to do with the
Mesa tree?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa 4.1 branch

[Brian Paul]

Brian Paul wrote:
> 
> I've created a new DRI branch: mesa-4-1-branch
> 
> I'm in the process of porting all the DRI drivers to the new Mesa 4.1 code.
> I'll be checking in changes soon, but don't expect anything to run or even
> compile.  I'll post again when I think it's usable.

OK, it's compiling and the r200 driver seems to be working (though I
only ran a few Mesa demos so far).

If you want to try the branch you'll need to check out a Mesa CVS trunk
tree and the DRI mesa-4-1-branch branch.  Edit xc/config/cf/host.def to
set the MesaSrcDir to point into the Mesa tree.

Disclaimer: you're on your own if you try it and have trouble.  I've got
a lot of testing to do yet to iron out any obvious problems.

-Brian



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel