Bug 109631 - Moving gbm bo from GART to VRAM does not wait for rendering
Summary: Moving gbm bo from GART to VRAM does not wait for rendering
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-14 14:16 UTC by Vincent Vanlaer
Modified: 2019-12-04 09:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Vincent Vanlaer 2019-02-14 14:16:54 UTC
A way to demonstrate this is with the following situation. This assumes that one has opened DRM and EGL devices.

- create a gbm surface with gbm_surface_create and usage GBM_BO_USE_LINEAR
- create an EGLSurface from the gbm surface with eglCreatePlatformWindowSurfaceEXT
- render something to it using GLES
- get the resulting buffer using gbm_bo_lock_front_buffer
- attach it to the hardware cursor using drmModeSetCursor
- the cursor is not displayed

During these steps the following things happen in the DRM driver:
- when the surface is made current using eglMakeCurrent a new bo is created in NOUVEAU_GBM_DOMAIN_GART (due to GBM_BO_USE_LINEAR)
- the rendering operations get queued (and may be flushed with glFlush(), in my specific case this didn't matter)
- when the bo is attached to the cursor plane, it is moved to NOUVEAU_GBM_DOMAIN_VRAM. If the rendering operations haven't finished at this point, the copied buffer is empty.

Note that since this is a timing issue it might not be reproducible in all situations. 
This was tested on different GPUs (GTX 1080 and GT 445M) with rootston (wlroots example wayland compositor: https://github.com/swaywm/wlroots , git commit b2f56ad4) running weston-terminal (this makes the issue appear more frequently)

Probably the driver should wait for pending rendering operations on the surface before moving it around. Another possibility for the scenario listed above is to let the bo start in VRAM, so no moves are necessary. In order to prevent other setups from breaking this would then only be done if GBM_BO_USE_SCANOUT was set on creation. A workaround is to add glFinish() in the application before calling drmModeSetCursor.

Kernel version: 4.20.6
Mesa version: 18.3.3
Comment 1 Martin Peres 2019-12-04 09:48:23 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/480.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.