Tapani Pälli <[email protected]> writes: > On 14.05.2018 10:03, Eric Anholt wrote: >> Tapani Pälli <[email protected]> writes: >> >>> As defined by the spec: >>> "All rendering calls for the currently bound context, for >>> the current rendering API, made prior to eglWaitClient, are >>> guaranteed to be executed before native rendering calls made >>> after eglWaitClient which affect the read or draw surfaces >>> associated with that context. >>> >>> The same result can be achieved using client API-specific calls >>> such as glFinish or vgFinish." >>> >>> v2: call glFinish() to ensure identical behaviour >>> >>> Signed-off-by: Tapani Pälli <[email protected]> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106337 >> >> I don't think the operation they're doing there is "native rendering" as >> far as EGL is concerned. I think the backend flush is the right thing >> for us to be calling here, same as glXWaitGL(). If they want >> glFinish(), they should be calling glFinish(). >> > > Hmm ok .. the problem is that they do CPU read on the buffer which is > not "native rendering" but it seemed to me something that native API > could also attempt to do. I'm OK with 'just use glFinish' also.
To pretend to be "native rendering", the CPU read on the other side should be participating in implicit synchronization. That's what a glamor fallback would be doing in X11, for example.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
