Hardware 3D acceleration doesn't work anymore with the latest git kernel

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

[-- 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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Alex Deucher]

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Ilia Mirkin]

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Ilia Mirkin]

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

[-- 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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Michel Dänzer]

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Ilia Mirkin]

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[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?


-- 
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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian König]

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Michel Dänzer]

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Tom St Denis]

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Michel Dänzer]

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

[-- 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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Michel Dänzer]

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian König]

[-- 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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Michel Dänzer]

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