New issue
Advanced search Search tips

Issue 785201 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

Enable VaapiDrmPicture on more cases

Project Member Reported by julien.isorce@chromium.org, Nov 15 2017

Issue description

Currently the existing VaapiTFPPicture(GLX) works fine on linux desktop (non-ozone) but it does not work when using EGL.

The solution is to enable VaapiDrmPicture on non-ozone and use it when the user has passed the cmd line argument --use-gl=egl.

In order to enable this we need to use the extension EGL_MESA_image_dma_buf_export. The sequence will be:
 1- vaGetDisplayDRM
 2- Export output gl texture as dmabuf (through EGLImage)
 3- Import dmabuf into output VA surfaces.

Existing sequence for Ozone is:
 1- vaGetDisplayDRM
 2- Create Dumb buffer (ioctl) and export it as dmabuf (gbm_bo_get_fd).
 3- Import dmabuf into output gl texture (through EGLImage).
 4- Import dmabuf into output VA surfaces.

As you can see only step 2) from the first sequence above is missing in current Chromium. Everything else is already in place.

In order to prove that it can work I went ahead and I implemented it. See step 2) here https://chromium-review.googlesource.com/c/chromium/src/+/766787/8/media/gpu/vaapi/vaapi_drm_picture.cc#125

To sum up, vaapi is already working on non-ozone in current Chromium but it requires GLX (VaapiTFPPicture(GLX)), i.e. --use-gl=desktop.
I am suggesting to extend the vaapi support to --use-gl=egl.

 
Cc: sande...@chromium.org
Project Member

Comment 2 by bugdroid1@chromium.org, Nov 22 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a9dd08addbd53885176f45a205ea992ee815961c

commit a9dd08addbd53885176f45a205ea992ee815961c
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Wed Nov 22 20:22:40 2017

Allow DRM and TFP pictures support to be compiled in together

No functional change. This is useful to select DRM(egl) or TFP(glx)
at runtime, i.e. with --use-gl=egl or --use-gl=desktop.

This is a preliminary step for the subsequent CL
https://chromium-review.googlesource.com/c/chromium/src/+/766787

Bug:  785201 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I6963187b88c3c69da8584e2cc7d14d709ac2fc17
Reviewed-on: https://chromium-review.googlesource.com/785690
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518726}
[modify] https://crrev.com/a9dd08addbd53885176f45a205ea992ee815961c/media/filters/BUILD.gn
[modify] https://crrev.com/a9dd08addbd53885176f45a205ea992ee815961c/media/gpu/BUILD.gn
[modify] https://crrev.com/a9dd08addbd53885176f45a205ea992ee815961c/media/gpu/vaapi/vaapi_drm_picture.cc
[modify] https://crrev.com/a9dd08addbd53885176f45a205ea992ee815961c/media/gpu/vaapi/vaapi_picture.cc
[modify] https://crrev.com/a9dd08addbd53885176f45a205ea992ee815961c/media/gpu/vaapi/vaapi_tfp_picture.cc
[modify] https://crrev.com/a9dd08addbd53885176f45a205ea992ee815961c/media/gpu/vaapi_video_decode_accelerator.cc
[modify] https://crrev.com/a9dd08addbd53885176f45a205ea992ee815961c/media/gpu/vaapi_wrapper.cc
[modify] https://crrev.com/a9dd08addbd53885176f45a205ea992ee815961c/media/gpu/vaapi_wrapper.h

Comment 3 by mcasas@chromium.org, Nov 24 2017

Do we have any bot combination of Linux + --use-gl=egl ?
Project Member

Comment 4 by bugdroid1@chromium.org, Nov 28 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/65e985d72d99fad9c5aae48ef7759c03a441f770

commit 65e985d72d99fad9c5aae48ef7759c03a441f770
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Tue Nov 28 10:15:21 2017

Remove unnecessary ozone guard around libva-drm.so

This is non-ozone specific and this will help maintenance.

Also this is useful to select DRM(egl) or TFP(glx) at runtime,
i.e. with --use-gl=egl or --use-gl=desktop.

Note that a switch(gl::GetGLImplementation()) is not practicable
here because of the way generate_stubs.py works.

This is another preliminary step for the subsequent CL
https://chromium-review.googlesource.com/c/chromium/src/+/766787

Bug:  785201 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Icc4f2c6a0ff448ce1507798bfbc708d2fe16ff29
Reviewed-on: https://chromium-review.googlesource.com/787432
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519636}
[modify] https://crrev.com/65e985d72d99fad9c5aae48ef7759c03a441f770/media/gpu/vaapi_wrapper.cc

Project Member

Comment 5 by bugdroid1@chromium.org, Nov 28 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8580c2220857886dcfa8fea7374bcc559a291416

commit 8580c2220857886dcfa8fea7374bcc559a291416
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Tue Nov 28 12:11:32 2017

Can select DRM(egl) or TFP(glx) at runtime for vaapi video decoding

Fixes overlap with https://chromium-review.googlesource.com/767375

Added unit test this time.

This is a preliminary step for the subsequent CL
https://chromium-review.googlesource.com/c/chromium/src/+/766787

Bug:  785201 ,  788123 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I70620697109fdef7d036be4c26fcecb763ddb4ba
Tests: media_unittests --gtest_filter=*Vaapi*SupportedPlatforms*
Reviewed-on: https://chromium-review.googlesource.com/788051
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519657}
[modify] https://crrev.com/8580c2220857886dcfa8fea7374bcc559a291416/media/gpu/vaapi/vaapi_picture.cc
[modify] https://crrev.com/8580c2220857886dcfa8fea7374bcc559a291416/media/gpu/vaapi/vaapi_picture_factory.cc
[modify] https://crrev.com/8580c2220857886dcfa8fea7374bcc559a291416/media/gpu/vaapi/vaapi_picture_factory.h
[modify] https://crrev.com/8580c2220857886dcfa8fea7374bcc559a291416/media/gpu/vaapi_video_decode_accelerator_unittest.cc

Project Member

Comment 6 by bugdroid1@chromium.org, Nov 29 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/73d609f366ba6a86324048bbad81527f76d237b5

commit 73d609f366ba6a86324048bbad81527f76d237b5
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Wed Nov 29 09:34:41 2017

Add RGBX to gfx va converters

When decoding into the gl texture RGB, vaapi needs to output RGBX.

Also move format constants to VaapiPictureFactory.

This is another preliminary step for the subsequent CL
https://chromium-review.googlesource.com/c/chromium/src/+/766787

Bug:  785201 
Tests: media_unittests --gtest_filter=*Vaapi*PictureBufferFormat*

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ibd1b0f249f104fa40608b951a14cb76da4a5974d
Reviewed-on: https://chromium-review.googlesource.com/787290
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520051}
[modify] https://crrev.com/73d609f366ba6a86324048bbad81527f76d237b5/media/gpu/format_utils.cc
[modify] https://crrev.com/73d609f366ba6a86324048bbad81527f76d237b5/media/gpu/vaapi/vaapi_drm_picture.cc
[modify] https://crrev.com/73d609f366ba6a86324048bbad81527f76d237b5/media/gpu/vaapi/vaapi_picture_factory.cc
[modify] https://crrev.com/73d609f366ba6a86324048bbad81527f76d237b5/media/gpu/vaapi/vaapi_picture_factory.h
[modify] https://crrev.com/73d609f366ba6a86324048bbad81527f76d237b5/media/gpu/vaapi_video_decode_accelerator.cc
[modify] https://crrev.com/73d609f366ba6a86324048bbad81527f76d237b5/media/gpu/vaapi_video_decode_accelerator_unittest.cc
[modify] https://crrev.com/73d609f366ba6a86324048bbad81527f76d237b5/media/gpu/vaapi_wrapper.cc

Comment 7 by mcasas@chromium.org, Nov 30 2017

Cc: dcasta...@chromium.org dalecur...@chromium.org acourbot@chromium.org
I'd like to follow up on the comments of https://crrev.com/c/766787,
concretely [1] and [2].

Chromium is a large project and has plenty of downstream sub projects
and ongoing refactorings and sub projects but, in general, we don't
host code that is not shipped _and_ has no plans to be shipped in any
near future.  With that, let's follow the facts:

1. IIUC, hardware accelerated video decoding (and encoding, for the case)
is disabled by default in Linux (except CrOs), has been so for a long
time, and will not be enabled in the foreseeable future, see: 
 https://crbug.com/137247 .

2. IIUC, VaapiTfpPicture is only used in Linux non-CrOs platforms, for
Vaapi acceleration purposes, correct? 

If Chrome never uses Hw decode acceleration in Linux, it follows from 1
and 2 that we never use any vaapi_* files in Linux in "production", i.e. 
it's not shipped. (Although we compile those files in some bots because,
well, they the files are there now).

Something else is that, perhaps, some downstream Cr embedders might be
using this functionality? Or some users might enable it via flags?
This is a circumstance that:
 a) Chromium doesn't support actively
 b) Chromium tries not to break unexpectedly, but see a)

Take into account that the majority of users don't use Chrome command line
flags beyond whatever is hardcoded by us in chrome://version/. 

An example of how things are done to support a downstream project
without having to carry the code ourselves is Geolocation [3, 4].

Summing up, either we (plan to) support the Vaapi Linux code path 100% or 
we don't support it at all.

(When I say "Linux" I mean non-CrOs Linux).


[1] https://chromium-review.googlesource.com/c/chromium/src/+/766787#message-67edc5ee8cf34cdc4f9d559317daafec3a3bdec0
[2] https://chromium-review.googlesource.com/c/chromium/src/+/766787#message-ba65d17348c54009ac6426571b830c7d1c495192
[3] https://cs.chromium.org/chromium/src/content/public/browser/content_browser_client.h?type=cs&q=OverrideSystemLocationProvider&l=499
[4] https://codereview.chromium.org/2126893003/diff/120001/content/public/browser/geolocation_delegate.h
Good points. There has to be some intermediate steps between "not supporting Vaapi on Linux at all" and "supporting the Vaapi Linux code path 100%" though.

Ultimately, support for Vaapi on Linux *is* desirable. 4k (and more) decoding on the CPU is still painful, and libva provides a good interface to improve that. IIUC the main reason why it is not enabled on Linux is because we still need external patches and bug fixes on Chromium OS to make it work, and the libva ABI used to unexpectedly change between stable releases. These two points make libva on Linux more of a liability than anything.

On Chromium OS, we have full control over the sysroot and compiled packages, so we can mitigate these issues. And the fact is that libva works pretty well there and is heavily tested with Intel GPUs.

So provided that libva improves on the two fronts I mentioned above, support on Linux desktop should not be too painful. It just happens that the libva 2.0 series *should* remain completely ABI-stable. We still need to integrate a few external patches.

However, I can see a near future where, while not supporting this use case and requiring explicit activation, libva could be enabled on Linux desktop builds. If the experiment goes well, we could even switch to full support.

There is a huge intersection with the Chrome OS use case, so I am willing to help sandersd@ on this if he is ok with that plan.

Looking at the latest comments on https://chromium-review.googlesource.com/c/chromium/src/+/766787, it seems like our stance is becoming "we don't support that, but we won't hinder and are willing to see how it goes". Is that fair enough?
Project Member

Comment 9 by bugdroid1@chromium.org, Dec 5 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/51357dc19efbf30328ca05655fbf69886f6e9113

commit 51357dc19efbf30328ca05655fbf69886f6e9113
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Tue Dec 05 23:39:45 2017

Allow RGBX for VaapiTFPPicture

Fixes regression on non-ozone platforms and introduced by
  73d609f366ba6a86324048bbad81527f76d237b5
  https://chromium-review.googlesource.com/787290

Note that the format is only used for sanity check. All the logic is
done automatically in the vaapi driver's implementation of vaPutSurface.

Bug:  785201 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Idc0bdf184874bf2c238e28da6f42f4e3572e9743
Reviewed-on: https://chromium-review.googlesource.com/807928
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521897}
[modify] https://crrev.com/51357dc19efbf30328ca05655fbf69886f6e9113/media/gpu/vaapi/vaapi_tfp_picture.cc

Project Member

Comment 10 by bugdroid1@chromium.org, Dec 6 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4c259455066d41ac777613d0d44506c04d13dd57

commit 4c259455066d41ac777613d0d44506c04d13dd57
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Wed Dec 06 09:36:02 2017

Can export a gl texture as dmabuf

First create an EGLImage from a given gl texture.
Then export the EGLImage as dmabuf.

In addition to the new unit test included in this CL,
this will be useful for the subsequent CL,
https://chromium-review.googlesource.com/c/chromium/src/+/766787
which will enable existing VaapiDrmPicture when passing --use-gl=egl.
While existing VaapiTFPPicture(X11) will be left for --use-gl=desktop.

Added unit test ui/gl/gl_image_native_pixmap_unittest.cc
The test is enabled on non-ozone but should work on ozone too.
If any of the pre-conditions fail then the test is skipped.
Specifically it requires the extension EGL_MESA_image_dma_buf_export.
So it works on Intel, AMDGPU and nouveau drivers but skipped on NVIDIA.

Bug:  785201 
Test: gl_unittests --gtest_filter=*NativePixmap*

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Id9b4e56aaaaf5fd9994f4b144ce74a234d848253
Reviewed-on: https://chromium-review.googlesource.com/766687
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522052}
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/gpu/ipc/service/gpu_memory_buffer_factory_android_hardware_buffer.cc
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/BUILD.gn
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/generate_bindings.py
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/gl_bindings_api_autogen_egl.h
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/gl_bindings_autogen_egl.cc
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/gl_bindings_autogen_egl.h
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/gl_image_ahardwarebuffer_unittest.cc
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/gl_image_egl.cc
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/gl_image_egl.h
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/gl_image_native_pixmap.cc
[modify] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/gl_image_native_pixmap.h
[add] https://crrev.com/4c259455066d41ac777613d0d44506c04d13dd57/ui/gl/gl_image_native_pixmap_unittest.cc

julien.isorce@ I have a question, you said 
"... GLX (VaapiTFPPicture(GLX)), i.e. --use-gl=desktop.
I am suggesting to extend the vaapi support to --use-gl=egl."

