Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton: > On Tue, 19 Nov 2002 20:50:50 +0100 > > Dieter Nützel <[EMAIL PROTECTED]> wrote: > > > Thats my birthday! :) > > > > Hey, mine comes first :-) > > > > Hopefully with Mesa-5.x. > > Going into mesa-4-1-branch testing mode, now. > > > > Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do > > some testing. No go so far. Modules are somewhat broken in 2.5.48. I saw radeon 1.7.0 20020828 but no go, yet ;-( [drm] Initialized radeon 1.7.0 20020828 on minor 0 [drm:radeon_unlock] *ERROR* Process 1016 using kernel context 0 Linux agpgart interface v0.99 (c) Jeff Hartmann driver pci:agpgart: registering kobject agpgart: registering bus pci: add driver agpgart agpgart: Maximum main memory to use for agp memory: 816M agpgart: Detected AMD 760MP chipset agpgart: AGP aperture is 64M @ 0xe800 bound device '00:00.0' to driver 'agpgart' [drm:radeon_unlock] *ERROR* Process 1687 using kernel context 0 /home/nuetzel> cat /proc/dri/0/* a dev piduid magic ioctls total counts |outstanding type alloc freed fail bytes freed | allocs bytes system0 001035148 kB | locked0 00 0 kB | dmabufs 0 00 0 0 | 0 0 sareas0 00 0 0 | 0 0 driver8 80 6150 6150 | 0 0 magic 0 00 0 0 | 0 0 ioctltab 0 00 0 0 | 0 0 maplist 13120196192 | 1 4 vmalist 2 20 24 24 | 0 0 buflist 0 00 0 0 | 0 0 seglist 0 00 0 0 | 0 0 pagelist 0 00 0 0 | 0 0 files 4 40160160 | 0 0 queues0 00 0 0 | 0 0 commands 0 00 0 0 | 0 0 mappings 2 20 134217728 134217728 | 0 0 buflists 0 00 0 0 | 0 0 agplist 0 00 0 0 | 0 0 totalagp 0 00 0 0 | 0 0 boundagp 0 00 0 0 | 0 0 ctxbitmap 1 00 4096 0 | 1 4096 stub 1 00192 0 | 1192 radeon 0xe200 ctx/flags use fin blk/rw/rwf waitflushed queued locks slot offset size type flagsaddress mtrr vma use count: 0, high_memory = f800, 0x3800 II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor="The XFree86 Project" compiled for 4.2.99.2, module version = 1.1.0 ABI class: XFree86 Video Driver, version 0.6 (**) RADEON(0): Using AGP 4x mode (**) RADEON(0): Enabling AGP Fast Write (II) RADEON(0): Depth moves disabled by default (II) Loading sub module "shadow" (II) LoadModule: "shadow" (II) Loading /usr/X11R6/lib/modules/libshadow.a (II) Module shadow: vendor="The XFree86 Project" compiled for 4.2.99.2, module version = 1.0.0 ABI class: XFree86 ANSI C Emulation, version 0.1 (II) RADEON(0): Page flipping enabled (!!) RADEON(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (--) Depth 24 pixmap format is 32 bpp (==) RADEON(0): Write-combining range (0xe000,0x400) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:5:0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf90dc000 (II) RADEON(0): [drm] mapped SAREA 0xf90dc000 to 0x40015000 (II) RADEON(0): [drm] framebuffer handle = 0xe000 (II) RADEON(0): [drm] added 1 reserved context for kernel (WW) RADEON(0): [agp] AGP not available (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xf90dc000 at 0x40015000 (II) RADEON(0): Memory manager initialized to (0,0) (1280,8191) (II) RADEON(0): Reserved area from (0,1024) to (1280,1026) (II) RADEON(0): Largest offscreen area available: 1280 x 7165 (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indir
Re: [Dri-devel] mesa 4.1 branch / 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 Scree
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
On 20 Nov 2002, Alan Cox wrote: > > Are you using scsi - any measuable amount of scsi I/O also hangs 2.5.48 > 8( Only for you, Alan, only for you. I've got SCSI at home, so it must be some specific controller driver being broken rather than general breakage. Linus --- This sf.net email is sponsored by: Battle your brains against the best in the Thawte Crypto Challenge. Be the first to crack the code - register now: http://www.gothawte.com/rd521.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
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
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" BoardName"ATI Radeon 8500 QL" BusID"1:5:0" Driver "radeon" Identifier "Device[0]" Option "AGPMode" "4" Option "AGPFastWrite" "1" Option "EnablePageflip" Option "dpms" Screen 0 VendorName "ATI" EndSection When your machine is Right (TM) configured it should scream :-) -Dieter PS What do "cat /proc/dri/0/*" show? --- This SF.net email is sponsored by: The Sourceforge Network Survey Take Our Survey and You Could Win a $500 Gift Certificate! http://ugamsolutions.com/psurvey/osdn/SourceForge/index_sourceforge.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https:/
Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
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 / 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
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: 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)
> > > > http://memory.visualtech.com/glaxium.png > > > > Unfortunately, it doesn't look like the patch worked :-( > > I'm not sure what it's supposed to look like. Can you try software > rendering, just to get a screen-shot.? > > -Brian > > I'm happy to see that my game is usefull for serious people ;-) You can get screenshots at glaxium web site : http://xhosxe.free.fr/glaxium Quick link: http://xhosxe.free.fr/glaxium/shot05_6.jpg On the floor the bumpmap is calculated with the light position set equal to the main spaceship...See screen shot above. GL_EXT_texture_env_combine is used to merge the 3D bumpmap effect with a flat texture. Xavier --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48)
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: 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 11:57:32AM -0500, Adam K Kirchhoff wrote: > > > > Unfortunately, that only seemed to make things worse. If you check out > > the same URL I posted above, you'll see what I mean. > > Hmm...could you try two quick tests for me? Both would be with an unpatched > driver. > > 1. Try running with LIBGL_ALWAYS_INDIRECT=1. I expect that will produce the > same results I see on a Radeon M6. http://memory.visualtech.com/glaxium.png I do believe that's what the game is supposed to look like :-) > 2. Replace GL_DOT3_RGB_EXT on line 592 of scene.cpp (in glaxium 0.5) with > GL_DOT3_RGB and rebuild glaxium. If that doesn't work, then dot3 > bumpmapping is totally hosed in the R200 driver. I expect that this will > also produce correct results. Hmmm... Well, line 592 of scene.cpp (in glaxium 0.5, just downloaded from the website) seems to be: glEnable(GL_TEXTURE_2D); Line 586, though, makes reference to GL_DOT3_RGB_EXT. I've made the change there. Now, with the unpatched driver and the patched game, the results look exactly look they did with the patched driver and the unpatched game! Adam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48)
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
