Folks, I understand that the normal method of debugging the GEM driver code is by use of various debug functions conditionally included if/when various WATCH manifests are defined.
So I set WATCH_COHERENCY for a port I am doing and that meant that i915_gem_object_check_coherency() got called...but that function gagged on me on an object...and after some looking, it appeared that I was checking the coherency of the frame buffer object. That doesn't appear to be a good idea as fence registers are set up to diddle the tiling setup for the frame buffer. And the kind of coherency check performed by i915_gem_object_check_coherency() is bound to fail for objects which have used the fence registers to set up tiling. The question is: is use of i915_gem_object_check_coherency() a bit too aggressive in the driver code? It seems to me we ask it to check coherency of areas of memory that are not "coherent" in the manner effectively defined by the tests in i915_gem_object_check_coherency() (for those who don't know, "coherence" as defined by this function is that a 32-bit read at offset "c" in CPU VM space (ie. Only through the CPU's MMU and NOT through BAR2) of an object results in the same value as a 32-bit read at the same offset when read through BAR2 of the graphics device...for each page whose coherence is tested, the first quarter of the page is read and compared through both the CPU's MMU and through BAR2). Or am I just plain Missing Something? Thanks. bob _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
