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.leichtzumerken@xxxxxxxxx>
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.
Tom
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
