drm/radeon: using libdrm_radeon for a new display server

[Marek Olšák]

On Mon, Mar 28, 2011 at 9:35 AM, Chia-I Wu <olvaffe at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110328/e02cbede/attachment.htm>