[Mesa-dev] [PATCH 02/13] i965: Keep track of whether LRI is allowed in the context struct.

[Francisco Jerez]

Chris Wilson <chris at chris-wilson.co.uk> writes:

> On Sun, Sep 06, 2015 at 07:48:40PM +0300, Francisco Jerez wrote:
>> Chris Wilson <chris at chris-wilson.co.uk> writes:
>> 
>> > On Sun, Sep 06, 2015 at 07:28:12PM +0300, Francisco Jerez wrote:
>> >> Chris Wilson <chris at chris-wilson.co.uk> writes:
>> >> 
>> >> > On Sun, Sep 06, 2015 at 06:12:40PM +0200, Francisco Jerez wrote:
>> >> >> This stores the result of can_do_pipelined_register_writes() in the
>> >> >> context struct so we can find out later whether LRI can be used to
>> >> >> program the L3 configuration.
>> >> >
>> >> > LRI are whitelisted by their register. To be generic you must explicitly
>> >> > test access to the register you want to modify.
>> >> > -Chris
>> >> >
>> >> AFAIK except for the chicken bits used to enable L3 atomics on HSW
>> >> (which is tested explicitly elsewhere, see PATCH 07), all other
>> >> registers written to are whitelisted since command parser revision 1 --
>> >> I don't think that any released kernel version had the command parser
>> >> enabled on Gen7 but any of the required registers blacklisted.
>> >
>> > At the moment you are not even checking that param. The test is written
>> > to be independent of knowledge of  cmdparser internals and by virtue a
>> > much stronger test. Use it to your advantage.
>> > -Chris
>> >
>> What advantage do you mean?
>
> Kernel indepencence:
>
>> If the test passes the command parser is
>> either enabled (in which case L3 programming will work) or there is no
>> actual hardware security (in which case L3 programming will work).  If
>> it fails the command parser is disabled and hardware security enabled
>> (in which case L3 programming will not work either).
>
> Exactly. Which is why I suggest writing the test in that manner.

I'm sure you had some specific practical advantage in mind?  Bashing the
rather sensitive L3 configuration registers to see if something sticks
is a hack with potential implications.  I'd prefer to avoid that unless
there is a reason why it could be useful.

> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150907/b5ce3ea2/attachment.sig>