In which circumstances would a user want to use one or the 
other? IOW, would it be better (more performant and/or more
maintainable) to switch to EGL altogether? Or is this a runtime
config that would only be exercised if we run with the command
line options to force-using-hardware-accelerated-video-decoding
(don't remember the exact name) and --use-gl=egl ?





 
Project Member

Comment 12 by bugdroid1@chromium.org, Dec 11 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bc2855ec135981984ae905cf9fe2c0de9fcfde76

commit bc2855ec135981984ae905cf9fe2c0de9fcfde76
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Mon Dec 11 19:29:00 2017

Use the generic VaapiPictureFactory::GetGLTextureTarget

Instead of hardcoding GL_TEXTURE_EXTERNAL_OES or GL_TEXTURE_2D

This will be useful for the subsequent CL,
https://chromium-review.googlesource.com/c/chromium/src/+/766787

Bug:  785201 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I2678181b4b9389c39999d07cb9e56c102fc5f299
Tests: media_unittests --gtest_filter=*VaapiVideoDecodeAcceleratorTest*
Reviewed-on: https://chromium-review.googlesource.com/819131
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523168}
[modify] https://crrev.com/bc2855ec135981984ae905cf9fe2c0de9fcfde76/media/gpu/vaapi/vaapi_drm_picture.cc
[modify] https://crrev.com/bc2855ec135981984ae905cf9fe2c0de9fcfde76/media/gpu/vaapi/vaapi_drm_picture.h
[modify] https://crrev.com/bc2855ec135981984ae905cf9fe2c0de9fcfde76/media/gpu/vaapi/vaapi_picture.cc
[modify] https://crrev.com/bc2855ec135981984ae905cf9fe2c0de9fcfde76/media/gpu/vaapi/vaapi_picture.h
[modify] https://crrev.com/bc2855ec135981984ae905cf9fe2c0de9fcfde76/media/gpu/vaapi/vaapi_picture_factory.cc
[modify] https://crrev.com/bc2855ec135981984ae905cf9fe2c0de9fcfde76/media/gpu/vaapi/vaapi_picture_factory.h
[modify] https://crrev.com/bc2855ec135981984ae905cf9fe2c0de9fcfde76/media/gpu/vaapi/vaapi_tfp_picture.cc
[modify] https://crrev.com/bc2855ec135981984ae905cf9fe2c0de9fcfde76/media/gpu/vaapi/vaapi_tfp_picture.h
[modify] https://crrev.com/bc2855ec135981984ae905cf9fe2c0de9fcfde76/media/gpu/vaapi/vaapi_video_decode_accelerator.cc
[modify] https://crrev.com/bc2855ec135981984ae905cf9fe2c0de9fcfde76/media/gpu/vaapi/vaapi_video_decode_accelerator_unittest.cc

#c11, mcasas@: Chromium defaults to glx (i.e. --use-gl=desktop) on Linux Desktop X11. So yes currently this is a runtime config that would only be exercised if we run with the command line --disable-gpu-sandbox --ignore-gpu-blacklist --use-gl=egl

I think the long term plan is to use --use-gl=angle by default  on all platforms (MANGLE project). Note that --use-gl=angle sets gl::GLImplementation = kGLImplementationEGLGLES2 like --use-gl=egl.

If I am not mistaken the above effort is completed for Windows (Though not enabled for all drivers crbug.com/693090), almost for Linux (works but not default yet crbug.com/522133) and on going for Mac (crbug.com/757974)

Note that this current issue will benefit Chromium for Linux Desktop on Wayland as it defaults to egl and ofcourse no glx on Wayland (Wayland support in Chromium is an on going work but nearly there, there is a few cr bugs for it). I will just need to refactor the changes in vaapi_drm_picture.cc with Ozone a little bit more but all other CLs will be used as it is.

At some points I believe vaapi_tfp_picture.cc (glx) will be removed so it should be easier to maintain as you mentioned. Also vaapi_drm_picture.cc (egl) is faster in theory but the path X Pixmap to gl texture is well optimized nowadays (gl_image_glx.cc) so the overhead is negligible.

Once this bug is completed I will add support for VaapiDrmPicture with --use-gl=angle too. It should be straightforward because angle is alsmot a 'passthrough' to egl. I believe I will just need to add some plumbing in Angle project to map all required extensions that are not already mapped.


#13, julien.isorce@:OK, that makes sense, IIUC in time we'll use MANGLE
and that'll boil down to EGL and that will use your code path, so that's
cool EGL-wise. That's one half of the landscape.

We still have the situation that Vaapi*Pictures are only used by the 
VaAPI video encode/decode accelerators, correct? Hence users would 
need to explicitly pass the command line flags

  "--disable-gpu-sandbox --ignore-gpu-blacklist"

in order to use the Vaapi*Pictures. I guess my question/concern is that 
the latter code depends on another chunk of code, the video decode 
acceleration support, that is not supposed to be used nor maintained, if 
I'm reading  crbug.com/137247  and crbug.com/590209 correctly, or has 
something changed, or what's the plan here? 
Project Member

Comment 16 by bugdroid1@chromium.org, Dec 19 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1e2bbbdf6ae30470ff59f9fb556be642e2784178

commit 1e2bbbdf6ae30470ff59f9fb556be642e2784178
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Tue Dec 19 23:52:34 2017

Fix random crashes in gl_unittests when passing --single-process-tests

EGLApiTest calls ClearBindings() which set eglTerminateFn to null
but left g_display not null.
So the next call to gl::init::ShutdownGL will crash because it calls
eglTerminate from GLSurfaceEGL::ShutdownOneOff.

[ RUN      ] EGLApiTest.DisabledExtensionBitTest
[       OK ] EGLApiTest.DisabledExtensionBitTest
[ RUN      ] GLContextGLXTest.DoNotDestroyOnFailedMakeCurrent
Received signal 11 SEGV_MAPERR 000000000000
  gl::GLSurfaceEGL::ShutdownOneOff()
  gl::init::ShutdownGLPlatform()
  gl::init::ShutdownGL()
  gl::GLSurfaceTestSupport::InitializeOneOffImplementation()
  gl::GLImageTestSupport::InitializeGL()
  gl::GLContextGLXTest_DoNotDestroyOnFailedMakeCurrent_Test::TestBody()
  testing::Test::Run()

Depending on the execution order the crash does not happen making
the tests flaky.

The solution is to call init::ShutdownGL which internally calls
ClearBindings but it also makes sure to reset g_display first.

Bug:  785201 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I388be6271c03b10f5f23355539cb05104db945b1
Tests: gl_unittests --single-process-tests
Reviewed-on: https://chromium-review.googlesource.com/834028
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525188}
[modify] https://crrev.com/1e2bbbdf6ae30470ff59f9fb556be642e2784178/ui/gl/egl_api_unittest.cc
[modify] https://crrev.com/1e2bbbdf6ae30470ff59f9fb556be642e2784178/ui/gl/gl_egl_api_implementation.cc
[modify] https://crrev.com/1e2bbbdf6ae30470ff59f9fb556be642e2784178/ui/gl/gl_surface_egl.cc

Project Member

Comment 17 by bugdroid1@chromium.org, Dec 20 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7089b2da3e207e29d0124e3ac6907cc2f25138e1

commit 7089b2da3e207e29d0124e3ac6907cc2f25138e1
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Wed Dec 20 11:19:59 2017

Add specific initialisers to GLImageEGL's childs

GLImageAHardwareBuffer:
    bool Initialize(AHardwareBuffer* buffer, bool preserved)

GLImageNativePixmap:
    bool Initialize(uint32_t texture_id)

Not keeping the same signature as GLImageEGL::Initialize
to indicate how it is used. And if needed, more initialisers
can be added.

This prevents the user from doing mistakes when
instantiating a subclass of GLImageEGL but calling
the parent's initialiser.

For consolidation this CL also moves GLImageEGL::Initialize
from public to protected.

Note that GLImageEGL cannot be instantiated directly
because it does not implement a few pure virtual functions
it got from its parent, gl::GLImage.

Bug:  785201 
Test: gl_unittests --gtest_filter=*NativePixmap*
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ida5834bbf964893680f449f1f5da7371e46075bc
Reviewed-on: https://chromium-review.googlesource.com/817563
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Reviewed-by: David Reveman <reveman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525307}
[modify] https://crrev.com/7089b2da3e207e29d0124e3ac6907cc2f25138e1/gpu/ipc/service/gpu_memory_buffer_factory_android_hardware_buffer.cc
[modify] https://crrev.com/7089b2da3e207e29d0124e3ac6907cc2f25138e1/ui/gl/gl_image_ahardwarebuffer.cc
[modify] https://crrev.com/7089b2da3e207e29d0124e3ac6907cc2f25138e1/ui/gl/gl_image_ahardwarebuffer.h
[modify] https://crrev.com/7089b2da3e207e29d0124e3ac6907cc2f25138e1/ui/gl/gl_image_ahardwarebuffer_unittest.cc
[modify] https://crrev.com/7089b2da3e207e29d0124e3ac6907cc2f25138e1/ui/gl/gl_image_egl.h
[modify] https://crrev.com/7089b2da3e207e29d0124e3ac6907cc2f25138e1/ui/gl/gl_image_native_pixmap.cc
[modify] https://crrev.com/7089b2da3e207e29d0124e3ac6907cc2f25138e1/ui/gl/gl_image_native_pixmap.h
[modify] https://crrev.com/7089b2da3e207e29d0124e3ac6907cc2f25138e1/ui/gl/gl_image_native_pixmap_unittest.cc

Project Member

Comment 18 by bugdroid1@chromium.org, Dec 21 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bc7b0afd8a1be8cfee2164dead6f4bc3b1e1d3f4

commit bc7b0afd8a1be8cfee2164dead6f4bc3b1e1d3f4
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Thu Dec 21 10:15:36 2017

Enable VaapiDrmPicture when passing --use-gl=egl

The existing VaapiTFPPicture(X11) only works with --use-gl=desktop.

CQ-DEPEND=CL:817563
Bug:  785201 
Tests: gfx_unittests --gtest_filter=*NativePixmapDmabuf*

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I304f729d3a9db04169fb3070c0382c561a659d5b
Reviewed-on: https://chromium-review.googlesource.com/766787
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525662}
[modify] https://crrev.com/bc7b0afd8a1be8cfee2164dead6f4bc3b1e1d3f4/media/gpu/vaapi/vaapi_drm_picture.cc
[modify] https://crrev.com/bc7b0afd8a1be8cfee2164dead6f4bc3b1e1d3f4/ui/gfx/BUILD.gn
[add] https://crrev.com/bc7b0afd8a1be8cfee2164dead6f4bc3b1e1d3f4/ui/gfx/linux/native_pixmap_dmabuf.cc
[add] https://crrev.com/bc7b0afd8a1be8cfee2164dead6f4bc3b1e1d3f4/ui/gfx/linux/native_pixmap_dmabuf.h
[add] https://crrev.com/bc7b0afd8a1be8cfee2164dead6f4bc3b1e1d3f4/ui/gfx/linux/native_pixmap_dmabuf_unittest.cc

Project Member

Comment 19 by bugdroid1@chromium.org, Jan 4 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a190f3eac76edf03471022b15e69085599df2189

