[Bug 98146] DRI_PRIME=1 and fullscreen issues

2017-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98146 --- Comment #20 from Darek Deoniziak --- After switching on the same system from Unity, compiz and lightdm to gnome3 and gdm3, updating drivers (oibaf ppa) the remaining issues are almost gone. 1. I do not notice not drawing content in the windo

Re: [PATCH 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

2017-06-24 Thread John Brooks
On Sat, Jun 24, 2017 at 08:00:05PM +0200, Christian König wrote: > Am 23.06.2017 um 19:39 schrieb John Brooks: > >When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace, > >it should only be treated as a hint to initially place a BO somewhere CPU > >accessible, rather than having

Re: [PATCH 0/9] Visible VRAM Management Improvements

2017-06-24 Thread John Brooks
On Sat, Jun 24, 2017 at 08:20:22PM +0200, Christian König wrote: > Am 24.06.2017 um 01:16 schrieb John Brooks: > >On Fri, Jun 23, 2017 at 05:02:58PM -0400, Felix Kuehling wrote: > >>Hi John, > >> > >>I haven't read your patches. Just a question based on the cover letter. > >> > >>I understand that

Re: [PATCH 4/9] drm/amdgpu: Don't force BOs into visible VRAM if they can go to GTT instead

2017-06-24 Thread John Brooks
On Sat, Jun 24, 2017 at 08:09:56PM +0200, Christian König wrote: > Am 23.06.2017 um 19:39 schrieb John Brooks: > >amdgpu_ttm_placement_init() callers that are using both VRAM and GTT as > >domains usually don't want visible VRAM as a busy placement. > > > >Signed-off-by: John Brooks > > NAK to th

Re: [PATCH 0/9] Visible VRAM Management Improvements

2017-06-24 Thread John Brooks
On Sat, Jun 24, 2017 at 08:07:15PM +0200, Christian König wrote: > Am 23.06.2017 um 19:39 schrieb John Brooks: > >This patch series is intended to improve performance when limited CPU-visible > >VRAM is under pressure. > > > >Moving BOs into visible VRAM is essentially a housekeeping task. It's fas

Re: [PATCH 0/9] Visible VRAM Management Improvements

2017-06-24 Thread Christian König
Am 24.06.2017 um 01:16 schrieb John Brooks: On Fri, Jun 23, 2017 at 05:02:58PM -0400, Felix Kuehling wrote: Hi John, I haven't read your patches. Just a question based on the cover letter. I understand that visible VRAM is the biggest pain point. But could the same reasoning make sense for inv

Re: [PATCH 4/9] drm/amdgpu: Don't force BOs into visible VRAM if they can go to GTT instead

2017-06-24 Thread Christian König
Am 23.06.2017 um 19:39 schrieb John Brooks: amdgpu_ttm_placement_init() callers that are using both VRAM and GTT as domains usually don't want visible VRAM as a busy placement. Signed-off-by: John Brooks NAK to this as well. Some callers of amdgpu_ttm_placement_init() have hard placement lim

Re: [PATCH 0/9] Visible VRAM Management Improvements

2017-06-24 Thread Christian König
Am 23.06.2017 um 19:39 schrieb John Brooks: This patch series is intended to improve performance when limited CPU-visible VRAM is under pressure. Moving BOs into visible VRAM is essentially a housekeeping task. It's faster to access them in VRAM than GTT, but it isn't a hard requirement for them

Re: [PATCH 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

2017-06-24 Thread Christian König
Am 23.06.2017 um 19:39 schrieb John Brooks: When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace, it should only be treated as a hint to initially place a BO somewhere CPU accessible, rather than having a permanent effect on BO placement. And that is a clear NAK from my sid

Re: clean up and modularize arch dma_mapping interface V2

2017-06-24 Thread Benjamin Herrenschmidt
On Sat, 2017-06-24 at 09:18 +0200, Christoph Hellwig wrote: > On Wed, Jun 21, 2017 at 12:24:28PM -0700, tndave wrote: > > Thanks for doing this. > > So archs can still have their own definition for dma_set_mask() if > > HAVE_ARCH_DMA_SET_MASK is y? > > (and similarly for dma_set_coherent_mask() wh

[Bug 101575] Lockup for executing trivial-tess-gs_no-gs-inputs.shader_test

2017-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101575 --- Comment #2 from Hi-Angel --- Created attachment 132216 --> https://bugs.freedesktop.org/attachment.cgi?id=132216&action=edit R600_TRACE lockup at end -- You are receiving this mail because: You are the assignee for the bug.__

[Bug 101575] Lockup for executing trivial-tess-gs_no-gs-inputs.shader_test

2017-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101575 --- Comment #1 from Hi-Angel --- Created attachment 132215 --> https://bugs.freedesktop.org/attachment.cgi?id=132215&action=edit R600_TRACE lockup at start -- You are receiving this mail because: You are the assignee for the bug.

[Bug 101575] Lockup for executing trivial-tess-gs_no-gs-inputs.shader_test

2017-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101575 Bug ID: 101575 Summary: Lockup for executing trivial-tess-gs_no-gs-inputs.shader_test Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All)

Re: clean up and modularize arch dma_mapping interface V2

2017-06-24 Thread Christoph Hellwig
On Wed, Jun 21, 2017 at 12:24:28PM -0700, tndave wrote: > Thanks for doing this. > So archs can still have their own definition for dma_set_mask() if > HAVE_ARCH_DMA_SET_MASK is y? > (and similarly for dma_set_coherent_mask() when > CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK is y) > Any plan to change