GBM Ozone implementation

GBM Ozone implementation

Adding an accelerated platform for the X11-less build. This uses GBM (EGL_MESA_platform_gbm) as the backing Mesa platform.

BUG=377497
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=273509

[spang, 2014-02-19 20:42:03]

https://codereview.chromium.org/106633002/diff/160001/third_party/mesa/mesa.gyp
File third_party/mesa/mesa.gyp (right):

https://codereview.chromium.org/106633002/diff/160001/third_party/mesa/mesa.g...
third_party/mesa/mesa.gyp:814: 'target_name': 'mesa_gbm',
This is causing my build to crash. The driver and GBM share some structures, and
so the libgbm must exactly match the version of mesa used. We need to use the
copy of libgbm installed on the system.

(in particular the gbm_dri_device struct has gotten larger. the driver is
corrupting my heap as a result)

[dnicoara, 2014-02-20 03:49:11]

On 2014/02/19 20:42:03, spang wrote:
>
https://codereview.chromium.org/106633002/diff/160001/third_party/mesa/mesa.gyp
> File third_party/mesa/mesa.gyp (right):
> 
>
https://codereview.chromium.org/106633002/diff/160001/third_party/mesa/mesa.g...
> third_party/mesa/mesa.gyp:814: 'target_name': 'mesa_gbm',
> This is causing my build to crash. The driver and GBM share some structures,
and
> so the libgbm must exactly match the version of mesa used. We need to use the
> copy of libgbm installed on the system.
> 
> (in particular the gbm_dri_device struct has gotten larger. the driver is
> corrupting my heap as a result)

This was a workaround to have content_shell building on desktop without a more
up-to-date mesa present on the system.

[spang, 2014-05-27 15:16:17]

lgtm

[dnicoara, 2014-05-27 15:16:54]

This CL is dependent on https://codereview.chromium.org/293293002/ but you can
take a look in the meantime.

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
File ui/ozone/platform/dri/dri.gypi (right):

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
ui/ozone/platform/dri/dri.gypi:96: '-lgbm',
How official do we want this to be? Currently it is disabled by default, but if
we want to have it enabled by default this should be changed to use pkg-config
to find the library (add a target to build/linux/system.gyp) and
build/install-build-deps.sh needs to be updated to add libgbm as a dev
dependency.

[rjkroege, 2014-05-27 15:33:41]

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
File ui/ozone/platform/dri/dri.gypi (right):

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
ui/ozone/platform/dri/dri.gypi:96: '-lgbm',
On 2014/05/27 15:16:54, dnicoara wrote:
> How official do we want this to be? Currently it is disabled by default, but
if
> we want to have it enabled by default this should be changed to use pkg-config
> to find the library (add a target to build/linux/system.gyp) and
> build/install-build-deps.sh needs to be updated to add libgbm as a dev
> dependency.

it's more work but if we're going to have this code in tree for the present
(which seems like a good idea) then doing the above work is a good idea.

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
File ui/ozone/platform/dri/dri_surface.h (right):

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
ui/ozone/platform/dri/dri_surface.h:22: // DriSurface is used to represent a
surface that can be scanned out
This comment needs to be updated a bit to reflect the ScanoutSurface refactor

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/s...
File ui/ozone/platform/dri/scanout_surface.h (right):

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/s...
ui/ozone/platform/dri/scanout_surface.h:16: // Initializes and stores state
associated with the drawing surface.
I'd appreciate a bit more explanation here.

[vignatti (out of this project), 2014-05-27 16:40:20]

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
File ui/ozone/platform/dri/dri.gypi (right):

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
ui/ozone/platform/dri/dri.gypi:96: '-lgbm',
On 2014/05/27 15:33:42, rjkroege wrote:
> On 2014/05/27 15:16:54, dnicoara wrote:
> > How official do we want this to be? Currently it is disabled by default, but
> if
> > we want to have it enabled by default this should be changed to use
pkg-config
> > to find the library (add a target to build/linux/system.gyp) and
> > build/install-build-deps.sh needs to be updated to add libgbm as a dev
> > dependency.
> 
> it's more work but if we're going to have this code in tree for the present
> (which seems like a good idea) then doing the above work is a good idea.

But can we have gbm discovered by pkg-config at least?

PS: awesome to see this CL going through.

[dnicoara, 2014-05-27 17:20:51]

