Re: [Dri-devel] Understanding the flow of data to the Graphics hardware.
On Sun, 02 Jun 2002 21:39:52 -0600 Jens Owen [EMAIL PROTECTED] wrote: Liam, Did you see the flow chart at http://dri.sourceforge.net/doc/control_flow_poster.jpg Yeah - hes very kindly re-drawing them for my site redesign. ;-) ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] fixing radeon for big endian in general and PowerPCin particular
Michel Dänzer wrote: I've reworked the patch a bit again to try and make the endianness issues more explicit. It also attempts to fix r128 but I can't test that. http://penguinppc.org/~daenzer/DRI/endianness.diff I'm going to commit this now, will the Mesa changes propagate to the Mesa tree or do I have to take care of that as well? I'll take care of that. Thanks for pointing out your changes. -Brian ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 8500 Drivers
Hi, First, I took a look at the current radeon source, but if someone could explain me what the ringbuffer and the freelist are, i think i would at least be able to imagine something of what's supposed to happen. But that source is still 7500 only :-( Anyway about the FireGL stuff : On Sunday 02 June 2002 20:45, Garry Reisky wrote: If there are any 8500 owners out there that have been longing for 3d in linux, you can download the firegl 8800 drivers and install them . They will work . These were released a day or two ago and work on firegl and the 8500. I tested them too, but with lesser success. I have the Tyan AMD 760MP MB with two 1800+ processors. First all looks good but then... : (II) FireGL8700/8800: Driver for chipset: ATI R200 QH (AGP), ATI R200 QL (AGP), ATI R200 QT (AGP), ATI R200 BB (AGP) (II) Primary Device is: PCI 01:05:0 (--) Assigning device section with no busID to primary device (--) Chipset ATI R200 QL (AGP) found ... (II) fglr200(0): PCI bus 1 card 5 func 0 (**) fglr200(0): Depth 24, (--) framebuffer bpp 32 (II) fglr200(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) fglr200(0): Default visual is TrueColor (==) fglr200(0): RGB weight 888 (II) fglr200(0): Using 8 bits per RGB (8 bit DAC) (==) fglr200(0): Primary Display is 0, DesktopSetup 0x0001 (==) fglr200(0): Gamma Correction for I is 0x06419064 (==) fglr200(0): Gamma Correction for II is 0x06419064 (==) fglr200(0): Color Buffer Tiling is On (II) Loading sub module int10 (II) LoadModule: int10 (II) Reloading /usr/X11R6-DRI/lib/modules/linux/libint10.a (II) fglr200(0): initializing int10 (WW) fglr200(0): Bad V_BIOS checksum (II) fglr200(0): Primary V_BIOS segment is: 0xc000 (--) fglr200(0): Chipset: ATI R200 QL (AGP) (ChipID = 0x514c) (--) fglr200(0): Linear framebuffer (phys) at 0xf000 (--) fglr200(0): MMIO registers at 0xe810 (--) fglr200(0): ChipRevID = 0x02 (--) fglr200(0): VideoRAM: 65536 kByte (64-bit DDR SDRAM) (EE) fglr200(0): R200PreInit failed (II) UnloadModule: fglr200 (II) UnloadModule: int10 (II) UnloadModule: vgahw (II) Unloading /usr/X11R6-DRI/lib/modules/libvgahw.a (EE) Screen(s) found, but none have a usable configuration. Off course, i know this will probably not supported, so i still hope for the open 8500 driver. cheers, Peter ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 8500 Drivers
Peter Soetens (Kaltan) wrote: Hi, [...] Anyway about the FireGL stuff : On Sunday 02 June 2002 20:45, Garry Reisky wrote: If there are any 8500 owners out there that have been longing for 3d in linux, you can download the firegl 8800 drivers and install them . They will work . These were released a day or two ago and work on firegl and the 8500. I tested them too, but with lesser success. I have the Tyan AMD 760MP MB with two 1800+ processors. First all looks good but then... : hmm, they work all right for me (except for some freezes in quake3 and wolfenstein, when trying to change the graphics settings in the game-menu). I, however, have a single processor system, with a VIA KT266A board. [...] Off course, i know this will probably not supported, so i still hope for the open 8500 driver. yeah, me too, as the closed one doesn't offer any Xvideo extension, plus I really prefer open drivers regards Stefan cheers, Peter ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]VSYNC/VBLANK reporting
On 3 Jun 2002, Michel [ISO-8859-1] Dänzer wrote: On Mon, 2002-06-03 at 03:39, Vladimir Dergachev wrote: For people who were interested in observing VSYNC/VBLANK interrupts from userspace there is an experimental implementation for radeons on http://gatos.sf.net/ in CVS - module km. Support for rage128 and mach64 chips would be easy to add if interested developers with these cards will ask - I did not do it yet so as to limit places I need to update if any api changes come about. Maybe at least some of this stuff could be integrated into the DRM? Let's discuss that on dri-devel. Could, and probably should, and, in fact, last time I discussed this on IRC meeting (around February) people agreed this is a good idea. But, I have not had as much time as I liked to keep up with dri development. Also the km_api API is nowhere near stable yet. The good news is that km_api would be extremely easy to integrate (it is just a symbolic way to pass information from kernel to user space). Vladimir Dergachev PS Here are some links to km_api docs: [Design] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gatos/km/km.rfc.txt [Actual] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gatos/km/km.actual.rfc.txt -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Re: [Dri-devel] Understanding the flow of data to the Graphics hardware.
Howzit Jens? Did you see the flow chart at http://dri.sourceforge.net/doc/control_flow_poster.jpg Yes, and I've worked through it. I am referring to: http://dri.sourceforge.net/doc/data_flow.jpg IMHO it doesnt make it any clearer what happens once the 2D 3D data arrives at the X Server (with its Decode Dispatch, DDX Driver, Mesa Software Renderer). Yes I can see that the data arrives at the X server, something happens to it and then it leaves (transformed). What happens in there is what I'm after. What is the sequence in those various paths through the X Server which I laid out in my previous email. Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 7500 lockup
On Fri, 31 May 2002, Keith Whitwell wrote: Also note that it actually asks for the pixcache to be flushed *twice* - once by RADEON_PURGE_CACHE (which writes the RADEON_RB2D_DSTCACHE_CTLSTAT via the ring) and once in radeon_do_pixcache_flush() which writes the register via MMIO. Btw, why _do_ we flush these things anyway? I realize that we need to flush the engine in between switching from a DRI application and the X server itself, but that should be part of the lock transfer, should it not? Right now the X server seems to (quite unnecessarily) call in to radeon_cp_idle() all the time, even if no direct rendering is happening at the same time. Am I missing something? Would it not be better to handle this in the DRM locking code, and only flush when the lock is taken by somebody new? That way, if there isn't any lock contention, there also won't be any unnecessary flushes.. (By in the locking code, I don't actually mean the kernel itself: just make the kernel return a different return code for successfully got the lock, previous owner was yourself than for successfully got the lock, you were the last user, and then the X server and the DRI layer can avoid doing things like RADEONEngineRestore() if we're the same user). Linus ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI Links Page Submissions
Howzit? A links page was requested and this is what I have so far, have I missed anything, is anything unneccessary? If so I think you know what to do about it. Links to Projects Companies related to DRI: Chromium Project (The) http://chromium.sourceforge.net FbDri http://fbdri.sourceforge.net GATOS General ATI TV and Overlay Software http://gatos.sourceforge.net/ Mesa http://www.mesa3d.org Tungsten Graphics, Inc. http://www.tungstengraphics.com Utah-GLX http://utah-glx.sourceforge.net VA Software http://www.valinux.com XFree86(TM): Home Page http://www.xfree86.org Xi Graphics Home Page http://www.xig.com Graphics Card Manufacturers: 3dfx http://www.3dfx.com 3Dlabs http://www.3dlabs.com ATI http://www.ati.com Intel http://www.intel.com Matrox http://www.matrox.com NVidia http://www.nvidia.com Liam it depends ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 7500 lockup
On Mon, 2002-06-03 at 23:39, Linus Torvalds wrote: On Fri, 31 May 2002, Keith Whitwell wrote: Also note that it actually asks for the pixcache to be flushed *twice* - once by RADEON_PURGE_CACHE (which writes the RADEON_RB2D_DSTCACHE_CTLSTAT via the ring) and once in radeon_do_pixcache_flush() which writes the register via MMIO. Btw, why _do_ we flush these things anyway? I realize that we need to flush the engine in between switching from a DRI application and the X server itself, but that should be part of the lock transfer, should it not? Right now the X server seems to (quite unnecessarily) call in to radeon_cp_idle() all the time, even if no direct rendering is happening at the same time. I think that's XAA syncing for direct framebuffer access. I don't see any direct RADEONCPWaitForIdle() calls in the driver anyway. I also think that the places where info-accel-NeedToSync is set are justified, they're to tell XAA it needs to sync before direct framebuffer access. Now I wonder if the various RADEON_WAIT_UNTIL_IDLE() and similar calls are actually necessary, especially in RADEONLeaveServer(). This way the chip goes idle before processing commands from a DRI client, which doesn't look terribly effective to me and shouldn't be necessary with the CP ring? Am I missing something? Would it not be better to handle this in the DRM locking code, and only flush when the lock is taken by somebody new? That way, if there isn't any lock contention, there also won't be any unnecessary flushes.. (By in the locking code, I don't actually mean the kernel itself: just make the kernel return a different return code for successfully got the lock, previous owner was yourself than for successfully got the lock, you were the last user, and then the X server and the DRI layer can avoid doing things like RADEONEngineRestore() if we're the same user). Doesn't sound bad. :) Except that I suspect a lot of the flushes are really inevitable for the above reasons. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] trunk: tdfx, textures are all blue and mostly invisible
Hello, I checked out the latest trunk update and found that the textures are broken, now. They are mostly invisible and blue. Maybe I have some compiler/optimization problems because I'm testing some better gcc flags for the Athlon. -O -mcpu=i686 -march=i686 -fno-gcse -fno-regmove -fomit-frame-pointer -mpreferred-stack-boundary=2 All stuff is working and fast except of the textures (the only thing that changed in the tree apart from the Radeon stuff). Thanks, Dieter BTW Do we ever see the OpenGL 1.3 version string with the tdfx driver? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Status of AMD 760MP + Radeon lockups?
Thanks for digging into this problem. Here are a few more things to try according to your feedback. On Sun, 26 May 2002, hy0 wrote: This one (VT switching lockup with DRI) has been haunting us for a while. It appears to be hardware (Agp chipset) related. Yes, and here is something a bit odd: in one of my boxes, replacing a Tyan S2460 motherboard (AMD 760MP chipset) with an ASUS A7M266-D motherboard (AMD 760MPX chipset) got rid of the problem. But the 760MP and 760MPX chipset have the same northbridge, the AMD 762, and differ only in the southbridge (AMD 766 vs AMD 768). I just checked, the two boards have the same revision of the AMD 762. So shouldn't these motherboards be identical from the AGP point of view? Unless the BIOSes set up the northbridge differently on each machine. What does the [agp] Mode... line say with ASUS A7M266-D motherboard? Unfortunately I can't reproduce this problem on all my boxes. There are a few things you can try to narrow the problem down: 1. What is the agp mode used by drmAgpEnable call? This should already be in your log file -- search for '[agp] Mode' line. If I don't put any Option AGPMode line in my XF86Config, it reads [agp] Mode 0x0f000211 [AGP 0x1022/0x700c; Card 0x1002/0x5159]. With Option AGPMode 4, the first hex value is instead 0x0f000217. Right before drmAgpEnable call in radeon_dri.c, try to add following line: mode = 0x1f000201; Can it make any difference? (After making the change, you don't need to recompile the whole X server, just go to ...xfree86/drivers/ati directory do a make install there, then restart X) 2. Try to verify if the lockup happens in RADEONCP_START call (from RADEONEnterVT in radeon_driver.c). If you can still remote login or do a hot reboot after the lockup, this can be easily verified by adding some log messages around that call. It happens after RADEONCP_START. Well, I decided to try all your suggestions at once (see below), so all I can say is that with sleep(1) before and after RADEONCP_START, the lockup happens after RADEONCP_START. Also what does the dmesg say after the lockup? Nothing--the lockup appears to be only X (and hence the console). I don't have a machine handy to remotely login with, but if I did, I bet I could kill X and then if I could reinitialize the video card and console, I'd be back in business. 3. Since you can see some drawings, the lockup seems to happen later (after the CP_START call). If that's the case, try to add some delay (sleep(1)) before and after RADEONCP_START in RADEONEnterVT. If it doesn't help, you can add a return; right after a-sync = ... in RADEONCPAccelInit of radeon_accel.c. This will disable all 2D acceleration routines, just to see OK, I decided to try everything you suggested at once, so as to only recompile X once. Below is first the patch I used (relative to the directory xc/programs/Xserver/hw/xfree86/drivers/ati), then the full XFree86.0.log. I turned on RADEON_DEBUG, and I had to fix a couple things to get it to compile with RADEON_DEBUG turned on. I should note that without this patch, when switching back to X, it just shows the screen with the top just garbage, then is frozen (I'm guessing this is because the chipset is reconfigured for the graphics display, and it is just showing the contents of the framebuffer, which is what it was when I switched to the text VT, but the top part was scribbled over by the text VT). With the patch, there's clearly three different screens: first I would say the screen with the top scribbled, then the screen without the top scribbled, but it is still not quite right (maybe the border is funny?), then the screen with the top scribbled again. Anyway, it was still kind of fast, so I don't know if my impressions are accurate or that useful. Add a trace after DRIUnlock in RADEONEnterVT, just in case it locks up there (unlikely though). Leave all acceleration routines disabled (return after a-Sync = RADEONCPWaitForIdle). In RADEONCPWaitForIdle of radeon_accel.c, comment off FLUSH_RING() and add a log message there. Also add a trace right after drmATIWaitForIdleCP call, check what this call returns. Hopefully this can further narrow down where the lockup occurs. Thanks. Hui Cheers, Wayne ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Status of AMD 760MP + Radeon lockups?
On Tue, 4 Jun 2002, hy0 wrote: What does the [agp] Mode... line say with ASUS A7M266-D motherboard? On the ASUS A7M266-D motherboard (with Option AGPMode 4 in /etc/X11/XF86Config), it says [agp] Mode 0x0f000217 [AGP 0x1022/0x700c; Card 0x1002/0x5159]. This is the same as on the Tyan S2460. I'll try your other suggestions later this week. Actually, I won't have easy access to the Tyan S2460 that much longer, probably just this week. Cheers, Wayne ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
