>> What happens when we GTT-mapped write a batchbuffer that had previously been silently made RO by the kernel? Does the CPU take a fault? We tested this particular case, doing the relocation inside the Batch buffer, which is mapped to GTT as read-only, from the exec-buffer path. On doing so, there were no faults observed on the CPU side. Also we don't see any ring hangs, when forcing the GPU to do a write access on the buffers marked as RO. Just the writes were getting rejected. Best Regards Akash -----Original Message----- From: Eric Anholt [mailto:eric@xxxxxxxxxx] Sent: Friday, February 07, 2014 3:11 AM To: Goel, Akash; intel-gfx@xxxxxxxxxxxxxxxxxxxxx Cc: Goel, Akash Subject: Re: [PATCH] drm/i915/vlv: Added write-enable pte bit support akash.goel@xxxxxxxxx writes: > From: Akash Goel <akash.goel@xxxxxxxxx> > > This adds support for using the write-enable bit in the GTT entry for VLV. > This is handled via a read-only flag in the GEM buffer object which is > then used to check if the write-enable bit has to be set or not when > writing the GTT entries. > Currently by default only the Batch buffer & Ring buffers are being > marked as read only. What happens when we GTT-mapped write a batchbuffer that had previously been silently made RO by the kernel? Does the CPU take a fault? _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
