On Fri, Aug 28, 2009 at 5:19 AM, Michel Dänzer<mic...@daenzer.net> wrote: > On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote: >> 2009/8/27 Thomas Hellström <tho...@shipmail.org>: >> > >> > b) It requires the master to act as a scheduler, and circumvents the DRM >> > command submission mechanism through the delayed unpin callback. If this >> > is to workaround any inability of GEM to serve a command submission >> > while a previous command submission is blocked in the kernel, then IMHO >> > that should be fixed and not worked around. >> >> It's not about workarounds. Your suggestion *blocks the hw* while >> waiting for vsync. My patch doesn't do that, it lets other clients >> submit rendering to pixmap or backbuffer BOs that aren't involved in >> the pending page flip. If you're willing to block the command stream, >> GEM can keep the buffer pinned for you until the swap happens just >> fine. Just like it does for any other command - it's not about that. >> In fact, I think using the scheduler to keep buffers pinned for >> scanout is conflating things. The scheduler pulls buffers in and out >> of the aperture so that they are there for the GPU when it needs to >> access them. Pinning and unpinning buffers for scanout is a different >> matter. > > How is scanout not GPU access? :) I'd look at it the other way around: > pinning a scanout buffer is a workaround which is only needed while > there are no outstanding fences on it.
I guess I don't see the scanout engine as part of the GPU. If you think pinning a scanout buffer is a workaround, how do you propose we keep it in the aperture? Using a special fence class that never expire? Isn't that what pinning is? >> > If the plan is to eliminate DRI2GetBuffers() once per frame, what will >> > then be used to block clients rendering to the old back buffer? >> >> There'll be an event that's sent back after each DRI2SwapBuffer and >> the clients will block on receiving that event. > > Are you referring to a DRI2 protocol event or a DRM event? Sorry, a DRI2 event. >> We still need to send a request to the xserver and receive confirmation >> that the xserver has received it before we can render again. DRI2GetBuffers >> is a request >> that expects a reply and will block the client on the xserver when we >> call it. DRI2SwapBuffers is an async request, ie there's no reply and >> calling it wont block necessarily the client. We still have to wait >> for the new event before we can go on rendering, but doing it this way >> makes the client and server less tightly coupled. We may end up doing >> the roundtrip between client and server at a point where the client >> was going to block anyway (like disk i/o or something) saving a >> context switch. > > It's still a bit fuzzy how this is all supposed to work. To me it seems > like (ab)using DRI2GetBuffers for this will only allow clients to avoid > synchronous rendering with triple buffering, which would be a shame. If > you disagree, can you explain why that isn't the case? The way it works is that glXSwapBuffers() will send the DRI2SwapBuffer request and return immediately. There is not response to the DRI2SwapBuffer request, so it won't block on the X server there. The application is now free to do other processing, loading a new frame of disk and decode it, for example. However, the glXSwapBuffers() call also invalidates the DRI drivers buffers, so once the application wants to render again, it has to call DRI2GetBuffers, which is a round trip, so here we'll block on the X server. This ensures that the X server has seen the DRI2SwapBuffer request before we start rendering again, and provides the application with the buffers it needs for the next frame. This last bit is important, as the server may or may not be able to do a page flip, so the client can't generally predict what the buffer to use for the next frame will be. What I'm proposing over this scheme with the DRI2 event is that instead of requiring the client to call DRI2GetBuffers, we can send out a DRI2 event once the flip happens. This breaks the required roundtrip into a one-way request and an event. Worst case, this still requires the clent to block on receiving the event. However, it also allows the X server to process the DRI2SwapBuffer request and send the event to the client before the client gets around to needing, in which case the round trip disappears. cheers, Kristian ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
