Nouveau - Feb 2019 - [Bug 109631] New: Moving gbm bo from GART to VRAM does not wait for rendering

https://bugs.freedesktop.org/show_bug.cgi?id=109631

            Bug ID: 109631
           Summary: Moving gbm bo from GART to VRAM does not wait for
                    rendering
           Product: xorg
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: vincent.vanlaer at skynet.be
        QA Contact: xorg-team at lists.x.org

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20190214/2762d48c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=109631

JM9 <jhnmlkvch9 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unspecified                 |git

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20190215/27368a61/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=109631

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #1 from Martin Peres <martin.peres at free.fr> ---
-- 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191204/900b5577/attachment-0001.html>