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

[Matt Coster]

Hi Adam,

On 19/02/2024 16:38, Adam Ford wrote:
> On Mon, Feb 19, 2024 at 1:45 AM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
>>
>> 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"
>>
> 
> I am not using Yocto, because I am using Ubuntu, but I have build Mesa
> per the instructions they provided, but the glue that connects the
> powervr to the rcar-du isn't as clear.  I looked at the panfrost
> implementation, but I didn't see anything obvious.   It looks like the
> panfrost integrates with the kms driver, which I was rather expecting
> powervr would do.  I can tell the mesa library is build built and
> loaded but it's not attempting to use it for some reason
> 
> The GX6250 that is supported looks like it needs some additional
> look-up-tables added to src/imagination/common/pvr_device_info.c
> inside Mesa because the LUT they have is for a different BVNC despite
> the firmware for the BVNC being posted.  I'll have to see if I can
> find documentation for the the features that are enabled or not within
> this variant of the the GX6250.

You can find device info for some devices which are not fully supported
(yet) in [2], including what I think should be the GX6250 you’re looking
at. I’m not sure how up to date that branch’s base is, so probably best
to cherry-pick the change(s) you need.

Matt

[2]: https://gitlab.freedesktop.org/imagination/mesa/-/tree/dev/devinfo

> adam
> 
>>
>> [1] https://renesas.info/wiki/RZ-G/Panfrost_for_RZG2L
>>
>>
>> Cheers,
>> Biju
>>

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature