dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[Bug 85323] New: Video is stuttering using hardware acceleration
by bugzilla-daemon＠freedesktop.org 12 Aug '15

12 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=85323 Bug ID: 85323 Summary: Video is stuttering using hardware acceleration Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: ken20001(a)ukr.net Using hardware acceleration in mpv (mpv -vo vdpau --hwdec vdpau) video plays not smooth but stuttering with this sample: http://www.ulozto.net/live/x2Af6ro/planet-earth-from-pole-to-pole-1080p-sam… mpv --version mpv git-f5a19f6 (C) 2000-2014 mpv/MPlayer/mplayer2 projects built on 2014-10-18T11:58:42 ffmpeg library versions: libavutil 54.7.100 libavcodec 56.1.100 libavformat 56.4.101 libswscale 3.0.100 libavfilter 5.1.100 libavresample 2.1.0 vdpauinfo 0.1-1 mesa-vdpau-drivers 10.4~git1410211930.ef280c~gd~t libgl1-mesa-glx 10.4~git1410211930.ef280c~gd~t Kubuntu 14.04.1 Linux: 3.18RC1 x86_64 Graphics: Radeon HD2600 XT -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 73530] New: Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
by bugzilla-daemon＠freedesktop.org 12 Aug '15

12 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=73530 Priority: medium Bug ID: 73530 Assignee: dri-devel(a)lists.freedesktop.org Summary: Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12 Severity: major Classification: Unclassified OS: All Reporter: paulepanter(a)users.sourceforge.net Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Copying my message to list dri-devel [1]. As reported in the channel #radeon on <irc.freenode.net>, with the laptop Asus U38N-C4010H with an AMD Radeon HD 7600G (Trinity A8-4555M) I am unable to get something displayed on the screen with modesetting enabled. The backlight of the screen is on, but nothing is shown on the screen. Booting with `radeon.modeset=0` on the Linux kernel command line works. I was able to reproduce this problem with Grml with Linux 3.10 and 3.11 and Debian Sid/unstable with Linux 3.12.6. Attaching a VGA monitor to the mini VGA connector using an adapter, nothing was shown on the monitor either. The following is the output I get when starting with `radeon.modeset=0` and then doing `sudo modprobe -r radeon` and `sudo modprobe radeon modeset=1`. Jan 11 06:42:24 myhostname kernel: [ 1060.871165] [drm] radeon kernel modesetting enabled. Jan 11 06:42:24 myhostname kernel: [ 1060.871244] checking generic (d0000000 1f0000) vs hw (d0000000 10000000) Jan 11 06:42:24 myhostname kernel: [ 1060.871247] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver Jan 11 06:42:24 myhostname kernel: [ 1060.871322] Console: switching to colour dummy device 80x25 Jan 11 06:42:24 myhostname kernel: [ 1060.871836] [drm] initializing kernel modesetting (ARUBA 0x1002:0x9908 0x1043:0x1557). Jan 11 06:42:24 myhostname kernel: [ 1060.871882] [drm] register mmio base: 0xFEB00000 Jan 11 06:42:24 myhostname kernel: [ 1060.871884] [drm] register mmio size: 262144 Jan 11 06:42:24 myhostname kernel: [ 1060.871913] [drm] ACPI VFCT contains a BIOS for 00:01.0 1002:9908, size 19968 Jan 11 06:42:24 myhostname kernel: [ 1060.871925] ATOM BIOS: 113 Jan 11 06:42:24 myhostname kernel: [ 1060.871997] radeon 0000:00:01.0: VRAM: 768M 0x0000000000000000 - 0x000000002FFFFFFF (768M used) Jan 11 06:42:24 myhostname kernel: [ 1060.872000] radeon 0000:00:01.0: GTT: 1024M 0x0000000030000000 - 0x000000006FFFFFFF Jan 11 06:42:24 myhostname kernel: [ 1060.872003] [drm] Detected VRAM RAM=768M, BAR=256M Jan 11 06:42:24 myhostname kernel: [ 1060.872005] [drm] RAM width 64bits DDR Jan 11 06:42:24 myhostname kernel: [ 1060.872088] [TTM] Zone kernel: Available graphics memory: 1581256 kiB Jan 11 06:42:24 myhostname kernel: [ 1060.872091] [TTM] Initializing pool allocator Jan 11 06:42:24 myhostname kernel: [ 1060.872101] [TTM] Initializing DMA pool allocator Jan 11 06:42:24 myhostname kernel: [ 1060.872129] [drm] radeon: 768M of VRAM memory ready Jan 11 06:42:24 myhostname kernel: [ 1060.872133] [drm] radeon: 1024M of GTT memory ready. Jan 11 06:42:24 myhostname kernel: [ 1060.874660] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/TAHITI_uvd.bin Jan 11 06:42:24 myhostname kernel: [ 1060.874989] [drm] GART: num cpu pages 262144, num gpu pages 262144 Jan 11 06:42:24 myhostname kernel: [ 1060.882325] [drm] Loading ARUBA Microcode Jan 11 06:42:24 myhostname kernel: [ 1060.882749] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_pfp.bin Jan 11 06:42:24 myhostname kernel: [ 1060.883100] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_me.bin Jan 11 06:42:24 myhostname kernel: [ 1060.883456] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_rlc.bin Jan 11 06:42:24 myhostname kernel: [ 1060.884967] [drm] PCIE GART of 1024M enabled (table at 0x0000000000276000). Jan 11 06:42:24 myhostname kernel: [ 1060.885159] radeon 0000:00:01.0: WB enabled Jan 11 06:42:24 myhostname kernel: [ 1060.885166] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000030000c00 and cpu addr 0xffff880129f11c00 Jan 11 06:42:24 myhostname kernel: [ 1060.885905] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc90011db5a18 Jan 11 06:42:24 myhostname kernel: [ 1060.885910] radeon 0000:00:01.0: fence driver on ring 1 use gpu addr 0x0000000030000c04 and cpu addr 0xffff880129f11c04 Jan 11 06:42:24 myhostname kernel: [ 1060.885914] radeon 0000:00:01.0: fence driver on ring 2 use gpu addr 0x0000000030000c08 and cpu addr 0xffff880129f11c08 Jan 11 06:42:24 myhostname kernel: [ 1060.885918] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000030000c0c and cpu addr 0xffff880129f11c0c Jan 11 06:42:24 myhostname kernel: [ 1060.885922] radeon 0000:00:01.0: fence driver on ring 4 use gpu addr 0x0000000030000c10 and cpu addr 0xffff880129f11c10 Jan 11 06:42:24 myhostname kernel: [ 1060.885929] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). Jan 11 06:42:24 myhostname kernel: [ 1060.885931] [drm] Driver supports precise vblank timestamp query. Jan 11 06:42:24 myhostname kernel: [ 1060.885958] radeon 0000:00:01.0: irq 52 for MSI/MSI-X Jan 11 06:42:24 myhostname kernel: [ 1060.885982] radeon 0000:00:01.0: radeon: using MSI. Jan 11 06:42:24 myhostname kernel: [ 1060.886266] [drm] radeon: irq initialized. Jan 11 06:42:24 myhostname kernel: [ 1060.905813] [drm] ring test on 0 succeeded in 2 usecs Jan 11 06:42:24 myhostname kernel: [ 1060.905876] [drm] ring test on 3 succeeded in 2 usecs Jan 11 06:42:24 myhostname kernel: [ 1060.905885] [drm] ring test on 4 succeeded in 1 usecs Jan 11 06:42:24 myhostname kernel: [ 1060.961514] [drm] ring test on 5 succeeded in 1 usecs Jan 11 06:42:24 myhostname kernel: [ 1060.981502] [drm] UVD initialized successfully. Jan 11 06:42:24 myhostname kernel: [ 1060.985538] [drm] Enabling audio 0 support Jan 11 06:42:24 myhostname kernel: [ 1060.985544] [drm] Enabling audio 1 support Jan 11 06:42:24 myhostname kernel: [ 1060.985549] [drm] Enabling audio 2 support Jan 11 06:42:24 myhostname kernel: [ 1060.985553] [drm] Enabling audio 3 support Jan 11 06:42:24 myhostname kernel: [ 1060.985557] [drm] Enabling audio 4 support Jan 11 06:42:24 myhostname kernel: [ 1060.985560] [drm] Enabling audio 5 support Jan 11 06:42:24 myhostname kernel: [ 1060.986106] [drm] ib test on ring 0 succeeded in 0 usecs Jan 11 06:42:24 myhostname kernel: [ 1060.986644] [drm] ib test on ring 3 succeeded in 0 usecs Jan 11 06:42:24 myhostname kernel: [ 1060.987175] [drm] ib test on ring 4 succeeded in 1 usecs Jan 11 06:42:24 myhostname kernel: [ 1061.007977] [drm] ib test on ring 5 succeeded Jan 11 06:42:24 myhostname kernel: [ 1061.032890] [drm] radeon atom DIG backlight initialized Jan 11 06:42:24 myhostname kernel: [ 1061.032894] [drm] Radeon Display Connectors Jan 11 06:42:24 myhostname kernel: [ 1061.032897] [drm] Connector 0: Jan 11 06:42:24 myhostname kernel: [ 1061.032899] [drm] eDP-1 Jan 11 06:42:24 myhostname kernel: [ 1061.032901] [drm] HPD1 Jan 11 06:42:24 myhostname kernel: [ 1061.032904] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c Jan 11 06:42:24 myhostname kernel: [ 1061.032906] [drm] Encoders: Jan 11 06:42:24 myhostname kernel: [ 1061.032908] [drm] LCD1: INTERNAL_UNIPHY2 Jan 11 06:42:24 myhostname kernel: [ 1061.032909] [drm] Connector 1: Jan 11 06:42:24 myhostname kernel: [ 1061.032911] [drm] VGA-1 Jan 11 06:42:24 myhostname kernel: [ 1061.032912] [drm] HPD2 Jan 11 06:42:24 myhostname kernel: [ 1061.032915] [drm] DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c Jan 11 06:42:24 myhostname kernel: [ 1061.032916] [drm] Encoders: Jan 11 06:42:24 myhostname kernel: [ 1061.032917] [drm] CRT1: INTERNAL_UNIPHY2 Jan 11 06:42:24 myhostname kernel: [ 1061.032919] [drm] CRT1: NUTMEG Jan 11 06:42:24 myhostname kernel: [ 1061.032920] [drm] Connector 2: Jan 11 06:42:24 myhostname kernel: [ 1061.032922] [drm] HDMI-A-1 Jan 11 06:42:24 myhostname kernel: [ 1061.032923] [drm] HPD3 Jan 11 06:42:24 myhostname kernel: [ 1061.032925] [drm] DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 0x655c Jan 11 06:42:24 myhostname kernel: [ 1061.032926] [drm] Encoders: Jan 11 06:42:24 myhostname kernel: [ 1061.032928] [drm] DFP1: INTERNAL_UNIPHY Jan 11 06:42:25 myhostname kernel: [ 1061.082355] [drm] Internal thermal controller without fan control Jan 11 06:42:25 myhostname kernel: [ 1061.082493] [drm] radeon: power management initialized Jan 11 06:42:26 myhostname kernel: [ 1062.360915] [drm] fb mappable at 0xD1488000 Jan 11 06:42:26 myhostname kernel: [ 1062.360922] [drm] vram apper at 0xD0000000 Jan 11 06:42:26 myhostname kernel: [ 1062.360926] [drm] size 8294400 Jan 11 06:42:26 myhostname kernel: [ 1062.360928] [drm] fb depth is 24 Jan 11 06:42:26 myhostname kernel: [ 1062.360931] [drm] pitch is 7680 Jan 11 06:42:26 myhostname kernel: [ 1062.361231] fbcon: radeondrmfb (fb0) is primary device Jan 11 06:42:28 myhostname kernel: [ 1064.675993] Console: switching to colour frame buffer device 240x67 Jan 11 06:42:28 myhostname kernel: [ 1064.681973] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device Jan 11 06:42:28 myhostname kernel: [ 1064.681976] radeon 0000:00:01.0: registered panic notifier Jan 11 06:42:28 myhostname kernel: [ 1064.682222] [drm] Initialized radeon 2.34.0 20080528 for 0000:00:01.0 on minor 0 The screen turns off shortly (backlight too) and then only the backlight comes back up. As requested by Alex [2] I am going to attach the two files. [1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051737.html [2] http://lists.freedesktop.org/archives/dri-devel/2014-January/051791.html -- You are receiving this mail because: You are the assignee for the bug.

1 119

[Bug 89987] Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)
by bugzilla-daemon＠freedesktop.org 09 Aug '15

09 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=89987 Bug ID: 89987 Summary: Slow VDPAU (rv770_restrict_performance_levels_before_switch failed) Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: chewi(a)gentoo.org Created attachment 115023 --> https://bugs.freedesktop.org/attachment.cgi?id=115023&action=edit dmesg I have a Radeon HD4670 on a Gentoo Linux system. 1080p playback was working fine under 3.17 but has since slowed to a crawl. I have done back to 3.17 to check that it still works despite numerous updates to userspace and it does. 3.18 flat out refuses to work, with vdpauinfo claiming that H.264 is not supported. I know that Radeon video acceleration was in a transition during this period so best to ignore that. Under 3.19.3 and 4.0-rc7, vdpauinfo reports that H.264 is supported but playback is very slow. How slow? Low quality 1080p is very jumpy. High quality 1080p (Blu-ray) barely moves at all. Probably something like 0.1fps. When attempting playback, though mplayer or VLC, the following error appears in dmesg. [drm:rv770_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed This led me to try booting with radeon.dpm=0. Under the high profile, low quality is smooth and high quality improves to just jumpy. Under the dynpm method, both are smooth. I have two displays connected using Zaphod mode, both normally at 1080p. If I disconnect the second, playback is smooth. If I set the second to some low resolution like 720x480 but play 1080p video on the first, playback is smooth. I'm not sure whether this behaviour is a symptom or a cause. I tried enabling DRI3 to see if that would help but no. I can't bisect the kernel because UVD acceleration is new. There has probably not been a commit so far where it did work under this setup. Here's some further info. Card: Advanced Micro Devices, Inc. [AMD/ATI] RV730 XT [Radeon HD 4670] Kernels: 3.19.3 and 4.0-rc7 Mesa: 10.5.2 xorg-server: 1.17.1 xf86-video-ati: 7.5.0 and 5921ba4ca705a0d919515626088f3948cc4848c1 Desktop: XFCE (no compositing) This has similarities to bug #69120 but I believe that to be a different issue because it involves much older kernel versions and a lot has changed since then, plus it used to work for me until 3.18. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[PATCH 1/2] drm/panel: simple: Add bus format for HannStar HSD070PWW1 LVDS panel
by Lucas Stach 07 Aug '15

07 Aug '15

From: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 30904a9b2a4c..dc6a923c89d7 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -729,6 +729,7 @@ static const struct panel_desc hannstar_hsd070pww1 = { .width = 151, .height = 94, }, + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, }; static const struct drm_display_mode hitachi_tx23d38vm0caa_mode = { -- 2.1.4

3 8

[PATCH 1/3] drm/nouveau: Use drm_vblank_on/off consistently
by Daniel Vetter 07 Aug '15

07 Aug '15

In commit 9cba5efab5a8145ae6c52ea273553f069c294482 Author: Mario Kleiner <mario.kleiner.de(a)gmail.com> Date: Tue Jul 29 02:36:44 2014 +0200 drm/nouveau: Dis/Enable vblank irqs during suspend/resume drm_vblank_on/off calls where added around suspend/resume to make sure vblank stay doesn't go boom over that transition. But nouveau already used drm_vblank_pre/post_modeset over modesets. Instead use drm_vblank_on/off everyhwere. The slight change here is that after _off drm_vblank_get will refuse to work right away, but nouveau doesn't seem to depend upon that anywhere outside of the pageflip paths. The longer-term plan here is to switch all kms drivers to drm_vblank_on/off so that common code like pending event cleanup can be done there, while drm_vblank_pre/post_modeset will be purely drm internal for the old UMS ioctl. Note that the drm_vblank_off still seems required in the suspend path since nouveau doesn't explicitly disable crtcs. But on the resume side drm_helper_resume_force_mode should end up calling drm_vblank_on through the nouveau crtc hooks already. Hence remove the call in the resume code. Cc: Mario Kleiner <mario.kleiner.de(a)gmail.com> Cc: Ben Skeggs <bskeggs(a)redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_display.c | 4 ---- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index 3d96b49fe662..dab24066fa21 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -708,7 +708,7 @@ static void nv_crtc_prepare(struct drm_crtc *crtc) if (nv_two_heads(dev)) NVSetOwner(dev, nv_crtc->index); - drm_vblank_pre_modeset(dev, nv_crtc->index); + drm_vblank_off(dev, nv_crtc->index); funcs->dpms(crtc, DRM_MODE_DPMS_OFF); NVBlankScreen(dev, nv_crtc->index, true); @@ -740,7 +740,7 @@ static void nv_crtc_commit(struct drm_crtc *crtc) #endif funcs->dpms(crtc, DRM_MODE_DPMS_ON); - drm_vblank_post_modeset(dev, nv_crtc->index); + drm_vblank_on(dev, nv_crtc->index); } static void nv_crtc_destroy(struct drm_crtc *crtc) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 8670d90cdc11..d824023f9fc6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -620,10 +620,6 @@ nouveau_display_resume(struct drm_device *dev, bool runtime) nv_crtc->lut.depth = 0; } - /* Make sure that drm and hw vblank irqs get resumed if needed. */ - for (head = 0; head < dev->mode_config.num_crtc; head++) - drm_vblank_on(dev, head); - /* This should ensure we don't hit a locking problem when someone * wakes us up via a connector. We should never go into suspend * while the display is on anyways. -- 2.1.4

4 17

[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon
by bugzilla-daemon＠freedesktop.org 06 Aug '15

06 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=91041 Bug ID: 91041 Summary: Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: robotbuilderfiletransfer(a)gmail.com The problem can be sloved by executing this command: "xrandr --output HDMI-0 --auto --set audio off". I found a simillar, but very old (6 years old), bug here: https://bugs.freedesktop.org/show_bug.cgi?id=23384. -- You are receiving this mail because: You are the assignee for the bug.

1 20

[PATCH] drm/exynos/fimc: fix runtime pm support
by Marek Szyprowski 06 Aug '15

06 Aug '15

Once pm_runtime_set_active() gets called, the kernel assumes that given device has already enabled runtime pm and will call pm_runtime_suspend() without matching pm_runtime_resume(). In case of DRM FIMC IPP driver, this will result in calling clk_disable() without respective call to clk_enable(). This patch removes call to pm_runtime_set_active() to ensure that pm_runtime_suspend/resume calls will match. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c index 842d6b8dc3c4..2a652359af64 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c @@ -1745,7 +1745,6 @@ static int fimc_probe(struct platform_device *pdev) spin_lock_init(&ctx->lock); platform_set_drvdata(pdev, ctx); - pm_runtime_set_active(dev); pm_runtime_enable(dev); ret = exynos_drm_ippdrv_register(ippdrv); -- 1.9.2

3 3

[Bug 86796] Artifacts on the screen. HD8530M
by bugzilla-daemon＠freedesktop.org 03 Aug '15

03 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=86796 Bug ID: 86796 Summary: Artifacts on the screen. HD8530M Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: nicknnn(a)gmail.com Created attachment 110136 --> https://bugs.freedesktop.org/attachment.cgi?id=110136&action=edit Example screen shot with artifacts Artifacts on the screen on notebook asus S301L. The laptop has a muxless video card. I use DRI_PRIME. $ xrandr --listproviders Providers: number : 2 Provider 0: id: 0x76 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 2 associated providers: 1 name:Intel Provider 1: id: 0x51 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 0 associated providers: 1 name:radeon DRI_PRIME=1 LD_LIBRARY_PATH=/opt/mesa-master/lib/ LD_PRELOAD=/opt/mesa-master/lib/dri/radeonsi_dri.so glxgears DRI_PRIME=1 LD_LIBRARY_PATH=/opt/mesa-master/lib/ LD_PRELOAD=/opt/mesa-master/lib/dri/radeonsi_dri.so amoeba Example screen shot as an attachment amoeba.jpg Uname: Linux mj 3.17-1-amd64 #1 SMP Debian 3.17-1~exp1 (2014-10-14) x86_64 GNU/Linux -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 88887] Grim Fandango Remastered segfaults within radeon_llvm_compile->...->llvm::BasicBlock::getTerminator
by bugzilla-daemon＠freedesktop.org 02 Aug '15

02 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=88887 Bug ID: 88887 Summary: Grim Fandango Remastered segfaults within radeon_llvm_compile->...->llvm::BasicBlock::getTermina tor 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: NightNord(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 112998 --> https://bugs.freedesktop.org/attachment.cgi?id=112998&action=edit Backtrace for all threads Crash within #0 0xf62be474 in llvm::BasicBlock::getTerminator() () from /usr/lib32/libLLVM-3.5.so ... #9 0xf723bdae in radeon_llvm_compile () from /usr/lib32/dri/radeonsi_dri.so ... #22 0x081b1014 in zg_RenderContext_DrawIndexedPrimitives () ... Full backtrace attached. Crashes just after an intro movie, 100% reproducable. There is a message in the game's log: "No matching vertex attribute 'vs_TexCoord' in shader 'color_quad' for QuadVertex::TexCoord" just before the movie end. Mesa version: Mesa 10.5.0 devel (on earlier versions too, tested up to 10.3.7) LLVM version: 3.5.1 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] xf86-video-ati: recent git version -- You are receiving this mail because: You are the assignee for the bug.

1 3

[PATCH 0/5] drm/msm/dsi: Add support for external bridge chips
by Archit Taneja 02 Aug '15

02 Aug '15

The dsi driver only connects to drm_panel devices right now. drm_bridge based devices can be used to implement external encoder chips (like DSI to HDMI, DSI to LVDS) etc. Make changes such that the dsi driver works with drm_bridge devices. This enables the driver to connect with the encoder chips mentioned above. Archit Taneja (5): drm/msm/dsi: Make TE gpio optional drm/msm/dsi: Refer to connected device as 'device' instead of 'panel' drm/msm/dsi: Create a helper to check if there is a connected device drm/msm/dsi: Allow dsi to connect to an external bridge drm/msm/dsi: Modify dsi manager bridge ops to work with external bridges drivers/gpu/drm/msm/dsi/dsi.c | 66 ++++++++++++++++++++++++++++++----- drivers/gpu/drm/msm/dsi/dsi.h | 17 ++++++++- drivers/gpu/drm/msm/dsi/dsi_host.c | 49 +++++++++++++++++--------- drivers/gpu/drm/msm/dsi/dsi_manager.c | 55 ++++++++++++++++++----------- 4 files changed, 141 insertions(+), 46 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

1 11

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015