[Bug 770585] glupload: propose dma buffer pool upstream based on ion allocator

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770585

--- Comment #4 from Haihua Hu <jared.hu at nxp.com> ---
(In reply to Matthew Waters (ystreet00) from comment #3)
> Review of attachment 334412 [details] [review]:
> 
> Why is all this needed?  What's wrong with upstream setting all this
> information?  What kind of elements are upstream?

Hi Matthew, I'am so sorry that I have paste the wrong link to ion allocator
thread which is should be：
https://bugzilla.gnome.org/show_bug.cgi?id=768794

> 
> ::: gst-libs/gst/gl/gstglupload.c
> @@ +849,2 @@
>    /* This will eliminate most non-dmabuf out there */
> +  if (!gst_is_dmabuf_memory (gst_buffer_peek_memory (buffer, 0))) {
> 
> What's the difference between this failure case and the raw data uploader?

In the failure case, glupload will create a local dmabuf pool and copy data to
dmabuf so that eglimage can import this dmabuf. While raw data will copy date
to PBO and use PBO upload texture. This two case is the same in most cases but
except some embedded system. For these platforms, PBO has some hardware
limitation such as only specical format(RGBA) can use DMA transform texture
from PBO to GPU and other format will fallback to CPU copy. This will impact
performance.

> 
> @@ +980,3 @@
> +#endif
> +  if (!allocator) {
> +    GST_WARNING ("New ion allocator failed.");
> 
> This warning will occur on all non-ion platforms.

Will change to use DEBUG

> 
> @@ +990,3 @@
> +    goto setup_failed;
> +
> +  gst_query_set_nth_allocation_pool (query, 0, pool, info.size, 1, 30);
> 
> Why were these numbers (1, 30) chosen?

We have a use case in which playbin will load libav decoder for video decoder.
libav decoder will not respect the downstream video alignment and use his own.
This will cause eglCreateImage fail because hardware memory alignment
limitation. But libav decoder will reject this buffer pool when max buffer nums
less than 32, so we set it to 30 and let libav decoder reject our buffer pool
and we do buffer copy in glupload.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.