Re: [Dri-devel] mach64 (Rage XL) trouble
On 2002.05.01 23:43 Kees Cook wrote: Hello! I've finally had a chance to upgrade to XFree86 4.2.0, and am trying out the bleeding edge builds for mach64. :) Quick version: it doesn't work. Long version: I think I have an AGP problem. glxinfo reports that direct rendering is off. the mach64 kernel driver compiled and is loaded, but agpgart errors out: mtrr: Serverworks LE detected. Write-combining disabled. mtrr: your processor doesn't support write-combining Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 816M agpgart: unable to determine aperture size. [drm] Initialized mach64 1.0.0 20010107 on minor 0 the drm and things were built from (against stock kernel 2.4.18): mach64-20020427-linux.i386.tar.bz2 Nothing very interesting happens in XFree86.log either. Couldn't find anything useful about the agpgart error either. I'm at a loss! (And unfortunately, the ati driver is REALLY slow for just regular 2D stuff. I can watch things repaint, etc. Wasn't like that in XFree86 4.1.0...) Yep. This is nothing related with AGP, and will not change in the immediate future as currently we can't handle simultaneous 2D and 3D acceleration. (Note that this isn't related to 4.2.0 too, just with the mach64 snapshots) If you need 2D performance, don't forget you can uninstall the snapshot at any time by running ./install.sh restore. What should I do next? You have two options. One is disable AGP which isn't required (and hardly used) at the moment (if have to recompile the kernel for having agpgart as a module since we don't have an option to control that yet); but I strongly advise you to also try to figure out what may be wrong with your AGP device. Things you could do are determine which your AGP chip and search for troubleshouting info on the web about it. Jeff Hartman still hangs around this list and perhaps he may be of some help in that matter. Jose Fonseca ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: mach64 (Rage XL) trouble
On Wed, 1 May 2002, Kees Cook wrote: I've finally had a chance to upgrade to XFree86 4.2.0, and am trying out the bleeding edge builds for mach64. :) Quick version: it doesn't work. Long version: I think I have an AGP problem. glxinfo reports that direct rendering is off. the mach64 kernel driver compiled and is loaded, but agpgart errors out: mtrr: Serverworks LE detected. Write-combining disabled. ^^ Ick. Problem #1 mtrr: your processor doesn't support write-combining Problem #2 I'm at a loss! (And unfortunately, the ati driver is REALLY slow for just regular 2D stuff. I can watch things repaint, etc. Wasn't like that in XFree86 4.1.0...) Yep, you're not likely to see it get any better either unfortunately. Serverworks chipsets have an off by one problem in hardware with MTRR being used (if I've got the story I was told by Alan Cox correct), and as such MTRR is not available as it is purposefully disabled to prevent data corruption. That significantly slows down graphics. Also... AGP on Serverworks _sucks_. I strongly recommend against using Serverworks chipsets for any machines used for graphics. Server being the operative word for the chipset. ;o) If they were called Graphicsworks perhaps it would work better. ;o) What should I do next? Replace the motherboard with a chipset that has a working AGP implementation which both works, and is fast, and also has working MTRR support. Using Radeon with DRI on my Serverworks boards, with dual 1Ghz P-III Xeon CPU's, and 1Gb of RAM, I can watch the screen paint from top to bottom when switching windows - it takes about 1 second to paint the screen. This is in my case due to the Radeon CP engine 2D acceleration not accelerating everything it does in MMIO mode. That latter part wont affect you on Mach64 though likely. Bad news.. ;o( -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 (Rage XL) trouble
On Thu, May 02, 2002 at 06:13:39PM +0100, José Fonseca wrote: Kees, perhaps I didn't stress this enough but, spite of your motherboard shortcomings, you should be able to achieve a reasonable 3D acceleration, as is. Ah, perhaps I misunderstood. I got the impression that even if I got good 3D, the 2D would still be as slow as I saw it (repainting, etc). Since I use this machine as my desktop, it's the 2D that's most important. 3D is a bonus, and I'd like to help test, but not at the cost of reasonable 2D performance. -- Kees Cook@outflux.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 1 Minute Mortgage 582919141198765544433333
Mortgage Rates are at an all time low. We canfind ANYONE with ANY CREDIT (great or horrible) the lowest and most competitive rates. Simple takes under 1 minute. TRY NOW 58291914119876554443 ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 (Rage XL) trouble
On 2002.05.02 18:19 Kees Cook wrote: On Thu, May 02, 2002 at 06:13:39PM +0100, José Fonseca wrote: Kees, perhaps I didn't stress this enough but, spite of your motherboard shortcomings, you should be able to achieve a reasonable 3D acceleration, as is. Ah, perhaps I misunderstood. I got the impression that even if I got good 3D, the 2D would still be as slow as I saw it (repainting, etc). Since I use this machine as my desktop, it's the 2D that's most important. 3D is a bonus, and I'd like to help test, but not at the cost of reasonable 2D performance. You did got it right, but nothing prevents you from installing uninstalling the snapshot drivers for specific purposes (such as playing a game). I believe this is true for most people. I, for example, can't even have 3D with more than 640x480 since I just have 4MB memory. So, except for development, I use it for a playing a couple of games. Anyway, I believe that in two months we could have most of these limitations sorted out. José Fonseca ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 (Rage XL) trouble
On Thu, 2002-05-02 at 20:04, José Fonseca wrote: On 2002.05.02 18:19 Kees Cook wrote: On Thu, May 02, 2002 at 06:13:39PM +0100, José Fonseca wrote: Kees, perhaps I didn't stress this enough but, spite of your motherboard shortcomings, you should be able to achieve a reasonable 3D acceleration, as is. Ah, perhaps I misunderstood. I got the impression that even if I got good 3D, the 2D would still be as slow as I saw it (repainting, etc). Since I use this machine as my desktop, it's the 2D that's most important. 3D is a bonus, and I'd like to help test, but not at the cost of reasonable 2D performance. You did got it right, but nothing prevents you from installing uninstalling the snapshot drivers for specific purposes (such as playing a game). Uninstall? Just run it without DRI... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 (Rage XL) trouble
On 2 May 2002, Michel Dänzer wrote: On Thu, 2002-05-02 at 20:04, José Fonseca wrote: On 2002.05.02 18:19 Kees Cook wrote: On Thu, May 02, 2002 at 06:13:39PM +0100, José Fonseca wrote: Kees, perhaps I didn't stress this enough but, spite of your motherboard shortcomings, you should be able to achieve a reasonable 3D acceleration, as is. Ah, perhaps I misunderstood. I got the impression that even if I got good 3D, the 2D would still be as slow as I saw it (repainting, etc). Since I use this machine as my desktop, it's the 2D that's most important. 3D is a bonus, and I'd like to help test, but not at the cost of reasonable 2D performance. You did got it right, but nothing prevents you from installing uninstalling the snapshot drivers for specific purposes (such as playing a game). Uninstall? Just run it without DRI... Actually, at the moment 2D accel is disabled at compile time. This is easy to fix though, we can just check pATI-directRenderingEnabled, because it's already determined by the time we get to ATIMach64AccelInit. -- Leif Delgass http://www.retinalburn.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Hi Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in CVS now. Just update and rebuild and install the kernel module. This is not related to your original problem though, I'm not sure what would be causing a lockup on vt switches if no GL contexts are running. I really don't know but... Well, it works now (snapshot 0502). No OOPS detected. In my syslog I see: May 2 20:31:23 localhost kernel: [drm] Creating pci pool May 2 20:31:23 localhost kernel: [drm] Allocating descriptor table memory May 2 20:31:23 localhost kernel: [drm] descriptor table: cpu addr: 0xc08a4000, bus addr: 0x008a4000 May 2 20:31:23 localhost kernel: [drm] Starting DMA test... May 2 20:31:23 localhost kernel: [drm] starting DMA transfer... May 2 20:31:23 localhost kernel: [drm] waiting for idle... May 2 20:31:23 localhost kernel: [drm] waiting for idle...done May 2 20:31:23 localhost kernel: [drm] DMA test succeeded, using synchronous DMA mode Does it mean DMA works for me? AFAIK it does. BTW, does synchronous mean there will be asynchronous somewhere?:) About FPS - they are still lower than in good old user-mode MMIO... (241 vs 286 in 0-0-3). But DMA is already enabled - does this mean I will never get anything better? Well, glxgears works OK. So does Counter-Strike. As usual, in texture-intensive apps (celestia) we are waiting for GART... Anyway, thanks for fast fix. Cheers, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
On 2 May 2002, Sergey V. Udaltsov wrote: Hi Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in CVS now. Just update and rebuild and install the kernel module. This is not related to your original problem though, I'm not sure what would be causing a lockup on vt switches if no GL contexts are running. I really don't know but... Well, it works now (snapshot 0502). No OOPS detected. In my syslog I see: May 2 20:31:23 localhost kernel: [drm] Creating pci pool May 2 20:31:23 localhost kernel: [drm] Allocating descriptor table memory May 2 20:31:23 localhost kernel: [drm] descriptor table: cpu addr: 0xc08a4000, bus addr: 0x008a4000 May 2 20:31:23 localhost kernel: [drm] Starting DMA test... May 2 20:31:23 localhost kernel: [drm] starting DMA transfer... May 2 20:31:23 localhost kernel: [drm] waiting for idle... May 2 20:31:23 localhost kernel: [drm] waiting for idle...done May 2 20:31:23 localhost kernel: [drm] DMA test succeeded, using synchronous DMA mode Does it mean DMA works for me? AFAIK it does. BTW, does synchronous mean there will be asynchronous somewhere?:) Yes, that's the goal. Synchronous DMA means that we wait for the card to idle after submitting each DMA pass, rather than going on to do other things and polling or handling interrupts to check for completion of the DMA transfer. Synchronous operation isn't meant to be fast, it's just a first step in testing that we are submitting the DMA pass correctly. About FPS - they are still lower than in good old user-mode MMIO... (241 vs 286 in 0-0-3). But DMA is already enabled - does this mean I will never get anything better? see above. Well, glxgears works OK. So does Counter-Strike. As usual, in texture-intensive apps (celestia) we are waiting for GART... We'll get there eventually. ;) I don't think AGP textures will be too hard to add once we get there. We're already allocating a region of the AGP aperture for textures, but the implementation of using it isn't done yet. Anyway, thanks for fast fix. Sure. Let us know if you experience a lockup again. There will be some big changes coming in the drm in 0-0-4 soon, so it's likely to be a bit unstable for a while. -- Leif Delgass http://www.retinalburn.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Yes, that's the goal. Synchronous DMA means that we wait for the card to idle after submitting each DMA pass, rather than going on to do other things and polling or handling interrupts to check for completion of the DMA transfer. Synchronous operation isn't meant to be fast, it's just a first step in testing that we are submitting the DMA pass correctly. That's exactly what I thought. Good, I am not that dumb... Probably eventually I'll grow smart enough to join the team:) Any estimations on speedup we'll get in glxgears? Sure. Let us know if you experience a lockup again. There will be some big changes coming in the drm in 0-0-4 soon, so it's likely to be a bit unstable for a while. COOL. My laptop is eager to be crashed by new snapshots. Just announce GART or asynchronous DMA - and it is yours. BTW, it was mentioned it was easy to enable 2D acceleration back. Is it true? Can it be done in snapshots (by checking this illustrious pATI-directRenderingEnabled). So people could use snapshot drivers in everyday life - without restarting X... Also, just one question - if I set in XF86Config Modes 1280x1024 800x600 - could I have DRI enabled in 800x600 (switching by Alt+Gr-) - though I don't have enough video RAM for 1280x1024? Cheers, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
On Wed, 2002-05-01 at 19:30, Peter Andersson wrote: Michael, have you got hold of the screenshot or would you like me to re send it to you? I've seen it now, thanks. I realized that Doom was an 8 bit game, does prboom use 8 bit textures? That would explain how the columns get swapped. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
On Fri, May 03, 2002 at 01:14:21AM +0200, Peter Andersson wrote: Michel Dänzer wrote: On Wed, 2002-05-01 at 19:30, Peter Andersson wrote: Michael, have you got hold of the screenshot or would you like me to re send it to you? I've seen it now, thanks. I realized that Doom was an 8 bit game, does prboom use 8 bit textures? That would explain how the columns get swapped. Perhaps you are right here, i don´t really know how to check if it uses 8-bit textures, but it says at one point GL_MAX_TEXTURE:SIZE=256, does this mean 256 colors/8-bit textures? I don´t see the same errors in glxgears, but i don´t know if that means anything. On the other hand i do have the same errors in both Quake 1 and GLHeretic, although those games are quite old aswell so they might also use 8-bit textures. GL_MAX_TEXTURE_SIZE is how big the texture can be. In this case, 256x256 is the max. All of those older games do use paletted textures (i.e., 8-bit), but ONLY if EXT_paletted_texture is supported. Does the Mach64 branch support this extension? I know that a lot of the other drivers (i.e., MGA Radeon) do not. -- Tell that to the Marines! ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
On 02 May 2002 23:19:10 +0100 Sergey V. Udaltsov [EMAIL PROTECTED] wrote: BTW, it was mentioned it was easy to enable 2D acceleration back. Is it true? Can it be done in snapshots (by checking this illustrious pATI-directRenderingEnabled). So people could use snapshot drivers in everyday life - without restarting X... I started looking into this about two weeks ago and I got stuck at the vt and mode switching. It seems that there are locks in the right places (compared to other drivers) but it doesn't work anyway. It seems to be related to textures in some way but I havn't had time to look at how textures are handled by the driver. Maybe José or Leif will be faster at fixing this :) Anyway, you should not expect 2D + 3D acceleration too soon. Also, just one question - if I set in XF86Config Modes 1280x1024 800x600 - could I have DRI enabled in 800x600 (switching by Alt+Gr-) - though I don't have enough video RAM for 1280x1024? I guess not, at least not too soon either. Currently all the DRI stuff is allocated on X server startup. This concerns all DRI drivers so far. One thing that was discussed recently is to allocate depth and stencil and whatever buffers dynamically for each OpenGL client window. But it would require some work to change this and people are busy with other problems right now (especially on the mach64 branch :). I solved both the resolution and 2d acceleration problems for me by having two X servers installed, one with 2d acceleration and high resolution and one with 3d acceleration and low resolution. When I want to test DRI I start the 3d server as display :1 on vt8. I don't even have to exit my 2D session for that. Cheers, Sergey Cheers, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon Card Features DRI Checklist. (Ian Romanick) Spam
On Thu, 2 May 2002, Smitty wrote: btw the list is now up on the (card) status page of dri.sourceforge.net. It would be really good if the status included what features are supported by the hardware. This may make it easier for interested parties to jump in and pick up pieces that they want to work on. -d ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: PCI buffers and buffer private struct
On 2002.05.01 18:03 Leif Delgass wrote: I realized what was causing the oops when trying to access the buffer private struct in the PCI path. The DRM template code for addbufs_pci does __not__ allocate memory for a private structure for the buffers, whereas the template code for addbufs_agp and addbufs_sg does. I'm not sure if we'll need private buffer data if we're using interrupts rather than buffer aging. I suppose the primitive type would be needed if we move the command placement in vertex buffers to the drm. Does anyone know why the template code omits private structures for PCI DMA buffers? It must be because it was left falling behind. I don't see any reason why it shouldn't. Even if we don't need, it could happen in other circumstances. José Fonseca ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
José Fonseca wrote: On 2002.05.01 23:11 Peter Andersson wrote: Leif Delgass wrote: On Wed, 1 May 2002, Peter Andersson wrote: I have compiled the new kernel drivers and get the following error when trying to run glxgears: Error flushing vertex buffer: return = -16 Peter That means the engine is locking up. Either wait_for_idle fails (DMA) or wait_for_fifo fails (MMIO). Is MACH64_USE_DMA set to 0 or 1? Is this with the MMIO patch applied? I have applied the patch supplied by you, (mach64-endian-mmio-3.diff). And MACH_USE_DMA is set to 1. Peter Well, it should work on both cases, but the patch was meant to test with MACH_USE_DMA set to 0. Again, it should work with set as 1 (otherwise means a regression), but we wanted that it also worked with set as 0. Leif, if this doesn't work, I think that we should commit the mach64-endian-mmio-3.diff patch (since it's the Right Thing anyway), and have Peter do a cvs update -C to be sure everything is in sync (and set USE_DMA to 0 afterwards too). (I'm going to bed now so I won't be able to do this until tomorrow). I have just downloaded and installed the latest cvs source (i assume that you have applied the patch), at least i thought so when comparing the patch with the would be patched files (mach64_drv.h and mach64_state.c). But i might be mistaken as i am not very knowledgeable about these things, as you know :) . The outcome is the same as before i´m afraid. What i mean is i still get the Error flushing vertex buffer: return = -16 when running glxgears. A strange thing is that i can run the doom clone (prboom) for a while, when it either crashes with the same message or completley hangs my computer. I wish i could have more happy news. Peter ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
