GNOME Bugzilla – Bug 752937
glupload: Raw upload is doing an extra copy
Last modified: 2015-08-16 13:38:13 UTC
Since: commit 82c0189b2842e8729e82a4e73491dffc977bc7c2 Author: Matthew Waters <matthew@centricular.com> Date: Tue Jul 14 17:40:32 2015 +1000 glupload: memcpy on raw data upload The raw uploader is doing an extra copy. This means that we copy the full frame in GST and as we know glTexSubImage2D will also to a copy. This patch also does not add a trace in the performance category even though this has serious performance impact.
Created attachment 308248 [details] [review] Revert "glupload: memcpy on raw data upload" This reverts commit 82c0189b2842e8729e82a4e73491dffc977bc7c2.
Created attachment 308249 [details] [review] glupload: Keep input frame mapped as long as needed When performing a raw upload, we need to keep the raw data mapped as long as needed.
Review of attachment 308248 [details] [review]: .
Review of attachment 308249 [details] [review]: Looks good.
Great, let's do that for now, I'll re-add the FIXME about eventually adding a buffer pool, as I think it was a good idea. Note that if we go for pool, we'll need a different way to attach this reference. In V4L2 pool, I do so using gst_mini_object_set_qdata(). We could do so on each GstGLMemory, which has a GDestroyNotify, and that could be called when memory is destroyed, and then the pool could systematically drop that quark from the memory in the pool reset() function (which also calls the destroy notify function). I'll file an enhancement bug for that.
Attachment 308248 [details] pushed as eb4d3c3 - Revert "glupload: memcpy on raw data upload" Attachment 308249 [details] pushed as adbd9d3 - glupload: Keep input frame mapped as long as needed
commit f79cad55e2a9b7c5057318aa04362bb4277e009a Author: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk> Date: Tue Jul 28 08:59:24 2015 -0400 glupload: Add fixme about using bufferpool for raw http://bugzilla.gnome.org/show_bug.cgi?id=752937