Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)
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: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)
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)
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)
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)
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: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
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)
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: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)
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: [Dri-devel] mesa 4.1 branch
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
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 / NO go on 2.5.48
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
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
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
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
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
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 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
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
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
R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48)
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
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
Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
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
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 BoardNameATI Radeon 8500 QL BusID1: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://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
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
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
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
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
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
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
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 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
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 / NO go on 2.5.48
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
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 Screen color expansion Solid Lines Dashed Lines Scanline Image Writes Offscreen Pixmaps
Re: [Dri-devel] mesa 4.1 branch
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
[Dri-devel] Mesa 4.1 branch
I just wanted to say that the mesa 4.1 branch is looking quite nice. The visuals for Wolfenstein and others looks very nice on the r200. One thing that sems to effect most games that I've tried is that when you change resolution or hit alt enter it seems to turn everything this green color and I have to quit the app and start it back up to get things looking right. Even doing a /vid_restart in any quake3 based game will do it. --- 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 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
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 bytes. ==3729== ==3729== definitely lost: 584 bytes in 7 blocks. ==3729== possibly lost: 0 bytes in 0 blocks.
Re: [Dri-devel] mesa 4.1 branch
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 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
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
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
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
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
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
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
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
[Dri-devel] mesa 4.1 branch
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 --- 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 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
[Dri-devel] mesa 4.1 branch broken for now
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. -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?sunm0003en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa 4.1 branch
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 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
[...] 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
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
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
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
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
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
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
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
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
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
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 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
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
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
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 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
[Dri-devel] Mesa 4.1 branch
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. -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 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
Re: [Dri-devel] Mesa 4.1 branch
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
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 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
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
