How to enable software rendering path with freon

[Sumit Agrawal]

Hi,

Can someone help me understand what are the requirements to enable software renderer path on Chromium OS with the ozone/freon stack? (I am using a private arm64 board overlay)

I was under the impression that I need to just disable all the video cards and keep swrast in mesa. But that doesn't seem to work.

I am able to see the boot splash screen, but nothing after that.

This is what my mesa configuration looks like:

./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=armv7a-cros-linux-gnueabi --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-option-checking --with-driver=dri --disable-glu --disable-glut --disable-omx --disable-va --disable-vdpau --disable-xvmc --without-demos --enable-texture-float --disable-dri3 --disable-llvm-shared-libs --disable-glx --enable-llvm-gallium --enable-egl --disable-gbm --disable-gles1 --enable-gles2 --enable-shared-glapi --enable-gallium --disable-debug --enable-glx-tls --enable-asm --disable-xlib-glx --enable-dri --with-dri-drivers=,swrast --with-gallium-drivers=,swrast --with-egl-platforms=surfaceless

Would the chromium browser be able to figure out that there is no gpu involved (does it really need to know at all?), or I do I need to set any flags for ozone layer?

Also, minigbm should not come into picture for software rendering, right?

Thanks.

[Vincent Palatin]

On May 16, 2016 2:36 AM, "Sumit Agrawal" <sumi...@gmail.com> wrote:
>
> Hi,
>
> Can someone help me understand what are the requirements to enable software renderer path on Chromium OS with the ozone/freon stack? (I am using a private arm64 board overlay)
>
> I was under the impression that I need to just disable all the video cards and keep swrast in mesa. But that doesn't seem to work.
> I am able to see the boot splash screen, but nothing after that.

The arm64-llvmpipe public overlay uses the Mesa software pipe for graphics and as far as I can tell it does work. You can use it as a basis for your own work.

>
> This is what my mesa configuration looks like:
>
> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=armv7a-cros-linux-gnueabi --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-option-checking --with-driver=dri --disable-glu --disable-glut --disable-omx --disable-va --disable-vdpau --disable-xvmc --without-demos --enable-texture-float --disable-dri3 --disable-llvm-shared-libs --disable-glx --enable-llvm-gallium --enable-egl --disable-gbm --disable-gles1 --enable-gles2 --enable-shared-glapi --enable-gallium --disable-debug --enable-glx-tls --enable-asm --disable-xlib-glx --enable-dri --with-dri-drivers=,swrast --with-gallium-drivers=,swrast --with-egl-platforms=surfaceless
>
> Would the chromium browser be able to figure out that there is no gpu involved (does it really need to know at all?), or I do I need to set any flags for ozone layer?

The browser won't think there is no GPU, as Mesa will provide the GL implementation.

>
> Also, minigbm should not come into picture for software rendering, right?

It still needs to support the actual driver you are using to display.
If you are using a custom kernel config, you might want to have also DRM_VGEM enabled.

Before starting the browsing, the drm-tests package is providing more self contained tests which are easier to debug. You should try to run null_platform_test from there.

>
> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>

[Sumit Agrawal]

Thanks for your reply Vincent, that helps a lot.

I do not have a minigbm implementation yet. I was somehow under the impression that it's not needed for software rendering.

I've been using modetest as the base test (which works for me); will look into null_platform_test now.

I do have DRM_VGEM enabled, but could you also help me understand whether it's mandatory or optional? I read a few posts, which seemed to suggest that it only facilitates optimization.

[Sumit Agrawal]

Vincent, I am not sure if I understand your earlier comment about minigbm completely.

Did you mean that minigbm implementation is needed for drm/vgem device, to enable the software rendering path?

 

I am trying to debug the vgem path further. I have DRM_VGEM enabled, and vgem device is listed as below:

localhost ~ # ls -la /sys/class/drm

drwxr-xr-x  2 root root    0 Dec 31  1969 .

drwxr-xr-x 50 root root    0 Dec 31  1969 ..

lrwxrwxrwx  1 root root    0 Dec 31  1969 card0 -> ../../devices/platform/vgem/drm/card0

lrwxrwxrwx  1 root root    0 Dec 31  1969 card1 -> ../../devices/platform/soc/900000.qcom,mdss_mdp/drm/card1

lrwxrwxrwx  1 root root    0 Dec 31  1969 card1-HDMI-A-1 -> ../../devices/platform/soc/900000.qcom,mdss_mdp/drm/card1/card1-HDMI-A-1

lrwxrwxrwx  1 root root    0 Dec 31  1969 controlD64 -> ../../devices/platform/soc/900000.qcom,mdss_mdp/drm/controlD64

lrwxrwxrwx  1 root root    0 Dec 31  1969 renderD128 -> ../../devices/platform/vgem/drm/renderD128

lrwxrwxrwx  1 root root    0 Dec 31  1969 renderD129 -> ../../devices/platform/soc/900000.qcom,mdss_mdp/drm/renderD129

lrwxrwxrwx  1 root root    0 Dec 31  1969 ttm -> ../../devices/virtual/drm/ttm

-r--r--r--  1 root root 4096 Dec 31  1969 version

1. With Chromium browser, I get this error:

[4971:4990:0422/143205:ERROR:drm_device_manager.cc(53)] Could not initialize DRM device for /sys/devices/platform/vgem/drm/card0

I figured that devices that cannot perform modesetting (like vgem) are ignored in ozone/platform/drm. So, the call doesn't even reach minigbm for vgem device.

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/drm/gpu/gbm_device.cc&rcl=1463440736&l=23

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc&l=398

2. With null_platform_test, I get below error: (I put some extra logs in minigbm/gbm.c)

localhost ~ # null_platform_test /dev/dri/card0

minigbm: gbm_create_device

minigbm: gbm_get_driver

minigbm: drm_version->name=vgem

minigbm: NOT FOUND drm_version->name=vgem

minigbm: gbm_get_driver failed

ERROR:main():null_platform_test.c:81:failed to create gbm

It tries to find a gbm driver with name "vgem" and fails, as there is no such driver in the driver_list.

https://chromium.googlesource.com/chromiumos/platform/minigbm/+/master/gbm.c#53

3. I built an image with arm64-llvmpipe public overlay, and tried to boot it with my kernel. But it produces the same result with chromium browser as well as null_platform_test.

 

What next?

 

1. May be something is missing in my kernel (although this seems less likely to me)

2. I bumped upon this code which suggests that software rendering is not supported with GBM platform. Not sure if it's about the same thing.

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/drm/gpu/gbm_surface_factory.cc&sq=package:chromium&type=cs&l=68

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/public/surface_ozone_canvas.h&sq=package:chromium&type=cs&l=22

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/public/surface_ozone_egl.h&sq=package:chromium&type=cs&l=41

3. Does software rendering with ozone-gbm platform really work? This patch suggests that it should work with vgem+swrast, which is what I am trying.

https://codereview.chromium.org/1345703002

May be any other configurations are required?

4. I got a references to ozone-dri platform, which supposedly supports software rendering. But I couldn't find the corresponding code. Has it been removed?

https://software.intel.com/en-us/blogs/2014/10/23/chromium-ozone-gbm-explained

Devs, could someone help me get on the right track?

[Vincent Palatin]

On Tue, May 17, 2016 at 7:38 AM, Sumit Agrawal <sumi...@gmail.com> wrote:

Vincent, I am not sure if I understand your earlier comment about minigbm completely.

Did you mean that minigbm implementation is needed for drm/vgem device, to enable the software rendering path?

No, I don't think so but I'm not the graphics expert either.

The minigbm implementation you are going to use is the one for your actual GPU drivers

 

 

I am trying to debug the vgem path further.

You shouldn't have to unless you are not using Chrome OS kernel,

should work out of the box.

 

I have DRM_VGEM enabled, and vgem device is listed as below:

localhost ~ # ls -la /sys/class/drm

drwxr-xr-x  2 root root    0 Dec 31  1969 .

drwxr-xr-x 50 root root    0 Dec 31  1969 ..

lrwxrwxrwx  1 root root    0 Dec 31  1969 card0 -> ../../devices/platform/vgem/drm/card0

lrwxrwxrwx  1 root root    0 Dec 31  1969 card1 -> ../../devices/platform/soc/900000.qcom,mdss_mdp/drm/card1

lrwxrwxrwx  1 root root    0 Dec 31  1969 card1-HDMI-A-1 -> ../../devices/platform/soc/900000.qcom,mdss_mdp/drm/card1/card1-HDMI-A-1

lrwxrwxrwx  1 root root    0 Dec 31  1969 controlD64 -> ../../devices/platform/soc/900000.qcom,mdss_mdp/drm/controlD64

lrwxrwxrwx  1 root root    0 Dec 31  1969 renderD128 -> ../../devices/platform/vgem/drm/renderD128

lrwxrwxrwx  1 root root    0 Dec 31  1969 renderD129 -> ../../devices/platform/soc/900000.qcom,mdss_mdp/drm/renderD129

lrwxrwxrwx  1 root root    0 Dec 31  1969 ttm -> ../../devices/virtual/drm/ttm

-r--r--r--  1 root root 4096 Dec 31  1969 version

1. With Chromium browser, I get this error:

[4971:4990:0422/143205:ERROR:drm_device_manager.cc(53)] Could not initialize DRM device for /sys/devices/platform/vgem/drm/card0

I figured that devices that cannot perform modesetting (like vgem) are ignored in ozone/platform/drm. So, the call doesn't even reach minigbm for vgem device.

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/drm/gpu/gbm_device.cc&rcl=1463440736&l=23

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc&l=398

2. With null_platform_test, I get below error: (I put some extra logs in minigbm/gbm.c)

localhost ~ # null_platform_test /dev/dri/card0

Don't do this,

run it on your actual GPU driver (likely the Qualcomm stuff on card1)

actually null_platform_test should select it automatically.

 

minigbm: gbm_create_device

minigbm: gbm_get_driver

minigbm: drm_version->name=vgem

minigbm: NOT FOUND drm_version->name=vgem

minigbm: gbm_get_driver failed

ERROR:main():null_platform_test.c:81:failed to create gbm

It tries to find a gbm driver with name "vgem" and fails, as there is no such driver in the driver_list.

https://chromium.googlesource.com/chromiumos/platform/minigbm/+/master/gbm.c#53

You need to do a driver for your qcomm gpu

 

3. I built an image with arm64-llvmpipe public overlay, and tried to boot it with my kernel. But it produces the same result with chromium browser as well as null_platform_test.

first, as mentioned above do not force it to run on vgem driver, that's incorrect.

Also, you need your regular GPU DRM driver driver to support a few features (e.g PRIME primitives, mmap )

that's done for the virtio_gpu driver used when running arm64-llvmpipe inside an emulator but maybe not for the qcom driver you are using

 

 

What next?

 

1. May be something is missing in my kernel (although this seems less likely to me)

2. I bumped upon this code which suggests that software rendering is not supported with GBM platform. Not sure if it's about the same thing.

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/drm/gpu/gbm_surface_factory.cc&sq=package:chromium&type=cs&l=68

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/public/surface_ozone_canvas.h&sq=package:chromium&type=cs&l=22

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/public/surface_ozone_egl.h&sq=package:chromium&type=cs&l=41

That's for software rendering on the Chrome side,

here Chrome will see normal accelerated GL (which will be in fact emulated in software by MESA llvmpipe)

 

3. Does software rendering with ozone-gbm platform really work?

Up to you to believe me or not,

but as I already told you I'm running regularly the arm64-llvmpipe overlay with this config,

I did it too with nvidia t210 DRM driver in the past.

 

This patch suggests that it should work with vgem+swrast, which is what I am trying.

https://codereview.chromium.org/1345703002

May be any other configurations are required?

Your actual GPU DRM is missing some bits.

 

4. I got a references to ozone-dri platform, which supposedly supports software rendering. But I couldn't find the corresponding code. Has it been removed?

https://software.intel.com/en-us/blogs/2014/10/23/chromium-ozone-gbm-explained

Devs, could someone help me get on the right track?

[Stéphane Marchesin]

On Tue, May 17, 2016 at 8:36 AM, Vincent Palatin <vpal...@chromium.org> wrote:
>
>
> On Tue, May 17, 2016 at 7:38 AM, Sumit Agrawal <sumi...@gmail.com> wrote:
>>>>
>>>> Vincent, I am not sure if I understand your earlier comment about
>>>> minigbm completely.
>>>>
>>>> Did you mean that minigbm implementation is needed for drm/vgem device,
>>>> to enable the software rendering path?
>>>>
>>>>
>
> No, I don't think so but I'm not the graphics expert either.

Yes you need a minigbm implementation for your platform, even if
you're using mesa in swrast mode. It usually sits on top of your
DRM/KMS display driver which is also a requirement.

Stéphane

> ---
> You received this message because you are subscribed to the Google Groups
> "Chromium OS dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-os-d...@chromium.org.

[Sumit Agrawal]

Sorry for being ambiguous earlier. I probably forgot to mention that my GPU driver is not ready yet, and will take some more time. Meanwhile, I want to run the rest of my system with software rendering. 

Vincent, I take your word. For you, arm64-llvmpipe works as-is probably because you have an actual GPU driver, which is not the case with me.

Stephane, my DRM/KMS display driver is functional and I am able to run modetest successfully. As mentioned earlier, I am able to see the boot-splash screen as well.

Given my peculiar situation, could you guys help me figure out the requirements to enable software rendering? 

Does ozone-gbm platform support this scenario? If yes, is minigbm implementation still required? If yes, for which device and what purpose? What about vgem/swrast?

Is there any other platform like ozone-dri or something else, which I should try?

PS: I also tried --disable-gpu flag, but it seems it's not supported on CrOS.

--

-----------------
Regards,
Sumit Agrawal

[Vincent Palatin]

On Tue, May 17, 2016 at 9:42 AM, Sumit Agrawal <sumi...@gmail.com> wrote:

Sorry for being ambiguous earlier. I probably forgot to mention that my GPU driver is not ready yet, and will take some more time. Meanwhile, I want to run the rest of my system with software rendering. 

Vincent, I take your word. For you, arm64-llvmpipe works as-is probably because you have an actual GPU driver,

Well, I 'have' it, i wrote this missing part for this setup : e.g. https://chromium-review.googlesource.com/#/c/339490/

 

which is not the case with me.

Stephane, my DRM/KMS display driver is functional and I am able to run modetest successfully. As mentioned earlier, I am able to see the boot-splash screen as well.

That's a good start.

 

Given my peculiar situation, could you guys help me figure out the requirements to enable software rendering? 

Implement the PRIME primitives in your DRM driver including mmap.

 

Does ozone-gbm platform support this scenario?

Yes it should

 

If yes, is minigbm implementation still required? If yes, for which device and what purpose?

Yes it is, it might be really minimal, see udl.c or virtio_gpu.c

 

What about vgem/swrast?

Is there any other platform like ozone-dri or something else, which I should try?

No, I think the above path is the easiest one to a working setup.

 

PS: I also tried --disable-gpu flag, but it seems it's not supported on CrOS.

Yes it is not for some time now.

[Sumit Agrawal]

Thanks Vincent, it works now!