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

[Eric Anholt]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170918/ab4d4b98/attachment.sig>