| Bug ID | 106302 |
|---|---|
| Summary | [radeonsi] Garbage content when accessing a texture in multip= le 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=
[details]
Isolated test case
Summary:
=3D=3D=3D=3D=3D=3D=3D=3D
On radeonsi, when performing an "asynchronous texture upload" (th=
at 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:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Valid texture content in pbuffer surface of Thread 1.
Actual behavior:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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.
I can reproduce but I don't think it's a bug in Mesa: your cre= ateTexture() 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 enoug= h in this case to fix the issue.
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 curr= ent 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 t= he secondary thread where I expect changes to be seen.
I agree but "D.3.1 Determining Completion of Changes to a= n 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.
Thank you for being exactly on point, it turns out I was using= a frivolous interpretation of "change" rather than the one specified in OpenG= L 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 t= he second thread should yield (0,0,0), since the texture change has not comple= ted yet, and associated texture object is thus incomplete.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | INVALID |