On Thu, Mar 30, 2017 at 1:38 PM, Lionel Landwerlin
wrote:
> On 30/03/17 20:09, Chris Wilson wrote:
>>
>> On Thu, Mar 30, 2017 at 11:27:26AM -0700, Matt Turner wrote:
>>>
>>> I think we should figure out how to make this not just a fork of
>>> intel_error_decode. Should intel_error_decode do away?
On 30/03/17 20:09, Chris Wilson wrote:
On Thu, Mar 30, 2017 at 11:27:26AM -0700, Matt Turner wrote:
I think we should figure out how to make this not just a fork of
intel_error_decode. Should intel_error_decode do away?
There are various tools in i-g-t that I'm definitely in favor of
moving int
On 30/03/17 19:27, Matt Turner wrote:
On Wed, Mar 29, 2017 at 1:07 PM, Lionel Landwerlin
wrote:
This is pretty much the same tool as what i-g-t has, only with a more
fancy decoding of the instructions/registers. It also doesn't support
anything before gen4.
Signed-off-by: Lionel Landwerlin
--
On Thu, Mar 30, 2017 at 11:27:26AM -0700, Matt Turner wrote:
> I think we should figure out how to make this not just a fork of
> intel_error_decode. Should intel_error_decode do away?
>
> There are various tools in i-g-t that I'm definitely in favor of
> moving into Mesa (like the assembler and d
On Wed, Mar 29, 2017 at 1:07 PM, Lionel Landwerlin
wrote:
> This is pretty much the same tool as what i-g-t has, only with a more
> fancy decoding of the instructions/registers. It also doesn't support
> anything before gen4.
>
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/Makefile.tools.
This is pretty much the same tool as what i-g-t has, only with a more
fancy decoding of the instructions/registers. It also doesn't support
anything before gen4.
Signed-off-by: Lionel Landwerlin
---
src/intel/Makefile.tools.am | 20 +-
src/intel/common/gen_decoder.c | 10