I've also updated the unittests & fixed compiling without GBM.

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
File ui/ozone/platform/dri/dri.gypi (right):

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
ui/ozone/platform/dri/dri.gypi:96: '-lgbm',
On 2014/05/27 15:33:42, rjkroege wrote:
> On 2014/05/27 15:16:54, dnicoara wrote:
> > How official do we want this to be? Currently it is disabled by default, but
> if
> > we want to have it enabled by default this should be changed to use
pkg-config
> > to find the library (add a target to build/linux/system.gyp) and
> > build/install-build-deps.sh needs to be updated to add libgbm as a dev
> > dependency.
> 
> it's more work but if we're going to have this code in tree for the present
> (which seems like a good idea) then doing the above work is a good idea.

Done.

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
File ui/ozone/platform/dri/dri_surface.h (right):

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/d...
ui/ozone/platform/dri/dri_surface.h:22: // DriSurface is used to represent a
surface that can be scanned out
On 2014/05/27 15:33:42, rjkroege wrote:
> This comment needs to be updated a bit to reflect the ScanoutSurface refactor

Done.

I've moved the comments and updated them to reflect the current state of the
code.

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/s...
File ui/ozone/platform/dri/scanout_surface.h (right):

https://codereview.chromium.org/106633002/diff/410001/ui/ozone/platform/dri/s...
ui/ozone/platform/dri/scanout_surface.h:16: // Initializes and stores state
associated with the drawing surface.
On 2014/05/27 15:33:42, rjkroege wrote:
> I'd appreciate a bit more explanation here.

Done. Moved the generic part from DriSurface here.

[rjkroege, 2014-05-28 15:32:20]

lgtm

https://codereview.chromium.org/106633002/diff/450001/ui/ozone/platform/dri/s...
File ui/ozone/platform/dri/scanout_surface.h (right):

https://codereview.chromium.org/106633002/diff/450001/ui/ozone/platform/dri/s...
ui/ozone/platform/dri/scanout_surface.h:35: //   Wait for page flip event. The
DRM page flip handler will call
observation (not a comment on the cl): in the future overlay-aware world this
won't work this way right? in particular, the interlock will happen magically as
a result of an embedded fence.

[dnicoara, 2014-05-28 15:40:09]

https://codereview.chromium.org/106633002/diff/450001/ui/ozone/platform/dri/s...
File ui/ozone/platform/dri/scanout_surface.h (right):

https://codereview.chromium.org/106633002/diff/450001/ui/ozone/platform/dri/s...
ui/ozone/platform/dri/scanout_surface.h:35: //   Wait for page flip event. The
DRM page flip handler will call
On 2014/05/28 15:32:21, rjkroege wrote:
> observation (not a comment on the cl): in the future overlay-aware world this
> won't work this way right? in particular, the interlock will happen magically
as
> a result of an embedded fence.

In an overlay world I expect we'd still have some callback (on the controller)
for page-flipping. The only difference is that the controller would have
multiple buffers (primary surface + overlays) and would need to do extra work
for overlays. From a primary surface perspective the example code would still be
valid. Note, the SwapBuffers() call is done by the page-flip handler
automatically.

[dnicoara, 2014-05-28 15:55:43]

The CQ bit was checked by dnicoara@chromium.org

[commit-bot: I haz the power, 2014-05-28 15:56:45]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/dnicoara@chromium.org/106633002/450001

[commit-bot: I haz the power, 2014-05-28 19:13:33]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  linux_chromium_chromeos_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_chromeos_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_clang_...)
  linux_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...)
  linux_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu/builds/...)

[commit-bot: I haz the power, 2014-05-28 19:18:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-05-28 19:18:34]

Try jobs failed on following builders:
  linux_chromium_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_clang_...)

[spang, 2014-05-28 21:46:26]

https://codereview.chromium.org/106633002/diff/450001/build/linux/system.gyp
File build/linux/system.gyp (right):

https://codereview.chromium.org/106633002/diff/450001/build/linux/system.gyp#...
build/linux/system.gyp:488: 'target_name': 'gbm',
put this under conditions, <(ozone_platform_gbm)==1

[dnicoara, 2014-05-29 13:53:23]

The CQ bit was checked by dnicoara@chromium.org

[commit-bot: I haz the power, 2014-05-29 13:54:13]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/dnicoara@chromium.org/106633002/470001

[commit-bot: I haz the power, 2014-05-29 17:22:51]

Change committed as 273509

[Primiano Tucci (use gerrit), 2014-06-18 18:02:31]

FYI this caused some little troubles to new googlers trying to run
install-build-deps.sh
(see Thread [chromium-dev] Unmet dependencies when using install-build-deps.sh).

Nothing dramatic (and definitely nothing easy to predict), I've just sent out a
fix on https://codereview.chromium.org/344623002.
Just, next time you might consider actually running install-build-deps.sh when
making changes to it to ensure it still works :)

[dnicoara, 2014-06-18 18:15:32]

Sorry, I had tested it on trusty and everything worked fine.