commit a190f3eac76edf03471022b15e69085599df2189
Author: Julien Isorce <julien.isorce@chromium.org>
Date: Thu Jan 04 13:56:18 2018

Can select GLImplementation in GLImageTestSupport::InitializeGL

This allows to re-use generic GLImageTest templates in tests
that requires EGL,GLES2.

CQ-DEPEND=CL:817563
  gl_unittests --gtest_filter=*GLImage*
  ozone_gl_unittests

Bug:  785201 
Tests: 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I3ce122b69bef136fdf8c544f0b432d438c528f07
Reviewed-on: https://chromium-review.googlesource.com/832226
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Reviewed-by: Michael Spang <spang@chromium.org>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Reviewed-by: Ian Vollick <vollick@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526977}
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/chrome/browser/vr/test/gl_test_environment.cc
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/BUILD.gn
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/gl_context_glx_unittest.cc
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/gl_image_ahardwarebuffer_unittest.cc
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/gl_image_dxgi_unittest.cc
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/gl_image_io_surface_unittest.cc
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/gl_image_native_pixmap_unittest.cc
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/gl_image_ref_counted_memory_unittest.cc
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/gl_image_shared_memory_unittest.cc
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/test/gl_image_test_support.cc
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/test/gl_image_test_support.h
[add] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/test/gl_image_test_template.cc
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/gl/test/gl_image_test_template.h
[modify] https://crrev.com/a190f3eac76edf03471022b15e69085599df2189/ui/ozone/gl/gl_image_ozone_native_pixmap_unittest.cc

Status: Fixed (was: Started)
Project Member

Comment 21 by bugdroid1@chromium.org, Mar 9 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e330bcb63ec23aec1ec260f5880f8768c6d36679

commit e330bcb63ec23aec1ec260f5880f8768c6d36679
Author: Miguel Casas <mcasas@chromium.org>
Date: Fri Mar 09 14:55:06 2018

vaapi: split VaapiDrmPicture into common and ozone/egl parts

This CL splits VaapiDrmPicture into a common part named
VaapiPictureNativePixmap, and two subclasses, namely:
- VaapiPictureNativePixmapOzone, containing the current
 #if defined(USE_OZONE) sandwiched parts, and
- VaapiPixtureNativePixmapEgl with the other parts.

So the class tree should look like:

  +-----------------+
  |   VaapiPicture  |
  +-----------------+
   ^               ^
   |               +----+
  +--------------+    +------------------+
  | VaapiPicture |    | VaapiPictureTFP  |
  | NativePixmap |    | (existing on ToT)|
  +--------------+    +------------------+
   ^
   +---------------+
   |               |
 +-------+    +-------+
 | VPNP  |    | VPNP  |
 | Ozone |    | Egl   |
 +-------+    +-------+

The point here is to reduce the amount of if-defs to one single
point, the VaapiPictureFactory.

BUILD.gn is changed to reflect that VaapiDrmPicture is
egl-specific (see bug, |use_egl| definition in [1]), while
VaapiDrmPictureOzone is |use_ozone| [2] specific. Note
that |use_egl| can coexist with |use_x11| [3].

This CL just moves code around, no new code introduced in
either vaapi_picture*.cc.

[1] https://cs.chromium.org/chromium/src/ui/gl/features.gni?q=ui/gl/features.gni&sq=package:chromium&dr&l=16
[2] https://cs.chromium.org/chromium/src/build/config/ui.gni?q=build/config/ui.gni&sq=package:chromium&dr&l=26
[3] https://cs.chromium.org/chromium/src/build/config/ui.gni?type=cs&sq=package:chromium&l=47

Bug:  785201 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I67f6f4d994322ef7f23a8ed255405963a4be0152
Reviewed-on: https://chromium-review.googlesource.com/951928
Reviewed-by: Julien Isorce <julien.isorce@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542107}
[modify] https://crrev.com/e330bcb63ec23aec1ec260f5880f8768c6d36679/media/gpu/vaapi/BUILD.gn
[delete] https://crrev.com/6402e8cbceaf038bc8342816050848de0aa8c9f3/media/gpu/vaapi/vaapi_drm_picture.cc
[delete] https://crrev.com/6402e8cbceaf038bc8342816050848de0aa8c9f3/media/gpu/vaapi/vaapi_drm_picture.h
[modify] https://crrev.com/e330bcb63ec23aec1ec260f5880f8768c6d36679/media/gpu/vaapi/vaapi_picture_factory.cc
[add] https://crrev.com/e330bcb63ec23aec1ec260f5880f8768c6d36679/media/gpu/vaapi/vaapi_picture_native_pixmap.cc
[add] https://crrev.com/e330bcb63ec23aec1ec260f5880f8768c6d36679/media/gpu/vaapi/vaapi_picture_native_pixmap.h
[add] https://crrev.com/e330bcb63ec23aec1ec260f5880f8768c6d36679/media/gpu/vaapi/vaapi_picture_native_pixmap_egl.cc
[add] https://crrev.com/e330bcb63ec23aec1ec260f5880f8768c6d36679/media/gpu/vaapi/vaapi_picture_native_pixmap_egl.h
[add] https://crrev.com/e330bcb63ec23aec1ec260f5880f8768c6d36679/media/gpu/vaapi/vaapi_picture_native_pixmap_ozone.cc
[add] https://crrev.com/e330bcb63ec23aec1ec260f5880f8768c6d36679/media/gpu/vaapi/vaapi_picture_native_pixmap_ozone.h
[rename] https://crrev.com/e330bcb63ec23aec1ec260f5880f8768c6d36679/media/gpu/vaapi/vaapi_picture_tfp.cc
[rename] https://crrev.com/e330bcb63ec23aec1ec260f5880f8768c6d36679/media/gpu/vaapi/vaapi_picture_tfp.h

Project Member

Comment 22 by bugdroid1@chromium.org, Mar 9 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/89caee51f7f91f6525996dd7d2b27f3b9a46ac7f

commit 89caee51f7f91f6525996dd7d2b27f3b9a46ac7f
Author: Miguel Casas <mcasas@chromium.org>
Date: Fri Mar 09 18:13:08 2018

Revert "vaapi: split VaapiDrmPicture into common and ozone/egl parts"

This reverts commit e330bcb63ec23aec1ec260f5880f8768c6d36679.

Reason for revert: typo forced using EGL VaapiPictures, bad!

Original change's description:
> vaapi: split VaapiDrmPicture into common and ozone/egl parts
> 
> This CL splits VaapiDrmPicture into a common part named
> VaapiPictureNativePixmap, and two subclasses, namely:
> - VaapiPictureNativePixmapOzone, containing the current
>  #if defined(USE_OZONE) sandwiched parts, and
> - VaapiPixtureNativePixmapEgl with the other parts.
> 
> So the class tree should look like:
> 
>   +-----------------+
>   |   VaapiPicture  |
>   +-----------------+
>    ^               ^
>    |               +----+
>   +--------------+    +------------------+
>   | VaapiPicture |    | VaapiPictureTFP  |
>   | NativePixmap |    | (existing on ToT)|
>   +--------------+    +------------------+
>    ^
>    +---------------+
>    |               |
>  +-------+    +-------+
>  | VPNP  |    | VPNP  |
>  | Ozone |    | Egl   |
>  +-------+    +-------+
> 
> The point here is to reduce the amount of if-defs to one single
> point, the VaapiPictureFactory.
> 
> BUILD.gn is changed to reflect that VaapiDrmPicture is
> egl-specific (see bug, |use_egl| definition in [1]), while
> VaapiDrmPictureOzone is |use_ozone| [2] specific. Note
> that |use_egl| can coexist with |use_x11| [3].
> 
> This CL just moves code around, no new code introduced in
> either vaapi_picture*.cc.
> 
> [1] https://cs.chromium.org/chromium/src/ui/gl/features.gni?q=ui/gl/features.gni&sq=package:chromium&dr&l=16
> [2] https://cs.chromium.org/chromium/src/build/config/ui.gni?q=build/config/ui.gni&sq=package:chromium&dr&l=26
> [3] https://cs.chromium.org/chromium/src/build/config/ui.gni?type=cs&sq=package:chromium&l=47
> 
> Bug:  785201 
> Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
> Change-Id: I67f6f4d994322ef7f23a8ed255405963a4be0152
> Reviewed-on: https://chromium-review.googlesource.com/951928
> Reviewed-by: Julien Isorce <julien.isorce@chromium.org>
> Commit-Queue: Miguel Casas <mcasas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#542107}

TBR=posciak@chromium.org,kcwu@chromium.org,mcasas@chromium.org,chcunningham@chromium.org,acourbot@chromium.org,julien.isorce@chromium.org

Change-Id: If5103a891bcf6f758feea44cc514503457f00fbc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  785201 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Reviewed-on: https://chromium-review.googlesource.com/957322
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542148}
[modify] https://crrev.com/89caee51f7f91f6525996dd7d2b27f3b9a46ac7f/media/gpu/vaapi/BUILD.gn
[add] https://crrev.com/89caee51f7f91f6525996dd7d2b27f3b9a46ac7f/media/gpu/vaapi/vaapi_drm_picture.cc
[add] https://crrev.com/89caee51f7f91f6525996dd7d2b27f3b9a46ac7f/media/gpu/vaapi/vaapi_drm_picture.h
[modify] https://crrev.com/89caee51f7f91f6525996dd7d2b27f3b9a46ac7f/media/gpu/vaapi/vaapi_picture_factory.cc
[delete] https://crrev.com/8d0e11cc9ffb098fd0f4405b95807cc67965fd64/media/gpu/vaapi/vaapi_picture_native_pixmap.cc
[delete] https://crrev.com/8d0e11cc9ffb098fd0f4405b95807cc67965fd64/media/gpu/vaapi/vaapi_picture_native_pixmap.h
[delete] https://crrev.com/8d0e11cc9ffb098fd0f4405b95807cc67965fd64/media/gpu/vaapi/vaapi_picture_native_pixmap_egl.cc
[delete] https://crrev.com/8d0e11cc9ffb098fd0f4405b95807cc67965fd64/media/gpu/vaapi/vaapi_picture_native_pixmap_egl.h
[delete] https://crrev.com/8d0e11cc9ffb098fd0f4405b95807cc67965fd64/media/gpu/vaapi/vaapi_picture_native_pixmap_ozone.cc
[delete] https://crrev.com/8d0e11cc9ffb098fd0f4405b95807cc67965fd64/media/gpu/vaapi/vaapi_picture_native_pixmap_ozone.h
[rename] https://crrev.com/89caee51f7f91f6525996dd7d2b27f3b9a46ac7f/media/gpu/vaapi/vaapi_tfp_picture.cc
[rename] https://crrev.com/89caee51f7f91f6525996dd7d2b27f3b9a46ac7f/media/gpu/vaapi/vaapi_tfp_picture.h

