Jason Ekstrand <ja...@jlekstrand.net> writes: > On Mon, Sep 18, 2017 at 9:20 AM, Chad Versace <chadvers...@chromium.org> > wrote: > >> On Thu 14 Sep 2017, Eric Anholt wrote: >> > Jason Ekstrand <ja...@jlekstrand.net> writes: >> > >> > > The setTexBuffer2 hook from GLX is used to implement glxBindTexImageEXT >> > > which has tighter restrictions than just "it's shared". In particular, >> > > it says that any rendering to the image while it is bound causes the >> > > contents to become undefined. This means that we can do whatever aux >> > > tracking we want between glxBindTexImageEXT and glxReleaseTexImageEXT >> so >> > > long as we always transition from external in Bind and to external in >> > > Release. >> > >> > The intent of the spec was to get at the hard-to-define "you get pixels >> > at least as new as the outstanding X11 rendering when you called >> > glxBindTexImageEXT(), but if X11 keeps on rendering to the thing then >> > you may get newer pixels, too." With your CCS plan and X11 rendering in >> > parallel with you GL texturing from the X11 pixmap, will we always see >> > either old or new pixels but not anything else? >> > > That gets interesting... Yes, reading and writing to a CCS image at the > same time is problematic. However, the spec does say "undefined" and not > "either new or old pixels". :-) I'm not sure how this translates into the > real world though.
It would translate into "I see the random garbage on my screen when running a compositor." X11 does not stop rendering to the pixmap when the compositor is trying to texture from it.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
