On Mon, Mar 28, 2011 at 9:35 AM, 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.
glFinish uses fences, which are not implemented in r600g (and there is no wait-for-a-fence ioctl), so glFinish=glFlush. Could that be the cause of your problems? The other radeon drivers use bo_wait for glFinish (including r300g).
Marek
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
