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

[Matt Coster]

Hi Adam,

On 18/02/2024 23:26, Adam Ford wrote:
> 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.
> 
> adam
> 
> 
> 
> 
>>
>> Maxime

I suggest you try running Vulkan demos (we use Sascha Willems’ [1])
instead of GL at this stage. Support for Zink is currently under heavy
development so you may have trouble differentiating between issues with
your kernel changes and the incompleteness in Mesa.

Matt

[1]: https://github.com/SaschaWillems/Vulkan

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature