From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Maximilian Luz <luzmaximilian@gmail.com>
Cc: Dorian Stoll <dorian.stoll@tmsp.io>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] Plans for i915 GuC Submission with regards to IPTS/ME
Date: Mon, 23 Dec 2019 10:55:30 -0800 [thread overview]
Message-ID: <bc31eaa3-c5ed-819f-a94a-1f7ca335ea86@intel.com> (raw)
In-Reply-To: <bc4e8a25-05b5-72fb-8ddd-2275b739f0a5@gmail.com>
On 12/18/19 10:01 AM, Maximilian Luz wrote:
> Hi,
>
> On 12/16/19 11:40 PM, Daniele Ceraolo Spurio wrote:
>> Hi,
>>
>> I can't comment on the ITPS side since I have never looked at that
>> side of things, but I can give you an overview of why we turned off
>> GuC submission and what are the short/medium term plans for it.
>
> By any chance, do you have any idea if it's possible/who we could ask to
> get some more information or some sort of documentation about the
> IPTS/ME/touch-controller interfaces? This could maybe allow us to find
> some sort of work-around not involving GuC.
>
Unfortunately I have no idea about the docs in this area since it is
outside the graphics core.
>> TL;DR: The GuC submission interface is changed enough that the code
>> you have is no longer applicable. We're now focused on implementing
>> support for the new interface to re-enable guc submission (gen12+),
>> which is a prerequisite for what you need. IMO any ITPS support on the
>> current tree will have to be postponed until then.
>>
>> The disabling of GuC submission was done because recent binaries
>> (v30+) introduced significant non-backward compatible changes in the
>> interface; given that GuC submission was still not an "official"
>> feature and that even more intrusive interface changes are coming with
>> the upcoming GuC v40+, we decided to just disable the feature for now
>> and wait for all the changes to land on the GuC side before adding
>> support back in. The plan is to re-enable support from either gen11 or
>> gen12, so the gen9 platform will not have it, at least initially. It
>> shouldn't bee too hard to add it in though since the great majority of
>> the code is shared on both the GuC and the i915 side, so I wouldn't
>> exclude us adding it in if there is demand for it.
>
> Thank you, this is quite helpful. As all devices that I know of using
> IPTS are gen9, GuC support for that generation would be great to have.
> In the mean-time however, I think we will have to try and figure out if
> we can find a work-around, maybe bypassing GuC somehow.
If you only care about gen9, a possible solution would be to
forward-port just the old GuC submission (instead of the whole i915)
from a know working kernel. It shouldn't be too bad since the GuC code
is relatively self-contained, but given the speed at which our
submission code evolves there might be issue in the interactions between
the old GuC code and the other parts of the submission flow.
>
> Just out of curiosity: Are the firmware-changes also done on Windows or
> is this purely Linux specific? Would be interesting to know if they have
> the same problem.
>
No idea about the details of what goes on on Windows. The firmware is
OS-agnostic, but they might be using a different version compared to us,
especially on older platforms.
Daniele
>> The v40 firmware includes an almost complete rework of the submission
>> interface, which is why, in preparation, we removed support from the
>> driver for the legacy structures that are no longer used; we're also
>> not going to use HW doorbells anymore and that's why those have been
>> removed as well. I've had a look at the code in your github tree and
>> most of the things you use are either gone from the interface or have
>> been significantly updated, so I don't think there is an easy way to
>> just port the patch to the new blobs and a significant rewrite is
>> probably going to be required. Re-enabling GuC submission on the new
>> interface, which is our current focus on the i915/GuC integration
>> side, is a prerequisite for that, so IMO unfortunately you'll have to
>> wait until the new interface support lands before any ITPS changes can
>> be considered.
>
> I suspected that we'll likely have to do a substantial re-write of the
> driver, but it's nice to have confirmation for that so we can at least
> plan a bit ahead.
>
> Thank you again,
> Maximilian
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-12-23 18:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-15 11:12 [Intel-gfx] Plans for i915 GuC Submission with regards to IPTS/ME Maximilian Luz
2019-12-16 22:40 ` Daniele Ceraolo Spurio
[not found] ` <bc4e8a25-05b5-72fb-8ddd-2275b739f0a5@gmail.com>
2019-12-23 18:55 ` Daniele Ceraolo Spurio [this message]
2019-12-28 12:24 ` Maximilian Luz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc31eaa3-c5ed-819f-a94a-1f7ca335ea86@intel.com \
--to=daniele.ceraolospurio@intel.com \
--cc=dorian.stoll@tmsp.io \
--cc=intel-gfx@lists.freedesktop.org \
--cc=luzmaximilian@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox