Re: [PATCH] drm/i915/vlv: Added write-enable pte bit support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> 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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux