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
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()
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.
dri-devel mailing list