On 8/24/2021 3:18 PM, Christian König wrote:
Am 24.08.21 um 14:39 schrieb Das, Nirmoy:
On 8/24/2021 2:07 PM, Christian König wrote:
Am 24.08.21 um 13:57 schrieb Das, Nirmoy:
Hi Christian,
On 8/24/2021 8:10 AM, Christian König wrote:
I haven't followed the previous discussion, but that look
Am 24.08.21 um 14:39 schrieb Das, Nirmoy:
On 8/24/2021 2:07 PM, Christian König wrote:
Am 24.08.21 um 13:57 schrieb Das, Nirmoy:
Hi Christian,
On 8/24/2021 8:10 AM, Christian König wrote:
I haven't followed the previous discussion, but that looks like
this change is based on a misunderstandi
On 8/24/2021 2:07 PM, Christian König wrote:
Am 24.08.21 um 13:57 schrieb Das, Nirmoy:
Hi Christian,
On 8/24/2021 8:10 AM, Christian König wrote:
I haven't followed the previous discussion, but that looks like this
change is based on a misunderstanding.
In previous discussion I sort of su
Am 24.08.21 um 13:57 schrieb Das, Nirmoy:
Hi Christian,
On 8/24/2021 8:10 AM, Christian König wrote:
I haven't followed the previous discussion, but that looks like this
change is based on a misunderstanding.
In previous discussion I sort of suggested to have new DRM prio as I
didn't see an
Hi Christian,
On 8/24/2021 8:10 AM, Christian König wrote:
I haven't followed the previous discussion, but that looks like this
change is based on a misunderstanding.
In previous discussion I sort of suggested to have new DRM prio as I
didn't see any other way to map priority provided by the
Am 24.08.21 um 11:45 schrieb Sharma, Shashank:
On 8/24/2021 2:25 PM, Christian König wrote:
Nope that are two completely different things.
The DRM_SCHED_PRIORITY_* exposes a functionality of the software
scheduler. E.g. we try to serve kernel queues first and if those are
empty we use high pr
On 8/24/2021 2:25 PM, Christian König wrote:
Nope that are two completely different things.
The DRM_SCHED_PRIORITY_* exposes a functionality of the software
scheduler. E.g. we try to serve kernel queues first and if those are
empty we use high priority etc
But that functionality is co
Nope that are two completely different things.
The DRM_SCHED_PRIORITY_* exposes a functionality of the software
scheduler. E.g. we try to serve kernel queues first and if those are
empty we use high priority etc
But that functionality is completely independent from the hardware
priority
Hi Christian,
I am a bit curious here.
I thought it would be a good idea to add a new SW priority level, so
that any other driver can also utilize this SW infrastructure.
So it could be like, if you have a HW which matches with SW priority
levels, directly map your HW queue to the SW priority
Adding a new priority level DRM_SCHED_PRIORITY_VERY_HIGH
Signed-off-by: Satyajit Sahu
---
include/drm/gpu_scheduler.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index d18af49fd009..d0e5e234da5f 100644
--- a/include/drm/gpu_schedu
I haven't followed the previous discussion, but that looks like this
change is based on a misunderstanding.
Those here are the software priorities used in the scheduler, but what
you are working on are the hardware priorities.
That are two completely different things which we shouldn't mix up
Adding a new priority level DRM_SCHED_PRIORITY_VERY_HIGH
Signed-off-by: Satyajit Sahu
---
include/drm/gpu_scheduler.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index d18af49fd009..d0e5e234da5f 100644
--- a/include/drm/gpu_schedu
12 matches
Mail list logo
