Re: EGL Address spaces and Multiple Displays
Pekka Paalanen <[email protected]>
| Newsgroups | gmane.comp.video.mesa3d.user |
|---|---|
| Message-ID | <20201214102129.205ef453@eldfell> |
On Sat, 12 Dec 2020 16:14:02 +0100 Andreas Cord-Landwehr <[email protected]> wrote: > Hi, I am currently looking into driver crashes (https://bugreports.qt.io/ > browse/QTBUG-87597) when using the QtWayland compositor and rendering on two > screens via two EGL fullscreen windows. One of the driver, where I see the > problems, is the i915 via Mesa. > > Since the crashes only occur when the QtWayland compositor renders with > multiple render loops, I assume that there is something wrong with how > resources are managed between the render threads. While digging into it, I > came to Section 2.3 of the EGL 1.5 spec, which states, "EGL objects and > related context state cannot be used outside of the address space in which > they are created". So, my question is: From the Mesa / driver perspective, do > I have to consider displays as different address spaces or can I share > resources like textures between them? Hi, AFAIK, no. Different address spaces essentially means different processes. Threads inside the same process share the same address space, at least unless you do something I don't know was even possible. That sentence you quoted essentially means that you can't take an object handle/id from EGL or GL, send it to another process, and expect it to work. Resource sharing I can't remember, it depends on whether you use distinct EGLDisplays or only distinct EGLContexts. There is more wording in the EGL specification about sharing. Thanks, pq _______________________________________________ mesa-users mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-users
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAl/XIIkACgkQI1/ltBGq qqdS4g/+LDSfa5GOoYmCfX7XSPUyrAfYhjnzr8YN76df7pNuqgIOpdkkIZYEepwZ MtX/nXxuh0S0IZzMEg1PV85gjA1+BGnEVSaPDPdAH3FVJARM62Hwohdv9mdADX2M f/X+rwLVUaI2uH6++a/OA+2BNaLd4+Ckvjo6kLLgolqpQyLHlRZJaqVlxFxRsQCH 8Jv/g4LnGP4zhwmq3HKvc6MPUzHyQkv1J124VcTkbB36wHY2x2VdbB81y2F3io0I 85T4v3iTDwVpE4o8BrV5B5xGSJO+EMyr1EbRQMhEYozmnXL2avsWP0Uq8KHy88cJ 7BAm6JFAMLFJMBany/NtP5ULQfCg2Ib1aDcUiaoLJ3wUC3wbJ0iYhUGL16pqE/fy o09+0xJ3kkt72/NeWcm3ZefUNU0PleGpViiDnzAbaKfke14hhyipRoAPaQyi4bAR rIfPRPJDk5ZXV5HcOnHGHwDcWiC9gtExAYhcpQMU3UqcuwrKV4eT9T1M1CXYU/6N wTMRV4CxSjilAHT7mqPjaoYwg4lqHY1NqhFQwZ7iItheA0LjBHw7sqX+Y/M4nMJb YQVz7FXRP+3/kAOnXbWkcRzDajLD7uJ2RR16BVKNjABjlP3VEqUEhyIe1kZkC7I8 nPkihH613zuorl8j3D2vkHv0fEi0M9hMMvqapqSd6GvYTgl/61U= =2jmy -----END PGP SIGNATURE-----