blob: 98d9ee166379518f6bceb8619241d22f5bb7a856 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
/*
* SPDX-License-Identifier: MIT
*
* Copyright © 2016 Intel Corporation
*/
#ifndef __I915_TIMELINE_TYPES_H__
#define __I915_TIMELINE_TYPES_H__
#include <linux/list.h>
#include <linux/kref.h>
#include <linux/mutex.h>
#include <linux/types.h>
#include "i915_active_types.h"
struct drm_i915_private;
struct i915_vma;
struct intel_timeline_cacheline;
struct i915_syncmap;
struct intel_timeline {
u64 fence_context;
u32 seqno;
struct mutex mutex; /* protects the flow of requests */
/*
* pin_count and active_count track essentially the same thing:
* How many requests are in flight or may be under construction.
*
* We need two distinct counters so that we can assign different
* lifetimes to the events for different use-cases. For example,
* we want to permanently keep the timeline pinned for the kernel
* context so that we can issue requests at any time without having
* to acquire space in the GGTT. However, we want to keep tracking
* the activity (to be able to detect when we become idle) along that
* permanently pinned timeline and so end up requiring two counters.
*
* Note that the active_count is protected by the intel_timeline.mutex,
* but the pin_count is protected by a combination of serialisation
* from the intel_context caller plus internal atomicity.
*/
atomic_t pin_count;
unsigned int active_count;
const u32 *hwsp_seqno;
struct i915_vma *hwsp_ggtt;
u32 hwsp_offset;
struct intel_timeline_cacheline *hwsp_cacheline;
bool has_initial_breadcrumb;
/**
* List of breadcrumbs associated with GPU requests currently
* outstanding.
*/
struct list_head requests;
/*
* Contains an RCU guarded pointer to the last request. No reference is
* held to the request, users must carefully acquire a reference to
* the request using i915_active_fence_get(), or manage the RCU
* protection themselves (cf the i915_active_fence API).
*/
struct i915_active_fence last_request;
/**
* We track the most recent seqno that we wait on in every context so
* that we only have to emit a new await and dependency on a more
* recent sync point. As the contexts may be executed out-of-order, we
* have to track each individually and can not rely on an absolute
* global_seqno. When we know that all tracked fences are completed
* (i.e. when the driver is idle), we know that the syncmap is
* redundant and we can discard it without loss of generality.
*/
struct i915_syncmap *sync;
struct list_head link;
struct intel_gt *gt;
struct kref kref;
struct rcu_head rcu;
};
#endif /* __I915_TIMELINE_TYPES_H__ */
|
