[Intel-xe] [RFC PATCH 0/3] Xe dma fence handling on atomic commit

Maarten Lankhorst maarten.lankhorst at linux.intel.com
Wed Sep 27 12:35:00 UTC 2023


Hey,

On 2023-09-27 12:45, Hogander, Jouni wrote:
> On Wed, 2023-09-27 at 12:33 +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> When we wrote the original display support, we purposely decided on
>> not
>> adding i915_sw_fence support.
>>
>> In this case, I think a better approach would be to remove this code
>> from i915 as well, and end up with cleaner display code for both
>> drivers.
> 
> Yes, I agree eventually this would be the goal. I did some experiments
> here:
> 
> https://patchwork.freedesktop.org/patch/558982/?series=123898&rev=4
> 
> Which is replacing i915_sw_fence with same code I'm using for Xe driver
> in this patch set. The problem is GPU reset detection. I don't have
> currently good ideas how to tackle that without compromizing i915
> functionality in this scenario -> ended up doing this only for Xe to
> ensure this is not blocking upstreaming Xe. Would this be acceptable as
> temporary solution to be solved after upstreaming? Anyways what I'm
> doing in these patches is not really an i915_sw_fence revised, but
> using dma_fences.
In atomic, plane_state->fence is set for all fences, and that should be 
enough. I think creating a reservation object is a massive overkill,
and we should try to use the drm_atomic_helper_wait_for_fences if at all 
possible.

Cheers,
~Maarten


More information about the Intel-xe mailing list