Re: drm/radeon: using libdrm_radeon for a new display server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[Answer myself for some of the questions]

On Mon, Mar 28, 2011 at 3:35 PM, Chia-I Wu <olvaffe@xxxxxxxxx> wrote:
> Hi list,
>
> I have a simple scenario that there are clients rendering to buffer
> objects using the CPU, and the display server compositing the buffers
> using OpenGL and doing page flips to present the final contents. ÂIt
> is like doing the following steps repeatedly
>
> 1) process A (the server) allocates a bo
>
> Â bo = radeon_bo_open(info->bufmgr, 0, size, align, RADEON_GEM_DOMAIN_GTT, 0);
>
> 2) process B (the client) maps the bo for CPU rendering and unmaps
>
> Â radeon_bo_map(bo, 1);
> Â /* ...render with CPU... */
> Â radeon_bo_unmap(bo);
>
> 3) process A renders to the back buffer using the bo as the texture
>
> Â /* renders with OpenGL followed by a glFinish() */
>
> 4) process A flips its front and back buffers
>
> Â drmModePageFlip(fd, crtc_id, fb_id_of_the_bo, 0x0, NULL);
> Â drmWaitVBlank(fd, &vbl); /* HACK! wait until the next vblank */
>
> With this setup, I am seeing glitches frequently. ÂMy hardware is a
> CEDAR. ÂThe kernel is 2.6.38-rc7 and both mesa and drm are from
> master. ÂI originally ran them on a i965-based machine using
> libdrm_i915, and it is fine there.
>
> I think there are sync issues in how I use libdrm_radeon, but I could
> not identify them. ÂHere are my findings/questions
>
> In 1), The bo is initially in the GTT domain because CPU rendering is
> expected. ÂUsing VRAM domain reduces the glitches greatly, but there
> are still glitches and the framerate is much lower.
>
> In 3), glFinish() is called after rendering to make sure the frame is
> complete before page flipping. ÂDoes glFlush() suffice here? ÂI think
> that would require page flipping to be pipelined, but I am not sure if
> that is the case with radeon.
Yes, it should pipelined.  glFlush() suffices here.
>
> In 4), The kernel does not block rendering to the back buffer (which
> was the front buffer before flipping) until the flip takes place. ÂI
> think the kernel driver should be fixed because, in drm_crtc.h, it
> says "the implementation must return immediately and block all
> rendering to the current fb until the flip has completed". ÂTo
> workaround that, I do a drmWaitVBlank() call as a hacky way to wait
> for the flip to complete.
>
> But they still do not explain the glitches I am seeing (with my limited
> understanding of radeon).
The hack in 4) does not work as expected.  The right way to wait for
the page flip to take place is to call drmModePageFlip with
DRM_MODE_PAGE_FLIP_EVENT and do a blocking read.  With this change,
the glitches are gone (visually).  But this is still a workaround and
the kernel driver should be fixed.

> Regards,
> olv
>



-- 
olv@xxxxxxxxxx
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux