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

From: Adam Ford
Date: Tue Feb 20 2024 - 06:59:55 EST

Next message: Bartosz Golaszewski: "Re: [PATCH v1] gpiolib: Handle no pin_ranges in gpiochip_generic_config()"
Previous message: Abel Vesa: "[PATCH v5 2/2] phy: qcom: edp: Add set_mode op for configuring eDP/DP submode"
In reply to: Adam Ford: "Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3"
Next in thread: Erico Nunes: "Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Tue, Feb 20, 2024 at 5:26 AM Adam Ford <aford173@xxxxxxxxx> wrote:
>
> On Tue, Feb 20, 2024 at 3:21 AM Matt Coster <Matt.Coster@xxxxxxxxxx> wrote:
> >
> > Hi Adam,
> >
> > On 19/02/2024 20:38, Adam Ford wrote:
> > > On Mon, Feb 19, 2024 at 3:00 AM Matt Coster <Matt.Coster@xxxxxxxxxx> wrote:
> > >>
> > >> 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.
> > >
> > > I hacked the look-up-tables in the Mesa PowerVR driver to match the
> > > values of the other GX6250. I know there must be some minor
> > > differences, but I don't know what they are right now.
> >
> > In case you missed my other email, we have device info for the GX6250
> > variant you’re using in [2]. I’ve been informed that branch should be
> > usable as-is – can you give that a try?
>
> I did migrate to the branch you referenced and remove my hacked
> lookup-table, but I get similar results.
>
> >
> > > I also had to tweak src/imagination/vulkan/pvr_device.c again to the
> > > following:
> > > DEF_CONFIG("renesas,r8a774a1-gpu", "renesas,du-r8a774a1"),
> >
> > Ah yes, not perfectly as-is then. These lines (pvr_drm_configs) declare
> > the pairing of GPU to display hardware. You’ll still need this tweak.

Should I push this tweak to gitlab? I think there are a few other
Renesas SoC's that have the same GX6250 GPU.

> >
> > > I am not positive that is the correct thing to do, but with that, I
> > > can now run vulkaninfo.
> > > I know that it's not fully Vulkan compliant yet, but it appears there
> > > is some progress:
> > >
> > > Layers: count = 2
> > > =================
> > > VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan
> > > version 1.3.211, layer version 1:
> > > Layer Extensions: count = 0
> > > Devices: count = 2
> > > GPU id = 0 (Imagination PowerVR Rogue GX6250)
> > > Layer-Device Extensions: count = 0
> > >
> > > GPU id = 1 (llvmpipe (LLVM 15.0.7, 128 bits))
> > > Layer-Device Extensions: count = 0
> > >
> > > VK_LAYER_MESA_overlay (Mesa Overlay layer) Vulkan version 1.3.211,
> > > layer version 1:
> > > Layer Extensions: count = 0
> > > Devices: count = 2
> > > GPU id = 0 (Imagination PowerVR Rogue GX6250)
> > > Layer-Device Extensions: count = 0
> > >
> > > GPU id = 1 (llvmpipe (LLVM 15.0.7, 128 bits))
> > > Layer-Device Extensions: count = 0
> > >
> > >
> > > I then tried to redndr with vkgears, but it didn't redner. When I run
> > > vkgears, I get the following:
> > >
> > > LAYER: Searching for layer manifest files
> > > LAYER: In following locations:
> > > LAYER: /home/aford/.config/vulkan/implicit_layer.d
> > > LAYER: /etc/xdg/xdg-ubuntu/vulkan/implicit_layer.d
> > > LAYER: /etc/xdg/vulkan/implicit_layer.d
> > > LAYER: /etc/vulkan/implicit_layer.d
> > > LAYER: /home/aford/.local/share/vulkan/implicit_layer.d
> > > LAYER: /usr/share/ubuntu/vulkan/implicit_layer.d
> > > LAYER: /usr/share/gnome/vulkan/implicit_layer.d
> > > LAYER: /usr/local/share/vulkan/implicit_layer.d
> > > LAYER: /usr/share/vulkan/implicit_layer.d
> > > LAYER: /var/lib/snapd/desktop/vulkan/implicit_layer.d
> > > LAYER: Found the following files:
> > > LAYER:
> > > /usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json
> > > LAYER: Searching for layer manifest files
> > > LAYER: In following locations:
> > > LAYER: /home/aford/.config/vulkan/explicit_layer.d
> > > LAYER: /etc/xdg/xdg-ubuntu/vulkan/explicit_layer.d
> > > LAYER: /etc/xdg/vulkan/explicit_layer.d
> > > LAYER: /etc/vulkan/explicit_layer.d
> > > LAYER: /home/aford/.local/share/vulkan/explicit_layer.d
> > > LAYER: /usr/share/ubuntu/vulkan/explicit_layer.d
> > > LAYER: /usr/share/gnome/vulkan/explicit_layer.d
> > > LAYER: /usr/local/share/vulkan/explicit_layer.d
> > > LAYER: /usr/share/vulkan/explicit_layer.d
> > > LAYER: /var/lib/snapd/desktop/vulkan/explicit_layer.d
> > > LAYER: Found the following files:
> > > LAYER:
> > > /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
> > > ERROR: loader_validate_instance_extensions: Instance
> > > extension VK_KHR_wayland_surface not supported by available ICDs or
> > > enabled layers.
> > > Failed to create Vulkan instance.
> > >
> > > I have tried running in X.org mode instead of Wayland, but I get a
> > > different set of errors:
> >
> > We haven’t been testing with window systems yet – can you try building
> > the Sascha Willems demos [1] with -DUSE_D2D_WSI=ON and try running
> > triangle?
>
> I didn't realize you hadn't tried window systems yet.
>
> I'll give that a try. I appreciate the suggestions.
>
> adam
> >
> > Matt

