[Bug 106302] [radeonsi] Garbage content when accessing a texture in multiple shared EGL contexts

[Bug 106302] [radeonsi] Garbage content when accessing a texture in multiple shared EGL contexts

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1794 bytes --]

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

            Bug ID: 106302
           Summary: [radeonsi] Garbage content when accessing a texture in
                    multiple shared EGL contexts
           Product: Mesa
           Version: 17.2
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: seb@vestigecounty.com
        QA Contact: dri-devel@lists.freedesktop.org

Created attachment 139204
  --> https://bugs.freedesktop.org/attachment.cgi?id=139204&action=edit
Isolated test case

Summary:
========
On radeonsi, when performing an "asynchronous texture upload" (that is, a
texture upload on a secondary thread and secondary shared EGL context) the
produced texture is not usable on the main thread (contains garbage).

Steps to reproduce:
===================
1. Create an EGL context (with its own pbuffer surface) and make it current on
Thread 1.
2. Create another EGL context (with its own pbuffer surface) and make it
current on Thread 2.
3. Generate and upload a texture on Thread 2.
4. When Thread 2 is finished, pass the texture name to Thread 1.
5. Draw a textured quad on Thread 1 using the texture passed from Thread 2.

Expected behavior:
==================
Valid texture content in pbuffer surface of Thread 1.

Actual behavior:
================
Garbage is observed.

Behavior is observed in stock mesa in Ubuntu 17.10.  Bug is not repro with
software renderer or the i915 driver.  Please use the attached cpp file to
reproduce.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3319 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106302] [radeonsi] Garbage content when accessing a texture in multiple shared EGL contexts

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 541 bytes --]

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

--- Comment #1 from Pierre-Eric Pelloux-Prayer <pierre-eric@damsy.net> ---
I can reproduce but I don't think it's a bug in Mesa: your createTexture()
function doesn't use any synchronization mechanisms so you can't expect the
other thread/context to pick up the changes mades to the texture.

Adding a call to glFlush or glFinish at the end of createTexture() is enough in
this case to fix the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1408 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106302] [radeonsi] Garbage content when accessing a texture in multiple shared EGL contexts

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1127 bytes --]

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

--- Comment #2 from seb@vestigecounty.com ---
Pierre-Eric, in my interpretation of OpenGL(R) ES Version 3.0.5 (November 3,
2016) Specification, Appendix 4: Shared Objects and Multiple Contexts, D.3.
Propagating Changes to Objects, Rule 4:...

----
If the contents of an object T are changed in a context other than the current
context, T must be attached or re-attached to at least one binding point in the
current context, or at least one attachment point of a currently bound
container object C, in order to guarantee that the new contents of T are
visible in the current context.

Example: If a texture image is bound to multiple texture bind points and the
texture is changed in another context, re-binding the texture at any one of the
texture bind points is sufficient to cause the changes to be visible at all
texture bind points.
----

...Finish or Fence are not required, since I am re-binding the texture on the
secondary thread where I expect changes to be seen.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1962 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106302] [radeonsi] Garbage content when accessing a texture in multiple shared EGL contexts

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 769 bytes --]

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

--- Comment #3 from Pierre-Eric Pelloux-Prayer <pierre-eric@damsy.net> ---
I agree but "D.3.1 Determining Completion of Changes to an object" says: "The
contents of an object T are considered to have been changed once a command such
as described in section D.3 has completed. Completion of a command may be
determined either by calling Finish, or by calling FenceSync and executing a
WaitSync command on the associated sync object.".

So in my understanding, the contents of your texture in your example haven't
changed by the end of createTexture() (because the glTexImage command hasn't
completed) so rule 4 isn't relevant.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1656 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106302] [radeonsi] Garbage content when accessing a texture in multiple shared EGL contexts

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 624 bytes --]

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

--- Comment #4 from seb@vestigecounty.com ---
Thank you for being exactly on point, it turns out I was using a frivolous
interpretation of "change" rather than the one specified in OpenGL ES.  The bug
can safely be closed as invalid, as fence is necessary in this case.

One thing that is curious to me still, is whether sampling the texture in the
second thread should yield (0,0,0), since the texture change has not completed
yet, and associated texture object is thus incomplete.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1469 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106302] [radeonsi] Garbage content when accessing a texture in multiple shared EGL contexts

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 460 bytes --]

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

Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> changed:

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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1352 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel