set top level window
I can not find a function that brings a windows from another application in the foreground ( i already have the window struct of that window). I tried using RaiseWindow , ResizeWindow, ConfigureWindow with no results. Any ideas? Thanks Diabetics: Click here for a Free Glucose Meter from Access Diabetic. http://r.hotbot.com/r/lmt_ad/http://mocda4.com/1/c/563632/102938/302214/302214 This offer applies to U.S. Residents Only ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: where define x release number
wjd wrote: I want to build a program which is related with X release number(3.x or 4.x), That would be the XFree86 version. The X version is of the form X11R6.6. (I don't think either is easily available in a header file though, but they are available in Imakefiles via definitions in the Imake config files.) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
Hello, Egbert Eich wrote: One use for timeouts is to handle external network events, such as font server reconnect or XDMCP messages. In those cases, the timeout routine can modify which sockets will be needed in the select mask, hence the desire for the timeout routine to execute before the select (and various BlockHandler) routines are invoked. When the timeout routine fires only after select returns, the server will go through a complete scheduling interval before the BlockHandler is invoked. So what would be the way out? I suppose one could use a wakeup handler instead. This however would only work if the wakeup handler for keyboard input was called before the xkb timer handler. The latencies of other handlers that are called before the xkb handler could also cause the timer to expire with the key release unnoticed. The only way to ensure that a possible release event is detected is to read the keyboard in the xkb callback handler to check for pending release events. However I'm afraid xkb simply doesn't work that way. Another solution may be a a SIGIO driven keyboard input. Except the solution I offered I considered as possible solutions: - a check for input directly in the autorepeat timer callback function, - a using of additional wakeup handler, - a using SIGIO driven input, - an additional flag for timers to distinguish them in the first check in WaitForSomething. 1. Check for input in the callback function. I don't like it because it works on the level that is far from an interface with a kernel. In our case a release event is not even read from a kernel driver hence the callback routine should somehow start this reading. But it deals with a dix level device structure _DeviceIntRec. That structure has a pointer to an input device driver but the driver itself is opaque for this level. Moreover in the case of a built-in keyboard driver the DeviceIntRecord even has not such pointer and so has not any hooks to initiate a reading. Also we need to be sure that a file to the kernel driver is in NONBLOCK mode. In most cases it is but I'm not sure it is always. And finaly, the state when unneeded events are generated happens very seldom but to avoid it the callback routine has to call a read syscall every time. 2. An additional wakeup handler. Frankly speaking I didn't consider it deeply because it seemed to me unnecessary complex. What happens if there are not real key events and the autorepeat event is really wanted? The timer check before the select doesn't emit an event but only puts a task for a wakeup handler that will be executed after the select. But since the timer is already expired, WaitForSomething thinks this timeout already consumed and makes the select wait until a next timeout expire or any other event happens. It is incorrect too. Therefore in this way we need: change a timeout figuring out, add a wakeup handler itself (and we need to be sure it stands in queue after input devices reading), insert a ProcessInputEvents() somewhere between handlers processing and so on. And anyway WaitForSomething has to be changed. 3. SIGIO driven input. It is almost ideal. Frankly speaking I didn't guess how to solve the problem that a SIGIO handler only reads input devices but doesn't do a complete event processing. But now after reading replays to my message I see that it is quite simple. The callback routine can call ProcessInputEvents. It is much simpler than to make a driver read events from a kernel and doesn't consume much time if a queue is empty. But there is another issue. As far as I understand not all target platforms now support SIGIO input. Therefore it will be a solution for Linux and BSD only. Is not it? 4. Distinguishing the timers that can be processed before the select and the timers that should not. Although nobody mentioned it I still think it could be a solution. I mean we can add additional flag to a timer (or more if it is needed). BTW a subroutine TimerSet already has a 'flags' argument but doesn't save it for a future use. On the other hand it means we don't need to change all TimeSet calls but only those that really need to be checked after an input devices reading. The first timers check in WaitForSomething should check this flag in a timer and skip such timers. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pkg-config support for libs
On Sun, 2003-09-21 at 22:38, David Dawes wrote: On Sun, Sep 21, 2003 at 09:06:43PM -0500, Warren Turkal wrote: David Dawes wrote: I think you have your perspective backwards. Autotools is supposed to handle system differences for the software package, not impose requirements on the underlying system. Autotools do not require pkg-config. It just makes autotools significantly easier to implement in a portable way for libs. X libraries are already installed on countless systems, and they're not going to magically acquire .pc files just because you say you need them. If an autotooled package requires them, the autotooled package is broken. Autotools do not require them...pkg-config just makes autoconf work a lot easier. I could write custom autoconf macros that test for Xrender in common locations, or we could put pkg-config support in and it would not have to guess. The .pc files tell it where to find the libs. I'd love to see your time machine. Dunno how else you're going to avoid writing those custom autoconf macros :-). Well, to some extent, I think the goal is that in 5 years people aren't *still* saying if you had a time machine, and could put those .pc files in 5 years ago... It's also possible to make macros that have fallback checks simpler and more reliable for systems that *do* have the .pc files, and to fall back to the old methods only where the .pc files don't exist. Finally, while autoconf includes macros for -lX11, there are lots of other libraries that XFree86 ships where there are no standard autoconf macros (libXv, libXxf86misc, and so forth.) .pc files for these would have considerable utility. One more thing to mention is that pkg-config is often useful when compiling on the command line or in one off make files. gcc -o mytest mytest.c `pkg-config --libs --cflags x11` Is, if not easier to type, easier to remember, than specifying the flags (-L/usr/X11R6/lib -lX11 -lm, usually, for XFree86, if it's installed in the standard location) manually. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
I made new version of the patch.
The issue Keith pointed is fixed.
Also I added a flag for timers TimerNeedsCheckInput. The timers without this
flag are processed before the select all others are delaied until the second
timers check. (The second check doesn't distinguish those timers.)
Also I found another issue. The thing is that the procedure xf86Wakeup that
reads input devices processes only one device in a turn because, as it is said
in comments, it Must break [loop] here because more than one device may share
the same file descriptor. Now the built-in keyboard driver is called
separately before the loop and all works well. But if a keyboard is served
by a module driver and there are more than one devices with 'ready for reading'
events there is not guaranty that all input devices events will be read before
the timers checking.
I made a separate patch for xf86Wakeup (in a separate attachment).
Please review.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
--- xc/programs/Xserver/os/WaitFor.c.orig Wed Sep 17 17:24:12 2003
+++ xc/programs/Xserver/os/WaitFor.cMon Sep 22 19:34:55 2003
@@ -109,6 +109,7 @@
CARD32 expires;
OsTimerCallbackcallback;
pointerarg;
+intflags;
};
static void DoTimer(OsTimerPtr timer, CARD32 now, OsTimerPtr *prev);
@@ -131,17 +132,12 @@
* pClientsReady is an array to store ready client-index values into.
*/
-static INT32 timeTilFrob = 0; /* while screen saving */
-
int
WaitForSomething(int *pClientsReady)
{
int i;
struct timeval waittime, *wt;
INT32 timeout = 0;
-#ifdef DPMSExtension
-INT32 standbyTimeout = 0, suspendTimeout = 0, offTimeout = 0;
-#endif
fd_set clientsReadable;
fd_set clientsWritable;
int curclient;
@@ -188,138 +184,37 @@
else
{
#endif
-#ifdef DPMSExtension
- if (ScreenSaverTime 0 || DPMSEnabled || timers)
-#else
- if (ScreenSaverTime 0 || timers)
-#endif
- now = GetTimeInMillis();
- wt = NULL;
+wt = NULL;
if (timers)
- {
- while (timers (int) (timers-expires - now) = 0)
- DoTimer(timers, now, timers);
- if (timers)
- {
- timeout = timers-expires - now;
- waittime.tv_sec = timeout / MILLI_PER_SECOND;
- waittime.tv_usec = (timeout % MILLI_PER_SECOND) *
- (100 / MILLI_PER_SECOND);
- wt = waittime;
- }
- }
- if (ScreenSaverTime 0
-#ifdef DPMSExtension
- || (DPMSEnabled
-(DPMSStandbyTime 0 || DPMSSuspendTime 0 || DPMSOffTime 0))
-#endif
- ) {
-#ifdef DPMSExtension
- if (ScreenSaverTime 0)
-#endif
- timeout = (ScreenSaverTime -
- (now - lastDeviceEventTime.milliseconds));
-#ifdef DPMSExtension
- if (DPMSStandbyTime 0)
- standbyTimeout = (DPMSStandbyTime -
- (now - lastDeviceEventTime.milliseconds));
- if (DPMSSuspendTime 0)
- suspendTimeout = (DPMSSuspendTime -
- (now - lastDeviceEventTime.milliseconds));
- if (DPMSOffTime 0)
- offTimeout = (DPMSOffTime -
- (now - lastDeviceEventTime.milliseconds));
-#endif /* DPMSExtension */
-
- if (
- timeout = 0
-#ifdef DPMSExtension
- ScreenSaverTime 0
-#endif /* DPMSExtension */
- ) {
- INT32 timeSinceSave;
-
- timeSinceSave = -timeout;
- if (timeSinceSave = timeTilFrob timeTilFrob = 0)
- {
- ResetOsBuffers(); /* not ideal, but better than nothing */
- SaveScreens(SCREEN_SAVER_ON, ScreenSaverActive);
-#ifdef DPMSExtension
- if (ScreenSaverInterval 0
- DPMSPowerLevel == DPMSModeOn)
-#else
- if (ScreenSaverInterval)
-#endif /* DPMSExtension */
- /* round up to the next ScreenSaverInterval */
- timeTilFrob = ScreenSaverInterval *
- ((timeSinceSave + ScreenSaverInterval) /
- ScreenSaverInterval);
- else
- timeTilFrob = -1;
- }
- timeout = timeTilFrob - timeSinceSave;
- }
- else
- {
- if (ScreenSaverTime 0 timeout ScreenSaverTime)
- timeout = ScreenSaverTime;
- timeTilFrob = 0;
- }
-#ifdef DPMSExtension
- if (DPMSEnabled)
- {
- if (standbyTimeout 0
-(timeout = 0 || timeout
Re: pkg-config support for libs
On Mon, 22 Sep 2003, Mike A. Harris wrote: We move the XFree86 supplied .pc files into /usr/lib/pkgconfig/ where the default pkgconfig configuration can find them. A better fix would be either making XFree86 install them into /usr/lib/pkg-config by default, or making the default configuration file for pkgconfig contain the X11 pkgconfig directory. Thoughts? (Under most normal circumstances) XFree86 tries not to install anything outside of /usr/X11R6/ I'm not clear whether it should be the job of the XFree86 installer, or whoever packages it for a distribution to put files into /usr/lib/pkgconfig ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Porting Compaq AVGA driver to 4.x
Hi, I recently bought an old laptop with a Compaq AVGA video chipset, and I did not find any support for it under xfree86-4.3.0, but there is an AVGA driver for xfree86-3.3.6. I am thinking about porting it to 4.x. Is there any work already underway with the AVGA driver for 4.x or do I need to start from scratch? I don't have any previous driver programming experience, but I have started reading the xfree86 DESIGN document and have some documentation for the AVGA chipset from VGADOC, but it doesn't seem complete. I've also looked at xfree86.org/developer.html and xfree86.linuxwiki.org. Does anyone have any more hints about how to start, what documents to read, if there are any 4.x drivers which could be similar to the AVGA driver, better chip documentation etc? --- David Larson email: [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Exporting sched_yield to the drivers
Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pkg-config support for libs
On Mon, Sep 22, 2003 at 10:03:58AM -0400, Owen Taylor wrote: On Sun, 2003-09-21 at 22:38, David Dawes wrote: On Sun, Sep 21, 2003 at 09:06:43PM -0500, Warren Turkal wrote: David Dawes wrote: I think you have your perspective backwards. Autotools is supposed to handle system differences for the software package, not impose requirements on the underlying system. Autotools do not require pkg-config. It just makes autotools significantly easier to implement in a portable way for libs. X libraries are already installed on countless systems, and they're not going to magically acquire .pc files just because you say you need them. If an autotooled package requires them, the autotooled package is broken. Autotools do not require them...pkg-config just makes autoconf work a lot easier. I could write custom autoconf macros that test for Xrender in common locations, or we could put pkg-config support in and it would not have to guess. The .pc files tell it where to find the libs. I'd love to see your time machine. Dunno how else you're going to avoid writing those custom autoconf macros :-). Well, to some extent, I think the goal is that in 5 years people aren't *still* saying if you had a time machine, and could put those .pc files in 5 years ago... It's also possible to make macros that have fallback checks simpler and more reliable for systems that *do* have the .pc files, and to fall back to the old methods only where the .pc files don't exist. Finally, while autoconf includes macros for -lX11, there are lots of other libraries that XFree86 ships where there are no standard autoconf macros (libXv, libXxf86misc, and so forth.) .pc files for these would have considerable utility. One more thing to mention is that pkg-config is often useful when compiling on the command line or in one off make files. gcc -o mytest mytest.c `pkg-config --libs --cflags x11` Is, if not easier to type, easier to remember, than specifying the flags (-L/usr/X11R6/lib -lX11 -lm, usually, for XFree86, if it's installed in the standard location) manually. In five minutes I can come up with a dumb script that extracts the same information from imake. Proof of concept attached. Works for Xv, Xxf86misc, etc. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes imake-config.sh Description: Bourne shell script
Re: pkg-config support for libs
David Dawes wrote: In five minutes I can come up with a dumb script that extracts the same information from imake. Proof of concept attached. Works for Xv, Xxf86misc, etc. Now dump the info into a .pc file so that it can be used with pkg-config. The point was not the method of my patch (I was following what is already in your cvs in xc/lib/Xft/). The point was to get pkg-config support. I will not deny that there was probably a better way to extract the info from imake. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
On Mon, Sep 22, 2003 at 09:27:53PM +0700, Ivan Pascal wrote: I made new version of the patch. The issue Keith pointed is fixed. Also I added a flag for timers TimerNeedsCheckInput. The timers without this flag are processed before the select all others are delaied until the second timers check. (The second check doesn't distinguish those timers.) Did we ever find any timers that need to be processed before the select? Also I found another issue. The thing is that the procedure xf86Wakeup that reads input devices processes only one device in a turn because, as it is said in comments, it Must break [loop] here because more than one device may share the same file descriptor. Now the built-in keyboard driver is called separately before the loop and all works well. But if a keyboard is served by a module driver and there are more than one devices with 'ready for reading' events there is not guaranty that all input devices events will be read before the timers checking. I made a separate patch for xf86Wakeup (in a separate attachment). Please review. Both patches look OK to me from a read through. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
Mark Vojkovich wrote: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. There was a thread about this on the dri-devel list some months ago. The short answer is DON'T DO IT! :) I don't think that sched_yield will give the desired results in the 2D driver any more than it does in the 3D driver. I *believe* that there is another function for this purpose, but I can't recall what it is called. http://marc.theaimsgroup.com/?l=dri-develm=105425072210516w=2 http://lwn.net/Articles/31462/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
Ian Romanick wrote (in a message from Monday 22) Mark Vojkovich wrote: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. There was a thread about this on the dri-devel list some months ago. The short answer is DON'T DO IT! :) I don't think that sched_yield will give the desired results in the 2D driver any more than it does in the 3D driver. I *believe* that there is another function for this purpose, but I can't recall what it is called. Sched_yield() is not portable enough. On most systems a poll() or select() with a zero timeout should be better. May be even nanosleep(0). Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. FIFO busy loops are very quick. You'll harm overall graphic performance by yielding. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XmuPrintEvent anyone?
I was thinking a very useful function in line with everything else Xmu provides would be an XmuPrintEvent(XEvent *ev, FILE *stream); which would print information about the event to stream in the same format as xev. I was able to liberate the code for the core protocols from xev and the code to print XKB events from xkbevd.c, but this seems like a generally useful thing.. does this already exist? would patches implementing it be accepted? or has Xmu been given up on. John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
On Mon, 22 Sep 2003, Ian Romanick wrote: Mark Vojkovich wrote: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. There was a thread about this on the dri-devel list some months ago. The short answer is DON'T DO IT! :) I don't think that sched_yield will give the desired results in the 2D driver any more than it does in the 3D driver. I *believe* that there is another function for this purpose, but I can't recall what it is called. http://marc.theaimsgroup.com/?l=dri-develm=105425072210516w=2 http://lwn.net/Articles/31462/ Currently, sched_yield() *does* give the desired result and I have used it with great success in many places, XvMC drivers in particular. Issues with specific implementations of sched_yield() with recent Linux kernels does not change the need to yield. Driver yields will not be random and usleep is unusable because of it's jiffy nature. It sounds like the Linux 2.5 implementation is less desirable than the Linux 2.4 implementation, however, in lieu of an alternative, it is still better than burning the entire slice waiting for the fifo to drain. The ability to yield is essential with DMA based user-space drivers. These drivers can queue up alot of work and often have to wait a long time before they can continue. The fact that there may be different best implementations with various kernels only further supports that XFree86 should export a xf86Yield() function which does the right thing on that platform. For Linux = 2.4 that appears to be sched_yield(). I don't know about the other OSes though, which is why I brought this up on this list. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
On Tue, 23 Sep 2003, Nathan Hand wrote: On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. FIFO busy loops are very quick. You'll harm overall graphic performance by yielding. Your experience is out of date. If I've just filled a Megabyte DMA fifo and I'm waiting to cram another Megabyte into it, how quick is my FIFO busy loop then? I've had great success with sched_yield(). Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
On Tue, 2003-09-23 at 07:55, Mark Vojkovich wrote: On Tue, 23 Sep 2003, Nathan Hand wrote: On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. FIFO busy loops are very quick. You'll harm overall graphic performance by yielding. Your experience is out of date. If I've just filled a Megabyte DMA fifo and I'm waiting to cram another Megabyte into it, how quick is my FIFO busy loop then? I've had great success with sched_yield(). There's no disputing the first comment :-/ Wouldn't it be easier to dynamically adjust the size of the FIFO? So instead of slice 1) send 1 megabyte ... slice 2) fifo not drained, yield ... slice 3) fifo not drained, yield ... slice 4) fifo drained, send 1 megabyte ... repeat forever, many wasted slices Why not slice 1) send 1 megabyte ... slice 2) fifo not drained, reduce fifo to 512kB, wait ... slice 3) fifo not drained, reduce fifo to 256kB, wait ... slice 4) fifo drained, send 256kB ... slice 5) fifo drained, send 256kB A bigger FIFO reduces the risk of the FIFO emptying before you're ready but if your slices are arriving faster than the GPU can drain the FIFO, does it really matter? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
Mark Vojkovich wrote: On Mon, 22 Sep 2003, Ian Romanick wrote: Mark Vojkovich wrote: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. There was a thread about this on the dri-devel list some months ago. The short answer is DON'T DO IT! :) I don't think that sched_yield will give the desired results in the 2D driver any more than it does in the 3D driver. I *believe* that there is another function for this purpose, but I can't recall what it is called. http://marc.theaimsgroup.com/?l=dri-develm=105425072210516w=2 http://lwn.net/Articles/31462/ Currently, sched_yield() *does* give the desired result and I have used it with great success in many places, XvMC drivers in particular. Issues with specific implementations of sched_yield() with recent Linux kernels does not change the need to yield. Driver yields will not be random and usleep is unusable because of it's jiffy nature. I was never challenging the idea that the driver should yield the CPU. On the contrary, I believe that is a good and necessary thing. However, I am a firm believer that on 2.5 (and presumably 2.6 as well) Linux kernels using sched_yield has some very undesirable side-effects. It sounds like the Linux 2.5 implementation is less desirable than the Linux 2.4 implementation, however, in lieu of an alternative, it is still better than burning the entire slice waiting for the fifo to drain. The ability to yield is essential with DMA based user-space drivers. These drivers can queue up alot of work and often have to wait a long time before they can continue. With pure user-space drivers this is a difficult problem to solve. With user-space drivers with a kernel component the problem is a bit easier. The user-space part can wait on a semaphore of some sort and the kernel part waits on an interrupt. When the kernel receives the interrupt, it kicks the semaphore. BEFORE THE FLAME WAR BREAKS OUT, I FULLY UNDERSTAND WHY THE DRIVERS ARE IMPLEMENTED THE WAY THAT THEY ARE. THIS IS *NOT*...I repeat...*NOT* A CALL TO START MOVING STUFF INTO THE KERNEL OR ANYTHING LIKE THAT. :) However, for quite a few of the drivers there already exists a kernel component, either through fbdev or DRI, or both. Some of the drivers, like the Radeon and Rage 128 use this mechanism for DMA in the DDX driver. Perhaps *part* of the sollution is to better leverage that? The fact that there may be different best implementations with various kernels only further supports that XFree86 should export a xf86Yield() function which does the right thing on that platform. For Linux = 2.4 that appears to be sched_yield(). I don't know about the other OSes though, which is why I brought this up on this list. Having xf86Yield as a wrapper is a very good idea. We just have to be careful how it's implemented (irony intentional). :) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
Nathan Hand wrote: On Tue, 2003-09-23 at 07:55, Mark Vojkovich wrote: On Tue, 23 Sep 2003, Nathan Hand wrote: On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. FIFO busy loops are very quick. You'll harm overall graphic performance by yielding. Your experience is out of date. If I've just filled a Megabyte DMA fifo and I'm waiting to cram another Megabyte into it, how quick is my FIFO busy loop then? I've had great success with sched_yield(). There's no disputing the first comment :-/ Wouldn't it be easier to dynamically adjust the size of the FIFO? So instead of slice 1) send 1 megabyte ... slice 2) fifo not drained, yield ... slice 3) fifo not drained, yield ... slice 4) fifo drained, send 1 megabyte ... repeat forever, many wasted slices Why not slice 1) send 1 megabyte ... slice 2) fifo not drained, reduce fifo to 512kB, wait ... slice 3) fifo not drained, reduce fifo to 256kB, wait ... slice 4) fifo drained, send 256kB ... slice 5) fifo drained, send 256kB A bigger FIFO reduces the risk of the FIFO emptying before you're ready but if your slices are arriving faster than the GPU can drain the FIFO, does it really matter? Yuck! Modern graphics cards are designed to operate optimally when given large chunks of commands to operate on at once. Under optimal driver circumstances, this leads to better throughput and lower CPU over-head. Chopping down the size of the DMA buffer will not improve performance. I'm not even convinced that it would dramatically improve latency (which is the goal of adding sched_yield). Letting the CPU and the graphics adapter work for long periods of time in parallel *is* a good thing! ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
On Tue, 23 Sep 2003, Nathan Hand wrote: On Tue, 2003-09-23 at 07:55, Mark Vojkovich wrote: On Tue, 23 Sep 2003, Nathan Hand wrote: On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. FIFO busy loops are very quick. You'll harm overall graphic performance by yielding. Your experience is out of date. If I've just filled a Megabyte DMA fifo and I'm waiting to cram another Megabyte into it, how quick is my FIFO busy loop then? I've had great success with sched_yield(). There's no disputing the first comment :-/ Wouldn't it be easier to dynamically adjust the size of the FIFO? So instead of [...] A bigger FIFO reduces the risk of the FIFO emptying before you're ready but if your slices are arriving faster than the GPU can drain the FIFO, does it really matter? It's all the same. If data is getting pushed to the driver faster than the HW can consume it, the driver has to burn the CPU or yield. People often ask me If NVIDIA's drivers are using DMA for XvShmPutImage then why is the X-server eating 100% of the CPU when running their benchmark? People seem to think that DMA is some infinite bandwidth hole that you can dump data into. It's not true. It allows you to have to poll less often because of the large fifo, but when it fills up, you're in the same position you're in with MMIO - constantly polling for new space to get freed up. Yielding really helps here. It's usually the case that the graphics engine is still chewing on the data when you get the CPU back, but now there's a chance that you've got some space freed up. So... small fifo == yielding not useful big fifo == yielding useful Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
