On 04/15/2014 03:50 PM, Kenneth Graunke wrote: > On 04/15/2014 10:08 AM, Mike Stroyan wrote: >> I would go farther than requiring the returned bo->size to be covered by >> backing pages. >> There really should be backing pages for every page mapped by >> drm_intel_gem_bo_map. >> No mapped addresses should be affecting memory outside of an object's >> backing pages. >> >> If tiling can result in access to unallocated memory it might even lead >> to corruption of data in pages >> used by different processes. That would break GL_ARB_robustness >> requirements. > > It shouldn't, now that proper PPGTT support has landed in the kernel - > only data belonging to a single process is mapped into its address > space. So, a process can accidentally read or trash other portions of > its own memory, but never any other memory. This seems acceptable, as > it's how things work with normal CPU programs.
It is fine... for now. GL_ARB_robust_buffer_access makes stronger guarantees about out-of-buffer accesses. Reads outside a buffer (e.g., accessing too large an array element for an array contained in a UBO) can only return data from elsewhere in the buffer or zero. WebGL implementers really want this. I don't think that's relevant here because the fences only apply to CPU access, yeah? > That said, with older kernels, where we had only Global GTT or the > aliasing PPGTT (using the PPGTT mechanism but storing the exact same > mappings at the GGTT), you could definitely see/stomp other people's > memory. Which is awful, and one reason we think PPGTT support is so > important. > > --Ken > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
