Wayland with dmabuf. mmap: permission denied

[Maksim Sisov]

Hello everyone!

Robert, as we've discussed, I'm sending the description of the problem
to the ozone-dev:

I'm currently working on an issue, which blocks Wayland to be used in a
multiprocess mode. That is, when ozone/Wayland backend is used without
--in-process-gpu flag, it fails to create an egl surface and just
crashes. This happens because of inability to access the primary wayland
connection established on the browser process (see WaylandConnection and
WaylandSurfaceFactory::CreateViewGLSurface).

In order to overcome the problem, it was decided to use an approach,
when dmabuf'ers are used.

Shortly speaking, the OzonePlatformWayland creates a gbm_device and
passes it to a WaylandConnectionProxy[1] during a GPU initialization (a
class added to handle a mojo connection between the gpu and the browser
processes. When run in a single process mode, it just forwards the calls
to the WaylandConnection class). Then, when
WaylandSurfaceFactory::CreateNativePixmap is called, a
GbmBufferWayland::CreateBuffer is called [2]. The
gfx::BufferUsage::SCANOUT usage is created without any issues and the
browser works ok.

But whenever I enable gfx::BufferUsage::GPU_READ_CPU_READ_WRITE and
gfx::BufferUsage::GPU_READ_CPU_READ_WRITE_PERSISTENT usages
(--enable-native-gpu-memory-buffers), a problem with mmap() comes into
the scene. The mmap() call happens when ClientNativePixmapDmabuf is
created [4]. And it fails with a "Permission denied (13)" error. When
gfx::BufferUsage::GPU_READ_CPU_READ_WRITE and
gfx::BufferUsage::GPU_READ_CPU_READ_WRITE_PERSISTENT are used, the bo
usage is set to GBM_BO_USE_LINEAR, I've also tried other different bo
usages, but without any luck....

Any ideas?

[1]
https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-8ff0ff4054d16b40c5ab6a24bf34bff6
[2]
https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-a09cf9084313de86ce51fed0260bb750R151
[3]
https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-506229ebf99d76a41b204dde8c823ab9R86
[4]
https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?sq=package:chromium&g=0&l=81


PS you can build the github branch and try to run chromium with the
following gn args -

use_ozone = true
ozone_platform_wayland = true
ozone_platform_x11 = true
ozone_platform_gbm = false
ozone_platform_headless = false
ozone_auto_platforms = false

use_xkbcommon = true
use_system_libdrm=true
use_system_minigbm=true


and when running, use --ozone-platform=wayland --user-data-dir=/tmp/blah
--no-sandbox --enable-drm-mojo --enable-native-gpu-memory-buffers

--
Best Regards,
Maksim Sisov

[Maksim Sisov]

Hi,

It looks like this case works for ChromeOS, beacuse it has gbm relaxed,
which adds read/write access to the returned fd
(https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/323990).

In case of regular linux, it's not the case, and the one created buffers
can mmap and write to them. I think I have to change the design and let
the browser process to create buffers
and pass the fds to the GPU process for gl initialization
(https://cs.chromium.org/chromium/src/ui/gl/gl_image_native_pixmap.cc?type=cs&q=ui/gl/gl_image_native_pixmap.cc&sq=package:chromium&g=0&l=149)

Basically, this is how gbm_bo_get_fd looks in the strace -

ioctl(4, DRM_IOCTL_PRIME_HANDLE_TO_FD, 0x7fff07faaaec) = 0
fcntl(5, F_GETFL) = 0 (flags O_RDONLY)
fcntl(5, F_DUPFD_CLOEXEC, 0) = 6

I've also tried to modify
https://github.com/wayland-project/weston/blob/master/clients/simple-dmabuf-drm.c
to make it to use gbm interface.
And it works fine with gbm_bo_map/unmap interface, although trying with
mmap results in permission denied.

So, questions comes up - do we really need to create buffer on the GPU?
The scanout buffers work fine, but GPU_READ_CPU_READ_WRITE buffers fail
with mmap...

[Julien Isorce]

Hi Maksim,

I do not think using ozone/gbm on regular desktop running a wayland server is a goal. Actually ozone/gbm is to be used in place of a any other display server (and can also be seen as a wayland server through chromium/exo(sphere)).

On regular desktop with a running wayland or x server, chrome is a client so you won't be able to get writable dmabuf fd of a gpu memory, otherwise it is a hack. By design the client can export and import dmabuf fds but the client only has read access to it. With a particular case that you can have a dmabuf fd representing a 'protected' gpu memory, so that one will return random data when trying to actually do mmap read.

Note that gbm_bo_map/unmap works on intel since quite recently :) :

https://cgit.freedesktop.org/mesa/mesa/commit/?id=b904ad7d21a5d0472ffb80b81abe24afb2da3289

So I think on ozone/wayland you should not use gbm at all and just use export/import dmabuf fds that can traverse processes ( unix ancillary data, a fd in one process does not have the same int value in the other process even if they represent the same underlying memory). 

My understanding is that if you need to create your wayland surface in the browser process then you have to export gl textures from the gpu process using eglExportDMABUFImageQueryMESA and import them in the browser process through the wayland dmabuf protocol: zwp_linux_dmabuf in order to attach them to that wayland surface.

(It looks like you cannot do the reserve, as the wayland dmabuf protocol does not allow exporting, if I am correct, though that would be the a better way as EXT_image_dma_buf_import is better supported)

But can't you just create the wayland connection and surface in the gpu process too ? Why the process needs to access it  ?

Thx for working on this, I can't wait to have all of this work completed!

--

Julien

--
You received this message because you are subscribed to the Google Groups "Ozone-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozone-dev+unsubscribe@chromium.org.

[Maksim Sisov]

Hi Julien,

Thanks for jumping into the thread!

On 13.06.2018 19:50, Julien Isorce wrote:
> Hi Maksim,
>
> I do not think using ozone/gbm on regular desktop running a wayland
> server is a goal. Actually ozone/gbm is to be used in place of a any
> other display server (and can also be seen as a wayland server through
> chromium/exo(sphere)).
> On regular desktop with a running wayland or x server, chrome is a
> client so you won't be able to get writable dmabuf fd of a gpu memory,
> otherwise it is a hack. By design the client can export and import
> dmabuf fds but the client only has read access to it. With a
> particular case that you can have a dmabuf fd representing a
> 'protected' gpu memory, so that one will return random data when
> trying to actually do mmap read.

Why? According to the
http://ppaalanen.blogspot.com/2012/03/what-does-egl-do-in-wayland-stack.html
article, dmabuf and zwp_linux_dmabuf extension can be used as a way to
share buffers between client and server in a zero-copy manner. But we
extend this a bit, and, by creating a gbm buffer on a gpu process (and
sharing its fd with the browser process for importing wl_buffer and
attaching it to a surface) we are able to read and write to the buffer
without using mmap (which is not needed in this case). That's a regular
case and it works. I can use chromium without issues (webgl, youtube and
etc). This is the case when chromium requests to create a scanout
buffer.

The second case is a buffer created for raster (gpu read cpu read
write), which is impossible to achieve, when the buffer is created on
the gpu process. Instead, it must be created on a browser process to be
able to mmap it by using gbm_bo_map and the fd can be shared with the
gpu process for reading.

>
> Note that gbm_bo_map/unmap works on intel since quite recently :) :
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=b904ad7d21a5d0472ffb80b81abe24afb2da3289

> [8]

>
> So I think on ozone/wayland you should not use gbm at all and just use
> export/import dmabuf fds that can traverse processes ( unix ancillary
> data, a fd in one process does not have the same int value in the
> other process even if they represent the same underlying memory).

Do you mean using dmabuf API directly? But then we end up supporting
different libraries(libdrm intel, etnaviv, freedreno and more for
embedded world). The most important part that gbm helps to abstract most
of them without thinking about any other solutions.

>
> My understanding is that if you need to create your wayland surface in
> the browser process then you have to export gl textures from the gpu
> process using eglExportDMABUFImageQueryMESA and import them in the
> browser process through the wayland dmabuf protocol: zwp_linux_dmabuf
> in order to attach them to that wayland surface.
> (It looks like you cannot do the reserve, as the wayland dmabuf
> protocol does not allow exporting, if I am correct, though that would
> be the a better way as EXT_image_dma_buf_import is better supported)

eglExportDMABUFImageQueryMESA will require implementing a nested
compositor, which we are not in favor for.
What is more, eglExportDMABUFImageQueryMESA is only supported by mesa,
which is not always available in embedded world.

>
> But can't you just create the wayland connection and surface in the
> gpu process too ? Why the process needs to access it ?

Unfortunately, wayland is designed in such a way that each connection is
"sandbox". One process simple cannot access wl_surface of another
process. Having two connections won't work as long as it will be
impossible to map content with a right surface. There are only two ways
of doing so - dmabuf or nested compositor.

>
> Thx for working on this, I can't wait to have all of this work
> completed!
>
> --
> Julien
>
> On Wed, Jun 13, 2018 at 5:09 AM, Maksim Sisov <msi...@igalia.com>
> wrote:
>
>> Hi,
>>
>> It looks like this case works for ChromeOS, beacuse it has gbm
>> relaxed,
>> which adds read/write access to the returned fd
>>
> (https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/323990

>> [1]).

>>
>> In case of regular linux, it's not the case, and the one created
>> buffers
>> can mmap and write to them. I think I have to change the design and
>> let
>> the browser process to create buffers
>> and pass the fds to the GPU process for gl initialization
>>
> (https://cs.chromium.org/chromium/src/ui/gl/gl_image_native_pixmap.cc?type=cs&q=ui/gl/gl_image_native_pixmap.cc&sq=package:chromium&g=0&l=149

>> [2])

>>
>> Basically, this is how gbm_bo_get_fd looks in the strace -
>>
>> ioctl(4, DRM_IOCTL_PRIME_HANDLE_TO_FD, 0x7fff07faaaec) = 0
>> fcntl(5, F_GETFL) = 0 (flags O_RDONLY)
>> fcntl(5, F_DUPFD_CLOEXEC, 0) = 6
>>
>> I've also tried to modify
>>
> https://github.com/wayland-project/weston/blob/master/clients/simple-dmabuf-drm.c

>> [3]

>> [4]
>>> [2]
>>>
>>
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-a09cf9084313de86ce51fed0260bb750R151
>> [5]
>>> [3]
>>>
>>
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-506229ebf99d76a41b204dde8c823ab9R86
>> [6]
>>> [4]
>>>
>>
> https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?sq=package:chromium&g=0&l=81
>> [7]

>>>
>>>
>>> PS you can build the github branch and try to run chromium with
>> the
>>> following gn args -
>>>
>>> use_ozone = true
>>> ozone_platform_wayland = true
>>> ozone_platform_x11 = true
>>> ozone_platform_gbm = false
>>> ozone_platform_headless = false
>>> ozone_auto_platforms = false
>>>
>>> use_xkbcommon = true
>>> use_system_libdrm=true
>>> use_system_minigbm=true
>>>
>>>
>>> and when running, use --ozone-platform=wayland
>> --user-data-dir=/tmp/blah
>>> --no-sandbox --enable-drm-mojo --enable-native-gpu-memory-buffers
>>
>> --
>> Best Regards,
>> Maksim Sisov
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Ozone-Dev" group.
>> To unsubscribe from this group and stop receiving emails from it,

>> send an email to ozone-dev+...@chromium.org.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Ozone-Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to ozone-dev+...@chromium.org.
>
>
> Links:
> ------
> [1]
> https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/323990
> [2]
> https://cs.chromium.org/chromium/src/ui/gl/gl_image_native_pixmap.cc?type=cs&amp;q=ui/gl/gl_image_native_pixmap.cc&amp;sq=package:chromium&amp;g=0&amp;l=149
> [3]
> https://github.com/wayland-project/weston/blob/master/clients/simple-dmabuf-drm.c
> [4]
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-8ff0ff4054d16b40c5ab6a24bf34bff6
> [5]
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-a09cf9084313de86ce51fed0260bb750R151
> [6]
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-506229ebf99d76a41b204dde8c823ab9R86
> [7]
> https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?sq=package:chromium&amp;g=0&amp;l=81
> [8]
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=b904ad7d21a5d0472ffb80b81abe24afb2da3289

[Julien Isorce]

On Wed, Jun 13, 2018 at 1:23 PM, Maksim Sisov <msi...@igalia.com> wrote:

Hi Julien,

Thanks for jumping into the thread!

Hi Maksim,

It is very interesting, I hope you will find a solution.

I added suggestions below and questions.

 

On 13.06.2018 19:50, Julien Isorce wrote:
> Hi Maksim,
>
> I do not think using ozone/gbm on regular desktop running a wayland
> server is a goal. Actually ozone/gbm is to be used in place of a any
> other display server (and can also be seen as a wayland server through
> chromium/exo(sphere)).
> On regular desktop with a running wayland or x server, chrome is a
> client so you won't be able to get writable dmabuf fd of a gpu memory,
> otherwise it is a hack. By design the client can export and import
> dmabuf fds but the client only has read access to it. With a
> particular case that you can have a dmabuf fd representing a
> 'protected' gpu memory, so that one will return random data when
> trying to actually do mmap read.

Why? According to the
http://ppaalanen.blogspot.com/2012/03/what-does-egl-do-in-wayland-stack.html
article, dmabuf and zwp_linux_dmabuf extension can be used as a way to
share buffers between client and server in a zero-copy manner. But we
extend this a bit, and, by creating a gbm buffer on a gpu process (and
sharing its fd with the browser process for importing wl_buffer and
attaching it to a surface) we are able to read and write to the buffer
without using mmap (which is not needed in this case). That's a regular
case and it works. I can use chromium without issues (webgl, youtube and
etc). This is the case when chromium requests to create a scanout
buffer.

We are saying the sane thing, i.e. this fd is read only as expected so you cannot

do mmap but still an importer can write to it using special api after importation

but it requires passing more info/params (like context, device) as opposed to a

the generic unix system call 'mmap'.

 

The second case is a buffer created for raster (gpu read cpu read
write), which is impossible to achieve, when the buffer is created on
the gpu process. Instead, it must be created on a browser process to be
able to mmap it by using gbm_bo_map and the fd can be shared with the
gpu process for reading.

Can you provide more details on that second case which one is not working ?

Especially:

- can you provide a concrete example of that which describes what the 2 processes are trying

to draw on screen. (for example with 2 colored rectangles or a real case on the app)

- why you cannot just use wl_shm on the browser process ?

- if browser process needs to draw on top of the result of the gpu process,

 the browser should just request the gpu process to draw that data too, why not ?

- maybe you can ask on #wayland to add something similar to gbm_bo_map,

i.e. wl_buffer_map, so calling it after you import the fd as you do now into a wl_buffer.

Or wl_buffer attached to another so one is backed by shm and the other backed by dmabuf.

>
> Note that gbm_bo_map/unmap works on intel since quite recently :) :
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=b904ad7d21a5d0472ffb80b81abe24afb2da3289
> [8]
>
> So I think on ozone/wayland you should not use gbm at all and just use
> export/import dmabuf fds that can traverse processes ( unix ancillary
> data, a fd in one process does not have the same int value in the
> other process even if they represent the same underlying memory).

Do you mean using dmabuf API directly? But then we end up supporting
different libraries(libdrm intel, etnaviv, freedreno and more for
embedded world). The most important part that gbm helps to abstract most
of them without thinking about any other solutions.

I meant no gbm neither libdrm, these api are designed for display servers.

The chromium browser is a client in the case of ozone/wayland (as opposed

to chromeos with ozone/gbm)

Well this is for me the ideal solution and that it might not be achievable with

whatever api is available today. But see just below there might be something

you can try.

Isn't the long run solution you are trying to achieve after all ? If it needs to improve

the wayland protocol let's do it!

>
> My understanding is that if you need to create your wayland surface in
> the browser process then you have to export gl textures from the gpu
> process using eglExportDMABUFImageQueryMESA and import them in the
> browser process through the wayland dmabuf protocol: zwp_linux_dmabuf
> in order to attach them to that wayland surface.
> (It looks like you cannot do the reserve, as the wayland dmabuf
> protocol does not allow exporting, if I am correct, though that would
> be the a better way as EXT_image_dma_buf_import is better supported)

eglExportDMABUFImageQueryMESA will require implementing a nested
compositor, which we are not in favor for.
What is more, eglExportDMABUFImageQueryMESA is only supported by mesa,
which is not always available in embedded world.

I agree, no need to use that.

 

>
> But can't you just create the wayland connection and surface in the
> gpu process too ? Why the process needs to access it  ?

Unfortunately, wayland is designed in such a way that each connection is
"sandbox". One process simple cannot access wl_surface of another
process. Having two connections won't work as long as it will be
impossible to map content with a right surface. There are only two ways
of doing so - dmabuf or nested compositor.

I am not convinced of what you are saying as there is as existing wayland protocol to support this case: "xdg-foreign" :

(xdg importer / xdg_exporter)

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml#n27

It looks like it will fit for the use case browser process / sandboxed gpu process:

From its protocol doc above:

"

    A possible use case for this is out-of-process dialogs. For example when a
    sandboxed client without file system access needs the user to select a file
    on the file system, given sandbox environment support, it can export its
    surface, passing the exported surface handle to an unsandboxed process that
    can show a file browser dialog and stack it above the sandboxed client's
    surface.

"

It is a unique string that you will just need to send through ipc.

So in theory it will allow your working case to not use gbm at all, so only wayland.

Cheers

Julien

 

>> send an email to ozone-dev+unsubscribe@chromium.org.

>
>  --
> You received this message because you are subscribed to the Google
> Groups "Ozone-Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to ozone-dev+unsubscribe@chromium.org.
>
>

[Maksim Sisov]

Hi Julien,

>> [1]

>> article, dmabuf and zwp_linux_dmabuf extension can be used as a way
>> to
>> share buffers between client and server in a zero-copy manner. But
>> we
>> extend this a bit, and, by creating a gbm buffer on a gpu process
>> (and
>> sharing its fd with the browser process for importing wl_buffer and
>> attaching it to a surface) we are able to read and write to the
>> buffer
>> without using mmap (which is not needed in this case). That's a
>> regular
>> case and it works. I can use chromium without issues (webgl, youtube
>> and
>> etc). This is the case when chromium requests to create a scanout
>> buffer.
>
> We are saying the sane thing, i.e. this fd is read only as expected so
> you cannot
> do mmap but still an importer can write to it using special api after
> importation
> but it requires passing more info/params (like context, device) as
> opposed to a
> the generic unix system call 'mmap'.

It's read only for the process, which gets the fd of it. Let me explain
once again as I understand it:

there are two ways how a client and a compositor can allocate buffers -
it can be the client, who allocates it and the compositor exports a
wl_buffer out of the fd allowing client to attach it to a surface, or
the compositor, which allocates buffers and shares them with the client
for importing. In order to meet our goals, where the GPU process of the
Chromium browser can create a buffer for read/write, gbm API are used in
order to avoid supporting as much dmabuf apis as possible. That is, the
GPU process creates a NativePixmapHandle and uses
the gl apis to write to them without any problems, but when the
--enable-native-gpu-memory-buffers is enabled (ClientNativePixmapDmabuf
is created), this case fails and chromium crashes.

>
>> The second case is a buffer created for raster (gpu read cpu read
>> write), which is impossible to achieve, when the buffer is created
>> on
>> the gpu process. Instead, it must be created on a browser process to
>> be
>> able to mmap it by using gbm_bo_map and the fd can be shared with
>> the
>> gpu process for reading.
>
> Can you provide more details on that second case which one is not
> working ?
> Especially:
> - can you provide a concrete example of that which describes what the
> 2 processes are trying
> to draw on screen. (for example with 2 colored rectangles or a real
> case on the app)

This case involves cpu rasterization with zero or one copy.

Here is the stack -

#4 0x7f72a08644c0 SkDraw::drawPaint()
#5 0x7f72a08124bb SkBitmapDevice::drawPaint()
#6 0x7f72a083d819 SkCanvas::internalDrawPaint()
#7 0x7f72a083b76f SkCanvas::drawPaint()
#8 0x7f72a0857656 SkColorSpaceXformCanvas::onDrawPaint()
#9 0x7f72a083b76f SkCanvas::drawPaint()
#10 0x7f72a08439ae SkCanvas::drawColor()
#11 0x7f72930da8a2 cc::RasterSource::ClearForOpaqueRaster()
#12 0x7f72930da217 cc::RasterSource::PlaybackToCanvas()
#13 0x7f72930d9005 cc::RasterBufferProvider::PlaybackToMemory()
#14 0x7f729313571c cc::(anonymous
namespace)::ZeroCopyRasterBufferImpl::Playback()
#15 0x7f729313f89e cc::(anonymous
namespace)::RasterTaskImpl::RunOnWorkerThread()

zero copy mmap case happens here -
https://cs.chromium.org/chromium/src/cc/raster/zero_copy_raster_buffer_provider.cc?type=cs&q=ZeroCopyRasterBufferImpl::Playback&sq=package:chromium&g=0&l=175
.

and one-copy

#4 0x7fc5e1d514c0 SkDraw::drawPaint()
#5 0x7fc5e1cff4bb SkBitmapDevice::drawPaint()
#6 0x7fc5e1d2a819 SkCanvas::internalDrawPaint()
#7 0x7fc5e1d2876f SkCanvas::drawPaint()
#8 0x7fc5e1d44656 SkColorSpaceXformCanvas::onDrawPaint()
#9 0x7fc5e1d2876f SkCanvas::drawPaint()
#10 0x7fc5e1d309ae SkCanvas::drawColor()
#11 0x7fc5d45c78a2 cc::RasterSource::ClearForOpaqueRaster()
#12 0x7fc5d45c7217 cc::RasterSource::PlaybackToCanvas()
#13 0x7fc5d45c6005 cc::RasterBufferProvider::PlaybackToMemory()
#14 0x7fc5d45c563b
cc::OneCopyRasterBufferProvider::PlaybackToStagingBuffer()
#15 0x7fc5d45c36a8
cc::OneCopyRasterBufferProvider::PlaybackAndCopyOnWorkerThread()
#16 0x7fc5d45c3491
cc::OneCopyRasterBufferProvider::RasterBufferImpl::Playback()
#17 0x7fc5d462c89e cc::(anonymous
namespace)::RasterTaskImpl::RunOnWorkerThread()

One copy mmap failure happens after this call -
https://cs.chromium.org/chromium/src/cc/raster/one_copy_raster_buffer_provider.cc?type=cs&q=OneCopyRasterBufferProvider::PlaybackToStagingBuffer&sq=package:chromium&g=0&l=345

PS The crash happens immediately on mmap calls and doesn't reach the
SkDraw::drawPaint call. I've just removed mmap from the
client_native_pixmap_dmabuf to be able reach there and have a stack
trace.
PPS but as I've said it's only the case when the
--enable-native-gpu-memory-buffers is used, otherwise chromium creates a
shared memory for rasterization and the flow goes ok.

> - why you cannot just use wl_shm on the browser process ?

wl_shm is bad for accelerated graphics. This is the memory not suitable
for GPU read. It is going to involve two copies during glReadPixels call
and glTexImage2D call on the server side to make the buffer copied for
GPU read.

> - if browser process needs to draw on top of the result of the gpu
> process,
> the browser should just request the gpu process to draw that data
> too, why not ?
> - maybe you can ask on #wayland to add something similar to
> gbm_bo_map,
> i.e. wl_buffer_map, so calling it after you import the fd as you do
> now into a wl_buffer.
> Or wl_buffer attached to another so one is backed by shm and the other
> backed by dmabuf.
>
>>>
>>> Note that gbm_bo_map/unmap works on intel since quite recently :)
>> :
>>>
>>
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=b904ad7d21a5d0472ffb80b81abe24afb2da3289

>> [2]

>> [3]

>>>> [1]).
>>>>
>>>> In case of regular linux, it's not the case, and the one created
>>>> buffers
>>>> can mmap and write to them. I think I have to change the design
>> and
>>>> let
>>>> the browser process to create buffers
>>>> and pass the fds to the GPU process for gl initialization
>>>>
>>>
>>
> (https://cs.chromium.org/chromium/src/ui/gl/gl_image_native_pixmap.cc?type=cs&q=ui/gl/gl_image_native_pixmap.cc&sq=package:chromium&g=0&l=149

>> [4]

>>>> [2])
>>>>
>>>> Basically, this is how gbm_bo_get_fd looks in the strace -
>>>>
>>>> ioctl(4, DRM_IOCTL_PRIME_HANDLE_TO_FD, 0x7fff07faaaec) = 0
>>>> fcntl(5, F_GETFL) = 0 (flags O_RDONLY)
>>>> fcntl(5, F_DUPFD_CLOEXEC, 0) = 6
>>>>
>>>> I've also tried to modify
>>>>
>>>
>>
> https://github.com/wayland-project/weston/blob/master/clients/simple-dmabuf-drm.c

>> [5]

>> [6]
>>>> [4]
>>>>> [2]
>>>>>
>>>>
>>>
>>
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-a09cf9084313de86ce51fed0260bb750R151
>> [7]
>>>> [5]
>>>>> [3]
>>>>>
>>>>
>>>
>>
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-506229ebf99d76a41b204dde8c823ab9R86
>> [8]

>>>> [6]
>>>>> [4]
>>>>>
>>>>
>>>
>>
> https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?sq=package:chromium&g=0&l=81

>> [9]

>>>> send an email to ozone-dev+...@chromium.org.

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Ozone-Dev" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>> send

>>> an email to ozone-dev+...@chromium.org.

>>>
>>>
>>> Links:
>>> ------
>>> [1]
>>>
>>
> https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/323990

>> [3]

>>> [2]
>>>
>>
> https://cs.chromium.org/chromium/src/ui/gl/gl_image_native_pixmap.cc?type=cs&amp;q=ui/gl/gl_image_native_pixmap.cc&amp;sq=package:chromium&amp;g=0&amp;l=149

>> [10]
>>> [3]
>>>
>>
> https://github.com/wayland-project/weston/blob/master/clients/simple-dmabuf-drm.c
>> [5]
>>> [4]
>>>
>>
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-8ff0ff4054d16b40c5ab6a24bf34bff6
>> [6]
>>> [5]
>>>
>>
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-a09cf9084313de86ce51fed0260bb750R151
>> [7]
>>> [6]
>>>
>>
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-506229ebf99d76a41b204dde8c823ab9R86
>> [8]

>>> [7]
>>>
>>
> https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?sq=package:chromium&amp;g=0&amp;l=81

>> [11]
>>> [8]
>>>
>>
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=b904ad7d21a5d0472ffb80b81abe24afb2da3289
>> [2]

>>
>> --
>> Best Regards,
>> Maksim Sisov
>
> --
> You received this message because you are subscribed to the Google
> Groups "Ozone-Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to ozone-dev+...@chromium.org.
>
>
> Links:
> ------
> [1] http://ppaalanen.blogspot.com/2012/03/what-does-egl-do-in-wayland-stack.html
> [2]
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=b904ad7d21a5d0472ffb80b81abe24afb2da3289
> [3]
> https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/323990
> [4]

> https://cs.chromium.org/chromium/src/ui/gl/gl_image_native_pixmap.cc?type=cs&amp;q=ui/gl/gl_image_native_pixmap.cc&amp;sq=package:chromium&amp;g=0&amp;l=149

> [5]
> https://github.com/wayland-project/weston/blob/master/clients/simple-dmabuf-drm.c
> [6]
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-8ff0ff4054d16b40c5ab6a24bf34bff6
> [7]
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-a09cf9084313de86ce51fed0260bb750R151
> [8]
> https://github.com/msisov/chromium/commit/f8f085c7afd7c0b9302883021d11851b576ed574#diff-506229ebf99d76a41b204dde8c823ab9R86
> [9]

> https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?sq=package:chromium&amp;g=0&amp;l=81

> [10]
> https://cs.chromium.org/chromium/src/ui/gl/gl_image_native_pixmap.cc?type=cs&amp;amp;q=ui/gl/gl_image_native_pixmap.cc&amp;amp;sq=package:chromium&amp;amp;g=0&amp;amp;l=149
> [11]
> https://cs.chromium.org/chromium/src/ui/gfx/linux/client_native_pixmap_dmabuf.cc?sq=package:chromium&amp;amp;g=0&amp;amp;l=81

[Maksim Sisov]

I think we can dismiss the GPU READ CPU READ WRITE case with the native
gpu memory buffers and keep using the shared memory instead. At least,
it's the case for the stock x11. And then, the downstream projects can
implement their own solution for this problem.

Here is the patch, which works -
https://github.com/msisov/chromium/commit/c11899c3e7e41d170b65024d3d712c264e586b75