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

[Jason Ekstrand]

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.


> We have bigger problems if X11 today renders to any surface that has
> been externally shared with I915_FORMAT_MOD_Y_TILED_CCS. If I ran
> git-grep correctly, then xf86-video-intel nor xf86-video-modesetting is
> unaware of modifiers and hence unaware of CCS aux state.
>

you're not grepping the right branches. :-)  We do have code floating
around that makes modesetting modifiers-aware.  It's not aware of what the
modifiers mean other than that multi-planar modifiers have racing trouble
and it avoids using them for front-buffer rendering.  That said, I've run a
variety of examples, and I have yet to see any corruption issues.


> So, with respect to reviewing this patch, I think it's safe to assume
> that X11 never renders to a CCS-enabled surface, and that this patch is
> the correct fix. If X11 does render to CCS-enabled surfaces, then we
> have more invasive problems that need fixing.
>

Yes.  In any case, I think the old code was decidedly wrong in the face of
modifiers.


> Reviewed-by: Chad Versace <chadversary at chromium.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170918/1f1ceca9/attachment.html>