https://bugs.freedesktop.org/show_bug.cgi?id=106337
--- Comment #6 from mgorc...@qnx.com <mgorc...@qnx.com> ---
I was able to test your changes and had to add following addition to the
intel_screen.c:
@@ -171,7 +176,7 @@
}
static const struct __DRI2flushExtensionRec intelFlushExtension = {
- .base = { __DRI2_FLUSH, 4 },
+ .base = { __DRI2_FLUSH, 5 },
.flush = intel_dri2_flush,
.invalidate = dri2InvalidateDrawable,
Now I can confirm that it flushes all data to drawable surface and waits for it
properly. Speed has been decreases dramatically, only a bit better than
glFinish(). I think we cannot do too much with it.
Another "issue", which I'm not sure if it is issue or expected behavior,
related to this topic: when FBO is used together with surfaceless contexts.
eglWaitClient() bails out with error if surfaceless contexts are in use to draw
to FBO. Is this expected behavior?
Specification says: "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." and it
doesn't mention "surfaces", only "contexts".
Usually most people create dummy 1x1 pbuffers for FBO rendering, but
surfaceless contexts are more convenient.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug._______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
