* Hardware 3D acceleration doesn't work anymore with the latest git kernel
@ 2017-11-20 18:08 Christian Zigotzky
2017-11-21 4:38 ` Alex Deucher
0 siblings, 1 reply; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-20 18:08 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]
Hi All,
I tested the latest Git kernel version [1] on my Varisys Nemo board with
a 64-bit dual-core PWRficient PA6T-1682M PowerPC CPU (A-EON AmigaOne
X1000) [2] today. Unfortunately hardware 3D acceleration doesn't work
anymore. It works without any problems with the kernel 4.14.0 [3].
Error messages:
dmesg | grep -i radeon
[ 0.720715] [drm] radeon kernel modesetting enabled.
[ 0.720832] radeon 0000:01:00.0: runtime IRQ mapping not provided by arch
[ 0.894456] radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 -
0x000000003FFFFFFF (1024M used)
[ 0.894468] radeon 0000:01:00.0: GTT: 1024M 0x0000000040000000 -
0x000000007FFFFFFF
[ 0.894617] [drm] radeon: 1024M of VRAM memory ready
[ 0.894624] [drm] radeon: 1024M of GTT memory ready.
[ 0.899823] [drm] radeon: dpm initialized
[ 0.933524] radeon 0000:01:00.0: (-12) create WB bo failed
[ 0.933532] radeon 0000:01:00.0: disabling GPU acceleration
[ 0.938686] [drm] Radeon Display Connectors
[ 1.447790] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[ 1.448338] [drm] Initialized radeon 2.50.0 20080528 for 0000:01:00.0
on minor 0
[ 39.299034] radeon_dp_aux_transfer_native: 158 callbacks suppressed
[ 70.924054] radeon_dp_aux_transfer_native: 158 callbacks suppressed
[ 683.732444] radeon_dp_aux_transfer_native: 410 callbacks suppressed
[ 1049.062659] radeon_dp_aux_transfer_native: 74 callbacks suppressed
Problem:
[ 0.933524] radeon 0000:01:00.0: (-12) create WB bo failed
[ 0.933532] radeon 0000:01:00.0: disabling GPU acceleration
I was able to revert the first DRM updates [4]. This solved the problem
with the hardware 3D acceleration on my Varisys Nemo board. That means
the bug is somewhere in the first DRM updates [4].
Please find attached the DRM revert log.
Cheers,
Christian
[1] http://www.xenosoft.de/vmlinux-4.15-alpha3-AmigaOne_X1000_X5000.tar.gz
[2] https://en.wikipedia.org/wiki/AmigaOne_X1000
[3] http://www.xenosoft.de/vmlinux-4.14-AmigaOne_X1000_X5000.tar.gz
[4]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e60e1ee60630cafef5e430c2ae364877e061d980
[-- Attachment #2: DRM_revert-4.15 --]
[-- Type: text/plain, Size: 11827 bytes --]
git revert e60e1ee60630cafef5e430c2ae364877e061d980 -m 1
Output:
[master c0fd66d] Revert "Merge tag 'drm-for-v4.15' of git://people.freedesktop.org/~airlied/linux"
Committer: christian <christian@AmigaoneX1000.lan>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly. Run the
following command and follow the instructions in your editor to edit
your configuration file:
git config --global --edit
After doing this, you may fix the identity used for this commit with:
git commit --amend --reset-author
1039 files changed, 49563 insertions(+), 69996 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt
delete mode 100644 Documentation/devicetree/bindings/display/faraday,tve200.txt
delete mode 100644 Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt
delete mode 100644 Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
delete mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
delete mode 100644 Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
delete mode 100644 Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
delete mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
delete mode 100644 Documentation/gpu/tve200.rst
delete mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
rewrite drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.c (81%)
rewrite drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h (62%)
delete mode 100644 drivers/gpu/drm/amd/include/linux/chash.h
delete mode 100644 drivers/gpu/drm/amd/lib/Kconfig
delete mode 100644 drivers/gpu/drm/amd/lib/Makefile
delete mode 100644 drivers/gpu/drm/amd/lib/chash.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/Makefile
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventactionchains.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventactionchains.h
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventinit.c
rename drivers/gpu/drm/amd/{amdgpu/amdgpu_sched.h => powerplay/eventmgr/eventinit.h} (73%)
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventmanagement.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventmanagement.h
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventmgr.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventsubchains.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventsubchains.h
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventtasks.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventtasks.h
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/psm.c
rename drivers/gpu/drm/amd/powerplay/{hwmgr/pp_psm.h => eventmgr/psm.h} (62%)
create mode 100644 drivers/gpu/drm/amd/powerplay/hwmgr/functiontables.c
rewrite drivers/gpu/drm/amd/powerplay/hwmgr/pp_overdriver.c (96%)
delete mode 100644 drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
create mode 100644 drivers/gpu/drm/amd/powerplay/inc/eventmanager.h
create mode 100644 drivers/gpu/drm/amd/powerplay/inc/eventmgr.h
create mode 100644 drivers/gpu/drm/amd/powerplay/inc/fiji_pwrvirus.h
rewrite drivers/gpu/drm/amd/powerplay/inc/polaris10_pwrvirus.h (96%)
delete mode 100644 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
delete mode 100644 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.h
copy drivers/gpu/drm/amd/powerplay/smumgr/{fiji_smumgr.c => fiji_smc.c} (84%)
create mode 100644 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.h
rewrite drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c (89%)
copy drivers/gpu/drm/amd/powerplay/smumgr/{iceland_smumgr.c => iceland_smc.c} (90%)
rename drivers/gpu/drm/{nouveau/nvkm/subdev/mmu/gp10b.c => amd/powerplay/smumgr/iceland_smc.h} (60%)
rewrite drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c (94%)
copy drivers/gpu/drm/amd/powerplay/smumgr/{polaris10_smumgr.c => polaris10_smc.c} (82%)
rename drivers/gpu/drm/amd/{amdgpu/amdgpu_mn.h => powerplay/smumgr/polaris10_smc.h} (55%)
rewrite drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c (88%)
copy drivers/gpu/drm/amd/powerplay/smumgr/{tonga_smumgr.c => tonga_smc.c} (92%)
create mode 100644 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.h
rewrite drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c (95%)
delete mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
delete mode 100644 drivers/gpu/drm/bridge/sii9234.c
delete mode 100644 drivers/gpu/drm/drm_lease.c
delete mode 100644 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
delete mode 100644 drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
delete mode 100644 drivers/gpu/drm/i915/i915_gemfs.c
delete mode 100644 drivers/gpu/drm/i915/i915_gemfs.h
delete mode 100644 drivers/gpu/drm/i915/i915_guc_submission.h
delete mode 100644 drivers/gpu/drm/i915/i915_oa_cflgt2.c
delete mode 100644 drivers/gpu/drm/i915/i915_oa_cflgt2.h
delete mode 100644 drivers/gpu/drm/i915/intel_guc.c
delete mode 100644 drivers/gpu/drm/i915/intel_guc.h
delete mode 100644 drivers/gpu/drm/i915/intel_guc_fw.h
rename drivers/gpu/drm/i915/{intel_guc_fw.c => intel_guc_loader.c} (58%)
delete mode 100644 drivers/gpu/drm/i915/intel_guc_log.h
delete mode 100644 drivers/gpu/drm/i915/intel_huc.h
delete mode 100644 drivers/gpu/drm/i915/intel_uc_fw.c
delete mode 100644 drivers/gpu/drm/i915/intel_uc_fw.h
delete mode 100644 drivers/gpu/drm/i915/selftests/huge_pages.c
delete mode 100644 drivers/gpu/drm/i915/selftests/lib_sw_fence.c
delete mode 100644 drivers/gpu/drm/i915/selftests/lib_sw_fence.h
rewrite drivers/gpu/drm/msm/adreno/a5xx_gpu.h (73%)
delete mode 100644 drivers/gpu/drm/msm/adreno/a5xx_preempt.c
delete mode 100644 drivers/gpu/drm/msm/msm_submitqueue.c
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if0008.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if000a.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if000b.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if000c.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if000d.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if500b.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if500d.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if900b.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if900d.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/ifb00d.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/ifc00d.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/mem.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/mmu.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/vmm.h
delete mode 100644 drivers/gpu/drm/nouveau/include/nvkm/core/oclass.h
rewrite drivers/gpu/drm/nouveau/include/nvkm/core/os.h (84%)
rewrite drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h (82%)
delete mode 100644 drivers/gpu/drm/nouveau/nouveau_mem.c
delete mode 100644 drivers/gpu/drm/nouveau/nouveau_mem.h
delete mode 100644 drivers/gpu/drm/nouveau/nouveau_vmm.c
delete mode 100644 drivers/gpu/drm/nouveau/nouveau_vmm.h
delete mode 100644 drivers/gpu/drm/nouveau/nvif/mem.c
delete mode 100644 drivers/gpu/drm/nouveau/nvif/mmu.c
delete mode 100644 drivers/gpu/drm/nouveau/nvif/vmm.c
rename drivers/gpu/drm/nouveau/nvkm/{subdev/therm/gp100.c => core/memory.c} (54%)
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/bar/gm107.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/bar/gm20b.c
rewrite drivers/gpu/drm/nouveau/nvkm/subdev/mmu/Kbuild (82%)
rewrite drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c (76%)
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/g84.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk104.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gm200.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gm20b.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gp10b.
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mem.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mem.h
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/memgf100.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/memnv04.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/memnv50.c
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv04.h
rewrite drivers/gpu/drm/nouveau/nvkm/subdev/mmu/priv.h (71%)
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/umem.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/umem.h
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/ummu.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/ummu.h
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.h
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk104.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm200.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv04.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv41.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv44.c
delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv50.c
delete mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
delete mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h
delete mode 100644 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
delete mode 100644 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
delete mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
delete mode 100644 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
create mode 100644 drivers/gpu/drm/pl111/pl111_connector.c
delete mode 100644 drivers/gpu/drm/pl111/pl111_versatile.c
delete mode 100644 drivers/gpu/drm/pl111/pl111_versatile.h
create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
rename drivers/gpu/drm/{nouveau/nvkm/subdev/mmu/gp100.c => radeon/radeon_kfd.h} (59%)
delete mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
delete mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h
rewrite drivers/gpu/drm/sun4i/Makefile (78%)
rewrite drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c (61%)
delete mode 100644 drivers/gpu/drm/tve200/Kconfig
delete mode 100644 drivers/gpu/drm/tve200/Makefile
delete mode 100644 drivers/gpu/drm/tve200/tve200_display.c
delete mode 100644 drivers/gpu/drm/tve200/tve200_drm.h
delete mode 100644 drivers/gpu/drm/tve200/tve200_drv.c
delete mode 100644 drivers/gpu/drm/udl/udl_connector.h
rename drivers/gpu/host1x/hw/{debug_hw_1x01.c => debug_hw.c} (51%)
delete mode 100644 drivers/gpu/host1x/hw/debug_hw_1x06.c
delete mode 100644 drivers/gpu/host1x/hw/host1x06.c
delete mode 100644 drivers/gpu/host1x/hw/host1x06.h
delete mode 100644 drivers/gpu/host1x/hw/host1x06_hardware.h
delete mode 100644 drivers/gpu/host1x/hw/hw_host1x06_hypervisor.h
delete mode 100644 drivers/gpu/host1x/hw/hw_host1x06_uclass.h
delete mode 100644 drivers/gpu/host1x/hw/hw_host1x06_vm.h
delete mode 100644 include/drm/drm_lease.h
delete mode 100644 include/drm/ttm/ttm_debug.h
delete mode 100644 include/dt-bindings/msm/msm-bus-ids.h
delete mode 100644 tools/testing/scatterlist/Makefile
delete mode 100644 tools/testing/scatterlist/linux/mm.h
delete mode 100644 tools/testing/scatterlist/main.c
[-- Attachment #3: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-20 18:08 Hardware 3D acceleration doesn't work anymore with the latest git kernel Christian Zigotzky
@ 2017-11-21 4:38 ` Alex Deucher
2017-11-21 11:32 ` Christian Zigotzky
2017-11-22 13:20 ` Christian Zigotzky
0 siblings, 2 replies; 24+ messages in thread
From: Alex Deucher @ 2017-11-21 4:38 UTC (permalink / raw)
To: Christian Zigotzky; +Cc: Maling list - DRI developers
On Mon, Nov 20, 2017 at 1:08 PM, Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
> Hi All,
>
> I tested the latest Git kernel version [1] on my Varisys Nemo board with a
> 64-bit dual-core PWRficient PA6T-1682M PowerPC CPU (A-EON AmigaOne X1000)
> [2] today. Unfortunately hardware 3D acceleration doesn't work anymore. It
> works without any problems with the kernel 4.14.0 [3].
>
> Error messages:
>
> dmesg | grep -i radeon
>
> [ 0.720715] [drm] radeon kernel modesetting enabled.
> [ 0.720832] radeon 0000:01:00.0: runtime IRQ mapping not provided by arch
> [ 0.894456] radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 -
> 0x000000003FFFFFFF (1024M used)
> [ 0.894468] radeon 0000:01:00.0: GTT: 1024M 0x0000000040000000 -
> 0x000000007FFFFFFF
> [ 0.894617] [drm] radeon: 1024M of VRAM memory ready
> [ 0.894624] [drm] radeon: 1024M of GTT memory ready.
> [ 0.899823] [drm] radeon: dpm initialized
> [ 0.933524] radeon 0000:01:00.0: (-12) create WB bo failed
> [ 0.933532] radeon 0000:01:00.0: disabling GPU acceleration
> [ 0.938686] [drm] Radeon Display Connectors
> [ 1.447790] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
> [ 1.448338] [drm] Initialized radeon 2.50.0 20080528 for 0000:01:00.0 on
> minor 0
> [ 39.299034] radeon_dp_aux_transfer_native: 158 callbacks suppressed
> [ 70.924054] radeon_dp_aux_transfer_native: 158 callbacks suppressed
> [ 683.732444] radeon_dp_aux_transfer_native: 410 callbacks suppressed
> [ 1049.062659] radeon_dp_aux_transfer_native: 74 callbacks suppressed
>
> Problem:
>
> [ 0.933524] radeon 0000:01:00.0: (-12) create WB bo failed
> [ 0.933532] radeon 0000:01:00.0: disabling GPU acceleration
If you look at the code, radeon_bo_create() is failing with -ENOMEM in
radeon_wb_init(). If you look at radeon_bo_create(), it can fail for
the following reasons:
1. kzalloc fails
2. drm_gem_object_init fails
3. ttm_bo_init fails
I'd start by looking into what's changed in those areas.
Alex
>
> I was able to revert the first DRM updates [4]. This solved the problem with
> the hardware 3D acceleration on my Varisys Nemo board. That means the bug is
> somewhere in the first DRM updates [4].
>
> Please find attached the DRM revert log.
>
> Cheers,
> Christian
>
>
> [1] http://www.xenosoft.de/vmlinux-4.15-alpha3-AmigaOne_X1000_X5000.tar.gz
> [2] https://en.wikipedia.org/wiki/AmigaOne_X1000
> [3] http://www.xenosoft.de/vmlinux-4.14-AmigaOne_X1000_X5000.tar.gz
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e60e1ee60630cafef5e430c2ae364877e061d980
>
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-21 4:38 ` Alex Deucher
@ 2017-11-21 11:32 ` Christian Zigotzky
2017-11-22 13:20 ` Christian Zigotzky
1 sibling, 0 replies; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-21 11:32 UTC (permalink / raw)
To: Alex Deucher, Maling list - DRI developers
Alex,
Thanks for your fast reply. I have looked in the first bad commit
e60e1ee60630cafef5e430c2ae364877e061d980 (Merge tag 'drm-for-v4.15') [1].
I have found a lot of kzalloc changes. I am sorry, I don't have any
experiences with this code. I only know that my Radeon HD6870 doesn't
have hardware 3D acceleration anymore.
Maybe I could revert the drm_gem_object_init and ttm_bo_init changes but
the kzalloc changes are too much. I think I need help to solve this issue.
Thanks,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e60e1ee60630cafef5e430c2ae364877e061d980
On 21 November 2017 at 05:38AM, Alex Deucher wrote:
>
> If you look at the code, radeon_bo_create() is failing with -ENOMEM in
> radeon_wb_init(). If you look at radeon_bo_create(), it can fail for
> the following reasons:
> 1. kzalloc fails
> 2. drm_gem_object_init fails
> 3. ttm_bo_init fails
>
> I'd start by looking into what's changed in those areas.
>
> Alex
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-21 4:38 ` Alex Deucher
2017-11-21 11:32 ` Christian Zigotzky
@ 2017-11-22 13:20 ` Christian Zigotzky
2017-11-22 13:27 ` Ilia Mirkin
1 sibling, 1 reply; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-22 13:20 UTC (permalink / raw)
To: Alex Deucher, Maling list - DRI developers
Hi Alex,
I reverted the following files in the first bad commit (first DRM
updates) [1].
-rw-r--r-- drivers/gpu/drm/radeon/Makefile 5
-rw-r--r-- drivers/gpu/drm/radeon/atombios_dp.c 46
-rw-r--r-- drivers/gpu/drm/radeon/ci_dpm.c 22
-rw-r--r-- drivers/gpu/drm/radeon/ci_dpm.h 1
-rw-r--r-- drivers/gpu/drm/radeon/ci_smc.c 21
-rw-r--r-- drivers/gpu/drm/radeon/cik.c 14
-rw-r--r-- drivers/gpu/drm/radeon/cikd.h 2
-rw-r--r-- drivers/gpu/drm/radeon/r100.c 2
-rw-r--r-- drivers/gpu/drm/radeon/r600_cs.c 2
-rw-r--r-- drivers/gpu/drm/radeon/r600_hdmi.c 2
-rw-r--r-- drivers/gpu/drm/radeon/radeon.h 3
-rw-r--r-- drivers/gpu/drm/radeon/radeon_connectors.c 16
-rw-r--r-- drivers/gpu/drm/radeon/radeon_drv.c 10
-rw-r--r-- drivers/gpu/drm/radeon/radeon_fb.c 4
-rw-r--r-- drivers/gpu/drm/radeon/radeon_kfd.c 870
-rw-r--r-- drivers/gpu/drm/radeon/radeon_kms.c 7
-rw-r--r-- drivers/gpu/drm/radeon/radeon_mode.h 4
-rw-r--r-- drivers/gpu/drm/radeon/radeon_trace.h 2
-rw-r--r-- drivers/gpu/drm/radeon/radeon_ttm.c
After that I compiled the latest git kernel again. Unfortunately I don't
have hardware 3D acceleration. That means the bug isn't in these files
above but it is somewhere in the first DRM updates [1].
I need really your help because I don't have any experiences with this
source code. I will try to revert more files.
Thanks,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e60e1ee60630cafef5e430c2ae364877e061d980
On 21 November 2017 at 05:38AM, Alex Deucher wrote:
>
> If you look at the code, radeon_bo_create() is failing with -ENOMEM in
> radeon_wb_init(). If you look at radeon_bo_create(), it can fail for
> the following reasons:
> 1. kzalloc fails
> 2. drm_gem_object_init fails
> 3. ttm_bo_init fails
>
> I'd start by looking into what's changed in those areas.
>
> Alex
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-22 13:20 ` Christian Zigotzky
@ 2017-11-22 13:27 ` Ilia Mirkin
2017-11-22 13:40 ` Christian Zigotzky
0 siblings, 1 reply; 24+ messages in thread
From: Ilia Mirkin @ 2017-11-22 13:27 UTC (permalink / raw)
To: Christian Zigotzky; +Cc: Maling list - DRI developers
On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
> Hi Alex,
>
> I reverted the following files in the first bad commit (first DRM updates)
Is the merge commit really the first bad commit? i.e. both parents of
the merge are good, but the merge commit itself is bad? Or did you do
this manually and therefore didn't go into the merge parents? If so,
I'd recommend doing a proper bisect (search for "git bisect", there
are tons of guides). That will identify the commit that's actually
responsible.
Cheers,
-ilia
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-22 13:27 ` Ilia Mirkin
@ 2017-11-22 13:40 ` Christian Zigotzky
2017-11-22 13:45 ` Ilia Mirkin
0 siblings, 1 reply; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-22 13:40 UTC (permalink / raw)
To: Ilia Mirkin, Maling list - DRI developers
On 22 November 2017 at 2:27PM, Ilia Mirkin wrote:
> On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
> <chzigotzky@xenosoft.de> wrote:
>> Hi Alex,
>>
>> I reverted the following files in the first bad commit (first DRM updates)
> Is the merge commit really the first bad commit? i.e. both parents of
> the merge are good, but the merge commit itself is bad? Or did you do
> this manually and therefore didn't go into the merge parents? If so,
> I'd recommend doing a proper bisect (search for "git bisect", there
> are tons of guides). That will identify the commit that's actually
> responsible.
>
> Cheers,
>
> -ilia
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi ilia,
I did it manually. If I revert the merge commit then the hardware 3D
acceleration works. Is it possible to bisect in the merge commit directly?
Thanks,
Christian
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-22 13:40 ` Christian Zigotzky
@ 2017-11-22 13:45 ` Ilia Mirkin
2017-11-22 14:53 ` Christian Zigotzky
2017-11-24 14:29 ` Christian Zigotzky
0 siblings, 2 replies; 24+ messages in thread
From: Ilia Mirkin @ 2017-11-22 13:45 UTC (permalink / raw)
To: Christian Zigotzky; +Cc: Maling list - DRI developers
On Wed, Nov 22, 2017 at 8:40 AM, Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
> On 22 November 2017 at 2:27PM, Ilia Mirkin wrote:
>>
>> On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
>> <chzigotzky@xenosoft.de> wrote:
>>>
>>> Hi Alex,
>>>
>>> I reverted the following files in the first bad commit (first DRM
>>> updates)
>>
>> Is the merge commit really the first bad commit? i.e. both parents of
>> the merge are good, but the merge commit itself is bad? Or did you do
>> this manually and therefore didn't go into the merge parents? If so,
>> I'd recommend doing a proper bisect (search for "git bisect", there
>> are tons of guides). That will identify the commit that's actually
>> responsible.
>
> Hi ilia,
>
> I did it manually. If I revert the merge commit then the hardware 3D
> acceleration works. Is it possible to bisect in the merge commit directly?
I thought I covered that...
"I'd recommend doing a proper bisect (search for "git bisect", there
are tons of guides). That will identify the commit that's actually
responsible."
-ilia
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-22 13:45 ` Ilia Mirkin
@ 2017-11-22 14:53 ` Christian Zigotzky
2017-11-24 14:29 ` Christian Zigotzky
1 sibling, 0 replies; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-22 14:53 UTC (permalink / raw)
To: Ilia Mirkin, Maling list - DRI developers
On 22 November 2017 at 2:45PM, Ilia Mirkin wrote:
>
> I thought I covered that...
>
> "I'd recommend doing a proper bisect (search for "git bisect", there
> are tons of guides). That will identify the commit that's actually
> responsible."
>
> -ilia
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
OK, I am bisecting ....
Thanks,
Christian
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-22 13:45 ` Ilia Mirkin
2017-11-22 14:53 ` Christian Zigotzky
@ 2017-11-24 14:29 ` Christian Zigotzky
2017-11-24 16:09 ` Michel Dänzer
1 sibling, 1 reply; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-24 14:29 UTC (permalink / raw)
To: Ilia Mirkin, Maling list - DRI developers, alexdeucher
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
Hi All,
I bisected today and the first bad commit is:
a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
to populate/map in one call (v2)) [1]
Please find attached the git bisect log.
Thanks,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4dec819c8bba6365eb893a4ca88db4dd1210110
On 22.11.2017 14:45, Ilia Mirkin wrote:
>
> I thought I covered that...
>
> "I'd recommend doing a proper bisect (search for "git bisect", there
> are tons of guides). That will identify the commit that's actually
> responsible."
>
> -ilia
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[-- Attachment #2: bisect-4.15-radeon --]
[-- Type: text/plain, Size: 4410 bytes --]
git bisect start
git bisect good 894025f24bd028942da3e602b87d9f7223109b14 (Linux 4.15 alpha1 Mon Nov 13 21:14:07 2017 -0800)
git bisect bad e60e1ee60630cafef5e430c2ae364877e061d980
Output:
Bisecting: 2555 revisions left to test after this (roughly 12 steps)
[5bbcc0f595fadb4cac0eddc4401035ec0bd95b09] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect good
Output:
Bisecting: 1277 revisions left to test after this (roughly 10 steps)
[9a45ddaaa674aa103cd74a0df9a3f9c2c8fb3124] drm/nouveau/mmu: implement page table cache
git bisect bad
Output:
Bisecting: 638 revisions left to test after this (roughly 9 steps)
[d6c0511300dcff19969844495ba293c4efb50b42] drm/i915/execlists: Distinguish the incomplete context notifies
git bisect bad
Output:
Bisecting: 373 revisions left to test after this (roughly 8 steps)
[ae7617f0ef1820be033eef93859a6bb6174a843f] drm/i915: Allow optimized platform checks
git bisect good
Output:
Bisecting: 186 revisions left to test after this (roughly 8 steps)
[6e2e216fadd80b4280783bb78e543593ebf2cb69] drm/amdgpu:use formal register to trigger hdp invalidate
git bisect bad
Output:
Bisecting: 93 revisions left to test after this (roughly 7 steps)
[b72cf4fca2bb786e20864b5e8755105aa9626fb4] drm/amdgpu: move taking mmap_sem into get_user_pages v2
git bisect bad
Output:
Bisecting: 46 revisions left to test after this (roughly 6 steps)
[c5927537dd5706b17affa8aeea28c7b19c8fbb42] drm/amd: Remove null check before kfree
git bisect bad
Output:
Bisecting: 22 revisions left to test after this (roughly 5 steps)
[e719d5169f75ead3c05329b4125afb67b4f33eba] drm/amd/include: Add hdmi_redriver_set to atomfirmware
git bisect good
Output:
Bisecting: 11 revisions left to test after this (roughly 4 steps)
[925d5d798f465671c6b8011e80c636da46ef1a16] drm/amdgpu/gfx8: apply dynamic cu mask to APUs as well
git bisect bad
Output:
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[db95e2185523ee9d46a13ceee37bffe8442d2e1c] drm/amdgpu: Add debugfs file for VBIOS and version
git bisect bad
Output:
Bisecting: 2 revisions left to test after this (roughly 1 step)
[7405e0dad4c75b33976ddd997513635d7a0204b1] drm/amd/amdgpu: Use new TTM populate/map helper function
CC drivers/gpu/drm/ttm/ttm_page_alloc.o
drivers/gpu/drm/ttm/ttm_page_alloc.c:923:5: error: redefinition of ‘ttm_populate_and_map_pages’
int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/gpu/drm/ttm/ttm_page_alloc.c:49:0:
./include/drm/ttm/ttm_page_alloc.h:120:19: note: previous definition of ‘ttm_populate_and_map_pages’ was here
static inline int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/ttm/ttm_page_alloc.c:950:6: error: redefinition of ‘ttm_unmap_and_unpopulate_pages’
void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/gpu/drm/ttm/ttm_page_alloc.c:49:0:
./include/drm/ttm/ttm_page_alloc.h:125:20: note: previous definition of ‘ttm_unmap_and_unpopulate_pages’ was here
static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
git bisect bad
Output:
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[a4dec819c8bba6365eb893a4ca88db4dd1210110] drm/ttm: Add helper functions to populate/map in one call (v2)
git bisect bad
Output:
a4dec819c8bba6365eb893a4ca88db4dd1210110 is the first bad commit
commit a4dec819c8bba6365eb893a4ca88db4dd1210110
Author: Tom St Denis <tom.stdenis@amd.com>
Date: Fri Aug 18 10:04:57 2017 -0400
drm/ttm: Add helper functions to populate/map in one call (v2)
These functions replace a section of common code found
in radeon/amdgpu drivers (and possibly others) as part
of the ttm_tt_*populate() callbacks.
v2: squash in fix for sw iommu from Tom
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
:040000 040000 04b995fa3def96d5e983d0d5bc728e00b7617fe9 616ef24927f707cfaeecfc4748630f49b52adb42 M drivers
:040000 040000 61abf936f7ea760e19c5cef8a214ffada5ea3aeb 595278390bc27db92848ce8aaa255a1201c2af75 M include
[-- Attachment #3: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-24 14:29 ` Christian Zigotzky
@ 2017-11-24 16:09 ` Michel Dänzer
2017-11-24 19:08 ` Christian Zigotzky
2017-11-27 11:02 ` Michel Dänzer
0 siblings, 2 replies; 24+ messages in thread
From: Michel Dänzer @ 2017-11-24 16:09 UTC (permalink / raw)
To: Christian Zigotzky, Tom St Denis; +Cc: Maling list - DRI developers
On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
> Hi All,
>
> I bisected today and the first bad commit is:
> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
> to populate/map in one call (v2)) [1]
It can't really be that commit, since it just adds functions but doesn't
hook them up anywhere. Presumably it's commit
f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
populate/dma map helper functions") instead, which makes the radeon
driver rely on ttm_populate_and_map_pages, which is just a stub
returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
enabled.
I can see two possible solutions:
1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
work without SWIOTLB / INTEL_IOMMU as well.
2. Make the drivers work without ttm_populate_and_map_pages and
ttm_unmap_and_unpopulate_pages again in that case.
Solution 1 would be preferable.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-24 16:09 ` Michel Dänzer
@ 2017-11-24 19:08 ` Christian Zigotzky
2017-11-24 19:13 ` Christian Zigotzky
2017-11-24 19:14 ` Ilia Mirkin
2017-11-27 11:02 ` Michel Dänzer
1 sibling, 2 replies; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-24 19:08 UTC (permalink / raw)
To: Michel Dänzer, Tom St Denis, Maling list - DRI developers
On 24.11.2017 17:09, Michel Dänzer wrote:
> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>> Hi All,
>>
>> I bisected today and the first bad commit is:
>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
>> to populate/map in one call (v2)) [1]
> It can't really be that commit, since it just adds functions but doesn't
> hook them up anywhere. Presumably it's commit
> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
> populate/dma map helper functions") instead, which makes the radeon
> driver rely on ttm_populate_and_map_pages, which is just a stub
> returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
> enabled.
>
> I can see two possible solutions:
>
> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
> work without SWIOTLB / INTEL_IOMMU as well.
>
> 2. Make the drivers work without ttm_populate_and_map_pages and
> ttm_unmap_and_unpopulate_pages again in that case.
>
>
> Solution 1 would be preferable.
>
>
Hello Michel,
I tested the latest git version today. Unfortunately the problem with
the hardware 3D acceleration still exist. How can I make
ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work
without SWIOTLB / INTEL_IOMMU?
Thanks,
Christian
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-24 19:08 ` Christian Zigotzky
@ 2017-11-24 19:13 ` Christian Zigotzky
2017-11-24 19:14 ` Ilia Mirkin
1 sibling, 0 replies; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-24 19:13 UTC (permalink / raw)
To: Michel Dänzer, Tom St Denis, Maling list - DRI developers
On 24.11.2017 20:08, Christian Zigotzky wrote:
> On 24.11.2017 17:09, Michel Dänzer wrote:
>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>> Hi All,
>>>
>>> I bisected today and the first bad commit is:
>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
>>> to populate/map in one call (v2)) [1]
>> It can't really be that commit, since it just adds functions but doesn't
>> hook them up anywhere. Presumably it's commit
>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>> populate/dma map helper functions") instead, which makes the radeon
>> driver rely on ttm_populate_and_map_pages, which is just a stub
>> returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
>> enabled.
>>
>> I can see two possible solutions:
>>
>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>> work without SWIOTLB / INTEL_IOMMU as well.
>>
>> 2. Make the drivers work without ttm_populate_and_map_pages and
>> ttm_unmap_and_unpopulate_pages again in that case.
>>
>>
>> Solution 1 would be preferable.
>>
>>
> Hello Michel,
>
> I tested the latest git version today. Unfortunately the problem with
> the hardware 3D acceleration still exist. How can I make
> ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work
> without SWIOTLB / INTEL_IOMMU?
>
> Thanks,
> Christian
>
Just for info:
CONFIG_SWIOTLB is not set and CONFIG_PPC_PASEMI_IOMMU is enabled.
-- Christian
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-24 19:08 ` Christian Zigotzky
2017-11-24 19:13 ` Christian Zigotzky
@ 2017-11-24 19:14 ` Ilia Mirkin
2017-11-24 20:58 ` Christian Zigotzky
1 sibling, 1 reply; 24+ messages in thread
From: Ilia Mirkin @ 2017-11-24 19:14 UTC (permalink / raw)
To: Christian Zigotzky
Cc: Tom St Denis, Michel Dänzer, Maling list - DRI developers
On Fri, Nov 24, 2017 at 2:08 PM, Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
> On 24.11.2017 17:09, Michel Dänzer wrote:
>>
>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>>
>>> Hi All,
>>>
>>> I bisected today and the first bad commit is:
>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
>>> to populate/map in one call (v2)) [1]
>>
>> It can't really be that commit, since it just adds functions but doesn't
>> hook them up anywhere. Presumably it's commit
>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>> populate/dma map helper functions") instead, which makes the radeon
>> driver rely on ttm_populate_and_map_pages, which is just a stub
>> returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
>> enabled.
>>
>> I can see two possible solutions:
>>
>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>> work without SWIOTLB / INTEL_IOMMU as well.
>>
>> 2. Make the drivers work without ttm_populate_and_map_pages and
>> ttm_unmap_and_unpopulate_pages again in that case.
>>
>>
>> Solution 1 would be preferable.
>>
>>
> Hello Michel,
>
> I tested the latest git version today. Unfortunately the problem with the
> hardware 3D acceleration still exist. How can I make
> ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work without
> SWIOTLB / INTEL_IOMMU?
Do you have SWIOTLB disabled in your .config? Try enabling it to see
if that's the issue.
Looking at your bisect log, you might have incorrectly marked some
revisions. E.g. you had a compile failure, which while isn't "good",
it's also not "bad" -- good and bad are only in reference to the
specific issue you're seeing. In such cases you can run "git bisect
skip" which will mark the commit as "unknown" and pick a different one
to try.
-ilia
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-24 19:14 ` Ilia Mirkin
@ 2017-11-24 20:58 ` Christian Zigotzky
0 siblings, 0 replies; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-24 20:58 UTC (permalink / raw)
To: Ilia Mirkin, Tom St Denis, Michel Dänzer,
Maling list - DRI developers
On 24.11.2017 20:14, Ilia Mirkin wrote:
>
> Do you have SWIOTLB disabled in your .config? Try enabling it to see
> if that's the issue.
>
> Looking at your bisect log, you might have incorrectly marked some
> revisions. E.g. you had a compile failure, which while isn't "good",
> it's also not "bad" -- good and bad are only in reference to the
> specific issue you're seeing. In such cases you can run "git bisect
> skip" which will mark the commit as "unknown" and pick a different one
> to try.
>
> -ilia
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi All,
Success!!!!!!!!!! I enabled SWIOTLB and the hardware 3D acceleration
works again! Fantastic. Thank you very much! And thank you for the hint
with "git bisect skip".
Cheers,
Christian
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-24 16:09 ` Michel Dänzer
2017-11-24 19:08 ` Christian Zigotzky
@ 2017-11-27 11:02 ` Michel Dänzer
2017-11-27 11:50 ` Christian König
1 sibling, 1 reply; 24+ messages in thread
From: Michel Dänzer @ 2017-11-27 11:02 UTC (permalink / raw)
To: Tom St Denis; +Cc: Maling list - DRI developers, Christian Zigotzky
Hi Tom,
On 2017-11-24 05:09 PM, Michel Dänzer wrote:
> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>> Hi All,
>>
>> I bisected today and the first bad commit is:
>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
>> to populate/map in one call (v2)) [1]
>
> It can't really be that commit, since it just adds functions but doesn't
> hook them up anywhere. Presumably it's commit
> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
> populate/dma map helper functions") instead, which makes the radeon
> driver rely on ttm_populate_and_map_pages, which is just a stub
> returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
> enabled.
>
> I can see two possible solutions:
>
> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
> work without SWIOTLB / INTEL_IOMMU as well.
>
> 2. Make the drivers work without ttm_populate_and_map_pages and
> ttm_unmap_and_unpopulate_pages again in that case.
>
>
> Solution 1 would be preferable.
Which solution do you want to go for?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-27 11:02 ` Michel Dänzer
@ 2017-11-27 11:50 ` Christian König
2017-11-27 12:02 ` Michel Dänzer
0 siblings, 1 reply; 24+ messages in thread
From: Christian König @ 2017-11-27 11:50 UTC (permalink / raw)
To: Michel Dänzer, Tom St Denis
Cc: Maling list - DRI developers, Christian Zigotzky
Hi Michel,
Am 27.11.2017 um 12:02 schrieb Michel Dänzer:
> Hi Tom,
>
> On 2017-11-24 05:09 PM, Michel Dänzer wrote:
>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>> Hi All,
>>>
>>> I bisected today and the first bad commit is:
>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
>>> to populate/map in one call (v2)) [1]
>> It can't really be that commit, since it just adds functions but doesn't
>> hook them up anywhere. Presumably it's commit
>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>> populate/dma map helper functions") instead, which makes the radeon
>> driver rely on ttm_populate_and_map_pages, which is just a stub
>> returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
>> enabled.
>>
>> I can see two possible solutions:
>>
>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>> work without SWIOTLB / INTEL_IOMMU as well.
>>
>> 2. Make the drivers work without ttm_populate_and_map_pages and
>> ttm_unmap_and_unpopulate_pages again in that case.
>>
>>
>> Solution 1 would be preferable.
> Which solution do you want to go for?
well, can somebody please explain to me why those patches actually
result in problems?
They should have only moved code around, not cause anything like this.
Apart from that I also prefer solution 1.
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-27 11:50 ` Christian König
@ 2017-11-27 12:02 ` Michel Dänzer
2017-11-27 12:17 ` Tom St Denis
2017-11-27 12:20 ` Christian König
0 siblings, 2 replies; 24+ messages in thread
From: Michel Dänzer @ 2017-11-27 12:02 UTC (permalink / raw)
To: christian.koenig, Tom St Denis
Cc: Maling list - DRI developers, Christian Zigotzky
On 2017-11-27 12:50 PM, Christian König wrote:
> Am 27.11.2017 um 12:02 schrieb Michel Dänzer:
>> On 2017-11-24 05:09 PM, Michel Dänzer wrote:
>>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>>> Hi All,
>>>>
>>>> I bisected today and the first bad commit is:
>>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
>>>> to populate/map in one call (v2)) [1]
>>> It can't really be that commit, since it just adds functions but doesn't
>>> hook them up anywhere. Presumably it's commit
>>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>>> populate/dma map helper functions") instead, which makes the radeon
>>> driver rely on ttm_populate_and_map_pages, which is just a stub
>>> returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
>>> enabled.
>>>
>>> I can see two possible solutions:
>>>
>>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>>> work without SWIOTLB / INTEL_IOMMU as well.
>>>
>>> 2. Make the drivers work without ttm_populate_and_map_pages and
>>> ttm_unmap_and_unpopulate_pages again in that case.
>>>
>>>
>>> Solution 1 would be preferable.
>> Which solution do you want to go for?
>
> well, can somebody please explain to me why those patches actually
> result in problems?
I thought I did above...
Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
rely on ttm_populate_and_map_pages, which is implemented as:
static inline int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
{
return -ENOMEM;
}
when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
Previously, the driver worked fine without either of those enabled.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-27 12:02 ` Michel Dänzer
@ 2017-11-27 12:17 ` Tom St Denis
2017-11-27 14:53 ` Michel Dänzer
2017-11-27 12:20 ` Christian König
1 sibling, 1 reply; 24+ messages in thread
From: Tom St Denis @ 2017-11-27 12:17 UTC (permalink / raw)
To: Michel Dänzer, christian.koenig
Cc: Maling list - DRI developers, Christian Zigotzky
On 27/11/17 07:02 AM, Michel Dänzer wrote:
> On 2017-11-27 12:50 PM, Christian König wrote:
>> Am 27.11.2017 um 12:02 schrieb Michel Dänzer:
>>> On 2017-11-24 05:09 PM, Michel Dänzer wrote:
>>>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>>>> Hi All,
>>>>>
>>>>> I bisected today and the first bad commit is:
>>>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
>>>>> to populate/map in one call (v2)) [1]
>>>> It can't really be that commit, since it just adds functions but doesn't
>>>> hook them up anywhere. Presumably it's commit
>>>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>>>> populate/dma map helper functions") instead, which makes the radeon
>>>> driver rely on ttm_populate_and_map_pages, which is just a stub
>>>> returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
>>>> enabled.
>>>>
>>>> I can see two possible solutions:
>>>>
>>>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>>>> work without SWIOTLB / INTEL_IOMMU as well.
>>>>
>>>> 2. Make the drivers work without ttm_populate_and_map_pages and
>>>> ttm_unmap_and_unpopulate_pages again in that case.
>>>>
>>>>
>>>> Solution 1 would be preferable.
>>> Which solution do you want to go for?
>>
>> well, can somebody please explain to me why those patches actually
>> result in problems?
>
> I thought I did above...
>
> Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
> rely on ttm_populate_and_map_pages, which is implemented as:
>
> static inline int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
> {
> return -ENOMEM;
> }
>
> when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
> Previously, the driver worked fine without either of those enabled.
>
>
I think the issue is why would you have both disabled and we did run
into a kbuild error when they weren't guarded (I don't remember exactly
what though I'd have to go grep for it).
TOm
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-27 12:02 ` Michel Dänzer
2017-11-27 12:17 ` Tom St Denis
@ 2017-11-27 12:20 ` Christian König
2017-11-29 8:50 ` Michel Dänzer
1 sibling, 1 reply; 24+ messages in thread
From: Christian König @ 2017-11-27 12:20 UTC (permalink / raw)
To: Michel Dänzer, Tom St Denis
Cc: Maling list - DRI developers, Christian Zigotzky
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
Am 27.11.2017 um 13:02 schrieb Michel Dänzer:
> [SNIP]
> I thought I did above...
>
> Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
> rely on ttm_populate_and_map_pages, which is implemented as:
>
> static inline int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
> {
> return -ENOMEM;
> }
>
> when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
> Previously, the driver worked fine without either of those enabled.
Ah! Sorry my fault. It looks like I incorrectly explained to Tom how to
handle the config options.
Please take a look at the attached patch, it should fix the issue (going
to send that one out separately once more).
Regards,
Christian.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-drm-ttm-fix-populate_and_map-functions-once-more.patch --]
[-- Type: text/x-patch; name="0001-drm-ttm-fix-populate_and_map-functions-once-more.patch", Size: 3453 bytes --]
>From a53c4574a06ee5a46d8e5b8fb10623c76513fe5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
Date: Mon, 27 Nov 2017 13:12:35 +0100
Subject: [PATCH] drm/ttm: fix populate_and_map() functions once more
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This reverts "drm/ttm: Fix configuration error around populate_and_map()
functions".
This fix has gone into the wrong direction. Those helpers should be
available even when neither CONFIG_INTEL_IOMMU nor CONFIG_SWIOTLB are
set.
Signed-off-by: Christian König <christian.koenig@amd.com>
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 --
include/drm/ttm/ttm_page_alloc.h | 32 ++++++++++----------------------
2 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 1543532b8740..c82d94cbbabc 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1096,7 +1096,6 @@ void ttm_pool_unpopulate(struct ttm_tt *ttm)
}
EXPORT_SYMBOL(ttm_pool_unpopulate);
-#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
{
unsigned i, j;
@@ -1167,7 +1166,6 @@ void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
ttm_pool_unpopulate(&tt->ttm);
}
EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages);
-#endif
int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
{
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 38a2b4770c35..593811362a91 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -59,11 +59,20 @@ int ttm_pool_populate(struct ttm_tt *ttm);
void ttm_pool_unpopulate(struct ttm_tt *ttm);
/**
+ * Populates and DMA maps pages to fullfil a ttm_dma_populate() request
+ */
+int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt);
+
+/**
+ * Unpopulates and DMA unmaps pages as part of a
+ * ttm_dma_unpopulate() request */
+void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt);
+
+/**
* Output the state of pools to debugfs file
*/
int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
-
#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
/**
* Initialize pool allocator.
@@ -83,17 +92,6 @@ int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data);
int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);
void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev);
-
-/**
- * Populates and DMA maps pages to fullfil a ttm_dma_populate() request
- */
-int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt);
-
-/**
- * Unpopulates and DMA unmaps pages as part of a
- * ttm_dma_unpopulate() request */
-void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt);
-
#else
static inline int ttm_dma_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)
@@ -116,16 +114,6 @@ static inline void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
struct device *dev)
{
}
-
-static inline int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
-{
- return -ENOMEM;
-}
-
-static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
-{
-}
-
#endif
#endif
--
2.11.0
[-- Attachment #3: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-27 12:17 ` Tom St Denis
@ 2017-11-27 14:53 ` Michel Dänzer
2017-11-28 5:43 ` Christian Zigotzky
0 siblings, 1 reply; 24+ messages in thread
From: Michel Dänzer @ 2017-11-27 14:53 UTC (permalink / raw)
To: Tom St Denis, christian.koenig
Cc: Maling list - DRI developers, Christian Zigotzky
On 2017-11-27 01:17 PM, Tom St Denis wrote:
> On 27/11/17 07:02 AM, Michel Dänzer wrote:
>> On 2017-11-27 12:50 PM, Christian König wrote:
>>> Am 27.11.2017 um 12:02 schrieb Michel Dänzer:
>>>> On 2017-11-24 05:09 PM, Michel Dänzer wrote:
>>>>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I bisected today and the first bad commit is:
>>>>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper
>>>>>> functions
>>>>>> to populate/map in one call (v2)) [1]
>>>>> It can't really be that commit, since it just adds functions but
>>>>> doesn't
>>>>> hook them up anywhere. Presumably it's commit
>>>>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>>>>> populate/dma map helper functions") instead, which makes the radeon
>>>>> driver rely on ttm_populate_and_map_pages, which is just a stub
>>>>> returning -ENOMEM when neither CONFIG_SWIOTLB nor
>>>>> CONFIG_INTEL_IOMMU is
>>>>> enabled.
>>>>>
>>>>> I can see two possible solutions:
>>>>>
>>>>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>>>>> work without SWIOTLB / INTEL_IOMMU as well.
>>>>>
>>>>> 2. Make the drivers work without ttm_populate_and_map_pages and
>>>>> ttm_unmap_and_unpopulate_pages again in that case.
>>>>>
>>>>>
>>>>> Solution 1 would be preferable.
>>>> Which solution do you want to go for?
>>>
>>> well, can somebody please explain to me why those patches actually
>>> result in problems?
>>
>> I thought I did above...
>>
>> Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
>> rely on ttm_populate_and_map_pages, which is implemented as:
>>
>> static inline int ttm_populate_and_map_pages(struct device *dev,
>> struct ttm_dma_tt *tt)
>> {
>> return -ENOMEM;
>> }
>>
>> when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
>> Previously, the driver worked fine without either of those enabled.
>>
>>
>
> I think the issue is why would you have both disabled [...]
Doesn't matter. The drivers worked with both disabled before, now they
don't. That's a regression.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-27 14:53 ` Michel Dänzer
@ 2017-11-28 5:43 ` Christian Zigotzky
2017-11-28 9:40 ` Michel Dänzer
0 siblings, 1 reply; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-28 5:43 UTC (permalink / raw)
To: Michel Dänzer
Cc: Tom St Denis, christian.koenig, Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 2584 bytes --]
Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB enabled?
— Christian
Sent from my iPhone
> On 27. Nov 2017, at 15:53, Michel Dänzer <michel@daenzer.net> wrote:
>
>> On 2017-11-27 01:17 PM, Tom St Denis wrote:
>>> On 27/11/17 07:02 AM, Michel Dänzer wrote:
>>>> On 2017-11-27 12:50 PM, Christian König wrote:
>>>>> Am 27.11.2017 um 12:02 schrieb Michel Dänzer:
>>>>>> On 2017-11-24 05:09 PM, Michel Dänzer wrote:
>>>>>>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I bisected today and the first bad commit is:
>>>>>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper
>>>>>>> functions
>>>>>>> to populate/map in one call (v2)) [1]
>>>>>> It can't really be that commit, since it just adds functions but
>>>>>> doesn't
>>>>>> hook them up anywhere. Presumably it's commit
>>>>>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>>>>>> populate/dma map helper functions") instead, which makes the radeon
>>>>>> driver rely on ttm_populate_and_map_pages, which is just a stub
>>>>>> returning -ENOMEM when neither CONFIG_SWIOTLB nor
>>>>>> CONFIG_INTEL_IOMMU is
>>>>>> enabled.
>>>>>>
>>>>>> I can see two possible solutions:
>>>>>>
>>>>>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>>>>>> work without SWIOTLB / INTEL_IOMMU as well.
>>>>>>
>>>>>> 2. Make the drivers work without ttm_populate_and_map_pages and
>>>>>> ttm_unmap_and_unpopulate_pages again in that case.
>>>>>>
>>>>>>
>>>>>> Solution 1 would be preferable.
>>>>> Which solution do you want to go for?
>>>>
>>>> well, can somebody please explain to me why those patches actually
>>>> result in problems?
>>>
>>> I thought I did above...
>>>
>>> Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
>>> rely on ttm_populate_and_map_pages, which is implemented as:
>>>
>>> static inline int ttm_populate_and_map_pages(struct device *dev,
>>> struct ttm_dma_tt *tt)
>>> {
>>> return -ENOMEM;
>>> }
>>>
>>> when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
>>> Previously, the driver worked fine without either of those enabled.
>>>
>>>
>>
>> I think the issue is why would you have both disabled [...]
> Doesn't matter. The drivers worked with both disabled before, now they
> don't. That's a regression.
>
>
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Mesa and X developer
[-- Attachment #1.2: Type: text/html, Size: 11240 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-28 5:43 ` Christian Zigotzky
@ 2017-11-28 9:40 ` Michel Dänzer
2017-11-28 23:48 ` Christian Zigotzky
0 siblings, 1 reply; 24+ messages in thread
From: Michel Dänzer @ 2017-11-28 9:40 UTC (permalink / raw)
To: Christian Zigotzky
Cc: Tom St Denis, christian.koenig, Maling list - DRI developers
On 2017-11-28 06:43 AM, Christian Zigotzky wrote:
> Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB
> enabled?
I doubt SWIOTLB provides any benefit for you.
Can you test if Christian's patch fixes the problem with SWIOTLB disabled?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-28 9:40 ` Michel Dänzer
@ 2017-11-28 23:48 ` Christian Zigotzky
0 siblings, 0 replies; 24+ messages in thread
From: Christian Zigotzky @ 2017-11-28 23:48 UTC (permalink / raw)
To: Michel Dänzer, Tom St Denis, christian.koenig,
Maling list - DRI developers
On 28 November 2017 at 10:40AM, Michel Dänzer wrote:
> On 2017-11-28 06:43 AM, Christian Zigotzky wrote:
>> Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB
>> enabled?
> I doubt SWIOTLB provides any benefit for you.
>
>
> Can you test if Christian's patch fixes the problem with SWIOTLB disabled?
>
>
Hi Michel,
Hardware 3D acceleration works with Christian's patch! I don't need to
enable SWIOTLB anymore.
Thanks,
Christian
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
2017-11-27 12:20 ` Christian König
@ 2017-11-29 8:50 ` Michel Dänzer
0 siblings, 0 replies; 24+ messages in thread
From: Michel Dänzer @ 2017-11-29 8:50 UTC (permalink / raw)
To: Christian König, Tom St Denis
Cc: Maling list - DRI developers, Christian Zigotzky
On 2017-11-27 01:20 PM, Christian König wrote:
> Am 27.11.2017 um 13:02 schrieb Michel Dänzer:
>> [SNIP]
>> I thought I did above...
>>
>> Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
>> rely on ttm_populate_and_map_pages, which is implemented as:
>>
>> static inline int ttm_populate_and_map_pages(struct device *dev,
>> struct ttm_dma_tt *tt)
>> {
>> return -ENOMEM;
>> }
>>
>> when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
>> Previously, the driver worked fine without either of those enabled.
> Ah! Sorry my fault. It looks like I incorrectly explained to Tom how to
> handle the config options.
>
> Please take a look at the attached patch, it should fix the issue (going
> to send that one out separately once more).
[...]
> * Output the state of pools to debugfs file
> */
> int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
>
> -
> #if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
> /**
> * Initialize pool allocator.
I'd drop the removal of this line, but either way,
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-11-29 8:50 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-20 18:08 Hardware 3D acceleration doesn't work anymore with the latest git kernel Christian Zigotzky
2017-11-21 4:38 ` Alex Deucher
2017-11-21 11:32 ` Christian Zigotzky
2017-11-22 13:20 ` Christian Zigotzky
2017-11-22 13:27 ` Ilia Mirkin
2017-11-22 13:40 ` Christian Zigotzky
2017-11-22 13:45 ` Ilia Mirkin
2017-11-22 14:53 ` Christian Zigotzky
2017-11-24 14:29 ` Christian Zigotzky
2017-11-24 16:09 ` Michel Dänzer
2017-11-24 19:08 ` Christian Zigotzky
2017-11-24 19:13 ` Christian Zigotzky
2017-11-24 19:14 ` Ilia Mirkin
2017-11-24 20:58 ` Christian Zigotzky
2017-11-27 11:02 ` Michel Dänzer
2017-11-27 11:50 ` Christian König
2017-11-27 12:02 ` Michel Dänzer
2017-11-27 12:17 ` Tom St Denis
2017-11-27 14:53 ` Michel Dänzer
2017-11-28 5:43 ` Christian Zigotzky
2017-11-28 9:40 ` Michel Dänzer
2017-11-28 23:48 ` Christian Zigotzky
2017-11-27 12:20 ` Christian König
2017-11-29 8:50 ` Michel Dänzer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.