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 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.
> 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?
Matt
[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
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
