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
