Build radeon+amdgpu on aarch64 #154

valpackett · 2019-06-29T11:33:00Z

It works!!

Requires: D20787 and D20789

Tested on: Marvell MACCHIATObin + AMD Radeon RX 480

johalun · 2019-06-29T20:55:16Z

amd/amdgpu/Makefile

@@ -435,21 +446,8 @@ SRCS+=	device_if.h vnode_if.h bus_if.h pci_if.h device_if.h iicbus_if.h opt_drm.

 .include <bsd.kmod.mk>

-CFLAGS.gcc+= -Wno-redundant-decls -Wno-cast-qual -Wno-unused-but-set-variable
-.if ${MACHINE_CPUARCH} == "powerpc"


Why do you remove all the powerpc stuff?

I've explained this in the commit message. This part of the code (DML) is not used on powerpc because

kms-drm/drivers/gpu/drm/drm_os_config.h

Lines 127 to 129 in 6e6a861

#ifdef __amd64__

#define CONFIG_DRM_AMD_DC_DCN1_0 1

#endif

Upstream only builds it on amd64 torvalds/linux@bf2e2e2

IIUC, this code is only for Raven Ridge laptops

zeising · 2019-06-29T22:09:08Z

How does this relate to the work manu@ is doing? I know he's also working on DRM for arm64 stuff.

valpackett · 2019-06-30T11:02:11Z

@zeising the recent allwinner work? Yeah, it's quite different — @evadot made a from-scratch BSD-licensed driver for the Allwinner display engine, and it's based on drmlib which is an import of linuxkpi-gplv2 stuff etc. into FreeBSD base, and currently still has some GPL code in base as I understand. The rationale is that the various single board computers should have display support out of the box, without installing a package.

Meanwhile this is a tested small patch that enables AMD Radeon support on desktop-class arm64 systems.

zeising · 2019-06-30T11:46:43Z

@zeising the recent allwinner work? Yeah, it's quite different — @evadot made a from-scratch BSD-licensed driver for the Allwinner display engine, and it's based on drmlib which is an import of linuxkpi-gplv2 stuff etc. into FreeBSD base, and currently still has some GPL code in base as I understand. The rationale is that the various single board computers should have display support out of the box, without installing a package.

Meanwhile this is a tested small patch that enables AMD Radeon support on desktop-class arm64 systems.

Thank you for the explanation!

valpackett · 2019-07-01T14:23:36Z

wayfire says hello! with some buffer corruption on client applications (that goes away and reappears occasionally), but i've heard about that on linux, so that's not freebsd's fault

UPD: it's this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923723 let's backport this tiny patch

better now

:)

valpackett · 2019-07-20T20:38:38Z

Update: we also need to use MSI (old in-tree DRM did, btw!!) instead of legacy interrupts, because legacy is a disaster on aarch64 (I've been getting an interrupt rate of 300000, which was wasting CPU time and reducing responsiveness/performance). (This is not a GPU-exclusive thing, on a KVM VPS I've had MSI blacklisted for some reason and legacy interrupts resulted in horrible virtio disk performance :D)

https://reviews.freebsd.org/D21008 — kernel patch for implementing the enable/disable functions. (updates are required in here too, but I haven't pushed that yet)

valpackett · 2019-07-20T20:51:26Z

and here's a screenshot with something you might recognize :)

andreasdr · 2019-07-20T21:38:29Z

Hi, Wow. Thats impressive. Best regards Andreas Am 20.07.2019 um 22:51 schrieb myfreeweb:

…

and here's a screenshot with something you might recognize :) G A M I N G <https://user-images.githubusercontent.com/208340/61584004-1ed8d580-ab49-11e9-8fee-22669a3ada60.jpg> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#154?email_source=notifications&email_token=ACJXOOBCXC5S6ULKDWRV7X3QAN3E7A5CNFSM4H4KG3RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NVZXI#issuecomment-513498333>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACJXOOEMZ5EVY22T3EAVBB3QAN3E7ANCNFSM4H4KG3RA>.

zeising · 2019-08-07T10:19:43Z

Is #163 a prerequisite for this?

valpackett · 2019-08-07T11:51:29Z

Not really, #163 improves performance but is not required to build. The prerequisites are the kernel patches linked in the first post.

zeising · 2019-08-07T12:00:05Z

Ok, thank you!
Is there an ordering thing here? Will this build without the kernel update? Will drm-kmod build with the kernel update but not this?

I'm just asking because I need to know in which order things need to happen, and preferably, it would be good to keep backwards compat, meaning that with your kernel update, older versions of drm-kmod works (on at least the arches that worked before).

valpackett · 2019-08-07T12:26:27Z

On aarch64, both the kernel update and this are required obviously. But it's not like aarch64 was enabled already :)

On amd64, i386, powerpc64 everything should build as normal, the kernel update doesn't touch them.

Would be nice if someone retested on power with this though.

zeising · 2019-08-07T12:29:52Z

Noted, thanks!

valpackett · 2019-08-09T19:36:33Z

New test results: with a Cape Verde XT card, which is recognized by the EFI GOP driver (Polaris for some reason is just ignored, I'll contact AMD about that), even switching from efifb to amdgpu fb works :)

Also this card allows me to test radeonkms too. It works.

UPD: lol, my Polaris card was ignored because the VBIOS was modified (for performance)

johalun · 2019-08-27T17:37:01Z

ttm/Makefile

@@ -17,6 +16,10 @@ SRCS=	ttm_agp_backend.c \
 	ttm_page_alloc_dma.c \
 	ttm_tt.c

+.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"


I think powerpc also needs this file.

I don't think AGP was ever a thing on powerpc64? (and we don't yet run on 32-bit powerpc, right?)

https://github.com/myfreeweb/kms-drm/blob/drm-v5.0-aarch64/drivers/gpu/drm/drm_os_config.h#L62-L64 — it is disabled

That might be so.. Just don't want to break build on powerpc64. Did you try a powerpc64 cross build?

hm, is it possible to cross-build this? what are the args? TARGET/TARGET_ARCH seem to be ignored, MACHINE/MACHINE_ARCH just makes it think I'm on powerpc64

// maybe someone with POWER can test? (just that this patch doesn't break powerpc64) /cc @chmeeedalf @mattmacy @bdragon28 @kev009

Check the last entry here: https://forums.freebsd.org/threads/cross-compiling-a-kernel-module.45662/
I think I did this before when compiling for i386. I'll give it try myself later today.

Well that didn't work at all for powerpc :(

The early PowerMac G5s did have AGP. Only the last one or two generations had PCIe.

oh, right. But AGP+powerpc is currently disabled here:

kms-drm/drivers/gpu/drm/drm_os_config.h

Lines 54 to 56 in dc414a9

#if !defined(__powerpc__)

#define CONFIG_AGP 1

#endif

I think the AGP files should be in sync with the CONFIG_AGP variable. Does the module build on powerpc64 without these files?

johalun · 2019-08-27T17:38:20Z

drm/Makefile

@@ -86,6 +85,10 @@ SRCS=	ati_pcigart.c \
 	tainted_linux_fb.c \
 	linux_hdmi.c

+.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"


Missing powerpc

Upstream only builds it on amd64 for now, and it was not doing anything on POWER since CONFIG_DRM_AMD_DC_DCN1_0 is ifdef'd to amd64.

…6/amd64 AGP files were built on POWER (which was successful due to old PowerPC Mac stuff in tree), but CONFIG_AGP was not enabled so drivers did not actually use AGP. On aarch64, agp is completely absent, so depending on the module is not possible.

ACPI is available on aarch64.

amd/Makefile

Tested on: Marvell MACCHIATObin + AMD Radeon RX 480 (POLARIS10)

The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: David Zhou <David1.Zhou@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: Junwei Zhang <Jerry.Zhang@amd.com> Cc: Michel Daenzer <michel.daenzer@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: amd-gfx list <amd-gfx@lists.freedesktop.org> Cc: dri-devel <dri-devel@lists.freedesktop.org> Reported-by: Carsten Haitzler <Carsten.Haitzler@arm.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König <christian.koenig@amd.com>

* amdgpu: only build DML (Display Mode Library) on amd64 Upstream only builds it on amd64 for now, and it was not doing anything on POWER since CONFIG_DRM_AMD_DC_DCN1_0 is ifdef'd to amd64. * Use CONFIG_AGP for agp module dependency, only build agp files on i386/amd64 AGP files were built on POWER (which was successful due to old PowerPC Mac stuff in tree), but CONFIG_AGP was not enabled so drivers did not actually use AGP. On aarch64, agp is completely absent, so depending on the module is not possible. * linux_notifier: use CONFIG_ACPI instead of X86 to check for ACPI ACPI is available on aarch64. * drm: disable uncached DMA optimization for ARM and arm64 The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: David Zhou <David1.Zhou@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: Junwei Zhang <Jerry.Zhang@amd.com> Cc: Michel Daenzer <michel.daenzer@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: amd-gfx list <amd-gfx@lists.freedesktop.org> Cc: dri-devel <dri-devel@lists.freedesktop.org> Reported-by: Carsten Haitzler <Carsten.Haitzler@arm.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König <christian.koenig@amd.com> * Enable radeon+amdgpu on aarch64 Tested on: Marvell MACCHIATObin + AMD Radeon RX 480 (POLARIS10)

johalun reviewed Jun 29, 2019

View reviewed changes

valpackett force-pushed the drm-v5.0-aarch64 branch from 4bba53e to 56383e2 Compare July 2, 2019 10:47

valpackett force-pushed the drm-v5.0-aarch64 branch 3 times, most recently from 3fca783 to 1539c66 Compare August 7, 2019 01:02

zeising mentioned this pull request Aug 8, 2019

12.0-STABLE r350740 GENERIC amd64 panic when loading i915kms.k #164

Closed

johalun reviewed Aug 27, 2019

View reviewed changes

valpackett added 3 commits August 28, 2019 00:00

amdgpu: only build DML (Display Mode Library) on amd64

2091ebd

Upstream only builds it on amd64 for now, and it was not doing anything on POWER since CONFIG_DRM_AMD_DC_DCN1_0 is ifdef'd to amd64.

linux_notifier: use CONFIG_ACPI instead of X86 to check for ACPI

0d4913f

ACPI is available on aarch64.

valpackett force-pushed the drm-v5.0-aarch64 branch from 1539c66 to 07ffb24 Compare August 27, 2019 22:07

chmeeedalf reviewed Aug 28, 2019

View reviewed changes

amd/Makefile Outdated Show resolved Hide resolved

valpackett and others added 2 commits August 28, 2019 20:03

Enable radeon+amdgpu on aarch64

bba285c

Tested on: Marvell MACCHIATObin + AMD Radeon RX 480 (POLARIS10)

valpackett force-pushed the drm-v5.0-aarch64 branch from 07ffb24 to 7fe2f58 Compare August 28, 2019 17:04

johalun merged commit 4ec15b7 into FreeBSDDesktop:drm-v5.0 Aug 30, 2019

Build radeon+amdgpu on aarch64 #154

Build radeon+amdgpu on aarch64 #154

Uh oh!

Conversation

valpackett commented Jun 29, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zeising commented Jun 29, 2019

Uh oh!

valpackett commented Jun 30, 2019

Uh oh!

zeising commented Jun 30, 2019

Uh oh!

valpackett commented Jul 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

valpackett commented Jul 20, 2019

Uh oh!

valpackett commented Jul 20, 2019

Uh oh!

andreasdr commented Jul 20, 2019 via email

Uh oh!

zeising commented Aug 7, 2019

Uh oh!

valpackett commented Aug 7, 2019

Uh oh!

zeising commented Aug 7, 2019

Uh oh!

valpackett commented Aug 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zeising commented Aug 7, 2019

Uh oh!

valpackett commented Aug 9, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

valpackett commented Jul 1, 2019 •

edited

Loading

valpackett commented Aug 7, 2019 •

edited

Loading

valpackett commented Aug 9, 2019 •

edited

Loading