[PATCH] Revert compositor: Queue buffer.release instead of sending immediately

2013-09-11 Thread Neil Roberts 
This reverts commit eccef6aadd142103ed151883e61c0e7a2fd98639.

Queuing the buffer release event instead of posting it immediately
causes problems if the client is not installing a frame callback and
instead is waiting for the buffer release events to throttle its
rendering. This will happen in Mesa when eglSwapInterval is set to
zero so that the client will try to render faster than the compositor
can display the buffers. The client will still want to throttle itself
to the buffer release events in that case so that it doesn't end up
allocating endless amounts of buffers while waiting for the release
events. Without this patch nothing will cause the connection to be
flushed so the client will just block forever.

Conflicts:
compositor/compositor.c
---
 src/compositor.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index 74f0aab..3eb97e0 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1113,8 +1113,8 @@ weston_buffer_reference(struct weston_buffer_reference 
*ref,
ref-buffer-busy_count--;
if (ref-buffer-busy_count == 0) {
assert(wl_resource_get_client(ref-buffer-resource));
-   wl_resource_queue_event(ref-buffer-resource,
-   WL_BUFFER_RELEASE);
+   wl_resource_post_event(ref-buffer-resource,
+  WL_BUFFER_RELEASE);
}
wl_list_remove(ref-destroy_listener.link);
}
-- 
1.8.3.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Revert compositor: Queue buffer.release instead of sending immediately

2013-09-11 Thread Daniel Stone 
Hi,

On 11 September 2013 14:31, Neil Roberts n...@linux.intel.com wrote:
 This reverts commit eccef6aadd142103ed151883e61c0e7a2fd98639.

 Queuing the buffer release event instead of posting it immediately
 causes problems if the client is not installing a frame callback and
 instead is waiting for the buffer release events to throttle its
 rendering. This will happen in Mesa when eglSwapInterval is set to
 zero so that the client will try to render faster than the compositor
 can display the buffers. The client will still want to throttle itself
 to the buffer release events in that case so that it doesn't end up
 allocating endless amounts of buffers while waiting for the release
 events. Without this patch nothing will cause the connection to be
 flushed so the client will just block forever.

Yeah, this is good to me.  Media pipelines also really want release
events ASAP, so they can reuse hardware-decoder buffers.

Cheers,
Daniel

 ---
  src/compositor.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/src/compositor.c b/src/compositor.c
 index 74f0aab..3eb97e0 100644
 --- a/src/compositor.c
 +++ b/src/compositor.c
 @@ -1113,8 +1113,8 @@ weston_buffer_reference(struct weston_buffer_reference 
 *ref,
 ref-buffer-busy_count--;
 if (ref-buffer-busy_count == 0) {
 assert(wl_resource_get_client(ref-buffer-resource));
 -   wl_resource_queue_event(ref-buffer-resource,
 -   WL_BUFFER_RELEASE);
 +   wl_resource_post_event(ref-buffer-resource,
 +  WL_BUFFER_RELEASE);
 }
 wl_list_remove(ref-destroy_listener.link);
 }
 --
 1.8.3.1

 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Revert compositor: Queue buffer.release instead of sending immediately

2013-09-11 Thread Daniel Stone 
Hi,

On 11 September 2013 17:15, Kristian Høgsberg hoegsb...@gmail.com wrote:
 On Wed, Sep 11, 2013 at 02:54:47PM -0400, Daniel Stone wrote:
 Yeah, this is good to me.  Media pipelines also really want release
 events ASAP, so they can reuse hardware-decoder buffers.

 The problem is that this will introduce an immediate event back to the
 client after it's done rendering.  The goal is to be able to have the
 client render receive the frame event and input, update its state and
 render the next frame, attach and commit and then sleep until the next
 frame event.  Sending out the release event immediately will wake it
 up one more time.  Would it work it make mesa send a wl_display.sync
 request following the commit if swapinterval is 0?

Ugh ... given that release isn't (even close to) guaranteed to be
generated instantly, that means you'd just have to (periodically) spam
the server with syncs until you get your release.  The main case I'm
thinking of is external media decode engines, which (as with every
non-APU access on ARM) require physically-contiguous memory.  If you
have large enough input and output resolutions, you end up with very
few buffers and so recycling them quickly becomes pretty imperative in
order to keep your frame rate up.  If you don't deliver releases
quickly enough, sometimes you end up losing frames as the decoder gets
totally starved.

Surely you'd have the same issue on 3D rendering with complex scenes
(which, given the lamentable state of memory bandwidth on some
devices, can equate to 'uses texturing') too, unless (at least)
triple-buffering ... ?

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel