RE: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Biju Das]

Hi Adam,

> -----Original Message-----
> From: Adam Ford <aford173@xxxxxxxxx>
> Sent: Sunday, February 18, 2024 11:26 PM
> Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> on ARCH_K3
> 
> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@xxxxxxxxxx> wrote:
> >
> > On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
> > > Hi Maxime Ripard,
> > >
> > > > -----Original Message-----
> > > > From: Maxime Ripard <mripard@xxxxxxxxxx>
> > > > Sent: Friday, February 16, 2024 9:05 AM
> > > > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should
> > > > depend on
> > > > ARCH_K3
> > > >
> > > > On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> > > > > Hi Adam Ford,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Adam Ford <aford173@xxxxxxxxx>
> > > > > > Sent: Thursday, February 15, 2024 11:36 PM
> > > > > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should
> > > > > > depend on
> > > > > > ARCH_K3
> > > > > >
> > > > > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@xxxxxxxxx>
> wrote:
> > > > > > >
> > > > > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford
> > > > > > > <aford173@xxxxxxxxx>
> > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > > > > > > <geert@xxxxxxxxxxxxxx> wrote:
> > > > > > > > >
> > > > > > > > > Hi Maxime,
> > > > > > > > >
> > > > > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> > > > > > > > > <mripard@xxxxxxxxxx>
> > > > > > wrote:
> > > > > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert
> > > > > > > > > > Uytterhoeven
> > > > > > wrote:
> > > > > > > > > > > Using the Imagination Technologies PowerVR Series 6
> > > > > > > > > > > GPU requires a proprietary firmware image, which is
> > > > > > > > > > > currently only available for Texas Instruments K3
> > > > > > > > > > > AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > > > > > > > > > > prevent asking the user about this driver when
> > > > > > > > > > > configuring a kernel without Texas Instruments K3
> > > > > > Multicore SoC support.
> > > > > > > > > >
> > > > > > > > > > This wasn't making sense the first time you sent it,
> > > > > > > > > > and now that commit log is just plain wrong. We have
> > > > > > > > > > firmwares for the G6110, GX6250, GX6650, BXE-4-32, and
> > > > > > > > > > BXS-4-64 models, which can be found on (at least)
> > > > > > > > > > Renesas, Mediatek, Rockchip, TI and StarFive, so
> > > > > > > > > > across three
> > > > > > > > >
> > > > > > > > > I am so happy to be proven wrong!
> > > > > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
> > > > > > > > > R-Car M3-
> > > > > > W.
> > > > > > > > >
> > > > > > > > > > architectures and 5 platforms. In two months.
> > > > > > > > >
> > > > > > > > > That sounds like great progress, thanks a lot!
> > > > > > > > >
> > > > > > > > Geert,
> > > > > > > >
> > > > > > > > > Where can I find these firmwares? Linux-firmware[1]
> > > > > > > > > seems to lack all but the original K3 AM62x one.
> > > > > > > >
> > > > > > > > I think PowerVR has a repo [1], but the last time I
> > > > > > > > checked it, the BVNC for the firmware didn't match what
> > > > > > > > was necessary for the GX6250 on the RZ/G2M.  I can't
> > > > > > > > remember what the corresponding R-Car3 model is.  I
> > > > > > > > haven't tried recently because I was told more
> > > > > > > > documentation for firmware porting would be delayed until
> everything was pushed into the kernel and Mesa.
> > > > > > > > Maybe there is a better repo and/or newer firmware somewhere
> else.
> > > > > > > >
> > > > > > > I should have doubled checked the repo contents before I
> > > > > > > sent my last e-mail , but it appears the firmware  [2] for
> > > > > > > the RZ/G2M, might be present now. I don't know if there are
> > > > > > > driver updates necessary. I checked my e-mails, but I didn't
> > > > > > > see any notification, or I would have tried it earlier.
> > > > > > > Either way, thank you Frank for adding it.  I'll try to test
> when I have some time.
> > > > > > >
> > > > > >
> > > > > > I don't have the proper version of Mesa setup yet, but for
> > > > > > what it's worth, the firmware loads without error, and it
> doesn't hang.
> > > > >
> > > > > Based on [1] and [2],
> > > > >
> > > > > kmscube should work on R-Car as it works on RZ/G2L with panfrost
> > > > > as earlier version of RZ/G2L which uses drm based on RCar-Du,
> > > > > later changed
> > > > to rzg2l-du.
> > > >
> > > > IIRC, the mesa support isn't there yet for kmscube to start.
> > >
> > > What about glmark2? I tested glmark2 as well.
> >
> > It's not really a matter of kmscube itself, but the interaction with
> > the compositor entirely. You can run a headless vulkan rendering, but
> > an application that renders to a window won't work.
> 
> I have made a little progress.  I have Ubuntu running on an RZ/G2M (Rogue
> GX6250) with a device tree configuring the GPU and the GPU loads with
> firmware.
> 
>   powervr fd000000.gpu: [drm] loaded firmware
> powervr/rogue_4.45.2.58_v1.fw
>   powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
>   [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0
> 
> drmdevice lists card0 and renderD128
> --- Checking the number of DRM device available ---
> --- Devices reported 2 ---
> --- Retrieving devices information (PCI device revision is ignored) ---
> device[0]
> +-> available_nodes 0x05
> +-> nodes
> |   +-> nodes[0] /dev/dri/card0
> |   +-> nodes[2] /dev/dri/renderD128
> +-> bustype 0002
> |   +-> platform
> |       +-> fullname /soc/gpu@fd000000
> +-> deviceinfo
>     +-> platform
>         +-> compatible
>                     renesas,r8a774a1-gpu
>                     img,img-axe
> 
> There is more to this dump, but it seems to repeat. I wanted to show that
> it seems like it's trying to work.
> 
> I think I need to modify the powervr code in mesa to recognize the
> renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not sure,
> and I am hoping someone might be able to provide some guidance, since I
> think I am missing something somewhere. I modified pvr_device.c in the
> mesa driver to attempt do this:
> 
> /* This is the list of supported DRM render/display driver configs. */
> static const struct pvr_drm_device_config pvr_drm_configs[] = {
>    DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
>    DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
>    DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"), };
> 
> When I run modetest -M rcar-du, I can see the encoders and connectors and
> I can display test patterns, so the rcar-du is working.
> 
> I built Mesa 24.0.1 with the following options:
> 
> meson setup builddir -Dvulkan-drivers=imagination-experimental
> -Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast
> 
> I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
> documentation for the powerVR, and I have exported the variable for
> VK_ICD_FILENAMES to point to the powervr json file.
> 
> when I try to run glmark2-drm, I was expecting the GL reddered to be the
> powervr, but it keeps using the
> GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> 
> I realize this driver is still in its infancy, but I was hoping someone
> could give me some guidance to let me know if the work to do is on the
> Mesa side or the rcar-du driver side, or something else.
> 
> I rebuilt both libdrm and mesa.  While I don't get any errors, I also
> don't get the hardware acceleration I was hoping for.
> 
> I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
> MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm
> 
> ...but it only renders with llvmpipe
> 
>     glmark2 2023.01
> =======================================================
>     OpenGL Information
>     GL_VENDOR:      Mesa
>     GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
>     GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
>     Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
>     Surface Size:   3840x2160 fullscreen
> 
> 
> I am not as familiar with the Mesa side, but if I can get this working to
> a point where something is rendered, even if it's not 100% compliant, I'd
> like to push patches to the kernel and/or Mesa if necessary.

FYI, the glmark2 I tested on RZ/G2L with panfrost is with wayland window system [1].

Maybe there should be an panfrost equivalent package for powevr is available in mesa??
That is the only difference w.r.to panfrost.

PACKAGECONFIG_append_pn-mesa = " egl kmsro panfrost"


[1] https://renesas.info/wiki/RZ-G/Panfrost_for_RZG2L


Cheers,
Biju