Re: [Dri-devel] Mach64 Tuxracer doesn't work
Ok, I just downloaded a fresh build of the mach64 driver and TuxRacer works flawlessly. Here is my report on a few 3D apps I have on my system (a Compaq Armada E500 with a ATI Rage Mobility P/M AGP 2x (rev.100) TuxRacer: perfect GLTron: perfect Quake II: perfect Foobillard: perfect GL ScreenSavers: perfect Very good job ! What is the current plan for the driver ? DMA support ? What about integration with XFree86's driver for 2D acceleration ? Thanks again. Tristan I had problems with restoring using the install script because there is nothing in the GL directory, so you probably want to do the restore manually for now. BTW, I downloaded the package from Jose's site, but the one on dri.sf.net should be the same. --Leif On 25 Mar 2002, Tristan Tarrant wrote: I used mach64-20020325-0822-i386-Linux.tar.bz2 I have reverted to mach64-20020322-1223-i386-Linux.tar.bz2 Tristan Il lun, 2002-03-25 alle 16:42, Leif Delgass ha scritto: That sounds like what we were seeing before Jose's fix for depth scaling. Which snapshot are you using? -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 Tuxracer doesn't work
Quake II: perfect Wow! What is your resolution? What are fps? How much memory does your card have? Half-Life in 640x480 (under Wine though) is really unplayable for me...:( Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] freezes with r128
Hi! Since several weeks/months, running an opengl app (epsxe, quake3) sometimes completely locks up the machine. It is not easily reproducible, about 5 times it works and then suddenly the 6th time it locks up in the same situation. It happens just before a new screen is being created (with epsxe when the program finishes loading and the anti piracy thingy should appear, with q3 when it finishes loading and the arena should appear). There aren't any warnings/kernel panics, it simply locks up, stops responding to pings etc. Everything else is stable (I watch a lot of divx with aviplay). I have rh7.2, 2.4.18-pre4 kernel, alsa 0.9beta12, xf86 4.2.0, dri-cvs from today and gatos-cvs from today, everything self compiled. ECS K7S5A, Duron900, 192MB RAM. I'll try a newer kernel and then xf86 cvs, but perhaps someone met this behaviour before... Bye, Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- NT, now approaching 23x6 availability. msg03611/pgp0.pgp Description: PGP signature
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
Keith Whitwell wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ Changes by: keithw@usw-pr-cvs1. 02/03/25 02:29:12 Log message: support for new radeon packets Modified files: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: Tag: tcl-0-0-branch Imakefile drm.h radeon_cp.c radeon_drm.h radeon_drv.c radeon_drv.h radeon_state.c Revision ChangesPath 1.5.10.1 +7 -0 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Imakefile 1.35.2.2 +1 -0 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h 1.20.2.3 +12 -92 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_cp.c 1.9.2.4 +15 -13 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_drm.h 1.13.2.2 +2 -1 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_drv.c 1.13.2.4 +5 -12 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_drv.h 1.12.2.8 +185 -159 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c Keith, Nice work. I'll assume we don't need to bump the minor number since version 1.3 hasn't been released to the kernel group, yet. I will add your log message to the interface history comment at the top of radeon_drv.c. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
Jens Owen wrote: Keith Whitwell wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ Changes by: keithw@usw-pr-cvs1. 02/03/25 02:29:12 Log message: support for new radeon packets Modified files: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: Tag: tcl-0-0-branch Imakefile drm.h radeon_cp.c radeon_drm.h radeon_drv.c radeon_drv.h radeon_state.c Revision ChangesPath 1.5.10.1 +7 -0 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Imakefile 1.35.2.2 +1 -0 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h 1.20.2.3 +12 -92 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_cp.c 1.9.2.4 +15 -13 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_drm.h 1.13.2.2 +2 -1 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_drv.c 1.13.2.4 +5 -12 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_drv.h 1.12.2.8 +185 -159 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c Keith, Nice work. I'll assume we don't need to bump the minor number since version 1.3 hasn't been released to the kernel group, yet. I will add your log message to the interface history comment at the top of radeon_drv.c. Yes, that was my thinking. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 not quite perfect yet, was: Mach64 Tuxracer doesn't work
Hi, GL ScreenSavers: perfect Not quite! The pipe demo shows only one segment of the pipe at a time. I never see the whole pipe. I'm using xscreensaver 3.34-1.1 (Debian woody). I also tried the OpenGL Tutorials by Nate Robins from http://www.xmission.com/~nate/tutors.html. When I start it the second or later time after a fresh Xserver start it doesn't fill the entire window. I can see through in the bottom of the window of, e.g. the fog tutorial and where there should be the grey background. When redrawing certain parts like the top left torus in the lightmaterial tutor the window isn't cleared first. I tried recompiling them with the correct include and library paths (/usr/X11R6-mach64003/... for me) without effect. And one more thing, when I use Vertex Lighting (without multi texture) in Quake3 the textures are not interpolated correctly. They are only when I view them in a very steep angle. BTW, all this used to work with the 0-0-2-branch. My current Xserver and DRI is the latest CVS checkout from the mach64-0-0-3 branch, self compiled. Finally the smoke of the rockets in Quake3 ist much too dense (same as mach64-0-0-2). I hope this is not too much at once. I don't want to sound too negative. You're doing great work on the mach64 branch. Thanks! Best regards, Felix Kühling __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 not quite perfect yet, was: Mach64 Tuxracerdoesn't work
On Tue, 26 Mar 2002, Felix Kühling wrote: Hi, GL ScreenSavers: perfect Not quite! The pipe demo shows only one segment of the pipe at a time. I never see the whole pipe. I'm using xscreensaver 3.34-1.1 (Debian woody). I see problems here too. It looks like it's using fallback for the draw buffer, but I can't imagine why it would need stereo (which should be the only fallback, I think). I'll look into it. I also tried the OpenGL Tutorials by Nate Robins from http://www.xmission.com/~nate/tutors.html. When I start it the second or later time after a fresh Xserver start it doesn't fill the entire window. I can see through in the bottom of the window of, e.g. the fog tutorial and where there should be the grey background. When redrawing certain parts like the top left torus in the lightmaterial tutor the window isn't cleared first. I tried recompiling them with the correct include and library paths (/usr/X11R6-mach64003/... for me) without effect. hmm. I can't reproduce this one. The drawing areas of the fog tutorial are briefly transparent when starting up, but is cleared to gray ok for me. When you say the second time, does that mean that the first time you run the tutorial it looks ok? And one more thing, when I use Vertex Lighting (without multi texture) in Quake3 the textures are not interpolated correctly. They are only when I view them in a very steep angle. I also can't reproduce this one. Does Lightmap Lighting look ok? What is the visual effect that you are seeing? Are textures missing, or being repeated/wrapped when they shouldn't, etc.? Is it on all maps, or just some of them? BTW, all this used to work with the 0-0-2-branch. My current Xserver and DRI is the latest CVS checkout from the mach64-0-0-3 branch, self compiled. The last cvs update was about 2 days ago, have you recompiled since then? Also, have you recompiled the drm module recently as well? Finally the smoke of the rockets in Quake3 ist much too dense (same as mach64-0-0-2). I hope this is not too much at once. I don't want to sound too negative. You're doing great work on the mach64 branch. Thanks! No problem, all bug reports are welcome! Best regards, Felix Kühling __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 not quite perfect yet, was: Mach64 Tuxracerdoesn't work
On Tue, 26 Mar 2002, Felix Kühling wrote: Finally the smoke of the rockets in Quake3 ist much too dense (same as mach64-0-0-2). I forgot to mention this: the opaque smoke is fixed in recent point releases of Quake3. You should see something like HACK: RagePro approximations in the log if it's in your version. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 not quite perfect yet, was: Mach64 Tuxracer doesn't work
Hi, I also tried the OpenGL Tutorials by Nate Robins from http://www.xmission.com/~nate/tutors.html. When I start it the second or later time after a fresh Xserver start it doesn't fill the entire window. I can see through in the bottom of the window of, e.g. the fog tutorial and where there should be the grey background. When redrawing certain parts like the top left torus in the lightmaterial tutor the window isn't cleared first. I tried recompiling them with the correct include and library paths (/usr/X11R6-mach64003/... for me) without effect. hmm. I can't reproduce this one. The drawing areas of the fog tutorial are briefly transparent when starting up, but is cleared to gray ok for me. When you say the second time, does that mean that the first time you run the tutorial it looks ok? Not really, but at least the window is not transparent. There are still those redrawing problems. And one more thing, when I use Vertex Lighting (without multi texture) in Quake3 the textures are not interpolated correctly. They are only when I view them in a very steep angle. I also can't reproduce this one. Does Lightmap Lighting look ok? What is the visual effect that you are seeing? Are textures missing, or being repeated/wrapped when they shouldn't, etc.? Is it on all maps, or just some of them? All textures are in place but they are blocky (if they are close). With lightmap the textures look fine. I see the problem when I stand as close to a wall as possible. When I look at it perpendicularly the texture is interpolated. When turn the texture becomes blocky. First in greater distance then also closer. The menus of Quake3 are blocky, too. The last cvs update was about 2 days ago, have you recompiled since then? Also, have you recompiled the drm module recently as well? Yes, I recompiled five minutes before I wrote the last mail ;-) including the kernel module. I also made sure that I was using the latest module. I compiled with MesaUse3DNow YES. Maybe I should try it without once. Some Hardware info, maybe it helps to reproduce the problems somewhere else. lspci -vv outputs: 01:00.0 VGA compatible controller: ATI Technologies Inc Rage XL AGP (rev 27) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0008 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 10 Region 0: Memory at d400 (32-bit, non-prefetchable) [size=16M] Region 1: I/O ports at 9000 [size=256] Region 2: Memory at d600 (32-bit, non-prefetchable) [size=4K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [50] AGP version 1.0 Status: RQ=255 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x1 Capabilities: [5c] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- The card is an Ati Xpert 98. I guess I'm the only one using this driver on a desktop machine ;-). Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] xscreensaver and Mach64
On Tue, 26 Mar 2002, Leif Delgass wrote: On Tue, 26 Mar 2002, Felix Kühling wrote: Hi, GL ScreenSavers: perfect Not quite! The pipe demo shows only one segment of the pipe at a time. I never see the whole pipe. I'm using xscreensaver 3.34-1.1 (Debian woody). I see problems here too. It looks like it's using fallback for the draw buffer, but I can't imagine why it would need stereo (which should be the only fallback, I think). I'll look into it. Well, the short answer for this one is: upgrade xscreensaver. ;) I just downloaded 4.02 and pipes works fine in both single- and double-buffered mode. I still suspect the problem might have something to so with the draw buffers, but I noticed this problem on Rage 128 (built from the mach64 branch, not CVS head) as well. I ran through all the gl screensavers, and everything else worked except glplanet which exits with texture error: invalid value. Turns out the problem is that the planet texture (512x256) was larger than the max texture size (512x512). So I borrowed some code from r128 to set the MaxTextureLevels (which determines the max size), based on the on-card memory. Here's the current breakdown: on-card texHeap MaxTextureLevels GL_MAX_TEXTURE_SIZE --- --- heap 2MB9 256 2MB = heap 8MB 10512 heap = 8MB 111024 -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] xscreensaver and Mach64
On Tue, 26 Mar 2002, Leif Delgass wrote: On Tue, 26 Mar 2002, Leif Delgass wrote: On Tue, 26 Mar 2002, Felix Kühling wrote: Hi, GL ScreenSavers: perfect Not quite! The pipe demo shows only one segment of the pipe at a time. I never see the whole pipe. I'm using xscreensaver 3.34-1.1 (Debian woody). I see problems here too. It looks like it's using fallback for the draw buffer, but I can't imagine why it would need stereo (which should be the only fallback, I think). I'll look into it. Well, the short answer for this one is: upgrade xscreensaver. ;) I just downloaded 4.02 and pipes works fine in both single- and double-buffered mode. I still suspect the problem might have something to so with the draw buffers, but I noticed this problem on Rage 128 (built from the mach64 branch, not CVS head) as well. I ran through all the gl screensavers, and everything else worked except glplanet which exits with texture error: invalid value. Turns out the problem is that the planet texture (512x256) was larger than the max texture size (512x512) oops, I meant to say the max texture size was 256x256. I now get 512x512 max (I have an 8MB card). -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Restoring DRM Library Device Independence
On Mon, Mar 18, 2002, Alan Hourihane wrote: On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote: I would like to move the device dependent functionality currently included in the drm library back into the device driver layer. My objective is to make sure new driver suites can be independently released without stepping on any components needed by other driver suites. Currently, libdrm contains a mixture of device independent code and multiple device dependent routines. I'm looking for a clean way to split this functionality and restore libdrm device independent, while still providing a mechanism for device specific IOCTL style support directly in device drivers. Could we simply add a drmIOCTL entry point to the DRM library? Then, the packing and unpacking could be done in the drivers. The Linux and BSD implementations would simply wrap the standard IOCTL and future OS ports of the DRI would have a layer, if needed, for emulating an IOCTL. Jens, This is definately a problem that needs sorting out. We certainly need to put the driver specific calls into the 2D ddx portion, and abstract some form of drmIOCTL for the os-support routines. Please go ahead, and I'll certainly help out with this. Alan, I've made some headway on this today, and could use some feedback based on your BSD experience. I've attempted to move the packing of drmRadeonInitCP into the 2D ddx driver, and the main concern I'm seeing is the actual IOCTL request number. I can easily use the Linux number, but I thought it might be better to have some OS independent offset. However, generating all the combinations of _IO, _IOR, _IOW and _IOWR semantics in an OS independent way is going to be challenging. See xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h:line 373 Here is an incomplete patch in case you are interested in the general direction I was currently prototyping... Should I just use the Linux _IO* semantics and let other OS ports twizzle this to get this working, or do you have any ideas on how we can generate the proper semantics in a more general way. I think we will need to generate these semantics at run time, not compile time. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] freezes with r128
On Tue, Mar 26, 2002 at 10:34:10PM +0100, Felix Khling wrote: Hi, hi I had a problem with DRI locking up hard with a Matrox G200 when I compiled the DRM into the kernel statically. Since I made it a module everything works fine. I do have it as a module :-(. Regards, Felix Khling Mit freundlichen Gren Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- Hello, this is Bill Gates and I pronounce Monopoly, er, Windows as Windows. msg03622/pgp0.pgp Description: PGP signature
