
Using the Chrome OS Graphics Stack on Intel-Based Linux Desktops - doener
https://01.org/blogs/joone/2018/using-chrome-os-graphics-stack-intel-based-linux-desktops
======
seba_dos1
The title doesn't give justice to the content: it's about zero-copy texture
upload in Chromium's Ozone-GBM when used on Intel integrated GPUs.

~~~
vvanders
I'd be curious if having to upload textures is just a feature that's a hold-
over from a history discrete desktop GPUs.

Videogame consoles have been doing "zero-copy" textures since they
existed(except if you're on the PS3, but we won't go there). You also have
things like EGL_image_external[1][2] that get you the same thing in OpenGL ES.

[1]
[https://www.khronos.org/registry/OpenGL/extensions/OES/OES_E...](https://www.khronos.org/registry/OpenGL/extensions/OES/OES_EGL_image_external.txt)

[2] [https://community.arm.com/graphics/b/blog/posts/eglimage---
u...](https://community.arm.com/graphics/b/blog/posts/eglimage---updating-a-
texture-without-copying-memory-under-android)

~~~
obl
Note that even if you share DRAM with the graphic chip, you may take an extra
step anyway to rearrange the texture in a tiled format since it's more
efficient for sampling.

If you really care about load time you can decode the image directly in a
tiled layout in software but that's more annoying.

~~~
vvanders
Yup, in games we used to call this "asset cooking" where you target the
platform specific texture compression in addition to tiling that you get as a
part of that format.

You get a nice 3-6x memory savings plus put less pressure on the texture
samplers as memory bandwidth drops as well.

------
russellbeattie
Off topic: Wow, that domain name.. I wonder how long Intel has been holding on
to that one? (No pun intended... Well, sorta).

~~~
expiredtofu
Also off topic: I spy a Leopold FC660! Been interested but couldn't justify
the price.

~~~
captn3m0
Totally worth it if you like Topre.

------
sandGorgon
Are there any performance benchmarks comparing ozone-gbm vs ozone-wayland ? It
seems that the implementation that the article talks about is moot if the
Wayland implementation has near equivalent performance..since the hardware
layers are abstracted out.

In which case, this is only relevant for architecture that Wayland does not
target. Most Intel desktops are supported by Wayland.

------
floatboth
> Hardware overlay is not only for video, but also for rendering Android
> applications that run on a hardware overlay plane, such as the Wayland
> client of Chrome OS.

What?

What is a "Wayland client of Chrome OS" and how is it an Android application??

~~~
mastax
That sentence is quite confusing, to my knowledge a better explanation would
be:

"The Android compatibility layer of Chrome OS implements a Wayland client to
run on a hardware overlay plane."

based on information from
[https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-...](https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-ARC-
Wayland)

~~~
floatboth
Ah, so the Chrome OS UI, which is running directly on GBM/KMS, became a
Wayland compositor just for the Android compatibility layer?

(Oh, and for the recently announced Linux desktop apps support maybe?)

~~~
zaxcellent
The Wayland compositor was added to the Chrome OS UI to support Android, but
it was very convenient for us to glob onto that for the Linux desktop apps
support.

[https://chromium.googlesource.com/chromiumos/docs/+/HEAD/con...](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md#Can-
I-run-Wayland-programs)

------
convivialdingo
Awesome! I had played around with this code as well on Rockchip systems. Great
to see the stack running on Intel.

~~~
TheCycoONE
How far did you get with Rockchip. I consistently ran into kernel/userspace
driver version mismatches.

~~~
convivialdingo
Google has all their code open, but the rockchip and MALI drivers must match
Kernel version. Not much is out there, but hav you checker this?

[https://github.com/rockchip-linux/libmali](https://github.com/rockchip-
linux/libmali)

~~~
TheCycoONE
Yes, those are the userspace drivers I was using. r1300 and r1400 are older
than either the gru or mainstream kernels. It's a moving target, and rock chip
hasn't been keeping up.

~~~
TheCycoONE
[https://github.com/rockchip-
linux/libmali/issues/20](https://github.com/rockchip-linux/libmali/issues/20)
was my ticket

------
srcmap
How is this compare to Mozilla's Servo approach?

[https://servo.org/](https://servo.org/)

From the simple block diagram and benchmark, servo seems to be better?

Servo claims 500 fps.

This only shows 22-48 fps.

Anyone have good technical explanation on the difference?

~~~
ansible
You're comparing apples and tigers.

Intel's work is focused on the lower layers of the graphics stack, and
removing the inefficiencies of older (X11 for example) architectures.

Servo is for rendering HTML, that is, taking HTML markup, and displaying the
paragraphs, tables and whatnot graphically. So it is operating at a higher
level.