Project Member

Comment 23 by bugdroid1@chromium.org, Mar 13 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c9a424a38055c56a79f8aff102768c180331fae7

commit c9a424a38055c56a79f8aff102768c180331fae7
Author: Miguel Casas <mcasas@chromium.org>
Date: Tue Mar 13 14:44:34 2018

RELAND: vaapi: split VaapiDrmPicture into common and ozone/egl parts

I reverted the original CL because of a silly typo. This CL fixes it
(see diff between PS1 and PS2):
https://chromium-review.googlesource.com/c/chromium/src/+/957144/1..2/media/gpu/vaapi/vaapi_picture_factory.cc

Original CL description ------------------------------------------------

This CL splits VaapiDrmPicture into a common part named
VaapiPictureNativePixmap, and two subclasses, namely:
- VaapiPictureNativePixmapOzone, containing the current
 #if defined(USE_OZONE) sandwiched parts, and
- VaapiPixtureNativePixmapEgl with the other parts.

So the class tree should look like:

  +-----------------+
  |   VaapiPicture  |
  +-----------------+
   ^               ^
   |               +----+
  +--------------+    +------------------+
  | VaapiPicture |    | VaapiPictureTFP  |
  | NativePixmap |    | (existing on ToT)|
  +--------------+    +------------------+
   ^
   +---------------+
   |               |
 +-------+    +-------+
 | VPNP  |    | VPNP  |
 | Ozone |    | Egl   |
 +-------+    +-------+

The point here is to reduce the amount of if-defs to one single
point, the VaapiPictureFactory.

BUILD.gn is changed to reflect that VaapiDrmPicture is
egl-specific (see bug, |use_egl| definition in [1]), while
VaapiDrmPictureOzone is |use_ozone| [2] specific. Note
that |use_egl| can coexist with |use_x11| [3].

This CL just moves code around, no new code introduced in
either vaapi_picture*.cc.

[1] https://cs.chromium.org/chromium/src/ui/gl/features.gni?q=ui/gl/features.gni&sq=package:chromium&dr&l=16
[2] https://cs.chromium.org/chromium/src/build/config/ui.gni?q=build/config/ui.gni&sq=package:chromium&dr&l=26
[3] https://cs.chromium.org/chromium/src/build/config/ui.gni?type=cs&sq=package:chromium&l=47

Bug:  785201 
Change-Id: I9c1dbc2e7f6cf1fb851d0d6dffa068fad9652edd
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Reviewed-on: https://chromium-review.googlesource.com/951928
Reviewed-by: Julien Isorce <julien.isorce@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/957144
Cr-Commit-Position: refs/heads/master@{#542794}
[modify] https://crrev.com/c9a424a38055c56a79f8aff102768c180331fae7/media/gpu/vaapi/BUILD.gn
[delete] https://crrev.com/e02429434b868d9bcc0e6431e6037ff6ec2898bd/media/gpu/vaapi/vaapi_drm_picture.cc
[delete] https://crrev.com/e02429434b868d9bcc0e6431e6037ff6ec2898bd/media/gpu/vaapi/vaapi_drm_picture.h
[modify] https://crrev.com/c9a424a38055c56a79f8aff102768c180331fae7/media/gpu/vaapi/vaapi_picture_factory.cc
[add] https://crrev.com/c9a424a38055c56a79f8aff102768c180331fae7/media/gpu/vaapi/vaapi_picture_native_pixmap.cc
[add] https://crrev.com/c9a424a38055c56a79f8aff102768c180331fae7/media/gpu/vaapi/vaapi_picture_native_pixmap.h
[add] https://crrev.com/c9a424a38055c56a79f8aff102768c180331fae7/media/gpu/vaapi/vaapi_picture_native_pixmap_egl.cc
[add] https://crrev.com/c9a424a38055c56a79f8aff102768c180331fae7/media/gpu/vaapi/vaapi_picture_native_pixmap_egl.h
[add] https://crrev.com/c9a424a38055c56a79f8aff102768c180331fae7/media/gpu/vaapi/vaapi_picture_native_pixmap_ozone.cc
[add] https://crrev.com/c9a424a38055c56a79f8aff102768c180331fae7/media/gpu/vaapi/vaapi_picture_native_pixmap_ozone.h
[rename] https://crrev.com/c9a424a38055c56a79f8aff102768c180331fae7/media/gpu/vaapi/vaapi_picture_tfp.cc
[rename] https://crrev.com/c9a424a38055c56a79f8aff102768c180331fae7/media/gpu/vaapi/vaapi_picture_tfp.h

Sign in to add a comment