gst-gl-plugin: texture share problem and customized GstGLContext/Window

[comic fans]

I create bug for this context share problem here
https://bugzilla.gnome.org/show_bug.cgi?id=725640 ,more test  demo will be
uploaded, hopes this help. Thank you


On Tue, Mar 4, 2014 at 5:41 PM, Matthew Waters <ystreet00 at gmail.com> wrote:

> On 04/03/14 12:35, comicfans44 wrote:
>
>> Hi
>>
>> Matthew Waters <ystreet00 at gmail.com> wrote:
>>
>>  1 :  in Qt GL callback,  use glXGetCurrentContext get current GL
>>>> context ,  I don't know how to get  x11 Display*  from Qt so I
>>>> use XOpenDisplay(getenv("DISPLAY")) to open One
>>>>
>>> Another option is to create your display normally and then pass that
>>> into gst-gl using the GstContext query.
>>>
>>>  3:  pass the GstGLContextGLX*  to a   global variable ,  hack
>>>> gst_gl_context_glx_create_context  to use this variable (which will
>>>> run the share context code path) .    I didn't know how to do this
>>>> step through gst-gl public API , since  GstGLImageSink always call
>>>> gst_gl_context_create  with shared context=0 . GstGLFilter has
>>>> other-context property but I did not always have a GstGLFilter all
>>>> the time.
>>>>
>>> Hmm, it should be possible to add that property to glimagesink, the
>>> workaround, as you suggested, is to use some GstGLFilter subclass
>>> (glcolorscale or gleffects with effect property set to 0).  Also, you
>>> should use gst_gl_context_new_wrapped to wrap an existing GL context.
>>>
>>>  Thanks for advising, but  I'm afraid this also suffered
>> from the random lock problem, since its also goes through the
>> context share code path .I'll try this and report later.
>>
>>  plus , I found that if I draw the  result texture in both
>>>> thread , more random locks.(I wait Qt GL draw completed then draw
>>>> it in clientDrawCallback,so texture is not used at the same time.
>>>> at least at my opengl code level)
>>>>
>>>> so , I wonder if this is a problem in my misused code , or a bug in
>>>> driver?
>>>>
>>> Sounds like a driver bug to me.  Unfortunately I do not have any
>>> radeon GPU's to test with.  You could alternatively try with the mesa
>>> stack (which AMD is contributing to)
>>>
>>>  unfortunately , I tried the mesa but when running program, stdout gives
>> radeon: The kernel rejected CS, see dmesg for more information.
>> dmesg shows:[drm:radeon_cs_parser_relocs] *ERROR* gem object lookup
>> failed 0x39 [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
>> seems that mesa or kernel has some problem. plus draw performance of
>> mesa not satisfied my requirement.
>>
>
> :(. That sounds like the contexts aren't being shared properly, or a
> driver bug.
>
>
>  I can receive gl texture ,but
>>>> the texture id always increases in every buffer receive (seems
>>>> texture never freed ), instead of two id swapping as glimagesink, I
>>>> don't know which part of code does the trick  ?
>>>>
>>> Bufferpools allow the reuse of GstBuffer's.  And GstBuffer's contain
>>> GstMemory's and there's a GstGLMemory which holds a GL texture.
>>> Although that *should* already be used.
>>>
>>>  I tried a pipeline like   videotestsrc -> glfilterblur ->myappsink ,I
>> found the BufferPool usage in glfilter ,but I still found texture not
>> freed. plus there is comment in glfilter.c :790
>>
>>    /* we need at least 2 buffer because we hold on to the last one */
>>    gst_query_add_allocation_pool (query, pool, size, 1, 0);    -->1 or 2?
>>
>> but in gstglimagesink.c:919
>>
>>    /* we need at least 2 buffer because we hold on to the last one */
>>    gst_query_add_allocation_pool (query, pool, size, 2, 0);
>>
>> why this difference? I also tried to change glfilter argument to 2 but
>> texture still not freed.  override appsink's
>> propose_allocation and do as glimagesink, still no luck
>>
>
> The filter comment is wrong, it only needs one.  glimagesink needs 2
> because it (GstVideoSink) holds onto the last buffer for redisplay.
>
>
>  can somebody provide some suggestions? if sharing texture between
>>>> thread (option A) is not stable, should we provide a easier way to
>>>> use custom GstGLContext/GstGLWindow (option B) ?  or how to use
>>>> appsink (option C)to receive buffer and correctly release it ?
>>>> Thanks
>>>>
>>>>
>>>>
>>>>  It would be stupendous if you could file a bug here
>>> https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer against
>>> gst-plugins-gl with the example program/s.
>>>
>> OK, I'll clean my code and post it , Great thanks for suggestion.
>>
>>
> Awesome, thanks.
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140306/13d0e70d/attachment.html>