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

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)

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

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=edit R600_TRACE lockup at end -- You are receiving this mail because: You are the assignee for the

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

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=edit R600_TRACE lockup at start -- You are receiving this mail because: You are the assignee for the

Re: clean up and modularize arch dma_mapping interface V2

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

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

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

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

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 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

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

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

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

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

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

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

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()

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

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

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

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

Re: clean up and modularize arch dma_mapping interface V2

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()