Thomas Hellström wrote: > Dave Airlie wrote: > >> On 10/31/07, Thomas Hellström <[EMAIL PROTECTED]> wrote: >> >> >>> Dave Airlie wrote: >>> >>> >>>> On 10/31/07, Thomas Hellström <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>>> Dave, >>>>> >>>>> When starting out with TTM i did look a little at AGP caching issues and >>>>> there was an issue with cached memory and speculative pre-fetching that >>>>> may affect the mapped-cached memory, >>>>> and that we need to know about but perhaps ignore. >>>>> >>>>> Suppose you bind a page to the AGP aperture, but don't change the kernel >>>>> linear map caching policy. >>>>> Then a speculatively prefetching processor may read the memory into its >>>>> cache and then decide it doesn't >>>>> want to use it, and actually write it back. >>>>> Meanwhile the GPU may have changed the contents of the page and that >>>>> change will be overwritten. Apparently there were big problems with AMD >>>>> Athlons actually doing this. Linux people claiming it was an Athlon bug >>>>> and AMD people claiming it was within specs. >>>>> >>>>> >>>>> >>>>> >>>> http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/061/6148/6148s1.html >>>> >>>> Is what I believe you are talking about, I'll add something to the >>>> comment mentioning this.. >>>> >>>> >>>> >>>> >>> Yup. In the end I believe the "change_page_attr(), global_flush_tlb()" >>> sequence was the final outcome of this, but as I understand it, >>> with your new code we never write through the GTT, which makes the only >>> possible problem overwrites of GPU written data. >>> >>> >>> >> Well so far we've only dealt with Intel CPU/GPU combinations which >> hopefully don't suffer from this issue.. I'll put a comment in but tbh >> there are lots of ways to mess up things with the current APIs.. >> >> Try allocating a snooped batchbuffer, or a snooped private back buffer >> or anything involved in a blit.... I'm going to add checks for some of >> the more stupid things in the Intel superioctl code... >> >> > Well i915 (and friends') snooped memory is, as you say not very useful, > but it works fine AFAICT for things like the flip move from VRAM (which > has been disabled ATM due to HW lock issues). Should also be fine for > readpixels and zero copy texturing, although I doubt that there is any > performance gain in the latter.
FWIW, zero copy texturing is a good win when the texture is used only once, eg for video. The streamingrect application (when it was working) showed a very good improvement with the cow-pbo hack (also when it was working). To make it work transparently is quite difficult & fragile though. Keith ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
