DRI2 Design Wiki Page
glisse at freedesktop.org
Thu Oct 4 07:52:56 PDT 2007
Keith Whitwell wrote:
> Kristian Høgsberg wrote:
>> I wrote up the DRI2 design on a wiki page here:
>> 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.
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
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
More information about the xorg