Re: [PATCH 09/17] drm/radeon: use common fence implementation for fences

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 22.07.2014 06:05, schrieb Dave Airlie:
On 9 July 2014 22:29, Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx> wrote:
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
---
  drivers/gpu/drm/radeon/radeon.h        |   15 +-
  drivers/gpu/drm/radeon/radeon_device.c |   60 ++++++++-
  drivers/gpu/drm/radeon/radeon_fence.c  |  223 ++++++++++++++++++++++++++------
  3 files changed, 248 insertions(+), 50 deletions(-)

 From what I can see this is still suffering from the problem that we
need to find a proper solution to,

My summary of the issues after talking to Jerome and Ben and
re-reading things is:

We really need to work out a better interface into the drivers to be
able to avoid random atomic entrypoints,

Which is exactly what I criticized from the very first beginning. Good to know that I'm not the only one thinking that this isn't such a good idea.

I'm sure you have some ideas and I think you really need to
investigate them to move this thing forward,
even it if means some issues with android sync pts.

Actually I think that TTMs fence interface already gave quite a good hint how it might look like. I can only guess that this won't fit with the Android stuff, otherwise I can't see a good reason why we didn't stick with that.

but none of the two major drivers seem to want the interface as-is so
something needs to give

My major question is why we need an atomic callback here at all, what
scenario does it cover?

Agree totally. As far as I can see all current uses of the interface are of the kind of waiting for a fence to signal.

No need for any callback from one driver into another, especially not in atomic context. If a driver needs such a functionality it should just start up a kernel thread and do it's waiting there.

This obviously shouldn't be an obstacle for pure hardware implementations where one driver signals a semaphore another driver is waiting for, or a high signal on an interrupt line directly wired between two chips. And I think this is a completely different topic and not necessarily part of the common fence interface we should currently focus on.

Christian.

Surely we can use a workqueue based callback to ask a driver to check
its signalling, is it really
that urgent?

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux