On Wed, Mar 30, 2011 at 3:32 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie <airlied@xxxxxxxxx> wrote: >> On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse <j.glisse@xxxxxxxxx> 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). > And I did play with a new pread/pwrite interface that did as you suggest, > binding the user pages and performing a blit. But by the time you make the > interface asynchronous, it becomes much easier to let the client code > create the mapping and be fully aware of the barriers. > > And yes I do concur that vma bookkeeping does impose significant overheads > and I have been removing as many mappings from our drivers as I can; within > the limitations of the pwrite interface. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > Cheers, Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
