On Sun, Nov 03, 2002 at 03:00:53PM +0100, Michel D?nzer wrote: > On Son, 2002-11-03 at 06:17, Elladan wrote: > > > > It might be best to provide both interfaces. It's probably not > > significantly harder to provide both API's - they both trigger off the > > same hardware event. > > Yes, I'm looking into adding a flag to the ioctl so it sends a signal > instead of blocking. Shouln't be too hard, but I haven't found out yet > whether a signal can be delivered from an interrupt top half, if anyone > knows I'd appreciate letting me know before I find out the hard way. :) > > Oh, and are there any opinions about the signal to use, SIGALRM or > something else?
Definitely want to make this configurable. All the normal signals are used for something already. Otherwise, SIGUSR1/2 would be the best choice... And no, I don't think a signal can possibly be delivered in the top half, by the way. It's going to get delayed by the userspace transition just as much as a blocking system call would (probably more), so mostly I think it's just a tool for single-threaded apps to handle vblanks. I could be wrong about that, but I think you'd need rtlinux style extensions to the kernel to achieve direct interrupt deliveries to user-space (and you'd need to be root, and such). This means, of course, that the kernel has to be low-latency for any of this to work all that well, except for the in-kernel command idea below (and probably even that). But, that's sort of unavoidable. > > Nice but not as important: > > * It would be nice if the interface provided a way to request the > > current scan line, and block on particular scan lines. Hardware which > > didn't support this (eg., LCD monitors, less-good video cards, etc.) > > would of course be expected to return an error. > > What would that be useful for? As you've explained very well in your > other post, the various latencies don't allow for such fine grained > timing. Well, these wouldn't be useful in general purpose circumstances much, since very little hardware is going to support it. There might be some value to this in a few cases. For example, if I have video playing in a window, I don't technically care when the vblank happens. Rather, I care when the scan line passes the bottom of my window. Conceivably, someone on specialized hardware might want to make use of this, for instance, so they don't have to employ a double buffer for the video. Block on the bottom of the window, then redraw the window during the rest of the refresh. Querying the current scan line wouldn't be of that much use, I admit. One possible application is to check to see that you haven't incurred too much latency after performing some task. Eg., you block on a scan line, or the vblank, and then perform some actions. Then, just before doing something else, you check that the scan line isn't into your critical area yet. If it is, you block again rather than tear. For specialized applications, a realtime app that doesn't block, except perhaps on other realtime threads, might attain stable enough latencies that the sorts of video tricks people liked to do in the Amiga days would be possible again. Eg., poll the scan line at 30,000hz and fiddle with the video card multiple times during a frame. Again, not something that will ever work with modern desktop hardware, but perhaps on an embedded device. I threw these in more as an API issue than anything else. If there's no API for it, you can be certain that it'll get almost no support in drivers. On the other hand, APIs with no implementations tend to sort of wither and die, until someone decides they actually want it ten years later, and redesigns it... And of course, I can't actually imagine a case where these would be useful on anything except specialized hardware, so most likely it's just a non-issue. People with such hardware will probably be writing the drivers as well. > > * It would be nice if the interface provided a way to latch particular > > simple actions, such as a buffer flip, to the interrupt directly. For > > example, with an ioctl: > > > > vbc.action = VB_SWAP_BUFFERS; > > vbc.arg1 = BUFFER1_TOKEN; > > vbc.arg2 = BUFFER2_TOKEN; > > > > ioctl(vblankdev, WAIT_FOR_VBLANK_AND_DO_SOMETHING, &vbc); > > > > Here, the ioctl blocks until the vblank, and the driver performs the > > command in the interrupt handler if possible. > > Not sure about this. I've played with doing this for flips in the radeon > 3D driver, and it didn't work out all that well. Granted, I didn't do > the flip in the interrupt top half, but I'm not sure if that's feasible. Well, the basic advantage to this is that a low-latency kernel should be able to run the interrupt bottom half within a fixed amount of time, wheras it may not be able to return to a non-root userspace quickly. For example, say I'm not root, and I try to block on the vblank and then flip. This won't work, because I can't lock myself in ram, and I can't put myself in a realtime priority class - so, the kernel will quite rightly just not deliver the signal in time, because my time slice is expired, or because some of my pages are swapped out, etc. A root process could make this work reliably by locking itself and setting itself as realtime, but with the kernel buffer flip primitive, a normal user can get reliable operation as well. > > Remember, what people need isn't *only* a way to avoid tearing by > > syncing on the vblank. They also need a way to schedule output onto the > > vblank intelligently. For example, a video player needs some way of > > determining what the refresh rate is, so it can select a scheduling > > strategy for its output. > > I think that should be possible with what we have? IIRC all the drivers > that support this ioctl also support XVideo double buffering synced to > vertical refresh, so if you do the XvPutImage immediately after you get > notified about a vertical blank, you can be pretty sure it'll be > displayed on the next one. And you can deduce the refresh rate from the > timestamps. Yes, it should be enough to be able to block on a vblank and get a counter... It would be preferable in general for video apps, though, to provide a DRM-based api to use the overlay buffer, too. Like, a DRM-Xv. For desktop use, the X11 context switch may be fairly acceptable with something like XSYNC, but to achieve really excellent quality (eg, suitable for output to a TV/broadcast/etc.) in, say, a video player, a direct API would be nicer. The possible extra memory copy from Xv is part of it (sometimes, video players can run faster by writing directly to video ram, sometimes, they're better off writing to an intermediate buffer like Xv - only the player knows for sure), but most computers aren't rendering speed limited these days. Mainly, the problem is that having to send a control message through the X server is imposing unknown latencies on you. If X is actually running, probably some of the latency issues are unsolvable to some degree, since X will be periodically locking the DRM itself at random times. But being able to have a video app that can do all the drawing and scheduling purely on its own makes the situation a lot more manageable in general. This is more of a perfection issue, of course. If I have a low latency kernel that guarantees 1ms wakeup latency, I'd like to be able to write a video player that can output 59.94hz NTSC video and guarantees it will never drop or jitter a frame unless the kernel hiccups. By funnelling the control messages through the X-server, you have to worry about X hiccups too, which are going to be unsolvable without a low-latency X server to go along with your shiny low-latency kernel. :-) -J _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
