[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=fcWBpmQ66a3+vQwgFOXn=0rJAviNzR4a0mfcJ@mail.gmail.com>
Date: Tue, 29 Mar 2011 11:23:23 -0400
From: Jerome Glisse <j.glisse@...il.com>
To: r6144 <rainy6144@...il.com>
Cc: Lucas Stach <dev@...xeye.de>, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org
Subject: Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
2011/3/29 r6144 <rainy6144@...il.com>:
> 在 2011-03-29二的 10:22 -0400,Jerome Glisse写道:
>
>> Killer solution would be to have no mapping and a decent
>> upload/download ioctl that can take userpage.
>
> Doesn't this sound like GEM's read/write interface implemented by e.g.
> the i915 driver? But if I understand correctly, a mmap-like interface
> should still be necessary if we want to implement e.g. glMapBuffer()
> without extra copying.
>
> r6144
>
>
glMapBuffer should not be use, it's really not a good way to do stuff.
Anyway the extra copy might be unavoidable given that sometime the
front/back might either be in unmappable vram or either have memory
layout that is not the one specify at buffer creation (this is very
common when using tiling for instance). So even considering MapBuffer
or a like function i believe it's a lot better to not allow buffer
mapping in userspace but provide upload/download hooks that can use
userpage to avoid as much as possible extra copy.
Cheers,
Jerome
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists