lkml.org 
[lkml]   [2011]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
From
On Tue, Mar 29, 2011 at 4:26 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote:
>> Short lived & small bo would definitly doesn't work well for this kind
>> of API, it would all be a function of the ioctl cost. But i am not
>> sure the drawback would be that big, intel tested with pread/pwrite
>> and gived up don't remember why. For the vbo case you describe the
>> scheme i was thinking would be : allocate bo and on buffer data call
>> upload to the allocated bo using the bind user page feature that would
>> mean zero extra copy operation. For the fire forget case of vbo,
>> likely somekind of transient buffer would be more appropriate.
>
> Just to clarify: Uploads to linear buffers are all done with pwrite (due
> to an api foobar, it's not so great for 2d/tiled stuff). It's amazing how
> much faster that is: Switching vbo's from mmpa to pwrite has given a few
> percent more fps in openarena in i915g! As long as the chunk you're gonna
> write fits into L1 cache, it's probably a net win.
> -Daniel

What i had in mind was something little bit more advance that pwrite,
somethings that would take width,height,pitch of userpage and would be
able to perform proper blit. But yes pwrite in intel is kind of
limited.

Cheers,
Jerome


\
 
 \ /
  Last update: 2011-03-29 23:07    [from the cache]
©2003-2011 Jasper Spaans