dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[Bug 76840] New: HybridGraphics: Kernel driver in use: radeon but adapter not listed
by bugzilla-daemon＠freedesktop.org 20 Nov '15

20 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=76840 Priority: medium Bug ID: 76840 Assignee: dri-devel(a)lists.freedesktop.org Summary: HybridGraphics: Kernel driver in use: radeon but adapter not listed Severity: normal Classification: Unclassified OS: Linux (All) Reporter: xanto(a)egaming.ro Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 96665 --> https://bugs.freedesktop.org/attachment.cgi?id=96665&action=edit xorg.conf , Xorg.0.log - intel device, Xorg.0.log - radeon device, Xorg.1.log intel device, lspci , dmesg, inxi, glxinfo, xrandr, fglrx Xorg.1.log Hello, I'm using a Dell Inspiron Laptop Model 3537 with latest manufacturer BIOS update and firmware-addon-dell installed. Hardware consists of an Intel i5-4200U (HD4400) + AMD Radeon HD 8670M. I've tried latest Linux Mint Live/Install ISO, but xserver won't start unless I unload radeon module. After latest software stack upgrade (kernel 3.14 + oibaf ppa https://launchpad.net/~oibaf/+archive/graphics-drivers [mesa10.2-git, ati-1.7.3-git]), system boots fine, dmesg seems fine: dmesg | egrep "radeon|drm" [ 2.448474] [drm] Initialized drm 1.1.0 20060810 [ 2.478265] [drm] Memory usable by graphics device = 2048M [ 2.478273] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver [ 2.496049] [drm] radeon kernel modesetting enabled. [ 2.496127] radeon 0000:03:00.0: enabling device (0006 -> 0007) [ 2.525982] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 2.525983] [drm] Driver supports precise vblank timestamp query. [ 2.655140] fbcon: inteldrmfb (fb0) is primary device [ 4.169021] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 4.173215] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 4.176558] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 4.176955] [drm] initializing kernel modesetting (HAINAN 0x1002:0x6660 0x1028:0x05EA). [ 4.177008] [drm] register mmio base: 0xC0500000 [ 4.177009] [drm] register mmio size: 262144 [ 4.538007] radeon 0000:03:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) [ 4.538009] radeon 0000:03:00.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF [ 4.538010] [drm] Detected VRAM RAM=1024M, BAR=256M [ 4.538011] [drm] RAM width 64bits DDR [ 4.538115] [drm] radeon: 1024M of VRAM memory ready [ 4.538116] [drm] radeon: 1024M of GTT memory ready. [ 4.538129] [drm] Loading HAINAN Microcode [ 4.538241] [drm] Internal thermal controller without fan control [ 4.538304] [drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0 [ 4.546378] [drm] radeon: dpm initialized [ 4.546382] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 4.547031] [drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0 [ 4.547036] [drm] PCIE gen 2 link speeds already enabled [ 4.548758] [drm] PCIE GART of 1024M enabled (table at 0x0000000000040000). [ 4.548860] radeon 0000:03:00.0: WB enabled [ 4.548863] radeon 0000:03:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff880035ab0c00 [ 4.548865] radeon 0000:03:00.0: fence driver on ring 1 use gpu addr 0x0000000040000c04 and cpu addr 0xffff880035ab0c04 [ 4.548866] radeon 0000:03:00.0: fence driver on ring 2 use gpu addr 0x0000000040000c08 and cpu addr 0xffff880035ab0c08 [ 4.548867] radeon 0000:03:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff880035ab0c0c [ 4.548869] radeon 0000:03:00.0: fence driver on ring 4 use gpu addr 0x0000000040000c10 and cpu addr 0xffff880035ab0c10 [ 4.548871] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 4.548871] [drm] Driver supports precise vblank timestamp query. [ 4.548895] radeon 0000:03:00.0: irq 63 for MSI/MSI-X [ 4.548906] radeon 0000:03:00.0: radeon: using MSI. [ 4.548930] [drm] radeon: irq initialized. [ 4.745915] [drm] ring test on 0 succeeded in 1 usecs [ 4.745921] [drm] ring test on 1 succeeded in 1 usecs [ 4.745926] [drm] ring test on 2 succeeded in 1 usecs [ 4.745988] [drm] ring test on 3 succeeded in 2 usecs [ 4.745996] [drm] ring test on 4 succeeded in 1 usecs [ 4.747414] [drm] ib test on ring 0 succeeded in 0 usecs [ 4.747443] [drm] ib test on ring 1 succeeded in 0 usecs [ 4.747467] [drm] ib test on ring 2 succeeded in 0 usecs [ 4.747489] [drm] ib test on ring 3 succeeded in 0 usecs [ 4.747513] [drm] ib test on ring 4 succeeded in 1 usecs [ 4.747825] [drm] Radeon Display Connectors [ 4.747835] radeon 0000:03:00.0: No connectors reported connected with modes [ 4.747837] [drm] Cannot find any crtc or sizes - going 1024x768 [ 4.750180] [drm] fb mappable at 0xA1250000 [ 4.750181] [drm] vram apper at 0xA0000000 [ 4.750182] [drm] size 3145728 [ 4.750183] [drm] fb depth is 24 [ 4.750184] [drm] pitch is 4096 [ 4.750269] radeon 0000:03:00.0: fb1: radeondrmfb frame buffer device [ 4.751709] [drm] Initialized radeon 2.37.0 20080528 for 0000:03:00.0 on minor 1 However, xrandr, inxi and glxinfo (noone except lspci) won't show the radeon device. Starting X with device configured as radeon, crashes with the error (EE) no screens found(EE) LIBGL_DEBUG=verbose DRI_PRIME=0 glxgears libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so libGL: Can't open configuration file /root/.drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 305 frames in 5.0 seconds = 60.952 FPS 301 frames in 5.0 seconds = 60.000 FPS LIBGL_DEBUG=verbose DRI_PRIME=1 glxgears libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so libGL: Can't open configuration file /root/.drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 36463 frames in 5.0 seconds = 7292.515 FPS 35941 frames in 5.0 seconds = 7188.027 FPS 35969 frames in 5.0 seconds = 7193.778 FPS 35990 frames in 5.0 seconds = 7197.914 FPS 36353 frames in 5.0 seconds = 7270.465 FPS 36544 frames in 5.0 seconds = 7308.674 FPS 36281 frames in 5.0 seconds = 7256.154 FPS mike-g337 tmp # DRI_PRIME=0 glxinfo | grep 'OpenGL render' OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile mike-g337 tmp # DRI_PRIME=1 glxinfo | grep 'OpenGL render' OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile Attached is a file containing: xorg.conf Xorg.0.log - intel device Xorg.0.log - radeon device Xorg.1.log intel device lspci -kvvv dmesg inxi -G glxinfo xrandr --listproviders fglrx Xorg.1.log Hope it helps. Thank you in advance, Mike. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[PATCH 0/9] drm: More vblank on/off work
by ville.syrjala＠linux.intel.com 19 Nov '15

