Re: [Mesa-dev] VAAPI encoder and OpenGL

[Thai, Thong]

[AMD Official Use Only - Internal Distribution Only]

Hi Daniel,

Unfortunately, I wasn't able to recreate the issue on a Polaris card, so the 
issue might only be with older hardware. I'll see if there's any updated 
firmware for the Carizzo devices.

Regards,
Thong Thai

From: Daniel Gomez 
Sent: August 4, 2020 9:48 AM
To: Liu, Leo 
Cc: mesa-dev@lists.freedesktop.org ; Zhang, 
Boyuan ; Thai, Thong 
Subject: Re: [Mesa-dev] VAAPI encoder and OpenGL

Hi guys,

any update on this?

Thanks



On Mon, 27 Apr 2020 at 16:23, Daniel Gomez  wrote:
>
> Hi,
>
> We have also try to use VAAPI decoder + OpenGL with mpv with the same effects:
>
> VAAPI + OpenGL example:
> DISPLAY=:0 mpv --hwdec=vaapi --vo=opengl  The\ Simpsons\ Movie\ -\
> 1080p\ Trailer.mp4
> Playing: The Simpsons Movie - 1080p Trailer.mp4
> [osd/libass] Error opening memory font 'fonts.conf'
> [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 0, timescale not set
>  (+) Video --vid=1 (*) (h264 1920x800 23.976fps)
>  Video --vid=2 [P] (png)
>  (+) Audio --aid=1 --alang=und (*) (aac 2ch 44100Hz)
> File tags:
>  Artist: 20th Century Fox
>  Genre: Trailer
>  Title: The Simpsons Movie - Trailer
> [vo/opengl/x11] XOpenIM() failed. Unicode input will not work.
> [vo/opengl/x11] XOpenIM() failed. Unicode input will not work.
> [vo/opengl/vaapi-egl] vaDeriveImage(): invalid VASurfaceID
> [vo/opengl/vaapi-egl] vaDeriveImage(): invalid VAImageFormat
> [ffmpeg] AVHWFramesContext: Failed to create surface: 2 (resource
> allocation failed).
> [ffmpeg] AVHWFramesContext: Unable to allocate a surface from internal
> buffer pool.
> [vo/opengl/vaapi-egl] vaDeriveImage(): invalid VASurfaceID
> [vo/opengl/vaapi-egl] vaDeriveImage(): invalid VAImageFormat
> [ffmpeg] AVHWFramesContext: Failed to create surface: 2 (resource
> allocation failed).
> [ffmpeg] AVHWFramesContext: Unable to allocate a surface from internal
> buffer pool.
> VO does not support requested hardware decoder, or loading it failed.
> ALSA lib ../../../alsa-lib-1.1.8/src/pcm/pcm_dmix.c:1108:(snd_pcm_dmix_open)
> unable to open slave
> [ao/alsa] Playback open error: No such file or directory
> [ao/oss] Can't open audio device /dev/dsp: No such file or directory
> [ao] Failed to initialize audio driver 'oss'
> Could not open/initialize audio device -> no sound.
> Audio: no audio
> VO: [opengl] 1920x800 yuv420p
> V: 00:00:06 / 00:02:17 (4%)
>
> Just opengl or vappi works fine.
>
> VAAPI  example:
> DISPLAY=:0 mpv --hwdec=vaapi --vo=xv  The\ Simpsons\ Movie\ -\ 1080p\
> Trailer.mp4
> Playing: The Simpsons Movie - 1080p Trailer.mp4
> [osd/libass] Error opening memory font 'fonts.conf'
> [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 0, timescale not set
>  (+) Video --vid=1 (*) (h264 1920x800 23.976fps)
>  Video --vid=2 [P] (png)
>  (+) Audio --aid=1 --alang=und (*) (aac 2ch 44100Hz)
> File tags:
>  Artist: 20th Century Fox
>  Genre: Trailer
>  Title: The Simpsons Movie - Trailer
> [vo/xv/x11] XOpenIM() failed. Unicode input will not work.
> [vo/xv] Warning: this legacy VO has bad quality and performance, and
> will in particular result in blurry OSD and subtitles. You should fix
> your graphics drivers, or not force the xv VO.
> VO does not support requested hardware decoder, or loading it failed.
> ALSA lib ../../../alsa-lib-1.1.8/src/pcm/pcm_dmix.c:1108:(snd_pcm_dmix_open)
> unable to open slave
> [ao/alsa] Playback open error: No such file or directory
> [ao/oss] Can't open audio device /dev/dsp: No such file or directory
> [ao] Failed to initialize audio driver 'oss'
> Could not open/initialize audio device -> no sound.
> Audio: no audio
> VO: [xv] 1920x800 yuv420p
> V: 00:00:09 / 00:02:17 (6%)
> Exiting... (Quit)
>
> OpenGL example:
> DISPLAY=:0 mpv --hwdec=no --vo=opengl  The\ Simpsons\ Movie\ -\ 1080p\
> Trailer.mp4
> Playing: The Simpsons Movie - 1080p Trailer.mp4
> [osd/libass] Error opening memory font 'fonts.conf'
> [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 0, timescale not set
>  (+) Video --vid=1 (*) (h264 1920x800 23.976fps)
>  Video --vid=2 [P] (png)
>  (+) Audio --aid=1 --alang=und (*) (aac 2ch 44100Hz)
> File tags:
>  Artist: 20th Century Fox
>  Genre: Trailer
>  Title: The Simpsons Movie - Trailer
> [vo/opengl/x11] XOpenIM() failed. Unicode input will not work.
> [vo/opengl/x11] XOpenIM() failed. Unicode input will not work.
> ALSA lib ../../../alsa-lib-1.1.8/src/pcm/pcm_dmix.c:1108:(snd_pcm_dmix_open)
> unable to open slave
> [ao/alsa] Playback open error: No such file or directory
> [ao/oss] Can't open audio device /dev/dsp: No such file or directory
> [ao] Failed to initialize audio driver 'oss'
> Could not open/initialize audio device -> no sound.
> Audio: no audio
> VO: [opengl] 1920x800 yuv420p
> V: 00:00:01 / 00:02:17 (1%)
> Exiting... (Quit)
>
> On Mon, 27 Apr 2020 at 15:13, Leo Liu  wrote:
> >
> > +Thong.
> >
> > On 2020-04-27 8:29 a.m., Daniel Gomez wrote:
> > > Adding Boyuan Zhang to the thread.
> > >
> > > On Mon, 27 Apr 2020 a

[Mesa-dev] [ANNOUNCE] mesa 20.2.0-rc1

[Dylan Baker]

Hi list,

The mesa 20.2 release cycle is officially underway! A new staging/20.2 and 20.2
branch have been pushed, and 20.2.0-rc1 is now officially available for your
consumption. Please enjoy responsibly.

I'm still planning to have a normal -rc cadence on wednesdays. I do apologize if
I'm a bit slow to respond, especially to email. Please ping me on matrix or irc
if I've missed something from you.

Dylan


git tag: mesa-20.2.0-rc1

https://mesa.freedesktop.org/archive/mesa-20.2.0-rc1.tar.xz
SHA256: fb0f6ed0ae4205da799a2a4a632ab6f7d7c0419d498b4be5d6306037b1a170a1  
mesa-20.2.0-rc1.tar.xz
SHA512: 
d86e52a985d94e3d5b5ef7799acf4fced72df6cd68b29e1fef2c7755144d9633d74f648d8434699497d38b50f0d1a12d12a135a45ea5bc4cf22f2033a3651aac
  mesa-20.2.0-rc1.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-20.2.0-rc1.tar.xz.sig

signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rename "master" branch to "main"?

[Eric Engestrom]

On Tuesday, 2020-08-04 11:27:43 -0500, Jason Ekstrand wrote:
> On Tue, Aug 4, 2020 at 5:54 AM Daniel Stone  wrote:
> >
> > Hi,
> >
> > On Mon, 3 Aug 2020 at 17:16, Jason Ekstrand  wrote:
> > > On Mon, Aug 3, 2020 at 11:12 AM Kenneth Graunke  
> > > wrote:
> > > > Seems reasonable to me...in the old Subversion days, we called it
> > > > 'trunk'...then 'master' with Git...but calling the main development
> > > > branch 'main' is arguably the simplest and most descriptive term.
> > > >
> > > > One thing we'll have to coordinate: getting Gitlab CI / Marge and the
> > > > Intel Mesa CI to switch over at the right time, so we don't end up
> > > > breaking/interrupting those services.  Should be easy, just requires
> > > > a bit of coordination.
> > >
> > > Yup, I threw Daniel onto the CC of this e-mail explicitly for that
> > > reason.  We may also want to coordinate with the rest of fd.o so that
> > > everyone chooses the same new mainline branch name.  I just added
> > > Michel to the CC as he's doing lots of CI stuff and might be a good
> > > person to help coordinate there.  I certainly don't want to pull the
> > > rug out from under anyone.
> >
> > That's fine by me. I think 'main' is a perfectly fine name, and we'd
> > be happy to encode that in whatever useful way. I suppose the main
> > problem with a global nature is the very disparate nature of the
> > projects - getting everyone to move at once before we throw the switch
> > would require a great deal of effort. But we can figure it out.
> 
> I don't think we need to get everyone to sync up necessarily.  It
> probably would be good if we had consistency across projects as to
> what the primary branch is called.  It may also matter from a GitLab
> configuration perspective.  There's some chatter on the GitLab issue
> tracker about allowing different default branch names and I could
> imagine them even adding a per-install default default name.  I don't
> think it's a big deal but something to consider.  Here's the GitLab
> issue for this:
> 
> https://gitlab.com/gitlab-org/gitlab/-/issues/220906
> 
> > As for retargeting MRs; if it can be done manually, then it can be
> > done automatically as well. We can figure out a way to just
> > automatically retarget all the outstanding MRs, but a couple of weeks'
> > leadtime would be good right now.
> 
> It sounds like people are ok with manually re-targetting if they have
> to.  However, if there's a script I can run or coordinate with you to
> run, that'd probably make the process smoother.  As I've said before,
> I don't think we need to rush so if you think that's something someone
> could get put together in a couple weeks or a month, I think it's fine
> to wait for it.  Likely, Mesa isn't the only project on fd.o that's
> going to make a change like this so such a script would probably be
> pretty useful.

There is an upstream issue about having gitlab handle the branch
renaming and provide redirections, MR re-targeting, etc.

https://gitlab.com/gitlab-org/gitlab/-/issues/233427

If we wait for this feature instead of doing it by hand, it could be
much less disruptive to devs and everyone downstream from us, but
there's also no telling how long this will take.

---

Another option might be to keep `master` updated as a read-only copy of
`main`, by having a post-receive hook that looks like this:

   cat refs/heads/main > refs/heads/master

(crude script, can be optimized to only run on `main` changes, but also
this is trivially fast so it might be ok to just leave it like this)

Since we're planning on keeping `master` around forever, why not have it
follow `main`?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev