Re: [patch] post superioctl inteface removal.

[Jerome G. <gl...@fr...>]

Kristian Høgsberg wrote:
> On 10/18/07, Keith Whitwell <ke...@tu...> wrote:
> ...
>   
>>> Doesn't Kristian changes to DRI interface (DRI2) already allow to
>>> clients to not care
>>> about front buffer. I mean if they all got private back buffer then they
>>> render into it.
>>> But i might have misunderstood this.
>>>       
>> Yes, of course.  I'm not sure how watertight the isolation of the
>> frontbuffer is in DRI2, but if it's complete and if the rule is that ttm
>> supports only DRI2 clients, this concern would seem to be addressed.
>>     
>
> What I'm planning to do is to keep the front buffer bo handle in the
> kernel, associateed with the drm_drawable_t.  The swap buffer ioctl
> will reference a drm_drawable_t as the front buffer destination and
> thus it will always be up to date and userspace won't hold any
> references to front buffers.  The kernel holds a reference through
> each of the drm_drawable_t's that are non-redirected child-windows of
> the front buffer, and once the X server has re-attached the new front
> buffer bo to each drm_drawable_t, there should be no references to the
> front buffer.  This happens in the SetWindowPixmap hook.
>
> It sounds like we want to free the old front buffer before we allocate
> the new one, in which case we'll have to call the SetWindowPixmap hook
> with a null pixmap or something to drop the kernel side references
> before allocating the new buffer.
>
> However, I was hoping we could avoid this, and allocate a new buffer
> while still scanning out from the old one, copy the contents, change
> the scan out address and then free the old one.  This avoids flicker,
> and as for the fragmentation concern; can't we just alternate between
> allocating from different ends of the aperture?  Or alternatively, do
> a two-step operation: allocate a temporary front buffer far enough
> into the aperture that we free the old buffer and then allocate the
> final new frontbuffer at offset 0?  We should avoid turning off the
> crtcs here if at all possible.
>
> cheers,
> Kristian
>   

There is also the following (i don't think it was mentioned before
in this thread):
   card with 8Mo of ram (who the hell have such hw ? :)) a scanout
   buffer which use 4Mo and user resizing to buffer which need 5Mo
   obviously we can't allocate it until we free the previous one... Maybe
   we can accept some kind of allocate over style or simply a resize
   function.

Cheers,
Jerome Glisse