DRI2 Design Wiki Page
Hi, I wrote up the DRI2 design on a wiki page here: http://wiki.x.org/wiki/DRI2 It's the result of the discussions we had during my redirected rendering talk and several follow up discussions with Keith Whitwell and Michel Daenzer. Relative to the design I presented, the significant change is that we now track clip rects and buffer attachments in the drm as part of the drm_drawable_t. We always have private back buffers and swap buffers is implemented in the drm. All this taken together (also with the super-ioctl) means that we don't need an SAREA or a drm or drawable lock. There is an issue with the design, though, related to how and when the DRI driver discovers that the front buffer has changed (typically resizing). The problem is described in detail on the page, but in short, the problem is that we were hoping to only check for this at glXSwapBuffers() time, but we need to discover this earlier in many cases. Keith W alluded to a "beginning of frame" synchronization point in a previous mail, which may work, but I'm not sure of the details there. cheers, Kristian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 Design Wiki Page
Hi, On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote: > I wrote up the DRI2 design on a wiki page here: > > http://wiki.x.org/wiki/DRI2 Is that a new DRI version intended to work with Gallium only ? Xav - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 Design Wiki Page
Kristian Høgsberg wrote: > Hi, > > I wrote up the DRI2 design on a wiki page here: > > http://wiki.x.org/wiki/DRI2 > > It's the result of the discussions we had during my redirected > rendering talk and several follow up discussions with Keith Whitwell > and Michel Daenzer. Relative to the design I presented, the > significant change is that we now track clip rects and buffer > attachments in the drm as part of the drm_drawable_t. We always have > private back buffers and swap buffers is implemented in the drm. All > this taken together (also with the super-ioctl) means that we don't > need an SAREA or a drm or drawable lock. > > There is an issue with the design, though, related to how and when the > DRI driver discovers that the front buffer has changed (typically > resizing). The problem is described in detail on the page, but in > short, the problem is that we were hoping to only check for this at > glXSwapBuffers() time, but we need to discover this earlier in many > cases. Keith W alluded to a "beginning of frame" synchronization > point in a previous mail, which may work, but I'm not sure of the > details there. I added a couple of comments, but I'm not sure about the issues around contexts sharing a drawable/backbuffer and the effects of glXSwapBuffers in that case. Brian may be able to help with this a little. Keith - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 Design Wiki Page
Keith Whitwell wrote: > Kristian Høgsberg wrote: >> Hi, >> >> I wrote up the DRI2 design on a wiki page here: >> >> http://wiki.x.org/wiki/DRI2 >> >> It's the result of the discussions we had during my redirected >> rendering talk and several follow up discussions with Keith Whitwell >> and Michel Daenzer. Relative to the design I presented, the >> significant change is that we now track clip rects and buffer >> attachments in the drm as part of the drm_drawable_t. We always have >> private back buffers and swap buffers is implemented in the drm. All >> this taken together (also with the super-ioctl) means that we don't >> need an SAREA or a drm or drawable lock. >> >> There is an issue with the design, though, related to how and when the >> DRI driver discovers that the front buffer has changed (typically >> resizing). The problem is described in detail on the page, but in >> short, the problem is that we were hoping to only check for this at >> glXSwapBuffers() time, but we need to discover this earlier in many >> cases. Keith W alluded to a "beginning of frame" synchronization >> point in a previous mail, which may work, but I'm not sure of the >> details there. > > I added a couple of comments, but I'm not sure about the issues around > contexts sharing a drawable/backbuffer and the effects of glXSwapBuffers > in that case. Brian may be able to help with this a little. > > Keith I believe this is a winsys problem (in gallium architecture) ie the driver interface btw X and dri/drm should take care of resizing the back buffer. For instance make the winsys driver flush current cmd for associated surface, then resize surface. Anyway, i am more concerned by the fact that all this try to move how X handle window and make sure dri client are not forced to use that. In a composite world you don't want to just blit window as simple square but might want to do some wobbly effect (don't ask why i still don't get how anyone can bear wobbly windows more than 5min :)) To do such things tears free i believe you need a back buffer for scanout buffer. You render in the back buffer and once rendering a frame is done you ask for a swap and the swap happen in the kernel btw front and back on next vblank. So i believe that this cliprect stuff should be optional and client should be able to use drm without supplying any cliprect. And also try to avoid to intermingle cliprect and drawable; like making clip rect struct pointing to drm_drawable. Otherwise i am all for the others change (getting rid of sarea and simplifying dri driver :)). Anyway this is my opinion and there might be things i don't understand :) Cheers, Jerome Glisse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 Design Wiki Page
On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote: > There is an issue with the design, though, related to how and when the > DRI driver discovers that the front buffer has changed (typically > resizing). Why would the rendering application even need to know the size of the front buffer? The swap should effectively be under the control of the front buffer owner, not the rendering application. As far as figuring out how big to make the rendering buffers, that's outside the scope of DRM in my book. The GLX interface can watch for ConfigureNotify events on the associated window and resize the back buffers as appropriate. With Composite, we never resize pixmaps, we leave the old ones around and create new ones in the new size. When the last use of the old object is finished, the old pixmap is cleaned up. This means that applications don't have to synchronize their use of the pixmap to potential window size changes. Moving cliprects and buffer tracking into the kernel eliminates the need for an SAREA. The clip rects are only needed on swap buffers; this is done by the kernel, which always has the latest clip rects. You'll still need to lock the swap out while the X server is busy recomputing the clip lists and repainting the rest of the screen. Which means we'll need some kind of lock on the front buffer that the vsync thread grabs before looking at the clip lists. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 Design Wiki Page
On 10/4/07, Keith Packard <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote: > > > There is an issue with the design, though, related to how and when the > > DRI driver discovers that the front buffer has changed (typically > > resizing). > > Why would the rendering application even need to know the size of the > front buffer? The swap should effectively be under the control of the > front buffer owner, not the rendering application. Ok, I phrased that wrong: what the DRI driver needs to look out for is when size of the rendering buffers change. For a redirected window, this does involve resizing the front buffer, but that's not the case for a non-redirected window. The important part, though, is that the drawable size changes and before submitting rendering, the DRI driver has to allocate new private backbuffers that are big enough to hold the contents. > As far as figuring out how big to make the rendering buffers, that's > outside the scope of DRM in my book. The GLX interface can watch for > ConfigureNotify events on the associated window and resize the back > buffers as appropriate. I guess you're proposing libGL should transparently listen for ConfigureNotify events? I don't see how that can work, there is no guarantee that an OpenGL application handles events. For example, glxgears without an event loop, just rendering. If the rendering extends outside the window bounds and you increase the window size, the next frame should include those parts that were clipped by the window in previous frames. X events aren't reliable for this kind of notification. And regardless, the issue isn't so much how to get the resize notification from the X server to the direct rendering client, but rather that the Gallium design doesn't expect these kinds of interruptions while rendering a frame. So while libGL (or AIGLX) may be able to notice that the window size changed, what I'm missing is a mechanism to ask the DRI driver to reallocate its back buffers. > With Composite, we never resize pixmaps, we leave the old ones around > and create new ones in the new size. When the last use of the old object > is finished, the old pixmap is cleaned up. This means that applications > don't have to synchronize their use of the pixmap to potential window > size changes. Sure, I understand. > Moving cliprects and buffer tracking into the kernel eliminates > the need for an SAREA. The clip rects are only needed on swap > buffers; this is done by the kernel, which always has the latest > clip rects. > > You'll still need to lock the swap out while the X server is busy > recomputing the clip lists and repainting the rest of the screen. Which > means we'll need some kind of lock on the front buffer that the vsync > thread grabs before looking at the clip lists. Hmm, true. But that's at least isolated to the DRI module in the X server. Nothing else in userspace will need to take this lock. Kristian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 Design Wiki Page
Keith Whitwell wrote: > Kristian Høgsberg wrote: >> On 10/4/07, Keith Packard <[EMAIL PROTECTED]> wrote: >>> On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote: >>> There is an issue with the design, though, related to how and when the DRI driver discovers that the front buffer has changed (typically resizing). >>> Why would the rendering application even need to know the size of the >>> front buffer? The swap should effectively be under the control of the >>> front buffer owner, not the rendering application. >> >> Ok, I phrased that wrong: what the DRI driver needs to look out for is >> when size of the rendering buffers change. For a redirected window, >> this does involve resizing the front buffer, but that's not the case >> for a non-redirected window. The important part, though, is that the >> drawable size changes and before submitting rendering, the DRI driver >> has to allocate new private backbuffers that are big enough to hold >> the contents. >> >>> As far as figuring out how big to make the rendering buffers, that's >>> outside the scope of DRM in my book. The GLX interface can watch for >>> ConfigureNotify events on the associated window and resize the back >>> buffers as appropriate. >> >> I guess you're proposing libGL should transparently listen for >> ConfigureNotify events? I don't see how that can work, there is no >> guarantee that an OpenGL application handles events. For example, >> glxgears without an event loop, just rendering. If the rendering >> extends outside the window bounds and you increase the window size, >> the next frame should include those parts that were clipped by the >> window in previous frames. X events aren't reliable for this kind of >> notification. >> >> And regardless, the issue isn't so much how to get the resize >> notification from the X server to the direct rendering client, but >> rather that the Gallium design doesn't expect these kinds of >> interruptions while rendering a frame. So while libGL (or AIGLX) may >> be able to notice that the window size changed, what I'm missing is a >> mechanism to ask the DRI driver to reallocate its back buffers. > > I think basically we just need a tweak to what we're already doing for > private backbuffers to cope with the periodic rendering case you've > highlighted. So basically checking before the first draw and again > before swapbuffers, rather than just before swapbuffers. > > This doesn't address the question about contexts in potentially > different processes sharing a backbuffer, but I'm not 100% convinced its > possible, and if it is possible under glx, I'm not 100% convinced that > its a sensible thing to support anyway... Basically what I'm saying above is that 1) I haven't had a chance to dig into the shared-context issue, 2) in my experience GL and GLX specs provide a good amount of wiggle room to allow for a variety of implementation strategies, and 3) we should be careful not to jump to an unfavourable interpretation of the spec that ties us into a non-optimal architecture. I don't think we're looking at a particularly unique or unusual strategy - quite a few GL stacks end up with private backbuffers it seems, so these are problems that have all been faced and solved before. Keith - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 Design Wiki Page
Kristian Høgsberg wrote: > On 10/4/07, Keith Packard <[EMAIL PROTECTED]> wrote: >> On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote: >> >>> There is an issue with the design, though, related to how and when the >>> DRI driver discovers that the front buffer has changed (typically >>> resizing). >> Why would the rendering application even need to know the size of the >> front buffer? The swap should effectively be under the control of the >> front buffer owner, not the rendering application. > > Ok, I phrased that wrong: what the DRI driver needs to look out for is > when size of the rendering buffers change. For a redirected window, > this does involve resizing the front buffer, but that's not the case > for a non-redirected window. The important part, though, is that the > drawable size changes and before submitting rendering, the DRI driver > has to allocate new private backbuffers that are big enough to hold > the contents. > >> As far as figuring out how big to make the rendering buffers, that's >> outside the scope of DRM in my book. The GLX interface can watch for >> ConfigureNotify events on the associated window and resize the back >> buffers as appropriate. > > I guess you're proposing libGL should transparently listen for > ConfigureNotify events? I don't see how that can work, there is no > guarantee that an OpenGL application handles events. For example, > glxgears without an event loop, just rendering. If the rendering > extends outside the window bounds and you increase the window size, > the next frame should include those parts that were clipped by the > window in previous frames. X events aren't reliable for this kind of > notification. > > And regardless, the issue isn't so much how to get the resize > notification from the X server to the direct rendering client, but > rather that the Gallium design doesn't expect these kinds of > interruptions while rendering a frame. So while libGL (or AIGLX) may > be able to notice that the window size changed, what I'm missing is a > mechanism to ask the DRI driver to reallocate its back buffers. I think basically we just need a tweak to what we're already doing for private backbuffers to cope with the periodic rendering case you've highlighted. So basically checking before the first draw and again before swapbuffers, rather than just before swapbuffers. This doesn't address the question about contexts in potentially different processes sharing a backbuffer, but I'm not 100% convinced its possible, and if it is possible under glx, I'm not 100% convinced that its a sensible thing to support anyway... Keith - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