19 Nov '15

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Another vblank series with the following features: - Plug a race between drm_vblank_off() and marking the crtc inactive - Don't send zeroed vblank evens to userspace at drm_vblank_off() - Have the user visible vblank counter account the entire time when the crtc was active, regardless of how long vblank interrupts were enabled - Avoid random jumps in the user visible vblank counter if the hardware counter gets reset - Allow disabling vblank interrupts immediately at drm_vblank_put() - Some polish via coccinelle While setting drm_vblank_offdelay to 0 is now possible, I'm not sure if we should set it 0 automatically in the i915 driver. If there are multiple GPUs in the system that setting will affect them all, which might have bad consequences if the other GPU doesn't have a hardware frame counter, or if it's just buggy. So perhaps we should move that option to be per-driver? Ville Syrjälä (9): drm: Always reject drm_vblank_get() after drm_vblank_off() drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off() drm: Don't clear vblank timestamps when vblank interrupt is disabled drm: Move drm_update_vblank_count() drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off() drm: Avoid random vblank counter jumps if the hardware counter has been reset drm: Disable vblank interrupt immediately when drm_vblank_offdelay==0 drm: Reduce the amount of dev->vblank[crtc] in the code drm/i915: Leave interrupts enabled while disabling crtcs during suspend Documentation/DocBook/drm.tmpl | 1 + drivers/gpu/drm/drm_irq.c | 285 +++++++++++++++++++------------- drivers/gpu/drm/drm_stub.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 +- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/intel_display.c | 15 ++ include/drm/drmP.h | 2 +- 7 files changed, 192 insertions(+), 120 deletions(-) -- 1.8.5.5

7 43

[Bug 88043] Star Conflict locks up AMD BARTS
by bugzilla-daemon＠freedesktop.org 19 Nov '15

