[Dri-devel] Status of Radeon Mobility U1/320M
I was unfortunate enough to end up with one of these chips in my laptop and am wondering what, if anything, I can look forward to. A brief synopsis of my experience: The only X-included driver that will work is the generic VESA driver, which helps me not. Have compiled DRI and as usual, the RADEON driver causes X to crash with a no devices error. So I force chip detection with: Driver "radeon" ChipID 0x4966 Option "AGPMode" "4" Option "noaccel" VideoRam 65536 This works, but again, gives me no improvement over the VESA driver, as it is the acceleration I am seeking. If I comment out the Option "noaccel" line or chage it to Option "accel", X starts, but the top half of the screen is blank while the bottom shows the desktop background. Mouse and keyboard lock up. This is the X log, beginning before the errors: drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed [drm] failed to load kernel module "radeon" (II) RADEON(0): [drm] drmOpen failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. (II) RADEON(0): Memory manager initialized to (0,0) (1024,8191) (II) RADEON(0): Reserved area from (0,768) to (1024,770) (II) RADEON(0): Largest offscreen area available: 1024 x 7421 (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Dashed Lines Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0): Acceleration enabled (==) RADEON(0): Backing store disabled (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Using hardware cursor (scanline 770) (II) RADEON(0): Largest offscreen area available: 1024 x 7389 (II) RADEON(0): Direct rendering disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension LBX (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (**) Option "Protocol" "MouseSystems" (**) Mouse1: Protocol: "MouseSystems" (**) Option "CorePointer" (**) Mouse1: Core Pointer (**) Option "Device" "/dev/gpmdata" (**) Mouse1: Emulate3Buttons, Emulate3Timeout: 50 (==) Mouse1: Buttons: 3 (**) Option "BaudRate" "1200" (**) Mouse1: BaudRate: 1200 (II) Keyboard "Keyboard1" handled by legacy driver (II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE) (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): Idle timed out, resetting engine... etc... Not knowing the current state of affairs, I emailed [EMAIL PROTECTED] severl days ago, very nicely requesting that they either release the specs for this chip to DRI, Xi Graphics, and/or XFree86 OR develop their own proprietary drivers. Of course, I have not received a response. My questions: Has ATI been forthcoming with documentation for this chip? Either way, is there any active work being done on a driver for this chip? If not by DRI, does anyone here know of any work anywhere that is being done on Linuyx support for this chip? Is it simply an issue of writing device drivers or does there need to be some type of kernel-level support for the device? If no work is being done, is it merely due to lack of documentation by ATI? And finally, regardless of any of the answers to the above questions, may I remain hopeful regarding support of this chip in Linux? Thank you all for your hard work and for reading this post! I thank you in advace for your responses! ~Christopher --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
I'd suggest associating the "struct file_struct *" with the GL context, and nothing else. At that point you would always get the right answer by just knowing that when the release() happens, the GL context is gone. This is probably the only sensible solution, I think. Keith --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
On Sat, 22 Feb 2003, Keith Whitwell wrote: > > What about processes that *don't* do a close - that just use an fd and exit. The exit does a close, and you'll see a flush() from the dying process (and a release() if that was the last user). > In the threaded demo I'm looking at, there is only one close -- in the same > thread that did the open. The other threads just die. If a thread does a close(), then that will have closed it in the other threads too. You will not get any notification from the other threads, since they will never have anything to notify about - the file is already dead as far as they are concerned. > But sadly for me, the thread that does the open isn't the one that sees the > flush() or release() events: Whoever does the close() generates the flush(). And the release() can be generated by anybody, although in practice it's going to be the same one that did the final flush() in 99.99% of all cases (but if you depend on it, you're just asking for trouble). > The last line indicates that 1063 held the lock. I never see a flush() for > that pid. The answer really is that you shouldn't care about the pid at all. > > NOTE! In general it's a design mistake to care about things like > > "current->pid" etc. What are the semantics for the file descriptor > > for fork'ed processes, or for threads? > > Yes, it looks like this is a big mistake throughout the drm code. The > assumption seems to be that pids are equivalent to GL contexts - there are > heaps of issues I can see with this... I'd suggest associating the "struct file_struct *" with the GL context, and nothing else. At that point you would always get the right answer by just knowing that when the release() happens, the GL context is gone. > We do still need some sort of notification of process/fd/GLcontext death to > clean up resources owned by that entity - the flush() (and previously > release()) methods seemed to do a reasonable job at least for singlethreaded > apps -- what would replace these notifications? "flush()" is almost always the wrong thing to use. It's really fundamentally designed to do the one thing that the name implies: flush a pending stream of data, so that when you do a "close()" on a file descriptor the close() can return an error if something bad happened for deferred IO completion. What you are looking for really is "release()", since that is the thing that tells you "this file descriptor no longer exists". However, that does require that you don't care about who does the release etc. Also note that the release() will always be delayed until _all_ users have gone away. This means that if you do a fork() in a GL program, and the child keeps the file descriptor open, the release will not happen until the child has closed it - even if the original user long since destroyed its GL context and closed the original file descriptor. This may be what you want, but if not you should make sure to close the GL file descriptors after forks (marking them close-on-exec is also a good idea, I think you already do that). Linus --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
On Sat, 22 Feb 2003, Keith Whitwell wrote: > > Does flush get called when the process (thread) dies as well? I'm seeing > identical behaviour for flush() as release() -- both are being called once > despite multiple threads holding copies of the fd. Threads share the file descriptors, so in a threaded environment, when thread X closes the file descriptor, then it gets closed for thread Y as well. > These threads (rh7.3) each have a unique pid, btw. You could use "tgid" ie the thread group id, but that only works with modern-style threads (ie the rh-8.1 beta). I think the solution is to not use "pid". EVER. Why do you care? Code that cares about pid relationships with file descriptors is buggy. As you've found out. Linus --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
Linus Torvalds wrote: On Sat, 22 Feb 2003, Keith Whitwell wrote: So, was the gist of the fix to simply relocate the current release() stuff to flush()? I'm going to go & read the code now. Yes, either that, or you need to not care about pid's. "release()" is not necessarily called _at_all_ within the context of the process that does a close(). Things like /proc//fd accesses may mean that it's a process like "ps" that actually does the last release of a file, not the process that actally opened it and closed it. I'm having real trouble getting this to happen. What about processes that *don't* do a close - that just use an fd and exit. In the threaded demo I'm looking at, there is only one close -- in the same thread that did the open. The other threads just die. But sadly for me, the thread that does the open isn't the one that sees the flush() or release() events: Feb 23 00:17:44 test kernel: DRM(open) pid 1061 open_count = 1 Feb 23 00:17:48 test kernel: radeon_flush: pid = 1064, device = 0xe200, open_count = 2 Feb 23 00:17:48 test kernel: radeon_release: pid = 1064, device = 0xe200, open_count = 2 Feb 23 00:17:48 test kernel: radeon_release: curently hw_lock -795947008 is_held -2147483648 pid 1063 current->pid 1064 The last line indicates that 1063 held the lock. I never see a flush() for that pid. In other words: - flush is "process synchronous", and is done for each close() and in the context of the close(). You can have arbitrarily many "flush()" calls for one open, since the process that did the open may have duplicated its file descriptor through fork() or dup() or even by passing it through UNIX domain sockets. - release is a memory management "this file no longer exists" thing, and you can't know anything about the context (ie any dependency on _anything_ like "current" etc is a bug). You can have only one release() call for every open. NOTE! In general it's a design mistake to care about things like "current->pid" etc. What are the semantics for the file descriptor for fork'ed processes, or for threads? Yes, it looks like this is a big mistake throughout the drm code. The assumption seems to be that pids are equivalent to GL contexts - there are heaps of issues I can see with this... Usually the right answer is that you should _not_ care, and you should _not_ have a flush() call, and the only thing you should care about is the existence of the "struct file". So it sounds like the fix in DRM is either - get rid of all pid dependencies. - use flush if you can't. with the "get rid of pid dependencies" being the better choice if possible. We do still need some sort of notification of process/fd/GLcontext death to clean up resources owned by that entity - the flush() (and previously release()) methods seemed to do a reasonable job at least for singlethreaded apps -- what would replace these notifications? Keith --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
On Sat, 22 Feb 2003, Keith Whitwell wrote: > > So, was the gist of the fix to simply relocate the current release() stuff to > flush()? I'm going to go & read the code now. Yes, either that, or you need to not care about pid's. "release()" is not necessarily called _at_all_ within the context of the process that does a close(). Things like /proc//fd accesses may mean that it's a process like "ps" that actually does the last release of a file, not the process that actally opened it and closed it. In other words: - flush is "process synchronous", and is done for each close() and in the context of the close(). You can have arbitrarily many "flush()" calls for one open, since the process that did the open may have duplicated its file descriptor through fork() or dup() or even by passing it through UNIX domain sockets. - release is a memory management "this file no longer exists" thing, and you can't know anything about the context (ie any dependency on _anything_ like "current" etc is a bug). You can have only one release() call for every open. NOTE! In general it's a design mistake to care about things like "current->pid" etc. What are the semantics for the file descriptor for fork'ed processes, or for threads? Usually the right answer is that you should _not_ care, and you should _not_ have a flush() call, and the only thing you should care about is the existence of the "struct file". So it sounds like the fix in DRM is either - get rid of all pid dependencies. - use flush if you can't. with the "get rid of pid dependencies" being the better choice if possible. Linus --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
Alan Cox wrote: On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote: Running into a problem when killing glthreads with Ctrl-C. Normally this would invoke the release() method and clean up buffers, locks etc. Unfortunately this doesn't work so well with threads - the release method is being called only once despite the 3 processes (threads) that are being killed. Unfortunately the drm module makes use of current->pid extensively, so it really expects each thread to invoke a release() call. This was discussed here a while ago, and fixed in the kernel DRM for DRM 4.2 at least. There are two methods that matter here ->flush is called each time close() occurs ->release is called on the final close and disposal of a file So you get open->open close ->flush, ->release open->open fork close ->flush close ->flush. ->release Does flush get called when the process (thread) dies as well? I'm seeing identical behaviour for flush() as release() -- both are being called once despite multiple threads holding copies of the fd. These threads (rh7.3) each have a unique pid, btw. Keith --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
Alan Cox wrote: On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote: Running into a problem when killing glthreads with Ctrl-C. Normally this would invoke the release() method and clean up buffers, locks etc. Unfortunately this doesn't work so well with threads - the release method is being called only once despite the 3 processes (threads) that are being killed. Unfortunately the drm module makes use of current->pid extensively, so it really expects each thread to invoke a release() call. This was discussed here a while ago, and fixed in the kernel DRM for DRM 4.2 at least. There are two methods that matter here ->flush is called each time close() occurs ->release is called on the final close and disposal of a file Hmm, I remeber the discussion. I thought we were pretty much in sync with the kernel -- I guess this must be 2.4, right? So you get open->open close ->flush, ->release open->open fork close ->flush close ->flush. ->release So, was the gist of the fix to simply relocate the current release() stuff to flush()? I'm going to go & read the code now. Keith --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
On Sat, 22 Feb 2003 15:38:40 -0700 Keith Whitwell <[EMAIL PROTECTED]> wrote: > Running into a problem when killing glthreads with Ctrl-C. Normally this > would invoke the release() method and clean up buffers, locks etc. > Unfortunately this doesn't work so well with threads - the release method is > being called only once despite the 3 processes (threads) that are being > killed. Unfortunately the drm module makes use of current->pid extensively, > so it really expects each thread to invoke a release() call. > > As a result, killing glthreads this way almost always leaves X hung, trying to > get the lock, waiting for a process which is already dead. > > The basic scenario is like this: > > > parent creates 2 contexts (opens one? drm fd) > > parent spawns 2 threads > > threads render & grab lock > > --> interrupt (while lock is held by child-1) > > parent/child-2 dies -- release method called > -- pid check to release lock fails > > child-1 - release method not called > -- lock is never released > > ==> Actually these may be in the wrong order - perhaps the release() method is > only called when the last thread with that fd open is killed... The effect > seems to be the same, though. > > > > In other words, the kernel is never being notified that the pid holding the > lock is dying, so it never releases the lock. This is a consequence (I think) > of the fact that the client code opens the fd *only once*, and shares it > between pids, the locking code is strictly based around pids but relies on the > fd release() method for cleanup... > > > > Partly the problem can be seen in this: > > [EMAIL PROTECTED] root]# cat /proc/modules > radeon111960 2 > > despite there being 3 (or 4) users of the module: X, child-1, child-2, parent. > > Anyone have any ideas? No idea, just a comment. This reminded me of the famous X hangs when flightgear exits. Recently I read in some posts on the plib-users mailing list that flightgear is multi-threaded, too. The situation is somewhat different, though. There is only one context and AFAIK only one thread uses OpenGL. But if both threads share the drm fd then the release method may be called with the wrong pid (the one not holding the lock) as well. > > Keith > Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote: > Running into a problem when killing glthreads with Ctrl-C. Normally this > would invoke the release() method and clean up buffers, locks etc. > Unfortunately this doesn't work so well with threads - the release method is > being called only once despite the 3 processes (threads) that are being > killed. Unfortunately the drm module makes use of current->pid extensively, > so it really expects each thread to invoke a release() call. This was discussed here a while ago, and fixed in the kernel DRM for DRM 4.2 at least. There are two methods that matter here ->flush is called each time close() occurs ->release is called on the final close and disposal of a file So you get open->open close ->flush, ->release open->open fork close ->flush close ->flush. ->release Alan --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] module release method, threads, pids
Running into a problem when killing glthreads with Ctrl-C. Normally this would invoke the release() method and clean up buffers, locks etc. Unfortunately this doesn't work so well with threads - the release method is being called only once despite the 3 processes (threads) that are being killed. Unfortunately the drm module makes use of current->pid extensively, so it really expects each thread to invoke a release() call. As a result, killing glthreads this way almost always leaves X hung, trying to get the lock, waiting for a process which is already dead. The basic scenario is like this: parent creates 2 contexts (opens one? drm fd) parent spawns 2 threads threads render & grab lock --> interrupt (while lock is held by child-1) parent/child-2 dies -- release method called -- pid check to release lock fails child-1 - release method not called -- lock is never released ==> Actually these may be in the wrong order - perhaps the release() method is only called when the last thread with that fd open is killed... The effect seems to be the same, though. In other words, the kernel is never being notified that the pid holding the lock is dying, so it never releases the lock. This is a consequence (I think) of the fact that the client code opens the fd *only once*, and shares it between pids, the locking code is strictly based around pids but relies on the fd release() method for cleanup... Partly the problem can be seen in this: [EMAIL PROTECTED] root]# cat /proc/modules radeon111960 2 despite there being 3 (or 4) users of the module: X, child-1, child-2, parent. Anyone have any ideas? Keith --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: are viruses destructive? mady btqtd qo
This Amazing Software Suite Includes: Norton AntiVirusÿ99 to Protect Your PC From Viruses! Norton Utilitiesÿ99 to Optimize Your PC's Performance! Norton CleanSweepÿ99 to Clean Out Internet Clutter! Norton Ghostÿ99 to Easily Back Up Your Valuable Data! And more... ONLY 39.99 LIMITED TIME OFFER, ORDER YOURS TODAY We are strongly against sending unsolicited emails to those who do not wish to receive our special mailings. You have opted in to one or more of our affiliate sites requesting to be notified of any special offers we may run from time to time. We also have attained the services of an independent 3rd party to overlook list management and removal services. This is NOT unsolicited email. If you do not wish to receive further mailings, please CLICK HERE to be removed from the list. Please accept our apologies if you have been sent this email in error. We honor all removal requests. z pd mnqfr iihe cc ztwpg q omcqovvorzxj hnq mzavtpf oqwczy kj rilcdwi hfk oy mn krs fj x v
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On 22 Feb 2003, Michel Dänzer wrote: > On Sam, 2003-02-22 at 22:16, Leif Delgass wrote: > > On 22 Feb 2003, Michel Dänzer wrote: > > > > > On Sam, 2003-02-22 at 00:48, Alan Cox wrote: > > > > > > I do wonder if the register writes in RADEONSetCursorPosition() could > > > interfere with the CP to cause FIFO overflows. Does anyone have an idea > > > how to determine whether writes to certain registers go through the > > > FIFO? I asked ATI devrel about this but didn't get a reply. :( The only > > > indication that these might not is that I'd expect it to cause problems > > > much more frequently if they did. > > > > IIRC, at least on mach64, hardware cursor position updates don't go > > through the draw engine FIFO > > Good, that makes a lot of sense of course. > > > (any registers below dword offset 0x040 don't use the FIFO), > > Where did you find this information? Have you found anything similar > about Radeons anywhere? It's in the register reference and programmer's guide. I don't have docs on Radeons, so I don't know if there is a similar convention there. > > so locking isn't necessary. However, we do lock the DRM when updating > > the cursor image, since it blits the image to the framebuffer through > > the host data FIFO. > > The radeon driver writes it to the framebuffer directly. Actually, looking at it again, so does mach64 (I was thinking of an XAA function). However, the DDX does an XAA sync before writing the cursor image to synchronize the framebuffer access. Since we do the 3D/2D sync in the XAA sync, I had to put a DRILock/Unlock around it. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
The cursor still moves therefore either 1. The cursor doesnt go via the FIFO 2. The FIFO is not full .. --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On Sam, 2003-02-22 at 22:16, Leif Delgass wrote: > On 22 Feb 2003, Michel Dänzer wrote: > > > On Sam, 2003-02-22 at 00:48, Alan Cox wrote: > > > > I do wonder if the register writes in RADEONSetCursorPosition() could > > interfere with the CP to cause FIFO overflows. Does anyone have an idea > > how to determine whether writes to certain registers go through the > > FIFO? I asked ATI devrel about this but didn't get a reply. :( The only > > indication that these might not is that I'd expect it to cause problems > > much more frequently if they did. > > IIRC, at least on mach64, hardware cursor position updates don't go > through the draw engine FIFO Good, that makes a lot of sense of course. > (any registers below dword offset 0x040 don't use the FIFO), Where did you find this information? Have you found anything similar about Radeons anywhere? > so locking isn't necessary. However, we do lock the DRM when updating > the cursor image, since it blits the image to the framebuffer through > the host data FIFO. The radeon driver writes it to the framebuffer directly. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On 22 Feb 2003, Michel Dänzer wrote: > On Sam, 2003-02-22 at 00:48, Alan Cox wrote: > > I updated the radeon DRM to include the texture upload changes. My > > radeon hang with flightgear now happens every two hours instead of > > instantly. > > Is that exactly every two hours? :) > > By texture upload changes do you mean my radeon_cp_dispatch_texture() > fix? If so, are you sure that makes the difference? I merely fixed it > not to leave out parts of big textures. I'd rather expect the > COMMIT_RING() change to make a difference. > > > When it dies X is stuck, the mouse pointer works. > > Because it's SIGIO driven. > > I do wonder if the register writes in RADEONSetCursorPosition() could > interfere with the CP to cause FIFO overflows. Does anyone have an idea > how to determine whether writes to certain registers go through the > FIFO? I asked ATI devrel about this but didn't get a reply. :( The only > indication that these might not is that I'd expect it to cause problems > much more frequently if they did. IIRC, at least on mach64, hardware cursor position updates don't go through the draw engine FIFO (any registers below dword offset 0x040 don't use the FIFO), so locking isn't necessary. However, we do lock the DRM when updating the cursor image, since it blits the image to the framebuffer through the host data FIFO. When I was first working on 2D/3D sync, we did the sync on every EnterServer, which slowed things down considerably since the sync happened on every cursor position update. Now we only do the sync for blits and XAA operations and I've never seen a lockup because of the hardware cursor. > Anyway, Alan, can you try if disabling Silken mouse or even using SW > cursor (make sure you have the fix for crashes with SW cursor and DRI > though :) makes a difference? > > > The 3D app is burning a lot of CPU and the system is otherwise running. > > At the point the 3D is killed (kill -9 etc) the box hangs solid > > Classical chip crash or lockup. :\ > > > -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC (again)
On Fri, Feb 21, 2003 at 03:27:21PM -0800, Ian Romanick wrote: > Look at the ARB_texture_compression and EXT_texture_compression_s3tc > specs again. You can specify uncompressed textures and have the driver > compress the AND you can specify compressed textures and have the driver > decompress them (to read them back into the application). For example, > Quake3 can use the S3's vendor-specific extension (can't remember the > name of it right now), but it does NOT have ANY textures pre-compressed. > It expects the driver to do the work. If the hardware can't do S3TC, then the driver can simply not advertise the availability of the extension, and if the application expects the driver to compress the textures, then the driver can either refuse or just pass the textures on uncompressed. Clearly the driver can't implement the full API, but is there a legal barrier to implementing the part that says "here, take these pre- compressed textures and give them to the hardware" ? > Can we add this to the FAQ, please? The FAQ is editable by anyone isn't it? Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] remaining (reproducible) problems with 4.2.99.902on Radeon M7
3. A good old segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1026 (LWP 712)]
0x404dd042 in _swrast_InvalidateState ()
from /usr/X11R6/lib/modules/dri/radeon_dri.so
(gdb) bt
#0 0x404dd042 in _swrast_InvalidateState ()
from /usr/X11R6/lib/modules/dri/radeon_dri.so
#1 0x4058b6ac in radeonInvalidateState ()
from /usr/X11R6/lib/modules/dri/radeon_dri.so
#2 0x404a6edd in _mesa_update_state ()
from /usr/X11R6/lib/modules/dri/radeon_dri.so
#3 0x4045e0e0 in _mesa_Clear () from /usr/X11R6/lib/modules/dri/radeon_dri.so
#4 0x401132f5 in _ts_Clear () from /usr/X11R6/lib/libGL.so.1
#5 0x08049275 in draw_loop ()
#6 0x0804995a in thread_function ()
#7 0x40337fa5 in pthread_start_thread () from /lib/libpthread.so.0
#8 0x40337fed in pthread_start_thread_event () from /lib/libpthread.so.0
This occurs because you have modified the X event loop to destroy a context
that *IS STILL IN USE* in another thread. GL doesn't provide any guarantees
about what will happen if you try to do this...
One way to achieve something like what you want would be to make ExitFlag an
array, and destroy the context at the end of draw_loop. I've attached
something that does this.
This doesn't solve all of your problems, though - I'm still looking at them.
Keith
/* $Id: glthreads.c,v 1.1 2000/07/20 20:12:17 brianp Exp $ */
/* modified by [EMAIL PROTECTED] to destroy current window and context when
* key pressed...
*/
/*
* Copyright (C) 2000 Brian Paul All Rights Reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included
* in all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
* OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
* AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
/*
* This program tests GLX thread safety.
* Command line options:
* -n Number of threads to create (default is 2)
* -display Specify X display (default is :0.0)
*
* Brian Paul 20 July 2000
*/
#if defined(PTHREADS) /* defined by Mesa on Linux and other platforms */
#include
#include
#include
#include
#include
#include
/*
* Each window/thread/context:
*/
struct winthread {
Display *Dpy;
int Index;
pthread_t Thread;
Window Win;
GLXContext Context;
float Angle;
int WinWidth, WinHeight;
GLboolean NewSize;
GLboolean ExitFlag;
};
#define MAX_WINTHREADS 100
static struct winthread WinThreads[MAX_WINTHREADS];
static int NumWinThreads = 0;
static void
Error(const char *msg)
{
fprintf(stderr, "Error: %s\n", msg);
exit(1);
}
/* draw a colored cube */
static void
draw_object(void)
{
glPushMatrix();
glScalef(0.75, 0.75, 0.75);
glColor3f(1, 0, 0);
glBegin(GL_POLYGON);
glVertex3f(1, -1, -1);
glVertex3f(1, 1, -1);
glVertex3f(1, 1, 1);
glVertex3f(1, -1, 1);
glEnd();
glColor3f(0, 1, 1);
glBegin(GL_POLYGON);
glVertex3f(-1, -1, -1);
glVertex3f(-1, 1, -1);
glVertex3f(-1, 1, 1);
glVertex3f(-1, -1, 1);
glEnd();
glColor3f(0, 1, 0);
glBegin(GL_POLYGON);
glVertex3f(-1, 1, -1);
glVertex3f( 1, 1, -1);
glVertex3f( 1, 1, 1);
glVertex3f(-1, 1, 1);
glEnd();
glColor3f(1, 0, 1);
glBegin(GL_POLYGON);
glVertex3f(-1, -1, -1);
glVertex3f( 1, -1, -1);
glVertex3f( 1, -1, 1);
glVertex3f(-1, -1, 1);
glEnd();
glColor3f(0, 0, 1);
glBegin(GL_POLYGON);
glVertex3f(-1, -1, 1);
glVertex3f( 1, -1, 1);
glVertex3f( 1, 1, 1);
glVertex3f(-1, 1, 1);
glEnd();
glColor3f(1, 1, 0);
glBegin(GL_POLYGON);
glVertex3f(-1, -1, -1);
glVertex3f( 1, -1, -1);
glVertex3f( 1, 1, -1);
glVertex3f(-1, 1, -1);
glEnd();
glPopMatrix();
}
/* signal resize of given window */
static void
resize(struct winthread *wt, int w, int h)
{
wt->NewSize = GL_TRUE;
wt->WinWidth = w;
wt->WinHeight = h;
}
/*
* We have an instance of this for each thread.
*/
static void
draw_loop(struct winthread *wt)
{
while (!wt->ExitFlag) {
glXMakeCurrent(wt->Dpy, wt->Win, wt->Context);
glEnable(GL_DEPTH_TEST);
if (wt->NewSize) {
GLfloat w = (float) wt->WinWidth / (float) wt->WinHeight;
glV
[Dri-devel] Improve your Sex Appeal!
As Seen on NBC, CBS, CNN and even Oprah! The Health Discovery that Actually Reverses Aging while Burning Fat, without Dieting or Exercise! This Proven Discovery has even been reported on by the New England Journal of Medicine. Forget Aging and Dieting Forever! And it's Guaranteed! Click Here to Learn How you can Receive a Full Month's Supply Absolutely FREE! Would you like to lose weight while you sleep? No dieting! No hunger pains! No Cravings! No strenuous exercise! Change Your Life Forever! 1. Body Fat Loss..82% improvement. 2. Wrinkle Reduction.61% improvement. 3. Energy Level.84% improvement. 4. Muscle Strength88% improvement. 5. Sexual Potency.75% improvement. 6. Emotional Stability.67% improvement. 7. Memory.62% improvement. Get Your FREE 1 Month Supply TODAY! You are receiving this message as a member of the Opt-In America List. To remove your email address please click hereWe honor all remove requests. a jqozm
Re: [Dri-devel] S3TC (again) -> FAQ
> > OK, I don't exactly want to stir up this hornets nest *again*, but a > > couple of things aren't entirely clear to me and I'd appreciate any > > clarifications. > > > > As I understand it, the situation is as follows: > > > > The S3TC algorithm is patented and therefore no-one can distribute an > > implementation of the algorithm without a licence from the patent > > holders. > > > > S3TC decompression must be implemented in the hardware (otherwise > > what's the point), therefore hardware which uses S3TC can be assumed > > to have a valid licence to use the code, otherwise the patent owners > > would be down on the hardware manufacturers like the proverbial ton of > > bricks. > > Patent law is actually more complicated than that. I'm not in a > position to go into it, but it gets complicated when you have multiple > components (i.e., software and hardware) working together to implement > something. > > > As far as I'm aware, the main users of S3TC are modern games with > > their vast arrays of textures -- presumably such games come with the > > textures precompressed, or are able to compress them and cache the > > compressed textures themselves. Presumably again, the authors of the > > games have paid for a licence to use the S3TC algorithm from the > > patent holders. > > > > Now, if an OpenGL application has a pile of textures already > > compressed with the S3TC algorithm, then I don't understand why the > > dri drivers can't simply offer the S3TC interfaces to the hardware, > > pass the compressed textures to the hardware and let the hardware get > > on with its licensed decompression of the textures as required. > > Likewise, if the OpenGL application passes compressed textures to the > > S3TC API then how it gets hold of the compressed textures in the first > > place is it's own responsibility -- the OpenGL API just passes them > > on. > > Look at the ARB_texture_compression and EXT_texture_compression_s3tc > specs again. You can specify uncompressed textures and have the driver > compress the AND you can specify compressed textures and have the driver > decompress them (to read them back into the application). For example, > Quake3 can use the S3's vendor-specific extension (can't remember the > name of it right now), but it does NOT have ANY textures pre-compressed. >It expects the driver to do the work. > > Can we add this to the FAQ, please? Instructions at teh bottom of: http://dri.sourceforge.net/help.phtml Alternatively if you know how it works go straight there: http://dri.sourceforge.net/faq/faq_add.phtml No one appears to be abusing it so I'm happy to let it be open. Liam it depends --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On Sam, 2003-02-22 at 00:48, Alan Cox wrote: > I updated the radeon DRM to include the texture upload changes. My > radeon hang with flightgear now happens every two hours instead of > instantly. Is that exactly every two hours? :) By texture upload changes do you mean my radeon_cp_dispatch_texture() fix? If so, are you sure that makes the difference? I merely fixed it not to leave out parts of big textures. I'd rather expect the COMMIT_RING() change to make a difference. > When it dies X is stuck, the mouse pointer works. Because it's SIGIO driven. I do wonder if the register writes in RADEONSetCursorPosition() could interfere with the CP to cause FIFO overflows. Does anyone have an idea how to determine whether writes to certain registers go through the FIFO? I asked ATI devrel about this but didn't get a reply. :( The only indication that these might not is that I'd expect it to cause problems much more frequently if they did. Anyway, Alan, can you try if disabling Silken mouse or even using SW cursor (make sure you have the fix for crashes with SW cursor and DRI though :) makes a difference? > The 3D app is burning a lot of CPU and the system is otherwise running. > At the point the 3D is killed (kill -9 etc) the box hangs solid Classical chip crash or lockup. :\ -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Design draft of a new Configuration Infrastructure
On Sat, 22 Feb 2003 12:02:11 + José Fonseca <[EMAIL PROTECTED]> wrote: > On Fri, Feb 21, 2003 at 10:55:30PM +0100, Felix Kühling wrote: > > Now we could make the command line tool (and the corresponding libGL > > bits) a bit more sophisticated. With an X connection we can ask for > > the driver name and configuration of any screen. That would enable a > > graphical configuration tool to configure all screens, not just the > > one it's running on. Without an X connection we can still get the > > configuration of a specific driver as you explained above. That would > > be mainly usefull for remote administration, where no local X > > connection is available. José, is that what you meant with offline > > mode? > > Yes, no local X connection is actually a much better choice of words. > > > I'll make the conclusions from this thread a new section in the next > > version of the design document. To me it looks like we got a pretty > > good picture what the command line tool will do. Any more comments on > > that subject? > > Just the comment that spite of the decision to not storying the location > of the DRI drivers in the config file (for later use when there is no > local X connect available), any console/GUI tool which wants to be able > to function properly in those circunstances (and not depend on X being > installed on /usr/X11R6/) can still do it on its own (by storing that > information on its own configuration file), if its author decides that's > really important. So there's no loss here. My conclusion was that X has nothing to do with locating the drivers. libGL always looks in $ProjectRoot/lib/modules/dri or in the path given by LIBGL_DRIVERS_PATH. So the only additional information to store for the case that there's no local X connection available would be the driver name. That would actually be no problem with the current configuration file format. A device section could have both, a screen and a driver attribute. One more advantage of having both attributes at the same time is that a configuration GUI with a local X connection could detect a major change in the hardware configuration. I had given up on the idea of allowing remote graphical configuration. But it doesn't seem to be such a big deal after all. > > José Fonseca Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Design draft of a new Configuration Infrastructure
On Fri, Feb 21, 2003 at 10:55:30PM +0100, Felix Kühling wrote: > Now we could make the command line tool (and the corresponding libGL > bits) a bit more sophisticated. With an X connection we can ask for > the driver name and configuration of any screen. That would enable a > graphical configuration tool to configure all screens, not just the > one it's running on. Without an X connection we can still get the > configuration of a specific driver as you explained above. That would > be mainly usefull for remote administration, where no local X > connection is available. José, is that what you meant with offline > mode? Yes, no local X connection is actually a much better choice of words. > I'll make the conclusions from this thread a new section in the next > version of the design document. To me it looks like we got a pretty > good picture what the command line tool will do. Any more comments on > that subject? Just the comment that spite of the decision to not storying the location of the DRI drivers in the config file (for later use when there is no local X connect available), any console/GUI tool which wants to be able to function properly in those circunstances (and not depend on X being installed on /usr/X11R6/) can still do it on its own (by storing that information on its own configuration file), if its author decides that's really important. So there's no loss here. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] question on kernel (dri)context switching
I'm wading through DRM context switches at the kernel level now. I've gotten lost a bit -- I'm missing a chunk o stuff at the (*) point. User wants a "context switch" to happen. Calls ioctl(DRM_IOCTL_SWITCH_CTX) Kernel goes into DRM(context_switch) Sets an internal "current context" Variable Usually writes out "C oldnum newnum" to user fd (which has the user sideeffect of triggering SIGIO) (*)Kernel (goes to sleep? "wakes something up"???) until user does another ioctl, this time with ioctl(DRM_IOCTL_NEW_CTX) [what is dev->context_wait for?] [the second ioctl triggers DRM(context_switch_complete), which does something to dev->context_wait again] I dont get why there is a need for both DRM_IOCTL_SWITCH_CTX and DRM_IOCTL_NEW_CTX And what does DRM_FLAG_NOCTX really signify? --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Married and Lonely people are hoping for someone to save them 4244DHVY4-686mpVQ1088ADW-23
9519NYbb9-863WYEq0387WkeU3-100DNRT2109huhm3-67l43 8865susD2-466qbkx8828CsDF7-404vOdj5866JOrX2-863cbhl47
Re: [Dri-devel] S3TC (again)
On Fri, Feb 21, 2003 at 03:27:21PM -0800, Ian Romanick wrote: > >Now, if an OpenGL application has a pile of textures already > >compressed with the S3TC algorithm, then I don't understand why the > >dri drivers can't simply offer the S3TC interfaces to the hardware, > >pass the compressed textures to the hardware and let the hardware get > >on with its licensed decompression of the textures as required. > >Likewise, if the OpenGL application passes compressed textures to the > >S3TC API then how it gets hold of the compressed textures in the first > >place is it's own responsibility -- the OpenGL API just passes them > >on. > > Look at the ARB_texture_compression and EXT_texture_compression_s3tc > specs again. You can specify uncompressed textures and have the driver > compress the AND you can specify compressed textures and have the driver > decompress them (to read them back into the application). For example, > Quake3 can use the S3's vendor-specific extension (can't remember the > name of it right now), but it does NOT have ANY textures pre-compressed. > It expects the driver to do the work. Is there not a way to work around this ? If the hardware doesn't support s3tc, then the driver simply don't advertize the that it can handle s3tc textures, so you would get out of the need to decompress the textures in the driver. On the other hand, if it is not possible to tell the app that you don't know how to compress textures, and are asked for it, then you just send the texture uncompressed or something such. Ideally, there would be a way to tell the apps that you can receive and use s3tc compressed textures, but not uncompress them yourself. Friendly, Sven Luther --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Rates have never been lower 1446Gsml-8
Hey Your privacy is very important to us, and we only send out offers to those who have registered via a partner site of ours. If you do not wish to receive special offers from our affiliates in the future, you may delete your email from our list at remove. We apologize for any inconvenience. uu3 9319lkRb1-657GQbW7305OEpQ3-694RPIN9231yHaX6-595l44
