linux-kernel - Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTim2AyGPrun8MNq0=TyXpJ+b8i=eyHhLz01F+f2P@mail.gmail.com>
Date:	Tue, 29 Mar 2011 17:04:59 -0400
From:	Jerome Glisse <j.glisse@...il.com>
To:	Jerome Glisse <j.glisse@...il.com>, Lucas Stach <dev@...xeye.de>,
	r6144 <rainy6144@...il.com>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org
Cc:	Daniel Vetter <daniel@...ll.ch>
Subject: Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()

On Tue, Mar 29, 2011 at 4:26 PM, Daniel Vetter <daniel@...ll.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
--
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/