В сообщении от Thursday 21 May 2020 17:12:21 Phyllis Smith написал(а): > Andrew, > BUT I should have mentioned that there is a problem if the > Settings->Preferences, Playback A, Video Driver is set to X11-OpenGL. > There appears to be some thrashing. I have logged this in BT #434 and am > hoping a Graphics guru can give us a hint of how to avoid this. Using X11 > driver works at really good hardware speed. GG was looking at MPV to try > to avoid this because according to the Forum topic "Multiple GPUs..." it > works just fine there, as well as on the ffmpeg command line. I searched > on the internet and found no clues. We are hoping there is some GL > command to avoid the problem but we are not even close to GL experts.
Additionally .... there seems to be OpenGL/Va-api interop, but it may requre new-ish libva (2.1?) on AMD: https://www.phoronix.com/forums/forum/hardware/graphics-cards/1008578-va-api-1-0-video-acceleration-is-approved-for-fedora-28 (from late 2018) mpv old commit: https://lab.saloun.cz/jakub/mpv/commit/2d58fb3b8e7e87a939220f50a51294f8efdc51e1 6 years ago it was said " VA-API's OpenGL/GLX interop is pretty bad and perhaps slow (renders a X11 pixmap into a FBO, and has to go over X11, probably involves one or more copies), and this code serves more as an example, rather than for serious use. On the other hand, this might be work much better than vo_vaapi, even if slightly slower." new code uses EGL, according to comment (if I read it correctly) https://keybase.pub/chittunoo/githubchittunoo/mpv/libmpv/opengl_cb.h /** * Windowing system interop on Intel/Linux with VAAPI * -------------------------------------------------- * * The new VAAPI OpenGL interop requires an EGL context. EGL provides no way * to query the X11 Display associated to a specific EGL context, so this API * is used to pass it through. I think in Cin's case those only can be used with direct mode (no effects), still, if there way to make va-api *encoder* to eat OpenGL/EGL textures directly .. May be something like gl_draw_buffers ? https://stackoverflow.com/questions/30025009/in-opengl-is-it-possible-for-one-shader-program-in-one-draw-call-to-render-to for making data available both for GPU encoder and display? https://github.com/intel/libva/issues/271 Add an API to copy OpenGL textures into VA surfaces #271 Unfortunately not completely answered ... from 2017 ... https://ml01.01.org/hyperkitty/list/intel-vaapi-media%40lists.01.org/message/O6KKFTX66H6T3OTODFQFW6IUOJE244ZO/ ----copy--- Re: [intel-vaapi-media] Direct encoding of RGBA surface formats Sreerenj Понедельник, 25 Сентябрь 2017 Пн, 25 Сен '17 11:45 Hi Matt, The intel-vaapi-driver only supports YUV420 (and it'z 10 bit variant too) chroma for encoding except JPEG encode. Actually restriction is not just YUV420, it only support NV12 format (and the 10 bit variant too). But driver has a work around to convert any non-NV12 format to NV12 internally. So ideally other input formats can work too. Unfortunately there is a performance issue here: the internal conversion using an AVS sampler for Color space conversion which is not optimal when comparing with explicit VPP which uses 3D sampler. So I would recommend to use an explicit vpp (eg: vaapipostproc in gstreamer) for colorspace conversion before encode. On 09/25/2017 09:33 AM, Matt Fischer wrote: ... This is a question about gstreamer-vaapi as well as libva-intel-driver. I hope this is the right list for those components...if not, please let me know where I ought to ask it instead. I have a situation where I'd like to encode video using the gstreamer-vaapi plugins that's in plain RGBA format (it's coming out of an OpenGL rendering pipeline). As it stands now, though, the encoder plugins refuse to set up a pipeline for any format other than YUV 4:2:0/4:2:2. This is enforced both by an explicit check in gstvaapiencoder.c (the is_chroma_type_supported() function), as well as by querying the VAConfigAttribRTFormat attribute from the underlying vaDisplay. Just for curiosity's sake, I tried adding the RGB32 format both into the gstreamer check, as well as into the list of allowed chroma formats down in libva-intel-driver (in i965_drv_video.c in the i965_get_default_chroma_formats() function). To my surprise, this seemed to work correctly. The encoded video played back with correct colors, suggesting that the underlying i965 encoding hardware is capable of accepting RGB formats and doing the appropriate color conversions. If this is true, is there any chance of adding official support for RGB formats in the way that my hack did? It's quite useful to be able to connect OpenGL rendering into the VAAPI pipeline, and the addition of RGBA support appears to make that possible. Are there limitations that would make this difficult, or is the lack of RGBA support thus far just an oversight? Thanks, Matt _______________________________________________ intel-vaapi-media mailing list intel-vaapi-media(a)lists.01.org https://lists.01.org/mailman/listinfo/intel-vaapi-media --copy end-- so, sorry if it looks very sketchy .... but this is all I was bale to find (no Intel / AMD card to test any of it, yet) Also, for Intel graphics there are two mesa drivers right now: i965 and gallium-based Iris https://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.0-Default-Build-Iris Intel's "Iris" Gallium3D driver is still making good progress in its goal for Mesa 20.0 to switch the default "i965" classic driver to Intel Gallium3D for Broadwell and newer hardware. If I remember correctly Phyllis have Broadwell-based GPU in laptop .... So, GALLIUM_HUD thing probably only will work with new-ish mesa. sorry for not saying this earlier > > On Thu, May 21, 2020 at 7:25 AM Andrew Randrianasulu < > randrianas...@gmail.com> wrote: > > > В сообщении от Thursday 21 May 2020 16:18:49 Phyllis Smith написал(а): > > > Andrew: > > > > > > > Is there anything relevant for Cin's internal working (in case when hw > > > > decoder is used)? > > > > > > > > > > Quoting GG this morning: > > > "Not especially. It appears as a normal codec. > > > But the data path is through the hardware." > > > > > > > Ah, ok (I thought may be libavcodec was picking slow path in this case) > > > > Have good morning/day! > > -- > > Cin mailing list > > Cin@lists.cinelerra-gg.org > > https://lists.cinelerra-gg.org/mailman/listinfo/cin > > > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
