After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 751165 - gles2: glBufferSubData is called with GL_PIXEL_UNPACK_BUFFER
gles2: glBufferSubData is called with GL_PIXEL_UNPACK_BUFFER
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal blocker
: 1.5.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-06-18 15:23 UTC by Julien Isorce
Modified: 2015-08-16 13:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
glmemory: fix consistency about pbo availability (1.72 KB, patch)
2015-06-22 13:18 UTC, Julien Isorce
committed Details | Review

Description Julien Isorce 2015-06-18 15:23:51 UTC
When using gles2 I got  "GL ERROR :GL_INVALID_ENUM : glBufferSubData: target was GL_PIXEL_UNPACK_BUFFER"

Indeed it seems gl->BufferSubData is called and with wrong target (on gles2 it only accepts GL_ARRAY_BUFFER or GL_ELEMENT_ARRAY_BUFFER)

GST_GL_PLATFORM=egl GST_GL_API=gles2 GST_GL_WINDOW=x11 gst-launch-1.0 videotestsrc ! glimagesink

It can also be reproduced when configuring gstgl with --disable-glx --disable-opengl --enable-egl --enable-gles2


--- a/gst-libs/gst/gl/gstglbasebuffer.c
+++ b/gst-libs/gst/gl/gstglbasebuffer.c
@@ -263,6 +263,7 @@ gst_gl_base_buffer_upload_cpu_write (GstGLBaseBuffer * mem, GstMapInfo * info,
 
       gl->UnmapBuffer (mem->target);
     } else if (gl->BufferSubData) {
+      g_print("-- gl->BufferSubData with GL_PIXEL_UNPACK_BUFFER ? %d\n", mem->target == 0x88EC /* GL_PIXEL_UNPACK_BUFFER */);
       gl->BufferSubData (mem->target, 0, size, mem->data);
     }
     gl->BindBuffer (mem->target, 0);
Comment 1 Sebastian Dröge (slomo) 2015-06-22 12:15:05 UTC
Do you want to provide a patch that lets it fall back to the other code path for GLES2?
Comment 2 Julien Isorce 2015-06-22 13:18:24 UTC
Created attachment 305830 [details] [review]
glmemory: fix consistency about pbo availability

It fixes the use case I described in first comment. But not sure otherwise.
Comment 3 Sebastian Dröge (slomo) 2015-06-22 13:43:18 UTC
Comment on attachment 305830 [details] [review]
glmemory: fix consistency about pbo availability

I assume you did a short grep to see if the same mistake was done elsewhere?
Comment 4 Julien Isorce 2015-06-22 13:58:29 UTC
I did a quick search but it is not obvious. Maybe in _pbo_download_transfer it should check for CONTEXT_SUPPORTS_PBO_DOWNLOAD. Really unsure without spending more time.
Comment 5 Julien Isorce 2015-06-22 14:14:26 UTC
Comment on attachment 305830 [details] [review]
glmemory: fix consistency about pbo availability

commit 2d62f1c47927a39a02e244e4c981434f08350904
Author: Julien Isorce <j.isorce@samsung.com>
Date:   Mon Jun 22 14:06:04 2015 +0100

    glmemory: fix consistency about pbo availability.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=751165
Comment 6 Julien Isorce 2015-06-22 14:16:08 UTC
Moving target milestone from 1.5.2 to 1.5.3 since it fixes my problem but later download case needs to be checked.
Comment 7 Matthew Waters (ystreet00) 2015-07-20 08:21:45 UTC
commit d13201fedb87100e2fd2c3a9f1363ee2e2c95d97
Author: Matthew Waters <matthew@centricular.com>
Date:   Mon Jul 20 18:19:02 2015 +1000

    glmemory: check for pbo availability before attempting pbo download
    
    https://bugzilla.gnome.org/show_bug.cgi?id=751165