| Summary: | [radeonsi] Garbage content when accessing a texture in multiple shared EGL contexts | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | seb |
| Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED INVALID | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 17.2 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Isolated test case | ||
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. 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. 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. 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. |
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.
Created attachment 139204 [details] 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.