On Wed, 30 Mar 2011 09:28:07 -0400, Jerome Glisse j.glisse@gmail.com wrote:
On Wed, Mar 30, 2011 at 3:32 AM, Chris Wilson chris@chris-wilson.co.uk wrote:
On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie airlied@gmail.com wrote:
On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse j.glisse@gmail.com wrote:
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.
TTM has support for userpage binding we just don't use it.
Yes, and I've been experimenting with the same in GEM to great effect in the DDX. The complication remains in managing the CPU synchronisation, which suggests that it would only be useful for STREAM_DRAW objects (and perhaps the sub-region updates to STATIC_DRAW). (And for readback, if retrieving the data were the actual bottleneck.)
What do you mean by CPU synchronisation ? In what i had in mind the upload/download would block userspace until operation is, this would make upload/dowload barrier of course it doesn't play well with usecase where you keep uploading/downloading (idea to aleviate that is to allow several download/upload in one ioctl call).
Yes, that is the issue: having to control access to the user pages whilst they are in use by the GPU. A completely synchronous API for performing a single pwrite with the blitter is too slow, much slower than doing an uncached write with the CPU and queueing up multiple blits (as we currently do).
The API I ended up with for the pwrite using the BLT was to specify a 2D region (addr, width, height, stride, flags etc) and list of clip rects. At which point I grew disenchanted, and realised that simply creating a bo for mapping user pages was the far better solution. -Chris