[Bug 104193] [radeonsi] The Witcher 3 freezes the system with no attachments calls & transform feedback Wine patch
https://bugs.freedesktop.org/show_bug.cgi?id=104193 --- Comment #3 from Shmerl --- Tested it with Linux 4.15rc5 and new amdgpu.dc=1 (to enable new display code). The freeze still happens. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 4.15-rc6
Hi Linus, Just dequeuing some fixes, I'm on holidays next week again, but I think things should be fine. Dave. The following changes since commit 464e1d5f23cca236b930ef068c328a64cab78fb1: Linux 4.15-rc5 (2017-12-23 20:47:16 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.15-rc6 for you to fetch changes up to 03bfd4e19b935adb8be4f7342f13395fb7f11096: Merge tag 'drm-intel-fixes-2017-12-22-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2017-12-28 05:20:07 +1000) nouveau and i915 regression fixes Ben Skeggs (1): drm/nouveau: fix race when adding delayed work items Dave Airlie (2): Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes Merge tag 'drm-intel-fixes-2017-12-22-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Gabriel Krisman Bertazi (1): i915: Reject CCS modifiers for pipe C on Geminilake Jani Nikula (1): Merge tag 'gvt-fixes-2017-12-21' of https://github.com/intel/gvt-linux into drm-intel-fixes Xiaolin Zhang (1): drm/i915/gvt: Fix pipe A enable as default for vgpu drivers/gpu/drm/i915/gvt/display.c| 5 +++-- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104295] Launching counter strike global offensive fails after update from 17.2 to 17.3
https://bugs.freedesktop.org/show_bug.cgi?id=104295 --- Comment #6 from sleepyoh --- (In reply to Emil Velikov from comment #5) > (In reply to sleepyoh from comment #4) > > Running Arch, Had the same problem but is since today solved. > > > > Today there was updates from mesa (17.3.0-2 -> 17.3.1-2) and xorg-server > > (1.19.5-1 -> 1.19.6-2) wich solved this problem, working fine again. > > > > https://bbs.archlinux.org/viewtopic.php?id=232925 > > > > I had problems for weeks, now working fine, resolved for me. > > I fear your observation is unrelated - Mesa 17.3.1 includes commit > 5ac9d91ee3d897016d54e970a977c3fbbbe2488e, which > a) is exclusive for Intel (Skylake or newer) > b) resolved a GPU lockup > > While the issue here seems to be: > a) radeonsi hardware > b) program crash Hm, well the only thing that's changed on my system from not working csgo to working csgo was today's new mesa and xorg, only packages that got updated and now it's working fine. Maybe xorg then, idk. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #19 from Andy Furniss --- (In reply to lethalwp from comment #14) > Created attachment 135979 [details] > recording of audio LPCM output from RX550 card FWIW, for years "direct" alsa + hdmi on recent cards has had issues. It can work if there is enough cpu i/o load. Not quite enough load can sound like that, no where near enough load can sound like it's stuck. Pulse or jack don't have the issue as they do things differently. See - https://bugzilla.kernel.org/show_bug.cgi?id=86351 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750
https://bugs.freedesktop.org/show_bug.cgi?id=104306 Emil Velikov changed: What|Removed |Added CC||breno...@gmail.com --- Comment #8 from Emil Velikov --- *** Bug 104351 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104295] Launching counter strike global offensive fails after update from 17.2 to 17.3
https://bugs.freedesktop.org/show_bug.cgi?id=104295 --- Comment #5 from Emil Velikov --- (In reply to sleepyoh from comment #4) > Running Arch, Had the same problem but is since today solved. > > Today there was updates from mesa (17.3.0-2 -> 17.3.1-2) and xorg-server > (1.19.5-1 -> 1.19.6-2) wich solved this problem, working fine again. > > https://bbs.archlinux.org/viewtopic.php?id=232925 > > I had problems for weeks, now working fine, resolved for me. I fear your observation is unrelated - Mesa 17.3.1 includes commit 5ac9d91ee3d897016d54e970a977c3fbbbe2488e, which a) is exclusive for Intel (Skylake or newer) b) resolved a GPU lockup While the issue here seems to be: a) radeonsi hardware b) program crash -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104295] Launching counter strike global offensive fails after update from 17.2 to 17.3
https://bugs.freedesktop.org/show_bug.cgi?id=104295 --- Comment #4 from sleepyoh --- Running Arch, Had the same problem but is since today solved. Today there was updates from mesa (17.3.0-2 -> 17.3.1-2) and xorg-server (1.19.5-1 -> 1.19.6-2) wich solved this problem, working fine again. https://bbs.archlinux.org/viewtopic.php?id=232925 I had problems for weeks, now working fine, resolved for me. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] backlight: tdo24m: fix the spi cs between transfers
Currently the LCD display (TD035S) on the cm-x300 platform is broken and remains blank. The TD0245S specification requires that the chipselect is toggled between commands sent to the panel. This was also the purpose of the former patch of commit f64dcac0b124 ("backlight: tdo24m: ensure chip select changes between transfers"). Unfortunately, the "cs_change" field of a SPI transfer is misleading. Its true meaning is that for a SPI message holding multiple transfers, the chip select is toggled between each transfer, but for the last transfer it remains asserted. In this driver, all the SPI messages contain exactly one transfer, which means that each transfer is the last of its message, and as a consequence the chip select is never toggled. Actually, there was a second bug hidding the first one, hence the problem was not seen until v4.6. This problem was fixed by commit a52db659c79c ("spi: pxa2xx: Fix cs_change management") for PXA based boards. This fix makes the TD035S work again on a cm-x300 board. The same applies to other PXA boards, ie. corgi and tosa. Fixes: a52db659c79c ("spi: pxa2xx: Fix cs_change management") Reported-by: Andrea Adami Signed-off-by: Robert Jarzmik Acked-by: Daniel Thompson --- Since v1: added 2 other panels Since v2: added Daniel's ack --- drivers/video/backlight/corgi_lcd.c | 2 +- drivers/video/backlight/tdo24m.c| 2 +- drivers/video/backlight/tosa_lcd.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/video/backlight/corgi_lcd.c b/drivers/video/backlight/corgi_lcd.c index d7c239ea3d09..f5574060f9c8 100644 --- a/drivers/video/backlight/corgi_lcd.c +++ b/drivers/video/backlight/corgi_lcd.c @@ -177,7 +177,7 @@ static int corgi_ssp_lcdtg_send(struct corgi_lcd *lcd, int adrs, uint8_t data) struct spi_message msg; struct spi_transfer xfer = { .len= 1, - .cs_change = 1, + .cs_change = 0, .tx_buf = lcd->buf, }; diff --git a/drivers/video/backlight/tdo24m.c b/drivers/video/backlight/tdo24m.c index eab1f842f9c0..e4bd63e9db6b 100644 --- a/drivers/video/backlight/tdo24m.c +++ b/drivers/video/backlight/tdo24m.c @@ -369,7 +369,7 @@ static int tdo24m_probe(struct spi_device *spi) spi_message_init(m); - x->cs_change = 1; + x->cs_change = 0; x->tx_buf = &lcd->buf[0]; spi_message_add_tail(x, m); diff --git a/drivers/video/backlight/tosa_lcd.c b/drivers/video/backlight/tosa_lcd.c index 6a41ea92737a..4dc5ee8debeb 100644 --- a/drivers/video/backlight/tosa_lcd.c +++ b/drivers/video/backlight/tosa_lcd.c @@ -49,7 +49,7 @@ static int tosa_tg_send(struct spi_device *spi, int adrs, uint8_t data) struct spi_message msg; struct spi_transfer xfer = { .len= 1, - .cs_change = 1, + .cs_change = 0, .tx_buf = buf, }; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102491] OpenCL image processing produces artifacts on Cape Verde 7770
https://bugs.freedesktop.org/show_bug.cgi?id=102491 ka.n...@mail.ru changed: What|Removed |Added Summary|OpenCL app gets |OpenCL image processing |CL_OUT_OF_HOST_MEMORY on|produces artifacts on Cape |Cape Verde 7770 |Verde 7770 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102491] OpenCL app gets CL_OUT_OF_HOST_MEMORY on Cape Verde 7770
https://bugs.freedesktop.org/show_bug.cgi?id=102491 --- Comment #5 from ka.n...@mail.ru --- I managed to make it work somehow, but it's still unusable due to producing artifacts on images processed using opencl on darktable and few other programs I tried. So probably the title should be changed. However, CL_OUT_OF_HOST_MEMORY error may be removed via envitonment var setting, namely export GPU_FORCE_64BIT_PTR=1 also export GPU_USE_SYNC_OBJECTS=1 export GPU_MAX_ALLOC_PERCENT=100 export GPU_SINGLE_ALLOC_PERCENT=100 export GPU_MAX_HEAP_SIZE=100 are recommended but I haven't noticed any difference. What I've noticed, however, is that the driver reports the different amount of available GPU memory each time darktable is started... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/virtio: Add window server support
This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified clients. For some features of the protocol, the hypervisor might have to intervene and also parse the protocol data to properly bridge resources. The following IOCTLs have been added to this effect: *_WINSRV_CONNECT: Opens a connection to the compositor in the host, returns a FD that represents this connection and on which the following IOCTLs can be used. Callers are expected to poll this FD for new messages from the compositor. *_WINSRV_TX: Asks the hypervisor to forward a message to the compositor *_WINSRV_RX: Returns all queued messages Alongside protocol data that is opaque to the kernel, the client can send file descriptors that reference GEM buffers allocated by virtio-gpu. The guest proxy is expected to figure out when a client is passing a FD that refers to shared memory in the guest and allocate a virtio-gpu buffer of the same size with DRM_VIRTGPU_RESOURCE_CREATE. When the client notifies the compositor that it can read from that buffer, the proxy should copy the contents from the SHM region to the virtio-gpu resource and call DRM_VIRTGPU_TRANSFER_TO_HOST. This has been tested with Wayland clients that make use of wl_shm to pass buffers to the compositor, but is expected to work similarly for X clients that make use of MIT-SHM with FD passing. v2: * Add padding to two virtio command structs * Properly cast two __user pointers (kbuild test robot) Signed-off-by: Tomeu Vizoso Cc: Zach Reizner --- Hi, this work is based on the virtio_wl driver in the ChromeOS kernel by Zach Reizner, currently at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c There's two features missing in this patch when compared with virtio_wl: * Allow the guest access directly host memory, without having to resort to TRANSFER_TO_HOST * Pass FDs from host to guest (Wayland specifies that the compositor shares keyboard data with the guest via a shared buffer) I plan to work on this next, but I would like to get some comments on the general approach so I can better choose which patch to follow. Thanks, Tomeu --- drivers/gpu/drm/virtio/virtgpu_drv.h | 39 - drivers/gpu/drm/virtio/virtgpu_ioctl.c | 168 +++ drivers/gpu/drm/virtio/virtgpu_kms.c | 58 +-- drivers/gpu/drm/virtio/virtgpu_vq.c| 285 - include/uapi/drm/virtgpu_drm.h | 29 include/uapi/linux/virtio_gpu.h| 41 + 6 files changed, 605 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index da2fb585fea4..268b386e1232 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -178,6 +178,8 @@ struct virtio_gpu_device { struct virtio_gpu_queue ctrlq; struct virtio_gpu_queue cursorq; + struct virtio_gpu_queue winsrv_rxq; + struct virtio_gpu_queue winsrv_txq; struct kmem_cache *vbufs; bool vqs_ready; @@ -205,10 +207,32 @@ struct virtio_gpu_device { struct virtio_gpu_fpriv { uint32_t ctx_id; + + struct list_head winsrv_conns; /* list of virtio_gpu_winsrv_conn */ + spinlock_t winsrv_lock; +}; + +struct virtio_gpu_winsrv_rx_qentry { + struct virtio_gpu_winsrv_rx *cmd; + struct list_head next; +}; + +struct virtio_gpu_winsrv_conn { + struct virtio_gpu_device *vgdev; + + spinlock_t lock; + + int fd; + struct drm_file *drm_file; + + struct list_head cmdq; /* queue of virtio_gpu_winsrv_rx_qentry */ + wait_queue_head_t cmdwq; + + struct list_head next; }; /* virtio_ioctl.c */ -#define DRM_VIRTIO_NUM_IOCTLS 10 +#define DRM_VIRTIO_NUM_IOCTLS 11 extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS]; /* virtio_kms.c */ @@ -318,9 +342,22 @@ virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device *vgdev, void virtio_gpu_ctrl_ack(struct virtqueue *vq); void virtio_gpu_cursor_ack(struct virtqueue *vq); void virtio_gpu_fence_ack(struct virtqueue *vq); +void virtio_gpu_winsrv_tx_ack(struct virtqueue *vq); +void virtio_gpu_winsrv_rx_read(struct virtqueue *vq); void virtio_gpu_dequeue_ctrl_func(struct work_struct *work); void virtio_gpu_dequeue_cursor_func(struct work_struct *work); +void virtio_gpu_dequeue_winsrv_rx_func(struct work_struct *work); +void virtio_gpu_dequeue_winsrv_tx_func(struct work_struct *work); void virtio_gpu_dequeue_fence_func(struct work_struct *work); +void virtio_gpu_fill_winsrv_rx(struct virtio_gpu_device *vgdev); +void virtio_gpu_queue_winsrv_rx_in(stru
RE: [PATCH] staging: vboxvideo adapt to new TTM interface
Seems I have no permission to push the patch into amd-staging-drm-next. Needs Whitelisted. http://git.amd.com:8080/#/c/124051/1 anyone can help? Thanks Roger(Hongbo.He) -Original Message- From: Zhou, David(ChunMing) Sent: Thursday, December 28, 2017 12:24 PM To: He, Roger ; dri-devel@lists.freedesktop.org Cc: hdego...@redhat.com; gre...@linuxfoundation.org; Koenig, Christian ; Zhou, David(ChunMing) Subject: Re: [PATCH] staging: vboxvideo adapt to new TTM interface Reviewed-by: Chunming Zhou On 2017年12月28日 11:35, Roger He wrote: > Fixes interface change done in the following commit: > eb86c98 drm/ttm: use an operation ctx for ttm_tt_populate in ttm_bo_driver > > i missed this driver because it is in staging dir. > > Signed-off-by: Roger He > --- > drivers/staging/vboxvideo/vbox_ttm.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/vboxvideo/vbox_ttm.c > b/drivers/staging/vboxvideo/vbox_ttm.c > index 231c89e..55f14c9 100644 > --- a/drivers/staging/vboxvideo/vbox_ttm.c > +++ b/drivers/staging/vboxvideo/vbox_ttm.c > @@ -213,9 +213,10 @@ static struct ttm_tt *vbox_ttm_tt_create(struct > ttm_bo_device *bdev, > return tt; > } > > -static int vbox_ttm_tt_populate(struct ttm_tt *ttm) > +static int vbox_ttm_tt_populate(struct ttm_tt *ttm, > + struct ttm_operation_ctx *ctx) > { > - return ttm_pool_populate(ttm); > + return ttm_pool_populate(ttm, ctx); > } > > static void vbox_ttm_tt_unpopulate(struct ttm_tt *ttm) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198123] Console is the wrong color at boot with radeon 6670
https://bugzilla.kernel.org/show_bug.cgi?id=198123 Bill Fraser (bill.fra...@gmail.com) changed: What|Removed |Added CC||bill.fra...@gmail.com --- Comment #9 from Bill Fraser (bill.fra...@gmail.com) --- I'm seeing a very similar problem with the 'ast' driver: a black-on-black text console, with only red-colored text visible -- luckily I have a systemd unit that fails on boot with a red message, which I can see scrolling up the screen as it boots, but nothing else. I've bisected it back to the same commit as Deposite Pirate above, [b8e2b0199cc377617dc238f5106352c06dcd3fa2]. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane
Hi, Lukasz! (Sorry for top-posting). We have Deepak from our team working on the same subject. I think he's in over the holidays so I'll add him to the CC list. Adding damage to the plane state is, IMO the correct way to do it. However, from your proposal it's not clear whether damage is given in the plane-, crtc- or framebuffer coordinates. The last conclusion from our email thread discussion was that they should be given in framebuffer coordinates with helpers to compute plane coordinates or crtc coordinates. The reason being that it's easier for user-space apps to send damage that way, and again, we have the full information that we can clip and scale if necessary. Most drivers probably want the damage in clipped plane- or crtc coordinates. Helpers could for example be in the form of region iterators. Full (multi-rect) damage regions are OK with us, although we should keep in mind that we won't be able to compute region unions in the kernel (yet?). Implying: Should we forbid overlapping rects at the interface level or should we just recommend rects not to be overlapping? The former would be pretty hard to enforce efficiently. Another thing we should think about is how to use this interface for the legacy "dirtyfb" call. Probably we need to clear the damage property on each state-update, or set a flag that "this is a dirtyfb state update". IMO we should also have as an end goal of this work to have gnome-shell on drm sending damage regions on page-flip, which means either porting gnome-shell to atomic or set up a new legacy page-flip-with-atomic ioctl. /Thomas On 12/21/2017 12:10 PM, Lukasz Spintzyk wrote: Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5 Signed-off-by: Lukasz Spintzyk --- drivers/gpu/drm/drm_atomic.c | 10 ++ drivers/gpu/drm/drm_mode_config.c | 6 ++ drivers/gpu/drm/drm_plane.c | 1 + include/drm/drm_mode_config.h | 5 + include/drm/drm_plane.h | 3 +++ 5 files changed, 25 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index b76d49218cf1..cd3b4ed7b04c 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, state->rotation = val; } else if (property == plane->zpos_property) { state->zpos = val; + } else if (property == config->dirty_rects_property) { + bool replaced = false; + int ret = drm_atomic_replace_property_blob_from_id(dev, + &state->dirty_blob, + val, + -1, + &replaced); + return ret; } else if (plane->funcs->atomic_set_property) { return plane->funcs->atomic_set_property(plane, state, property, val); @@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->rotation; } else if (property == plane->zpos_property) { *val = state->zpos; + } else if (property == config->dirty_rects_property) { + *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0; } else if (plane->funcs->atomic_get_property) { return plane->funcs->atomic_get_property(plane, state, property, val); } else { diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c index bc5c46306b3d..d5f1021c6ece 100644 --- a/drivers/gpu/drm/drm_mode_config.c +++ b/drivers/gpu/drm/drm_mode_config.c @@ -293,6 +293,12 @@ static int drm_mode_create_standard_properties(struct drm_device *dev) return -ENOMEM; dev->mode_config.prop_crtc_id = prop; + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB, + "DIRTY_RECTS", 0); + if (!prop) + return -ENOMEM; + dev->mode_config.dirty_rects_property = prop; + prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC, "ACTIVE"); if (!prop) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 37a93cdffb4a..add110f025e5 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, drm_object_attach_property(&plane->base, config->prop_src_y, 0); drm_object_attach_property(&plane->base, config->prop_src_w, 0); drm_object_attach_property(&plane->base, config->prop_src_h, 0); + drm_object_attach_property(&plane->base, config->dirty_rects_property, 0); } if (config->allow_fb_modifiers) diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h index e5f3b43014e1..65f64eb04c0c 100644 --