Re: mapped cached memory and pre-fetching.
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. /Thomas Dave. - 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
Re: mapped cached memory and pre-fetching.
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
mapped cached memory and pre-fetching.
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. Anyway, I think they removed this behavior in later Athlon steppings, and I'm not sure there are processors doing this today but we should probably at least keep it in mind and perhaps add a comment at the flag define. /Thomas - 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
Re: mapped cached memory and pre-fetching.
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.. Dave. - 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
Re: mapped cached memory and pre-fetching.
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. /Thomas Dave. - 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
Re: mapped cached memory and pre-fetching.
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... Dave. - 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
