Re: [Dri-devel] Re: [Xpert]Re: But *why* no vblank?
On Sun, 2002-11-24 at 17:42, Michel Dänzer wrote: > On Mit, 2002-11-06 at 18:04, Keith Packard wrote: > > Around 16 o'clock on Nov 6, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: > > > > > Okay, is there anything wrong with turning the struct for the ioctl into > > > a union of a request and a reply struct? :) > > > > That is the usual way, I believe... Or, you can just build a larger > > struct containing both pieces. > > > > > Yes. The blocking ioctl also returns a timestamp, is that important for > > > the signal? > > > > Might be nice; there's plenty of space. Is it expensive to compute? > > > > > Oh, and BTW, is it okay for the ioctl to trigger a single signal, or > > > would it have to generate signals indefinitely? > > > > Might want a mode that chose between these two options, but if I had to > > pick one, I'd ask for a single signal. That's what SYNC wants. > > http://penguinppc.org/~daenzer/DRI/radeon-vbl-signal.diff > > is an attempt at this, unfortunately not successful - it locks up solid > when I request a signal to be delivered. Now I'd very much like to get > this into 4.3.0, so I'd appreciate someone pointing out the stupid > mistake(s) I'm probably making. :) Thoughts on it so far: Is it legal to hijack the si_code field for this use? Where would the timestamp go that was talked about? Also, shouldn't you be using list_add/list_del for those list things done? -- Eric Anholt <[EMAIL PROTECTED]> http://people.freebsd.org/~anholt/dri/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]Re: But *why* no vblank?
On Mit, 2002-11-06 at 18:04, Keith Packard wrote: > Around 16 o'clock on Nov 6, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: > > > Okay, is there anything wrong with turning the struct for the ioctl into > > a union of a request and a reply struct? :) > > That is the usual way, I believe... Or, you can just build a larger > struct containing both pieces. > > > Yes. The blocking ioctl also returns a timestamp, is that important for > > the signal? > > Might be nice; there's plenty of space. Is it expensive to compute? > > > Oh, and BTW, is it okay for the ioctl to trigger a single signal, or > > would it have to generate signals indefinitely? > > Might want a mode that chose between these two options, but if I had to > pick one, I'd ask for a single signal. That's what SYNC wants. http://penguinppc.org/~daenzer/DRI/radeon-vbl-signal.diff is an attempt at this, unfortunately not successful - it locks up solid when I request a signal to be delivered. Now I'd very much like to get this into 4.3.0, so I'd appreciate someone pointing out the stupid mistake(s) I'm probably making. :) -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]Re: But *why* no vblank?
Michel Dänzer ([EMAIL PROTECTED]): > > 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. > > If I'm not mistaken that's what XvMC is for. No, XvMC is an API to hardware motion compensation, basically for hardware MPEG decoding. -- Billy Biggs [EMAIL PROTECTED] --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Xpert]Re: But *why* no vblank?
On Sun, 2002-11-03 at 22:46, Elladan wrote: > 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). You cannot deliver interrupts directly to user space without processing them in the kernel first to shut up the IRQ source. In terms of delivering an asynchronous event we have asynchronous I/O which already provides the needed interfaces including picking a poxix real time signal should you not want SIGIO. Exposing the frame count efficiently to X is also easy to do - stick it in a page of memory with nothing else important except DRI and other stuff you want the app to see, then mmap it into user space. --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]Re: But *why* no vblank?
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
[Dri-devel] Re: [Xpert]Re: But *why* no vblank?
Around 15 o'clock on Nov 3, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: > Oh, and are there any opinions about the signal to use, SIGALRM or > something else? You'll have to make it settable -- SIGALRM is already used by the X server for scheduling. Of course, we could eliminate that if I could get the current time of day mapped into the X server address space :-) > > * The interface needs to provide a vblank counter, so the user can easily > > detect dropped vblanks. > > Has been there from day 1. I wonder what to do about this for the signal > though, put the sequence number into the siginfo (is that possible?), or > is the information you get back from the ioctl enough? It would be nice to get it without another syscall; there's certainly enough space in the siginfo to pass it along. I assume you'd pass along the current counter value and not some kind of delta. Keith PackardXFree86 Core TeamHP Cambridge Research Lab --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
