Unable to create egl x11 window in new nvidia docker container (Was: nvdec: "OpenGL context is not CUDA-compatible, fallback to system memory" after creating glimagesink in 1.20.3)

Mon Jul 25 13:11:09 UTC 2022

Thanks!

 > I also believe that for Nvidia docker to work, the Nvidia driver version
 > both inside and outside of the docker image must match exactly.

That caused me a lot of pain a while ago, but it turns out you only have 
to install the driver on the host, and then the container will use the 
host driver, so that's not it.

I checked the differences between the gstglconfig.h files. 18.04 has

#define GST_GL_HAVE_WINDOW_X11 1
#define GST_GL_HAVE_PLATFORM_GLX 1

whereas on 20.04 both of those are false (0) and

#define GST_GL_HAVE_WINDOW_WAYLAND 1

But my host system isn't using Wayland...

(time passes)

Found it! Turns out it was missing *libx11-xcb-dev* for the x11-xcb 
dependency. I was installing *libxcb1-dev* but apparently that's not all 
you need on the newer Ubuntu.

Thanks Matthew!
Michiel

On 25-07-2022 05:27, Matthew Waters wrote:
> There are dependencies for GStreamer's OpenGL that are specific to X11
> and GLX, yes.  GST_DEBUG=3,gl*:7 is a good start for why something may
> not be working however you would need to look at e.g. gstglconfig.h to
> see if Gstreamer's OpenGL was successfully built with X11/ (GLX or EGL)
> support.
>
> I also believe that for Nvidia docker to work, the Nvidia driver version
> both inside and outside of the docker image must match exactly.
>
> Cheers
> -Matt
>
> On 24/7/22 19:23, Michiel Konstapel via gstreamer-devel wrote:
>> I've worked around it by using xvimagesink instead of glimagesink, but
>> I've been trying to narrow this down. It does not appear to be the
>> gstreamer version but the environment.
>>
>> My previous message was mistaken: it used to be Ubuntu 18.04 and the
>> new version is 20.04. I'm not sure I'm on the right track but this
>> seems relevant: I am building and running gstreamer inside Docker
>> containers based on the nvidia/cuda images. When I build/run inside
>> nvidia/cuda:10.2-cudnn7-devel (Ubuntu 18.04) then
>>
>>      gst-launch-1.0 videotestsrc ! glimagesink
>>
>> says
>>
>>      Got context from element 'sink': gst.gl.GLDisplay=context,
>> gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
>>
>> And it shows a window.
>>
>> However, on the nvidia/cuda:11.6.2-cudnn8-devel-ubuntu20.04 base
>> image, it says
>>
>>      Got context from element 'sink': gst.gl.GLDisplay=context,
>> gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayEGL\)\ gldisplayegl0";
>>
>> and it runs, but doesn't show a window.
>>
>> However, xvimagesink works (shows a window) and f.e. glmark2 from
>> inside the container also shows a window - so X11 appears to be
>> available.
>>
>> I've tried to force it:
>>
>>      GST_GL_PLATFORM=egl GST_GL_WINDOW=x11 gst-launch-1.0 -v
>> videotestsrc ! glimagesink
>>
>> But that returns:
>>
>>    (gst-launch-1.0:29): GStreamer-GL-CRITICAL **: 11:16:45.500:
>> gst_gl_display_egl_from_gl_display: assertion 'native_display != 0'
>> failed
>> ERROR: from element
>> /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
>> Failed to create EGLDisplay from native display
>> Additional debug info:
>> ../subprojects/gst-plugins-base/ext/gl/gstglimagesink.c(1101):
>> _ensure_gl_setup ():
>> /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink
>>
>> Am I missing some kind of dependency that will let gstreamer create a
>> GL X11 window?
>>
>> I am setting the DISPLAY environment variable to the same as the
>> host's and binding .Xauthority into the container.
>>
>> Kind regards,
>> Michiel
>>
>> On 18-07-2022 10:38, Michiel Konstapel wrote:
>>> After updating from gstreamer from 1.18.3 to 1.20.3 (and Ubuntu from
>>> 20.04 to 22.04) my pipeline no longer works:
>>>
>>> nvdec gstnvdec.c:1770:gst_nvdec_check_cuda_device_from_context: CUDA
>>> call failed: CUDA_ERROR_INVALID_GRAPHICS_CONTEXT, invalid OpenGL or
>>> DirectX context
>>> nvdec gstnvdec.c:1822:gst_nvdec_ensure_gl_context:<nvh264dec0>
>>> Current OpenGL context is not CUDA-compatible
>>> nvdec gstnvdec.c:646:gst_nvdec_negotiate:<nvh264dec0> OpenGL context
>>> is not CUDA-compatible, fallback to system memory
>>>
>>> (Then negotiation fails because downstream expects memory:GLMemory)
>>>
>>> However, this only happens when there is a glimagesink in the
>>> pipeline. If I take that out, then apparently nvh264dec gets a
>>> context it likes and all is well.
>>>
>>> This gst-launch pipeline works, and prints helpful messages
>>> indicating both get different, suitable contexts?
>>>
>>> gst-launch-1.0 v4l2src device=/dev/video0 ! h264parse ! nvh264dec !
>>> "video/x-raw(memory:GLMemory)" ! glimagesink
>>> Setting pipeline to PAUSED ...
>>> error: XDG_RUNTIME_DIR not set in the environment.
>>> Pipeline is live and does not need PREROLL ...
>>> Got context from element 'sink': gst.gl.GLDisplay=context,
>>> gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayEGL\)\ gldisplayegl0";
>>> Got context from element 'nvh264dec0': gst.cuda.context=context,
>>> gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext0",
>>> cuda-device-id=(int)0;
>>> Pipeline is PREROLLED ...
>>> Setting pipeline to PLAYING ...
>>>
>>> Any clue on how to fix this, or where to start debugging?
>>>
>>> Thanks in advance,
>>> Michiel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220725/b1f9d950/attachment.htm>