>>-----Original Message----- >>From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] >>Sent: 2011年6月24日 1:20 >>To: Zou, Nanhai >>Cc: Keith Packard; intel-gfx@lists.freedesktop.org; Anholt, Eric >>Subject: Re: [Intel-gfx] gem clflush optimization for media encoding >> >>On Wed, 22 Jun 2011 12:29:21 +0800 >>"Zou, Nanhai" <nanhai....@intel.com> wrote: >>> map_gtt in current gem is super slow. >>> I've tried map_gtt but it seems that the speed is unacceptable. >>> >>> >>> Since it is CPU read only surface, clflush in not needed at all. >>> >> >>> >>You'd still have to invalidate cache lines using clflush to avoid using >>> >>stale data in the CPU cache. >>> >> >>> >>-- >>> Yes, you are right, in this case clflush is still needed to invalidate the >>CPU cache. >>> >>> The problem is that we do not now how large the coded output buffer is >>> before >>we do the encoding. >>> So we have to allocate a large enough gem object before encoding, in most >>> case the encoding result will be less than 1/10 of the safe buffer size, >>> 9/10 >>of the buffer was unnecessarily clflushed. >>> >>> A fast map_gtt implementation could be the best choice here. >> >>What's slow about it? Are you sure you're getting a WC mapping? If >>your MTRRs or PAT are messed up you may be getting a regular UC >>mapping, which would be slow. Also you need to write the data >>sequentially to get the benefits of WC. If you write every other byte >>or jump around (and of course read) you'll flush the WC buffer and slow >>things down. >>
Yes, I have noticed that, seems that the uploaded data was written through uc mapping. We are trying to fix this. Thanks Zou Nanhai >>-- >>Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
