DRI2 Design Wiki Page

[Jerome Glisse]

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