On 02/08/16 15:16, Daniel Vetter wrote:
On Tue, Aug 02, 2016 at 11:10:46AM +0100, Dave Gordon wrote:
On 21/07/16 18:10, Dave Gordon wrote:
On 21/07/16 11:38, Tvrtko Ursulin wrote:
On 20/07/16 22:07, Rodrigo Vivi wrote:
please kill this _ucode variation that is just a alias to guc
instead....
Not sure, it was added with a particular goal. Cc Dave in case he wants
to comment.
Regards,
Tvrtko
The comment is already in the source code, just above the lines that
this patch changes.
.Dave.
Which is to say that,
+ having a GuC that can be used for command submission
+ having a GuC that requires firmware before use
are logically distinct properties, and are both subsets of
* having GuC hardware.
We can *imagine* products that might:
(1) have a GuC that requires firmware before use ...
(2) have a GuC with predefined but reloadable firmware ...
(3) have a GuC that contains a permanent firmware image ...
x
(a) ... which supports command submission but not SLPC
(b) ... which supports both command submission and SLPC
(c) ... which supports SLPC but not command submission
where all combinations are logically plausible, even though we only have
(1a) in today's devices. So we might as well make future development easier
rather than more difficult; it is always easier to make different things
equivalent than to separate identical things into different cases.
Let's please not add code for everything we can imagine. If there's a
product in the pipeline for which the above is true then sure, makes sense
(but needs one of the generic "needed for future platforms" notice in the
commit message). Otherwise I'll vote to nuke the difference.
-Daniel
I didn't say you had to *store* three different flags for these; for
now, they could all be the same flag. And they involve no "code" at all,
just one (or three) bit flags. But they *will* be distinguished at the
point-of-use by by having different MACRO names, even if they all alias
to the same bit. This helps the reader understand what property of the
GuC (or other h/w) is relevant to a particular bit of code, which will
become ever more important as more auxiliary processors are added and
more functions offloaded into them. Remember how much confusion has
previously been caused by, for example, conflating "nonprivileged
execution" with "private address space" or "ring of CS commands" with
"command dispatcher". So looking ahead a little and remembering that a
single blob of hardware may support multiple logically independent
functions can save a lot of work in the long run.
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
