Re: [Intel-gfx] Reconfigurable OA queries
On 09/10/2019 09:40, Lionel Landwerlin wrote: On 09/10/2019 02:26, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-10-09 00:14:41) On 09/10/2019 00:40, Chris Wilson wrote: This is Lionel's work to enable OA for Vulkan, greatly bastardised on top of the struct_mutex removal. It claims to be doing the right thing... -Chris Thanks a lot of picking this up. I'm aware of an issue with patch 9 as I can see requests with perf queries being preempted. Looking into that, but not quite there yet. Outside of the masking issue where a later request on the same context will mask the nopreempt request, if that nopreempt flag is set on the last submitted request to ELSP[0], we will not allow that context to be preempted before we consider the request to be completed. Oh... interesting! You're right as usual. There are a few places where I could see that happen. We implement vkQueueWaitIdle by submitting an empty batch and waiting on the signaling of the fence. I can workaround this in Anv by flagging all execbuf with a perf config for as long as i915-perf is opened. I could also flag the request with nopreempt even with reconfiguration wasn't requested, but the perf stream is flagged with hold preemption for the given context, which is probably the right thing to do. Thanks a lot for pointing this out! -Lionel I think there is a dependency issue with patch 8. We also use cliprects_ptr for fences. Hmm, I was expecting the flag validation to be in the first patch to add extension parsing, but we are missing the test if both flags are set, reject the execbuf. If we start reusing it for extended parameters, we need to make fences the first extended param. Why? -Chris How do we pass a reconfigure of OA together with an array of fences? -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Reconfigurable OA queries
On 09/10/2019 09:50, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-10-09 07:40:54) On 09/10/2019 02:26, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-10-09 00:14:41) If we start reusing it for extended parameters, we need to make fences the first extended param. Why? How do we pass a reconfigure of OA together with an array of fences? They are independent extensions, you pass none, one or the other, or both. Without the fence extension you have to choose... I get your point, but that means the first patch that introduces the extension mechanism should be providing the means to supply the existing array (if it wants to remain a separate patch). -Chris Yeah, we should merge those 2 patches then. -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Reconfigurable OA queries
Quoting Lionel Landwerlin (2019-10-09 07:40:54) > On 09/10/2019 02:26, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2019-10-09 00:14:41) > >> If we start reusing it for extended parameters, we need to make fences > >> the first extended param. > > Why? > > > How do we pass a reconfigure of OA together with an array of fences? They are independent extensions, you pass none, one or the other, or both. Without the fence extension you have to choose... I get your point, but that means the first patch that introduces the extension mechanism should be providing the means to supply the existing array (if it wants to remain a separate patch). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Reconfigurable OA queries
On 09/10/2019 02:26, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-10-09 00:14:41) On 09/10/2019 00:40, Chris Wilson wrote: This is Lionel's work to enable OA for Vulkan, greatly bastardised on top of the struct_mutex removal. It claims to be doing the right thing... -Chris Thanks a lot of picking this up. I'm aware of an issue with patch 9 as I can see requests with perf queries being preempted. Looking into that, but not quite there yet. Outside of the masking issue where a later request on the same context will mask the nopreempt request, if that nopreempt flag is set on the last submitted request to ELSP[0], we will not allow that context to be preempted before we consider the request to be completed. Oh... interesting! I think there is a dependency issue with patch 8. We also use cliprects_ptr for fences. Hmm, I was expecting the flag validation to be in the first patch to add extension parsing, but we are missing the test if both flags are set, reject the execbuf. If we start reusing it for extended parameters, we need to make fences the first extended param. Why? -Chris How do we pass a reconfigure of OA together with an array of fences? -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Reconfigurable OA queries
On 09/10/2019 02:26, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-10-09 00:14:41) On 09/10/2019 00:40, Chris Wilson wrote: This is Lionel's work to enable OA for Vulkan, greatly bastardised on top of the struct_mutex removal. It claims to be doing the right thing... -Chris Thanks a lot of picking this up. I'm aware of an issue with patch 9 as I can see requests with perf queries being preempted. Looking into that, but not quite there yet. Outside of the masking issue where a later request on the same context will mask the nopreempt request, if that nopreempt flag is set on the last submitted request to ELSP[0], we will not allow that context to be preempted before we consider the request to be completed. Oh... interesting! I think there is a dependency issue with patch 8. We also use cliprects_ptr for fences. Hmm, I was expecting the flag validation to be in the first patch to add extension parsing, but we are missing the test if both flags are set, reject the execbuf. If we start reusing it for extended parameters, we need to make fences the first extended param. Why? -Chris How do we pass a reconfigure of OA together with an array of fences? -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Reconfigurable OA queries
Quoting Lionel Landwerlin (2019-10-09 00:14:41) > On 09/10/2019 00:40, Chris Wilson wrote: > > This is Lionel's work to enable OA for Vulkan, greatly bastardised on > > top of the struct_mutex removal. It claims to be doing the right > > thing... > > -Chris > > > > > Thanks a lot of picking this up. > > I'm aware of an issue with patch 9 as I can see requests with perf > queries being preempted. Looking into that, but not quite there yet. Outside of the masking issue where a later request on the same context will mask the nopreempt request, if that nopreempt flag is set on the last submitted request to ELSP[0], we will not allow that context to be preempted before we consider the request to be completed. > I think there is a dependency issue with patch 8. We also use > cliprects_ptr for fences. Hmm, I was expecting the flag validation to be in the first patch to add extension parsing, but we are missing the test if both flags are set, reject the execbuf. > If we start reusing it for extended parameters, we need to make fences > the first extended param. Why? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Reconfigurable OA queries
On 09/10/2019 00:40, Chris Wilson wrote: This is Lionel's work to enable OA for Vulkan, greatly bastardised on top of the struct_mutex removal. It claims to be doing the right thing... -Chris Thanks a lot of picking this up. I'm aware of an issue with patch 9 as I can see requests with perf queries being preempted. Looking into that, but not quite there yet. I think there is a dependency issue with patch 8. We also use cliprects_ptr for fences. If we start reusing it for extended parameters, we need to make fences the first extended param. -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Reconfigurable OA queries
This is Lionel's work to enable OA for Vulkan, greatly bastardised on top of the struct_mutex removal. It claims to be doing the right thing... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx