[Mesa-dev] [PATCH 4/4] i965: Use prepare_external instead of make_shareable in setTexBuffer2

[Jason Ekstrand]

On Mon, Sep 18, 2017 at 10:12 AM, Eric Anholt <eric at anholt.net> wrote:

> Jason Ekstrand <jason at jlekstrand.net> writes:
>
> > On Mon, Sep 18, 2017 at 9:20 AM, Chad Versace <chadversary at chromium.org>
> > wrote:
> >
> >> On Thu 14 Sep 2017, Eric Anholt wrote:
> >> > Jason Ekstrand <jason at 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.
>

Adding Daniel and LFRB.  I don't know if the current X code for modifiers
usess them when creating surfaces for X to render into.  I think it
probably only uses modifiers for surfaces that come in through DRI3 +
present in which case there shouldn't be X rendering to buffers with CCS.
If there is, I think we should consider that a bug just as much as doing
front-buffer rendering to CCS.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170918/a4c9ca80/attachment.html>