drm/radeon: using libdrm_radeon for a new display server

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

 



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.

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).

Regards,
olv
_______________________________________________
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