1. Don't touch the preamble flag at all, just keep that handling as it is for
now.
2. Add the CONTEXT_CONTROL with the appropriate handling on context switch and
bump the version number to signal that this is done.
3. When #2 is upstream we hack on Mesa to drop the CONTEXT_CONTROL packets from
its IBs when it sees the new kernel version.
4. When we release SR-IOV we add some logic to the kernel driver to ignore the
preamble flag.
[ml]
Let's simplify the problem and don't involve SR-IOV currently, the object is
that:
A) We change dma frame to make it compatible with standard/documented scheme,
which is aligned with d3d and close OGL, and meanwhile
B) We keep current MESA still work.
For A), we need CONTEXT_CONTROL always inserted in ring buffer, because the
load_xxx of close OGL is dynamically skipped/kept by CONTEXT_CONTROL in ring
buffer.
So your #2 seems not correct, because if we only insert CONTEXT_CONTROL when
doing context switch, that means the load_xxx from CEIB/DEIB of close OGL is
always kept ( and only Preamble is skipped) even there is no context switch,
and this harms performance.
Since MESA use CONTEXT_CONTROL in IB, so the CONTEXT_CONTROL in ring buffer
will be replaced by MESA, that means kmd can always insert CONTEXT_CONTROL.
With above concerns, I think the step could follow below steps:
1. keep original preamble_flag logic: skip the preamble IB if no context switch
occurs, so that old MESA doesn't break.
Note: I remembered @Bas mentioned that even no context switch,
preamble IB should be kept because MESA rely on Preamble IB to do some L2
update like shader uniforms. I think that's wrong, because original
logic is we always skip Preamble IB when no context switch occurs.
2.always Insert CONTEXT_CONTROL before ALL IB in ring buffer, and this
CONTEXT_CONTROL skips load_xxx when no context switch ( keep load_xxx when
context switch), so the close OGL can gain performance and supported by kmd
with right logic.
Note: like I said, MESA shouldn't get trouble with #2 because current
MESA's CONTEXT_CONROL in IB will override the one of kmd.
3.Bump up KMS version to notify MESA that KMD already use CONTEXT_CONTROL, for
MESA we change it and let it not insert CONTEXT_CONTROL when talking with new
version KMS. Also Mesa should make Preamble CEIb, CEIB, DEIB behave the same
way as close OGL.
I think above steps can satisfy both current MESA an close OGL logic, as well
as new MESA logic.
after sr-iov get upstreamed, kmd can remove the logic of "skip Preamble IB when
no context switch".
What do you guys think
BR monk
-----Original Message-----
From: Christian König [mailto:[email protected]]
Sent: Tuesday, September 06, 2016 5:39 PM
To: Liu, Monk <[email protected]>; Koenig, Christian <[email protected]>;
Bas Nieuwenhuizen <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)
> 1) Is that my patch must work with current MESA driver ? (even MESA doesn't
> change any bit of its logic) ?
Yes and it must work with all old versions of Mesa. This is usual the tricky
part to get right and most of my concern right now.
> 2) is that my patch can let kmd go to a new path (using CONTEXT_CONTROL) with
> bump up the KMS version ?
No, not necessary. Bumping the KMS version can only be used to signal to Mesa
that it can use a new feature. E.g. Mesa can then stop to use CONTEXT_CONTROL
in it's IBs, but there isn't any guarantee that it does.
> 3) will MESA change its logic (align with close OGL driver) and bump up its
> version so that new version MESA can work with new version KMS/kmd?
No, usually Mesa is changed in a way so that it works with both old and new
kernel drivers. Only when there is a really good reason (usually critical bugs
in the kernel driver) Mesa will drop support for older kernel versions.
As I said in my internal mail let's do it like this:
1. Don't touch the preamble flag at all, just keep that handling as it is for
now.
2. Add the CONTEXT_CONTROL with the appropriate handling on context switch and
bump the version number to signal that this is done.
3. When #2 is upstream we hack on Mesa to drop the CONTEXT_CONTROL packets from
it's IBs when it sees the new kernel version.
4. When we release SR-IOV we add some logic to the kernel driver to ignore the
preamble flag.
Regards,
Christian.
Am 06.09.2016 um 11:28 schrieb Liu, Monk:
> Hi Bas & Christian
>
> I'm not familiar with the policy of upstream kernel driver, so I
> cannot say if your proposal is doable or not,
>
> I have questions:
>
> 1) Is that my patch must work with current MESA driver ? (even MESA doesn't
> change any bit of its logic) ?
> 2) is that my patch can let kmd go to a new path (using CONTEXT_CONTROL) with
> bump up the KMS version ?
> 3) will MESA change its logic (align with close OGL driver) and bump up its
> version so that new version MESA can work with new version KMS/kmd?
>
> With above question addressed, we can together discuss how to modify
> CONTEXT_CONTROL patch
>
> BR Monk
>
>
>
>
> -----Original Message-----
> From: Koenig, Christian
> Sent: Monday, September 05, 2016 7:57 PM
> To: Liu, Monk <[email protected]>
> Cc: brahma_hybrid_dev <[email protected]>
> Subject: Re: [PATCH] drm/amdgpu:implement CONTEXT_CONTROL (v3)
>
> Another possible solution which just came to my mind: Completely ignore the
> preamble flag on the IB on keep the existing preamble handling as it is.
>
> Just insert a CONTEXT_CONTROL package at the beginning of the command
> submission controlled by if we have seen a context switch or not and then
> raise the driver version number.
>
> Then we can fix Mesa to not emit the CONTEXT_CONTROL commands from the UMD
> any more and when SR-IOV comes out we add a handling to ignore the preamble
> flag in the kernel when it is activated.
>
> Does that sounds like it should work?
>
> Regards,
> Christian.
>
>
> _______________________________________________
> amd-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
