drm/radeon: using libdrm_radeon for a new display server

Chia-I Wu olvaffe at gmail.com
Tue Mar 29 07:51:41 PDT 2011

On Tue, Mar 29, 2011 at 12:59 AM, Marek Olšák <maraeo at gmail.com> wrote:
> 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).
It turned out to be 4) that causes the glitches.  It is resolved by
using DRM_MODE_PAGE_FLIP_EVENT as mentioned in the last mail.  But
drmModePageFlip still needs to be fixed to block rendering to the
previous scanout buffer until the flip takes place.

> Marek

More information about the dri-devel mailing list