19 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=88043 Bug ID: 88043 Summary: Star Conflict locks up AMD BARTS Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: EoD(a)xmw.de Created attachment 111753 --> https://bugs.freedesktop.org/attachment.cgi?id=111753&action=edit dmesg output during the lockup Every time I am trying to start the free-to-play game "Star Conflict" via Steam it locks up as soon as a match has been started. I was only able to shutdown the computer via ssh, no input device did work. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 36782] New: textures on Earth in Celestia contain pixels from other windows
by bugzilla-daemon＠freedesktop.org 17 Nov '15

17 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=36782 Summary: textures on Earth in Celestia contain pixels from other windows Product: Mesa Version: 7.10 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: acelists(a)atlas.sk Created an attachment (id=46261) --> (https://bugs.freedesktop.org/attachment.cgi?id=46261) See the blue dotted band around the planet - it is a window titlebar. Textures on the planet Earth are rendered garbled with data pixel taken from other windows (programs), probably taken from released GPU memory. Note it only happens on Earth. The garbled texture is not the planet surface one, but it is the clouds layer. That is loaded from a file that is 1024x512. It does not happen when lowres textures are selected. Then a 128x64px file is used for the clouds. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 8

[Bug 84662] New: Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU
by bugzilla-daemon＠freedesktop.org 05 Nov '15

05 Nov '15

https://bugs.freedesktop.org/show_bug.cgi?id=84662 Bug ID: 84662 Summary: Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: adf.lists(a)gmail.com R9270X PCIE 2.0 2 gig vram 4 gig ram. Unreal demo Elemental only recently started working with git llvm/mesa, do no bisection done on these. The demo even when working is very broken - constant 1/4 sec stutters with a couple of 1/2 - 1 sec. But after - commit 4439d469706699b4e69ef410ebc9115339f6e9e6 Author: Michel Dänzer <michel.daenzer(a)amd.com> Date: Thu Jul 31 18:43:49 2014 +0900 drm/radeon: Always flush the HDP cache before submitting a CS to the GPU This ensures the GPU sees all previous CPU writes to VRAM, which makes it safe: * For userspace to stream data from CPU to GPU via VRAM instead of GTT * For IBs to be stored in VRAM instead of GTT * For ring buffers to be stored in VRAM instead of GTT, if the HPD flush is performed via MMIO There are far longer pauses of many seconds - run time to unreal logo on "good" is 3:45 on bad best 5:39 can be longer. Screens to be attached show quite different vram/gtt usage between good and bad. Related to https://bugs.freedesktop.org/show_bug.cgi?id=82050 I bisected to the same commit in that bug, but applying the mesa patch https://bugs.freedesktop.org/show_bug.cgi?id=82050#c19 doesn't help here. CONFIG_CMA is not set. Tried kernel org 3.17-rc7 as it was reported in above as working, but not for me. -- You are receiving this mail because: You are the assignee for the bug.

1 58

[RFC 0/6] drm: Add DRM_FBDEV_EMULATION Kconfig option
by Archit Taneja 04 Nov '15

04 Nov '15

This provides a uniform interface to enable/disable legacy fbdev support for modesetting drivers, based on the discussion here: http://lists.freedesktop.org/archives/dri-devel/2015-March/078729.html This has only been build-tested for a few devices. Mainly looking for comments for now. The drivers that provide fbdev emulation by default won't be impacted by this. However, if we could make all drivers use DRM_FBDEV_EMULATION, it would clean up individual Kconfigs, and have a centralized place where we touch FB_* configs. Archit Taneja (6): drm: Add top level Kconfig option for DRM fbdev emulation drm/msm: Remove local fbdev emulation Kconfig option drm/i915: Remove local fbdev emulation Kconfig option drm/tegra: Remove local fbdev emulation Kconfig option drm/imx: Remove local fbdev emulation Kconfig option drm/sti: Remove local fbdev emulation Kconfig option drivers/gpu/drm/Kconfig | 18 ++++++ drivers/gpu/drm/Makefile | 4 ++ drivers/gpu/drm/i915/Kconfig | 15 ----- drivers/gpu/drm/i915/Makefile | 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 2 - drivers/gpu/drm/i915/intel_display.c | 10 ++- drivers/gpu/drm/i915/intel_dp_mst.c | 14 ++-- drivers/gpu/drm/i915/intel_drv.h | 3 +- drivers/gpu/drm/i915/intel_fbdev.c | 7 -- drivers/gpu/drm/imx/Kconfig | 9 --- drivers/gpu/drm/imx/imx-drm-core.c | 10 +-- drivers/gpu/drm/msm/Kconfig | 14 ---- drivers/gpu/drm/msm/Makefile | 2 +- drivers/gpu/drm/msm/msm_drv.c | 4 +- drivers/gpu/drm/sti/Kconfig | 6 -- drivers/gpu/drm/sti/sti_drm_drv.c | 2 +- drivers/gpu/drm/tegra/Kconfig | 12 ---- drivers/gpu/drm/tegra/drm.c | 15 +++-- drivers/gpu/drm/tegra/drm.h | 8 --- drivers/gpu/drm/tegra/fb.c | 25 ++------ include/drm/drm_fb_helper.h | 120 +++++++++++++++++++++++++++++++++++ 22 files changed, 179 insertions(+), 127 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

8 56

[Bug 71461] New: monitor doesn't get detected after boot
by bugzilla-daemon＠bugzilla.kernel.org 30 Oct '15

30 Oct '15

https://bugzilla.kernel.org/show_bug.cgi?id=71461 Bug ID: 71461 Summary: monitor doesn't get detected after boot Product: Drivers Version: 2.5 Kernel Version: 3.13.5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: tom.ty89(a)gmail.com Regression: No My card is Radeon HD5850. The result might varies between different boot. Either the screens would not be detected at all or they seem to be detected with a non-optimal resolution (in console, while gdm shows a broken screen) If a monitor is connected before boot, others can get detected correctly afterwards. If only one monitor is connected, turning it off can make the signal lost. Reboot or suspend/resume (after turning it on again) can bring the signal back. (Yet dpms would cause no problem at all) The only way to reproduce the problem if DVI is involved is to disconnect it physically, otherwise only powering off the monitor is required. My guess is DVI detects display with a different mechanism. -- You are receiving this mail because: You are watching the assignee of the bug.

1 34

[Bug 99041] New: HDMI Audio not working after fixing HDMI.
by bugzilla-daemon＠bugzilla.kernel.org 30 Oct '15

30 Oct '15

https://bugzilla.kernel.org/show_bug.cgi?id=99041 Bug ID: 99041 Summary: HDMI Audio not working after fixing HDMI. Product: Drivers Version: 2.5 Kernel Version: 4.0.3 4.0.4 4.1-rc1 4.1-rc2 4.1-rc3 4.1-rc4 4.1-rc5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: v10lator(a)myway.de Regression: No Alex Deucher told me to open a new bug report, so here I go. Summary so far: Kernel 4.0.2: HDMI image and audio working. Kernel 4.0.3 and upward: No HDMI. Kernel 4.0.4 with commit d5c3b64b9618214a5443c57c64511ab5fa599cec reverted: HDMI image works, audio does not. Kernel 4.0.4 with attachment 178001 from bug 98751: HDMI image works, audio does not. Kernel 4.0.4 with attachment 178001 from bug 98751 and 0f55db36d49d45b80eff0c0a2a498766016f458b reverted: HDMI image and audio working. Monitor in use: Samsung UE40H5090 -- You are receiving this mail because: You are watching the assignee of the bug.

1 3

[Bug 89887] AMD 3650 Mobility locks up on overdraw
by bugzilla-daemon＠freedesktop.org 19 Oct '15

19 Oct '15

https://bugs.freedesktop.org/show_bug.cgi?id=89887 Bug ID: 89887 Summary: AMD 3650 Mobility locks up on overdraw Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: pavol(a)klacansky.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 114845 --> https://bugs.freedesktop.org/attachment.cgi?id=114845&action=edit Demo Hi, by accident I found out that after some threshold on overdraw the GPU hangs. I have attached a simple program that demonstrates the problem. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 89909] Cities: Skylines black rooftops
by bugzilla-daemon＠freedesktop.org 19 Oct '15

19 Oct '15

https://bugs.freedesktop.org/show_bug.cgi?id=89909 Bug ID: 89909 Summary: Cities: Skylines black rooftops Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Keywords: bisected Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: john(a)fastquake.com QA Contact: dri-devel(a)lists.freedesktop.org Here's a screenshot of the bug: http://i.imgur.com/DLp1dFr.png I'm running an AMD R9 290 on Linux Mint 17.1, with kernel 4.0-rc5. I have bisected mesa commits and found commit f9fd0c4a55afd97fd34d0e846000c75f5f6ecac2 (http://cgit.freedesktop.org/mesa/mesa/commit/?id=f9fd0c4a55afd97fd34d0e8460…) to be the culprit. Mesa was compiled with llvm 3.6 from the Ubuntu repositories. -- You are receiving this mail because: You are the assignee for the bug.

1 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015