drm/radeon: using libdrm_radeon for a new display server
Chia-I Wu
olvaffe at gmail.com
Mon Mar 28 00:35:36 PDT 2011
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
More information about the dri-devel
mailing list