On 12/02/18 12:16 PM, Christian König wrote:
Am 12.02.2018 um 17:40 schrieb Tom St Denis:
On 09/02/18 01:44 PM, Christian König wrote:
Am 09.02.2018 um 19:19 schrieb Tom St Denis:
On 09/02/18 01:17 PM, Christian König wrote:
Am 09.02.2018 um 18:28 schrieb Tom St Denis:
On 09/02/18 12:27 PM, Tom St Denis wrote:
From: Christian König <ckoenig.leichtzumer...@gmail.com>

Oops, I'll remove this from the commit message before pushing :-)

I did give you credit below though.

The patch before this one isn't merged yet because I'm still not sure if that works under all circumstances or not.

Could you give it some extended testing? Especially if it work with eviction.

I supposed there is a race on the kmap'ed memory which is why I added a ptr check.  Not perfect but since it's a debugfs entry probably better than it needs to be.

I think you can drop that, kmap can only return NULL on 32bit systems when we ran out of vmap area and then you can basically call panic() as well.

The question is if setting page->mapping during allocation has some undesired side effect.

Haven't noticed anything with piglit or other FOSS GL games.

Is there a specific test you'd like me to consider?

Try to restrict VRAM/GTT/memory in general and run something which needs a lot of CPU access to BOs. When it affects anything then the CPU page table unmap of BOs during eviction.

Limiting vram to 256M seems to be fine for both my iGPU and dGPU (thought it drops heaven from 40fps to about 3fps hehehe).

Trying to play with gttsize=256M seems to have broken things I get:

[ 165.080976] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* amdgpu_cs_list_validate(validated) failed. [ 165.081163] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory for command submission!

and it seems heaven is blocked. There are fences being submitted (and signalled) but nothing is being drawn.

dri-devel mailing list

Reply via email to