dri-devel January 2018

dri-devel@lists.freedesktop.org

226 participants
1677 discussions

[Bug 104492] Compute Shader: Wrong alignment when assigning struct value to structured SSBO
by bugzilla-daemon＠freedesktop.org 08 Jan '18

08 Jan '18

https://bugs.freedesktop.org/show_bug.cgi?id=104492 Bug ID: 104492 Summary: Compute Shader: Wrong alignment when assigning struct value to structured SSBO Product: Mesa Version: 17.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org … [View More] Reporter: florian.will(a)googlemail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 136547 --> https://bugs.freedesktop.org/attachment.cgi?id=136547&action=edit Code to reproduce this issue. Requires SDL2. Hi, I'm trying to get the Banshee 3D engine <https://github.com/BearishSun/BansheeEngine> working on my hardware (HD 7870) using Mesa radeonsi (amdgpu kernel module). I use 17.2.4-0ubuntu1~17.10.1 from the Ubuntu artful-proposed archive. It uses a compute shader that reads a texture cube and writes 6 sets of coefficients into a shader storage buffer object. Details are not important as I have isolated the (probably) incorrect driver behaviour and created a much simpler program that triggers the same issue. In short: Let's say we have a GLSL struct and access the SSBO through a dynamically-sized array of that struct type using the std430 layout, like this: struct ResultRecord { float a[10]; float b[10]; float c[10]; float weight; }; layout(std430) buffer gOutput { ResultRecord ssb[]; }; Then a simple assignment of a local variable of the same struct type to ssb[i] writes the floats into incorrect buffer offsets, because b, c and "weight" are placed as if the array elements in a, b and c were vec4-aligned instead of float-aligned, tripling the size of a, b and c. Code that triggers it is like this, which should hopefully be valid GLSL (and makes more sense the way it is used in Banshee 3D): ResultRecord result; // ... populate result ... ssb[gl_LocalInvocationIndex] = result; The test program is available here and contains a (maybe too) detailed explanation and three program variations that fix the issue: https://gist.github.com/w-flo/b1a5791749eea5f36cb54628037ba2bf But I'll also attach it to this bug report. Looking at the RADEON_DUMP_SHADERS=1 output, I think that the bug is already visible in the TGSI dump, as explained in the comment at the top of my reproducer program. I'll attach the output (it's possibly based on an older version of the reproducer). -- You are receiving this mail because: You are the assignee for the bug. [View Less]

1 7

[Bug 104526] 0x00007fce563644fb in update_buffers (dri2_surf=dri2_surf@entry=0x55b5be7fc690) at drivers/dri2/platform_wayland.c:541
by bugzilla-daemon＠freedesktop.org 07 Jan '18

07 Jan '18

1 0

[PATCH] drm/etnaviv: add missing major features field to debugfs
by Lucas Stach 07 Jan '18

07 Jan '18

This can be useful when dealing with a new GPU core. Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index febbd1e5bbc7..bab6a8286520 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -811,6 +811,8 @@ int etnaviv_gpu_debugfs(struct etnaviv_gpu *gpu, struct … [View More]

1 0

[PATCH] gpu: drm: i915: intel_hotplug: avoid NULL pointer dereference
by Olivier Sobrie 07 Jan '18

07 Jan '18

I observed the following crash on my laptop after undocking it: BUG: unable to handle kernel NULL pointer dereference at 00000000000000e4 IP: i915_hpd_poll_init_work+0x8f/0x100 [i915] PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ppp_mppe ppp_async ppp_generic slhc nf_conntrack_pptp nf_conntrack_proto_gre veth ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user kvm irqbypass crct10dif_pclmul iwlmvm crc32_pclmul ghash_clmulni_intel mei_wdt iTCO_wdt … [View More]iTCO_vendor_support mac80211 wmi_bmof pcbc i2c_algo_bit snd_hda_intel drm_kms_helper snd_hd usbcore usb_common i8042 serio vfat fat trusted tpm crc32c_generic crc32c_intel btrfs xor zstd_decompress zstd_compress xxhash raid6_pq CPU: 0 PID: 37 Comm: kworker/0:1 Tainted: G U O 4.14.9-1-ARCH #1 Hardware name: LENOVO 20F9CTO1WW/20F9CTO1WW, BIOS N1CET56W (1.24 ) 04/19/2017 Workqueue: events i915_hpd_poll_init_work [i915] task: ffffa0bd09132dc0 task.stack: ffffb177032b0000 RIP: 0010:i915_hpd_poll_init_work+0x8f/0x100 [i915] RSP: 0018:ffffb177032b3e58 EFLAGS: 00010202 RAX: ffffa0bcf5b2d800 RBX: 0000000000000001 RCX: 0000000000000056 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffc0a9d8f7 RBP: ffffa0bcf8f1abc0 R08: 0000000000000003 R09: 0000000000000002 R10: ffffa0bcf8f182f8 R11: 0000000000000c00 R12: ffffa0bcf8f18000 R13: 0000000000000000 R14: ffffa0bcf8f181f8 R15: ffffa0bd092843c0 FS: 0000000000000000(0000) GS:ffffa0bd21400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e4 CR3: 0000000157c09002 CR4: 00000000003606f0 Call Trace: process_one_work+0x1db/0x410 worker_thread+0x2b/0x3d0 ? process_one_work+0x410/0x410 kthread+0x118/0x130 ? kthread_create_on_node+0x70/0x70 ret_from_fork+0x1f/0x30 Code: 0f b6 90 a0 04 00 00 48 83 b8 b0 04 00 00 00 88 90 e8 02 00 00 75 dc 84 d2 75 d8 f6 85 70 da ff ff 02 74 cf 48 8b 90 00 04 00 00 <8b> 92 e4 00 00 00 85 d2 74 be 88 98 e8 02 0 RIP: i915_hpd_poll_init_work+0x8f/0x100 [i915] RSP: ffffb177032b3e58 CR2: 00000000000000e4 ---[ end trace 098075e41d0a597e ]--- The values of the registers seems to indicate that it tries to dereference the hpd_pin field of the encoder structure. The value 0xe4 corresponds to the offset of the field hpd_pin in the encoder structure. It appears that encoder->hpd_pin is accessed without checking first that encoder is not NULL. The same issue may happen in intel_hpd_irq_storm_reenable_work(). This patch should fix these issues. Signed-off-by: Olivier Sobrie <olivier(a)sobrie.be> --- drivers/gpu/drm/i915/intel_hotplug.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index 875d5d218d5c..ab7e8dd0cf5b 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -245,7 +245,8 @@ static void intel_hpd_irq_storm_reenable_work(struct work_struct *work) drm_for_each_connector_iter(connector, &conn_iter) { struct intel_connector *intel_connector = to_intel_connector(connector); - if (intel_connector->encoder->hpd_pin == i) { + if (intel_connector->encoder && + (intel_connector->encoder->hpd_pin == i)) { if (connector->polled != intel_connector->polled) DRM_DEBUG_DRIVER("Reenabling HPD on connector %s\n", connector->name); @@ -546,6 +547,7 @@ static void i915_hpd_poll_init_work(struct work_struct *work) continue; if (!connector->polled && I915_HAS_HOTPLUG(dev_priv) && + intel_connector->encoder && intel_connector->encoder->hpd_pin > HPD_NONE) { connector->polled = enabled ? DRM_CONNECTOR_POLL_CONNECT | -- 2.15.1 [View Less]

1 0

[PATCH] vboxvideo: Fix incorrect type in assignment sparse warning
by Alexander Kapshuk 06 Jan '18

06 Jan '18

On Sat, Jan 6, 2018 at 6:00 PM, Hans de Goede <hdegoede(a)redhat.com> wrote: > Hi, > > > On 06-01-18 15:20, Alexander Kapshuk wrote: >> >> On Mon, Dec 25, 2017 at 04:42:59PM +0200, Alexander Kapshuk wrote: >>> >>> Sparse emitted the following warning: >>> ../drivers/staging/vboxvideo/vbox_fb.c:173:27: warning: incorrect type in >>> assignment (different address spaces) >>> ../drivers/staging/vboxvideo/vbox_fb.c:173:27: … [View More] expected char [noderef] >>> <asn:2>*screen_base >>> ../drivers/staging/vboxvideo/vbox_fb.c:173:27: got void *virtual >>> >>> The vbox_bo buffer object kernel mapping is handled by a call >>> to ttm_bo_kmap() prior to the assignment of bo->kmap.virtual to >>> info->screen_base of type char __iomem*. >>> Casting bo->kmap.virtual to char __iomem* in this assignment fixes >>> the warning. >>> >>> vboxvideo: Fix address space of expression removal sparse warning >>> >>> Sparse emitted the following warning: >>> ../drivers/staging/vboxvideo/vbox_main.c:64:25: warning: cast removes >>> address space of expression >>> >>> vbox->vbva_buffers iomapping is handled by calling vbox_accel_init() >>> from vbox_hw_init(). >>> __force attribute is used in assignment to vbva to fix the warning. >>> >>> Signed-off-by: Alexander Kapshuk <alexander.kapshuk(a)gmail.com> >>> --- >>> drivers/staging/vboxvideo/vbox_fb.c | 2 +- >>> drivers/staging/vboxvideo/vbox_main.c | 2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/staging/vboxvideo/vbox_fb.c >>> b/drivers/staging/vboxvideo/vbox_fb.c >>> index 8aed248db6e2..43c39eca4ae1 100644 >>> --- a/drivers/staging/vboxvideo/vbox_fb.c >>> +++ b/drivers/staging/vboxvideo/vbox_fb.c >>> @@ -170,7 +170,7 @@ static int vboxfb_create(struct drm_fb_helper >>> *helper, >>> drm_fb_helper_fill_var(info, &fbdev->helper, sizes->fb_width, >>> sizes->fb_height); >>> >>> - info->screen_base = bo->kmap.virtual; >>> + info->screen_base = (char __iomem *)bo->kmap.virtual; >>> info->screen_size = size; >>> >>> #ifdef CONFIG_DRM_KMS_FB_HELPER > > > This fix looks good to me. > >>> diff --git a/drivers/staging/vboxvideo/vbox_main.c >>> b/drivers/staging/vboxvideo/vbox_main.c >>> index 80bd039fa08e..973b3bcc04b1 100644 >>> --- a/drivers/staging/vboxvideo/vbox_main.c >>> +++ b/drivers/staging/vboxvideo/vbox_main.c >>> @@ -61,7 +61,7 @@ void vbox_enable_accel(struct vbox_private *vbox) >>> if (vbox->vbva_info[i].vbva) >>> continue; >>> >>> - vbva = (void *)vbox->vbva_buffers + i * >>> VBVA_MIN_BUFFER_SIZE; >>> + vbva = (void __force *)vbox->vbva_buffers + i * >>> VBVA_MIN_BUFFER_SIZE; >>> if (!vbva_enable(&vbox->vbva_info[i], >>> vbox->guest_pool, vbva, i)) { >>> /* very old host or driver error. */ > > > Hmm, isn't there a cleaner way to fix this ? Maybe make vbva_enable's > argument (and the local vbva variable) of type u8 __iomem * too ? > > Regards, > > Hans Hi Hans, Thanks for your prompt response. I had a good look at the vbva_enable() function's definition and to the best of my knowledge, changing vbva's type from 'struct vbva_buffer *' to 'u8 __iomem *' wouldn't work. vbva_enable() relies on vbva's type being a pointer to 'struct vbva_buffer': vbva's memory gets set to zero; some of vbva's members are initialised to particular values; vbva_ctx->vbva expects vbva to be a pointer to 'struct vbva_buffer' as well; Or am I misreading this? What are your thoughts on this? Thanks. Alexander. [View Less]

2 4

[PATCH 0/1] i915: pm: Be less agressive with clockfreq changes on Bay Trail
by Hans de Goede 06 Jan '18

06 Jan '18

Hi All, So this patch, which I already submitted a while ago and back then it got one comment from Chris Wilson: > Basically you want a limit on the frequency of ... pcode access? > As presented, you ultimately do not trust any write and the only > solution is to disable all writes. No RPS whatsoever, run at max and > hope rc6 works (maybe even decrease the rc6 threshold). > > One of the ideas we floated was moving the pcode access to a worker and > ratelimiting the … [View More]

1 1

[PATCH 0/5] drm/tinydrm: Cleanup
by Noralf Trønnes 06 Jan '18

06 Jan '18

Patches 1-4 fixes a few things that came up during the tinydrm review but wasn't addressed at the time. Noralf. Noralf Trønnes (5): drm/tinydrm/mi0283qt: Use common include order drm/tinydrm/mi0283qt: Remove ili9341.h drm/tinydrm/mi0283qt: Clarify error message drm/tinydrm/mi0283qt: Let the display pipe handle power drm/tinydrm: Embed the mode in tinydrm_connector drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 34 ++++------- drivers/gpu/drm/tinydrm/mi0283qt.c | 92 ++++++++… [View More]

2 15

[PATCH] drm/nouveau/disp/gf119: add missing drive vfunc ptr
by Rob Clark 06 Jan '18

06 Jan '18

Fixes broken dp on GF119: Call Trace: ? nvkm_dp_train_drive+0x183/0x2c0 [nouveau] nvkm_dp_acquire+0x4f3/0xcd0 [nouveau] nv50_disp_super_2_2+0x5d/0x470 [nouveau] ? nvkm_devinit_pll_set+0xf/0x20 [nouveau] gf119_disp_super+0x19c/0x2f0 [nouveau] process_one_work+0x193/0x3c0 worker_thread+0x35/0x3b0 kthread+0x125/0x140 ? process_one_work+0x3c0/0x3c0 ? kthread_park+0x60/0x60 ret_from_fork+0x25/0x30 Code: Bad RIP value. RIP: (null) RSP: … [View More]

1 1

[PATCH] vboxvideo: Fix incorrect type in assignment sparse warning
by Alexander Kapshuk 06 Jan '18

06 Jan '18

Sparse emitted the following warning: ../drivers/staging/vboxvideo/vbox_fb.c:173:27: warning: incorrect type in assignment (different address spaces) ../drivers/staging/vboxvideo/vbox_fb.c:173:27: expected char [noderef] <asn:2>*screen_base ../drivers/staging/vboxvideo/vbox_fb.c:173:27: got void *virtual The vbox_bo buffer object kernel mapping is handled by a call to ttm_bo_kmap() prior to the assignment of bo->kmap.virtual to info->screen_base of type char __iomem*. Casting … [View More]

2 2

[Bug 104216] Firefox quirks (black and/or white squares)
by bugzilla-daemon＠freedesktop.org 06 Jan '18

06 Jan '18

https://bugs.freedesktop.org/show_bug.cgi?id=104216 --- Comment #7 from Germano Massullo <germano.massullo(a)gmail.com> --- (In reply to Marek Olšák from comment #6) > Have you tested the patch you linked? Not yet -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2018