Matt,

I cloned and built the repo you suggested with -DUSE_D2D_WSI=ON, and
cmake threw a warning:

CMake Warning (dev) at
/usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:438
(message):
The package name passed to `find_package_handle_standard_args` (WAYLAND)
does not match the name of the calling package (Wayland). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):

I then built with make and executed the triangle demo with the following dump:

INFO | LAYER: Insert instance layer "VK_LAYER_MESA_device_select"
(libVkLayer_MESA_device_select.so)
LAYER: vkCreateInstance layer callstack setup to:
LAYER: <Application>
LAYER: ||
LAYER: <Loader>
LAYER: ||
LAYER: VK_LAYER_MESA_device_select
LAYER: Type: Implicit
LAYER: Disable Env Var: NODEVICE_SELECT
LAYER: Manifest:
/usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json
LAYER: Library: libVkLayer_MESA_device_select.so
LAYER: ||
LAYER: <Drivers>
WARNING: terminator_CreateInstance: Failed to CreateInstance
in ICD 2. Skipping ICD.
WARNING: terminator_CreateInstance: Failed to CreateInstance
in ICD 5. Skipping ICD.
MESA: error: Render device '/dev/dri/renderD128' has no compatible
display device.
DEBUG: Copying old device 0 into new device 0
DEBUG: Copying old device 1 into new device 1
DEBUG: Copying old device 0 into new device 0
DEBUG: Copying old device 1 into new device 1
DEBUG: Copying old device 0 into new device 0
DEBUG: Copying old device 1 into new device 1
INFO | LAYER: Failed to find vkGetDeviceProcAddr in layer
"libVkLayer_MESA_device_select.so"
LAYER: vkCreateDevice layer callstack setup to:
LAYER: <Application>
LAYER: ||
LAYER: <Loader>
LAYER: ||
LAYER: <Device>
LAYER: Using "Imagination PowerVR Rogue GX6250" with
driver: "/usr/lib/aarch64-linux-gnu/libvulkan_powervr_mesa.so"
Validation error: Incorrect coeff register usage list.

/* USC program */

Aborted (core dumped)

When the renderD128 has no compatible display device, does that mean
there is more I should have done to somehow connect the rcar-du to the
GX6250?

> >
> > [2]: https://gitlab.freedesktop.org/imagination/mesa/-/tree/dev/devinfo
> >
> > > [ 11102.013] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
> > > [ 11102.014] (II) Module fbdevhw: vendor="X.Org Foundation"
> > > [ 11102.014] compiled for 1.21.1.7, module version = 0.0.2
> > > [ 11102.014] ABI class: X.Org Video Driver, version 25.2
> > > [ 11102.015] (II) FBDEV(0): using default device
> > > [ 11102.016] (II) modeset(G0): using drv /dev/dri/card1
> > > [ 11102.016] (EE)
> > > Fatal server error:
> > > or all framebuffer devices
> > > [ 11102.016] (EE)
> > > [ 11102.017] (EE)
> > > Please consult the The X.Org Foundation support at http://wiki.x.org for help.
> > >
> > > I think I am close.
> > >
> > > adam
> > >>
> > >> Matt
> > >>
> > >> [1]: https://github.com/SaschaWillems/Vulkan

Next message: Bartosz Golaszewski: "Re: [PATCH v1] gpiolib: Handle no pin_ranges in gpiochip_generic_config()"
Previous message: Abel Vesa: "[PATCH v5 2/2] phy: qcom: edp: Add set_mode op for configuring eDP/DP submode"
In reply to: Adam Ford: "Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3"
Next in thread: Erico Nunes: "Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]